Live data from Hacker News

Ask HN: What did Linux not do right?

news.ycombinator.com

51–60 of 173 posts

Re: Ask HN: What did Linux not do right?

#51

Earlier quoted context omitted.

Before if you knew the standard unix-ey tools you could get by. For example, want to list services? Just use `ls /etc/init.d/`. Want to monitor a log file? Use something like `tail -f /var/log/whatever`. Want to see what filesystems are supposed to be mounter? Just opne /etc/fstab with your favorite text editor. Sure, it wasn't super consistent but you used the same tools as you always used, whether you're editing so…

> if you knew the standard unix-ey tools you could get by And if you know the standard systemd tools, you can get by with systemd. It's far from enigmatic, the docs are freely available. Yes, systemd does things differently from what you might be used to, but I don't see how that's an issue beyond having to surf the usual learning curve of a new tool. > how do I see what services are available under systemd? systemct…

> but I don't see how that's an issue beyond having to surf the usual learning curve of a new tool.

I responded to that in another post, but basically unix is a programming environment and when you start composing tools together you get a powerful solution for quickly throwing things together.

Re: Ask HN: What did Linux not do right?

#52
post #42

Earlier quoted context omitted.

Before if you knew the standard unix-ey tools you could get by. For example, want to list services? Just use `ls /etc/init.d/`. Want to monitor a log file? Use something like `tail -f /var/log/whatever`. Want to see what filesystems are supposed to be mounter? Just opne /etc/fstab with your favorite text editor. Sure, it wasn't super consistent but you used the same tools as you always used, whether you're editing so…

Except on big iron UNIXes that introduced such concepts years before it became such a big issue on Linux.

That's kind of the point, it often prioritizes large enterprise needs over the convenience of lone sysadmins. Binary logs are great if you're a large enterprise who is paying to have those logs ingested into an elasticsearch cluster, but less useful if you're not at that scale, as one example. Systemd has great support for complicated log collection daemons, but makes it more difficult to just rsync your logs to some other server.

Re: Ask HN: What did Linux not do right?

#53

Earlier quoted context omitted.

Sure, but like 5 open source drivers is better than one proprietary driver that works, so that math gets complicated pretty fast. For a while you could actually use windows USB wifi drivers (Ndiswrapper) under linux, but it turned out to be unnecessary eventually.

It's ironic that the Windows system of stable ABI is the reason NDISWrapper was feasible in the first place.

Not ironic, kind of the point. If we cared all that much in the linux world about a stable driver ABI we could literally just implement the windows one, like reactos did.

Re: Ask HN: What did Linux not do right?

#54

Earlier quoted context omitted.

A proprietary driver that works is better than an open-source one that doesn’t work or doesn’t even exist.

Sure, but like 5 open source drivers is better than one proprietary driver that works, so that math gets complicated pretty fast. For a while you could actually use windows USB wifi drivers (Ndiswrapper) under linux, but it turned out to be unnecessary eventually.

1 working proprietary driver is better than 5 half-assed open source drivers

Re: Ask HN: What did Linux not do right?

#55
post #43
post #36

Earlier quoted context omitted.

If that was the case, macOS and windows would own the server market because who would want to have a server that "freezes" under "heavy memory load". MacOS is virtually non-existent and Windows has a small share of the market and performs poorly comparison.

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 guessed as much but I stand by my statement… If there was a serious problem, we would know by now.

Re: Ask HN: What did Linux not do right?

#56
post #48
post #43

Earlier 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.

see also: https://lore.kernel.org/all/d9802b6a-949b-b327-c4a6-3dbca485... https://lore.kernel.org/all/20211130201652.2218636d@mail.inb...

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=macOS+

So? What’s the point here?

Re: Ask HN: What did Linux not do right?

#58

Earlier quoted context omitted.

Sure, but like 5 open source drivers is better than one proprietary driver that works, so that math gets complicated pretty fast. For a while you could actually use windows USB wifi drivers (Ndiswrapper) under linux, but it turned out to be unnecessary eventually.

1 working proprietary driver is better than 5 half-assed open source drivers

You see my thought is that a lot of proprietary drivers end up being half assed, and kernal code tends to be pretty good. Your mileage may vary though.

Re: Ask HN: What did Linux not do right?

#59
post #55
post #43

Earlier 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 guessed as much but I stand by my statement… If there was a serious problem, we would know by now.

We do know by now, which is why the LKML thread I linked is titled "the elephant in the room."

Re: Ask HN: What did Linux not do right?

#60
post #56
post #48

Earlier quoted context omitted.

see also: https://lore.kernel.org/all/d9802b6a-949b-b327-c4a6-3dbca485... https://lore.kernel.org/all/20211130201652.2218636d@mail.inb...

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=macOS+ So? What’s the point here?

I linked threads on LKML that are directly relevant to this subject, about how this (system becomes nonresponsive under memory pressure) is a real problem that people really experience, with a lot of people agreeing that it is a problem and suggesting various mitigations. Most of those ideas presuppose that memory pressure leads to stalls and are about figuring out how to detect when the system is stalled and making no progress and killing processes after it has gone on for a while (often with userspace daemons). I think MGLRU is maybe getting merged in linux 6.x and will hopefully help avoid the stalls.

you linked a list of all CVEs in macOS. I don't see how this is relevant at all.

Post reply on HN