What if your 10B investment encourages others to invest 50B and much of that makes it back to you indirectly via selling more of your core business?
I may be way off, but to me it seems like the AI bubble is largely a way to siphon money from institutional investors to the tech industry (and try to get away with it by proxying the investments) based on a volatile and unpredictable promise?
That’s a good way of putting it. Previously Serif’s goals were aligned with my wishes. They’d release a new version of the software ever so often and I’d pay to upgrade. Fair.
Now I’m suddenly a third-class user, as I’m neither an enterprise customer nor paying for their AI features. I can only cross my fingers and hope the product doesn’t follow its new incentives. That doesn’t feel like a great position to be as a hobbyist who appreciated and paid for everything they released previously.
It nuances ”leader” and ”manager” from something you are to descriptions of problem-solving toolkits when dealing with people.
In that sense it could be reconstructed as ”soft power mode” and ”hard power mode” where the former inspires confidence and encourages creativity and the latter emphasizes compliance and alignment. Any person in a position of power will utilize strategies that could be seen as signs of either mode depending on the situation.
Honestly I think people are just going to use whatever definitions are most convenient for them to make their point. That’s the problem with vague terms.
I’d suggest the GPL family without a CLA as an approximation of that intent.
> If it exists, what are the barriers to adoption? Why don't we all use it?
My theory is that people in general don’t care that much, or (particularly in the case of corporations) consider permissive licenses to be ”freer” than copyleft.
> But suppose we accept that the XDG specification only applies to some Unix operating systems, despite making no mention of this.
the very first paragraphs on specifications.freedesktop.org says this:
> Freedesktop.org is a project to work on interoperability and shared base technology for free-software desktop environments for the X Window System (X11) and Wayland on Linux and other Unix-like operating systems.
> We are not a formal standards body. The standards published on these pages are active or tentative (if marked as such) specifications which desktop environments may implement to improve mutual compatibility, share code and pool resources.
Deferring to XDG_CONFIG_HOME on MacOS if it exists makes a lot of sense as it conveys a clear intent from the user and the convention has grown popular. I’m not sure that the default ~/.config from the XDG specification is automatically better than ~/Library/Application Support by appeal to freedesktop.org’s authority.
And please don’t move configuration files around between releases without really being intentional about it.
Why should it not.
The easier case for me to defend is XDG_CACHE_HOME - if it defaults to ~/.Library/Caches then it makes life simpler on macOS as it means that you don't have to add other directories to be removed from your backups.
Doesn't matter. This whole situation is a mess, and it's still a mess in the year 2025. Clearly existing operating systems can't be changed significantly enough to change anything like this.
but we're all still afraid to write new operating systems. We cling to MacOS, FreeBSD, Linux, and Windows as if our lives depend on it. Our lives do not depend on it.
If we want a saner OS, we could have it, but we don't want it bad enough, I think. It's easier to just deal with the piles of horse manure that has been piled on top of everything. So we have a rather active bikeshed discussion on HN about whether or not to use XDG_*.
We want to bikeshed more than we want to fix anything. Like all communities, this one also disappoints me.
Of course, if you decide to account for Windows / macOS conventions, it’ll be a bit trickier, but pulling in a library for that is a bit overkill, yeah.
Adding a library has nothing to do with that. You can implement it yourself in a few lines of code, especially if you only need one path, like configs. You do need to research for caveats (e.g. check $XDG_CONFIG_HOME on Linux and not just put it into ~/.config) but it’s not rocket science.
And if you choose to just trust library authors, you are putting their ideas there instead. There’s that Rust crate that uses XDG on macOS, for example.
I’m concerned that AI slop will affect open source projects by tilting the already unfavorable maintainer-contributor balance even more towards low-quality contributions.
Daniel Stenberg (from the curl project) has blogged a bunch about AI slop seeping into vulnerability reports[1], and if the same happens to code contributions, documentation and so forth that can help turning a fun hobby project into something you dread maintaing.
When I checked a few years back, even a ”hello world” Go application compiled for Windows was flagged as malware by a malware scanner that I investigated.
I’m not at a computer where I could try that hypothesis right now, but back then my conclusion after testing various executables was that any unsigned Go binary would be flagged as a malware.
I don’t think hobby developers are the cause for concern here. To me, these steps should be taken for professionally developed services where there is a reasonable expectation of accessibility (in my mind this would roughly speaking be those that are either publicly funded or where the revenue is at least a million euros).
For smaller businesses and hobbyists it feels like expecting support for all major browsers would be discouraging in a negative way. I appreciate digital art even if it doesn’t work in my favorite browser and a shitty online menu for a food truck is better than none.
I don’t think the rebase is malicious. Would they even be allowed to continue distributing the older commits (where they claim an Apache license) or would that be to perpetuate the license violation?
I'm too jaded to pointlessly debate all the misunderstandings about copyright and licenses. Bottom line is, this case is clearly not going to court, so there's no entity allowing or not allowing them to do anything, the only thing that matters is does this act of hiding enrages the original author even more? My answer to that is yes. Plus that old commit is still there, accessible after a couple of rather obscure clicks, so it's not even taken down if you want to debate technicalities.
I think the assumption that the license.txt in a given revision is accurate an applicable is erroneous. One is expected to follow the license.txt in the main repo regardless of revision.
Absolutely not, if a project relicensed and someone on earth did a git clone with a previous license that gave some specific rights, the previous commits keep their license (or if the license was incorrect you can go to court)
I don't think a court is going to understand git revisions. I also don't think a person reverting to timepoint 1 with license A changes the fact that they received it at time point 2 offered under license B.
At best the license.txt that accompanies a particular revision can serve as a sign post of what license applies it is not dispositive and if the sign post is wrong it was your bad for failing to understand what license applied before distributing.
That seems quite harsh. Just because the designers aren’t perfect doesn’t mean the design is universally bad.
To address your example: Why were the arrow keys on those particular keys? Who put them there? hjkl are on the home row, and touch typists end up having the movement keys under their right hand’s resting fingers. That’s suddenly quite convenient.
> and touch typists end up having the movement keys under their right hand’s resting fingers.
This is false, h isn't in the resting place. So go back and spend more time trying to explain that historic tidbid of design before trying to defend it (I'd also be curious to know why they shifted left instead of using resting places)!
Or don't and use this obvious principle directly and change keybinds to jkl;
Or go with the muscle memory of inverted T and use ijkl
But whatever you do, prioritizing the original design is a common bad heuristic because there is no reason to think that the original designer was great (not perfect!, don't twist it), so trying to understand the original reasons is a waste of "productivity" time (but if you're curious, it's not a waste of regular time)
As pointed out, this is wrong. What touch-typists want is jkl;, because the right home key is j. This is an absolutely necessary config change in vanilla vim, unfortunately.
For me personally is the J/K direction still feels swapped and I always have to remind myself they are in fact the other way round. Even (especially) for touch typists, I would really expect [k] to point down and [j] up. In our writing system from the top left to bottom right my intuition would really be to stick ↑ with ← together and vice versa ↓ with →.
← ↓ ↑ →
makes a little sense to me.
← ↑ ↓ →
would be way better, IMO.
Not only because the most used used direction (↓) would be closer to my "neutral" finger position, but mainly because the the keys for progressing "back" and keys for progressing "forwards would be grouped together.
Honestly, I wouldn't even mind having them spread across two rows, like U I J K
↑ ↓
← →
or something. (Personally, I have global WASD-like arrow mapping bound to IJKL through capslock combo in AutoHotkey, since sometimes cursor keys are really inconveniently far away when typing.)
I think the current system is the way it is in order so that the most used direction (down) uses your strongest finger, the index finger.
I don't know what your mean by "Not only because the most used used direction (↓) would be closer to my "neutral" finger position" - what is your neutral finger position?
I also got lost in the sentence about "back" and "forwards" - what is back and forwards?
Sorry, I didn't realise that was unclear. By "back" and "forwards", I mean movement through the flow of text relative to the cursor position. Given any reference point in linear text, all surrounding content either precedes or follows that point. Moving through preceding content is "going back", and moving through following content is "going forwards". When we move to the preceding line (↑) or preceding character (←), we're going "back". When we move to the following line (↓) or following character (→), we're moving "forwards". My point was that ← ↓ ↑ → effectively represents "back one character — forward one line — back one line — forward one character", which feels counter-intuitive to me.
> strongest finger, the index finger.
Interesting. As far as I now, middle finger is usually considered stronger than the index finger. Index finger might be more dextrous, though (?). Personally, I also slightly prefer the middle finger for rapid pressing over the index finger, but cannot see strong definitive advantage of either one. (I guess most of us use the middle finger for regular ↑↓ keys, as well as W/S in WASD bindings in games/project just fine, and using index finger in that context instead would feel odd.)
> what is your neutral finger position?
Mostly index finger on "K". (So I guess I'd prefer having "down" (being the most frequently used when VIM binding is involved) on "L", where my middle finger usually dwells, and "K" for moving up, if I had to invent it from scratch.)
I like the bindings, because I move vertically more than I move, so I want my strongest (other than the thumb) there. And I move to the right more than I do to the left. So I don’t mind moving my finger to do the latter.
It may be different based for others based on hand anatomy, but at least for me the index finger is so much stronger than the little finger, that it feels more comfortable moving it one space to the left, especially on keyboards with heavy keys (like model M).
I will admit that I had never considered things like this (there's a couple of you making a similar point). It's a decent argument. Maybe I'll revert to the default and see if I can handle the change.
As a touch typist that learned decades before learning vi, with Emacs in the middle, I can definitively say your blanket statement is false. And as a recovering Emacs user, I can also say the little finger thing for a repetitive key is a dangerous proposition with real potential health drawbacks.
I may be way off, but to me it seems like the AI bubble is largely a way to siphon money from institutional investors to the tech industry (and try to get away with it by proxying the investments) based on a volatile and unpredictable promise?
reply