Hacker Newsnew | past | comments | ask | show | jobs | submit | colonwqbang's commentslogin

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?

https://en.wikipedia.org/wiki/XML_appliance

E.g.

https://www.serverwatch.com/hardware/power-up-xml-data-proce...


From your first link

> An XML appliance is a special-purpose network device used to secure, manage and mediate XML traffic.

Holy moly


At least arrays of numbers are naturally much closer to the hardware, we've definitely come a long way in that regard.

Exactly. Compared to microservices XML is a pretty minor problem.

Agreed. Also, Docker.

They can’t just undo it but they can challenge it in court.

But you are right, in a way the FTC is appealing their own decision [1]. US politics can be quite mad at times.

[1] https://www.ftc.gov/news-events/news/press-releases/2012/08/...


> "US politics can be quite mad at times."

No question about the truth of that statement.

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.


Project Runeberg seems to be still going after 30-odd years.


Project Runeberg is trying to be a nordic Project Gutenberg, not a nordic Standard Ebooks.


The point of an RW lock is that it supports multiple concurrent readers. Why is it weird to expect a non exclusive lock operation to be non exclusive?


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)

[1] https://learn.microsoft.com/en-us/azure/ai-services/openai/o...

[2] https://www.microsoft.com/en-us/microsoft-copilot/blog/2025/...

[3] https://x.com/yusuf_i_mehdi/status/1897783236354515420


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.


It's still nightly-only.


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.


All of those things are trivially true. What are you disagreeing with?


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.


"these programs are unrelated" ok, enough feeding the systemd troll. Good luck with all of whatever that is.


I thought the same thing. "Hazel" sounds like a play on words, a "Hazy Haskell"? Or is it because hazels and elms are trees.


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.


> I agree that keeping pets is probably immoral.

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.


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: