>> For example, kernel or compilers are very complicated in certain way, too, but whichever company makes those products probably is way more stringent about the quality comparing to other companies that are happy to move forward with tons of bugs and tech debts.
IMHO, the complexity of kernel and compilers is usually more justified and less accidental. At least non technical people are rarely the cause.
In my company it's a bit more complicated, but I have the spirit of your thoughts. I think business software (such as the ERP-like software I work on) is often an entropy magnet from the complexity point of view. It doesn't strive to be simple and elegant because business / finance world is messy. Whether all the complexity and messiness of the financial world is accidental or justified, this is irrelevant for me because I don't care about their business problems. It will be soul sucking anyway.
>> I feel like it depends on the task, and that's why people seem to disagree on this. Think about a manager managing 5 devs. If he is working on planning and managing work for his dev team, we don't say he is task switching, he's just taking a management role where he takes a high level view of the task at hand and then delegates the deep dive.
This is assuming you fully trust AI code. AI is still not perfect and sometimes might produce code with insufficient quality even when it works. For example, it can fix a bug in a wrong way, such as removing the symptoms instead of fixing the root cause. And so on. Also, I still have to review and test that generated code, especially in complex systems. Yes, AI reduces coding time, but at the expense of increasing the review / testing time, and review is not something all developers enjoy (both as reviewer and someone who is reviewed). This still doesn't seem to be something that has negligible cost of context switching. Also, AI tends to make you more lazy and care less about understanding the requirements. I'll prefer manual coding with some AI assistance for boring / repetitive tasks and finding potential mistakes for software that I care.
>> I’m clearly much more productive now. I’m doing five things at once very effectively, switching between multiple agent sessions from morning to night.
Yeah, same thoughts. And this industry is becoming so volatile, I'm not sure what will happen tomorrow. I mean it's highly unlikely that AI will replace developers at least in the next 10 years, but I'm not sure what will "software developer" become. Certain people love to work with details. If AI is taking away this joy, I'll rather retire as early as possible from this volatile industry.
Yes, that was my point. But Windows might still allocate pages lazily (i.e. reserve them and actually allocate only when the program writes into them). The difference from Linux is that it will only reserve if the allocation has a reasonable size and the total committed allocation doesn't exceed certain safe limits / quotas, so it will be possible to safely swap on disk later under low memory conditions.
But why wouldn't have happened with Rust? Sorry I can't find anything about Rust in the article. Or you mean if the Linux kernel was written in Rust and that stupid bool coercion was not possible?
As I understand, Windows can also lazily allocate pages, but it does after making sure the memory budget is adequate in a case of low physical RAM pressure and is guaranteed to be backed up by a page. But yeah, Linux approach is really sloppy.
I think Windows doesn't do OOM kill, it just fails fast for unreasonably large memory allocations. If the allocation is succeeds, the committed virtual pages are backed up (or more precisely guaranteed to be backed up) by a page file.
I think Windows also uses something similar to Linux memory overcommit (maybe call it "lazy page allocation"), but probably all the available virtual memory is backed by the page file, the OS has limit for the allocation size and all the edge cases are handled well under low memory conditions. For example, think about stack memory. Megabytes of stack space can be reserved for each thread, but since programs rarely use the whole stack, it's not rational to immediately allocate all the physical pages, it will waste a lot of memory (especially for multi-threaded programs). The stack grows on demand when the program hits a guard page.
In short, Windows partially does the same lazy thing but unlike Linux with its optimistic overcommit, it is stricter about commit/backing-budget reservation.
Well, they might still do it but less aggressively. For example, only when using MS Store or only some specific services. Apple uses a similar strategy with MacOS. Online accounts can also be convenient with with service integrations, provided they are optional. Also, I slightly disagree that average users don't care at all. Even setting aside ideological reasons, mandatory online accounts are terrible if there is no internet or the system must be preinstalled for another person (although the person who installs is not that average user). The system should be functional in offline mode.
>> Windows 11 requiring TPM, Secure Boot and being all react wasn't great.
For me a bigger concern is that Windows 11 requires MS account, and making harder and harder to bypass it. This is a disrespect for my freedom and privacy. The hardware is not the biggest issue because it might catch up eventually. https://waspdev.com/articles/2026-03-12/i-ll-probably-never-...
The source, conventions are quite similar to Linux. So, probably some level of POSIX compliance + reusing standard libraries (such as mlibc) helped a lot.
https://waspdev.com