Ask HN: What did Linux not do right?
121–130 of 173 posts
Re: Ask HN: What did Linux not do right?
#122Earlier quoted context omitted.
Windows freezes, too and if you are a heavy multitasker with a program that hogs memory and you are not carefully it can happen wow frequently
The old Windows Task Manager has code in it that killed other programs to be able to start so the user could kill more programs. I don't know if this feature still exists in modern versions since memory has increased so much but I always found it to be neat that some developers thought about this.
I've ended up in a couple of situations where servers are so hammered it takes five minutes just to get a ssh session up and running because some process took up all CPU/RAM and was barely able to do anything in the server itself. Something like that could maybe help.
Re: Ask HN: What did Linux not do right?
#123Earlier quoted context omitted.
If you call changing APIs every other major release of Windows, then sure. Having your drivers in tree allows the developer changing said API to update everything in tree that depends on said API which they are changing.
> If you call changing APIs every other major release of Windows, then sure. Yet here I am, on windows 10, using printer drivers designed and released for windows vista.
Re: Ask HN: What did Linux not do right?
#124Realtime audio. Audio interface makers don't even release Linux drivers. I wish the situation could improve so that I can use Linux for both work and music production.
As an example, the popular Focusrite Scarlett 3rd gen works on Linux with the only missing feature being toggling the physical buttons via software.
Audio interface drivers aside, the adoption of Pipewire seems to have made Linux a decent platform for audio production.
Re: Ask HN: What did Linux not do right?
#125Re: Ask HN: What did Linux not do right?
#126Printing & Bluetooth. It works mostly, until it fails without hints and is a mess to fix
Re: Ask HN: What did Linux not do right?
#1271. Fix process management ( lots of issues around spawning, FD inheritance, waiting for state change, hierarchy management, etc.) 2. Fix Linux's misinterpretation and broken implementation of fsync 3. Remote thread management (like CreateRemoteThread) 4. Get rid of the fundamentally-broken notion of SUID bits and grant privileges via control flow (instead of via data) 5. More handles/FDs, less IDs/paths/etc. 6. If in…
Re: Ask HN: What did Linux not do right?
#128How Linux freezes under high memory usage, Mac OS and Windows both handle such situations well without requiring a hard reboot.
Mac OS absolutely freezes too. It happened to me just a few days ago and I had to hard reboot.
Re: Ask HN: What did Linux not do right?
#129Earlier quoted context omitted.
by "freezes", 'deeter72 almost certainly means that the user interface becomes unresponsive, which is not relevant for servers. windows has policies that prioritize maintaining user interface and foreground app responsiveness.
I vaguely remember Solaris had a way to prioritise focused X Window application (IA) while keeping it within time-sharing (TS) scheduling class. Kernel thread for interactive applications in focused window would then have higher priority than background applications improving responsiveness. I am not sure what manipulated the priority, but I assume Xsun (X Window server) did it.
Re: Ask HN: What did Linux not do right?
#130Earlier quoted context omitted.
Disagree but not because of philosophical reasons like “I want to fix my driver and know what it is doing”, but actually practical reasons — tons of companies make a driver plus hardware and end up semi abandoning it.. but some people in the community with open source drivers will often fix it.. then after some time people end up realizing the way they fixed it is better than the original driver and now the companies…
On the topic of open-source vs closed-source drivers: Maintaining an open-source kernel driver is extremely complex and not user-friendly for the individual, so the complexity level is in practice similar to doing black-box reverse-engineering on a closed-source Windows driver, in both cases you need significant resources. If you need to have a team of experienced kernel developers to maintain a driver continuously,…
Just to be clear, if you mean kernel drivers I find this -very- difficult to believe.
There are linux kernel drivers I'd love to see die that will never die. If you're talking about 'downloads from some guys website', you may have a viable example but this is not the common case.
Code lasts -way- too long. For example the ISA BUS is still supported, aint no win10 drivers for ISA soundcards.