There have been many such cycles, but the XML hysteria of the 00s is the worst I can think of. It lasted a long time and the square peg XML was shoved into so many round holes.
IDK, the XML hysteria is similar by comparison to the dynamic and functional languages hysterias. And it pales in comparison to the micro services, SPA and the current AI hysterias.
IMHO it's pretty comparable, the difference is only in the magnitude of insanity. After all, the industry did crap out these hardware XML accelerators that were supposed to improve performance of doing massive amounts of XML transformations — is it not the GPU/TPU craze of today?
However, though the FTC approved the acquisition 10 years ago, the current FTC commissioners have evidently concluded that in the interim things have changed. Whether the court agrees with the FTC's logic remains to be seen.
It's fair to say that most people can't hit this bug, or rather, they can't hit the grave consequence (a deadlock). To deadlock you need to specifically need shared access when you asked for shared access. A lot of people have code where they want shared access for improved performance, but they don't need it. This bug makes their code a tiny bit slower in some edge cases (where it took the wrong lock), they're not overjoyed about the bug but it has no significant consequences.
Sure, microsoft isn’t going to foot the openai bill for every idiot with a pirated windows installation. I’m sure nobody is really surprised to hear that.
The fact that somebody at Microsoft saw fit to add AI integration for notepad.exe in the first place is … interesting. I guess it’s been a very dull time for the notepad product manager during the past 30 years so now they finally get their revenge on the world.
You're right about them not wanting to give away requests for free, but in fact they don't rely on OpenAI directly - thanks to the agreement Microsoft has with OpenAI they get model weights for all OpenAI models before OpenAI "achieves AGI", and Microsoft hosts all of these on their own Azure cloud [1].
Oh, and as a counterpoint, o3 mini is completely free and relatively unlimited (I don't know, probably there are actual usage limits) in Microsoft Copilot in chat. See the original announcement [2] and in the tweet [3] they mention that they "updated it" to o3 mini (high)
Can’t rust do safe simd? This is just vectorised multiplication and xor, but it gets labelled as unsafe. I imagine most code that wants to be fast would use simd to some extent.
This is anti-systemd FUD. Implying that applications which work without systemd are going to stop doing so. Suggesting that Linux distributions adopted systemd because it's good for distributors and not because users actually want it. We are "forced" to use systemd's udev implementation. Please.
There are extremely few use cases where your app may want to integrate with systemd. Out of those, you get again a small percentage that can't be trivially made optional. (99.9% is just optional notification and socket passing) Outside of large projects which are interested in full system integration like gnome, nobody breaks apps to not work without systemd.
Except none of these are true, they're just things people have made up to conceal the fact they oppose systemd for ideological reasons. There's little to no technical arguments against systemd - it's fast, much more robust than what came before it, and services 99% of usecases.
Users DID want systemd. Ask any sys admin, most much prefer systemd.
Also systemd doesn't "force" anything. Most distributions don't even ship all systemd projects, just a couple.
systemd-init IS small. The idea that systemd is a big ole monolith is just not true, and one glance at the git repo reveals that.
oh definitely not, and it's a matter of record. Red Hat and Poettering wanted systemd in order to control more of the platform; this is why they absorbed in udev (which had been a separate repo), came out saying that there are certain parts of the system that, despite all this being open source, were forbidden to modify or replicate, and stacked the debian voting. Systemd at the time sucked, incredibly, even worse than it does today, and routinely bricked or crashed systems. The adoption was forced and 100% political.
systemd is, of course,today a continuing shambling feature factory behemoth in which hundreds of product managers try to shoehorn in more mandatory features in order to cement grip on the platform. That's why you get this ridiculous dns nonsense, this ridiculous container nonsense, this ridiculous cron nonsense, hostnamed (!), the list is endless.
The technical argument is that it's a giant tasteless bag of ever increasing poorly implemented scope. The rest of Unix, by comparison, is generally not that way. If you pick up a BSD or even an alpine, you'll find that you don't need a bunch of badly written, hacked together garbage in order to get your work done. The system can be entirely readable and repeatable without cramming a bunch of cruft and poor decisions into pid 1.
The idea that systemd doesn't 'force' anything is, of course, hilarious. Systemd is designed to try to be the ultimate mandatory dependency for essentially everything on the system. That's the way Red Hat wanted it to be, and that's the way it is.
Every time someone mentions systemd, some random apologist dutifully trots out the idea that systemd-init is small and therefore systemd is not a monolith, checkmate. Of course, journald, libudev, localed, logind, hostnamed, homed, networkd, resolevd, systemd-boot, systemd-bsod, systemd-nspawn, timedated, timesyncd, tmpfiles, udevd, and all of the other array of dumbass bolted-on second-system-effect-driven product-managed nonsense somehow don't get mentioned.
> Red Hat and Poettering wanted systemd in order to control more of the platform
Speculative and ideological. From a technical perspective, I don't care about this.
> despite all this being open source, were forbidden to modify or replicate
This isn't true - you're allowed to modify or replicate any parts of systemd and always have been.
> systemd is, of course,today a continuing shambling feature factory behemoth in which hundreds of product managers try to shoehorn in more mandatory features in order to cement grip on the platform
I'm not sure you understand what systemd is.
systemd is not a piece of software, systemd is an endeavor. Many, many projects are under "systemd", as in they have the name, but they are all individual binaries. Practically 0 distros include all systemd binaries, because they're optional. Many projects already existed before systemd, like gummi boot, and were just given the name.
> The rest of Unix, by comparison, is generally not that way
This is untrue, as systemd follows unix principles. systemd-init does one thing and one thing only - it's only the init system. systemd-networkd is just the network daemon. systemd-journald is just the logger. And on and on. Despite what you may think, they ARE optional, and distros mix and match constantly.
> without cramming a bunch of cruft and poor decisions into pid 1
Again, out of the dozens and dozens of binaries under the systemd umbrella, only one (1) runs under PID 1. This simply isn't true.
> Systemd is designed to try to be the ultimate mandatory dependency for essentially everything on the system. That's the way Red Hat wanted it to be, and that's the way it is
Speculation, ideological, and not evidence backed.
> Of course, journald, libudev, localed, logind, hostnamed, homed, networkd, resolevd, systemd-boot, systemd-bsod, systemd-nspawn, timedated, timesyncd, tmpfiles, udevd, and all of the other array of dumbass bolted-on second-system-effect-driven product-managed nonsense somehow don't get mentioned
Yeah... because those are separate programs. Maybe you just don't understand how computers work, but these programs are unrelated. They talk over IPC, they're not even linked together on any systems. You can take or leave any of them, and many distros do. Even Debian, the supposed systemd cocksucker, doesn't include half of these.
A relatively generous interpretation is that they want to keep down the price of the entry model. They make their own silicon now, only three different sizes so it's not viable to differentiate on compute power. The easy way out is to put too little storage and memory in the base model and make customers pay through the nose for more storage and memory.
I agree that keeping pets is probably immoral. But even if we accept that, there are multiple problems.
- There may not be much of a "wild" left to release animals into.
- Some animals have been bred for hundreds of generations and are now dependent on humans.
- Who has the right to speak for these animals? How do they divine what their client wants? It's not reasonable that any person on the street can bring a motion of habeas corpus on behalf of your dog.
Watching the foxes and squirrels that live near humans has suggested to me that domestication is two-way. The animals want what we have: spare food, shelter. Some of them are brave and willing enough to interact with us, some aren’t. Over time, more of them become brave and willing enough to interact.
Anyone that considers a cat their pet will observe that cats are mainly in it for themselves. They (try to) go out when they want, they’ll make it clear when they’re not in the mood for attention. They spend hours each day ignoring us whilst making use of the shelter we provide. They’ve been known to leave their humans and return to their familiar territories when their humans move house.
I don’t think pet “ownership” is inherently immoral, but some people’s implementations of it, and the terminology, probably are.
reply