[HN Gopher] Ask HN: What did Linux not do right?
___________________________________________________________________
Ask HN: What did Linux not do right?
Or, if you have enough funding to write a new kernel, what would
you do differently?
Author : nhgiang
Score : 22 points
Date : 2022-10-01 16:48 UTC (6 hours ago)
| TillE wrote:
| If you were starting a project like that today, it'd probably be
| a capability-based microkernel written in Rust.
| vlmutolo wrote:
| You probably already know this, but "a capability-based
| microkernel written in Rust" describes RedoxOS.
|
| http://redox-os.org/
| saltcured wrote:
| A project like what, exactly? Linux wasn't some high-minded
| academic project that would pick off a menu of contemporary
| systems research or software engineering goals.
|
| The early Linux project was a punk concept of its era. Linus
| very clearly started out as wanting to make a Unix-like kernel
| on commodity x86 PCs of the time. It was a personal,
| workstation hack for motivated tinkerers. Things like server
| and supercomputer usage were not imagined yet.
|
| I'm not even sure what a moral equivalent project idea might
| look like today. It was a typical hacker blend of wanting to
| emulate something that was scarce/expensive using less
| expensive resources. Today, the smartphone might be the
| equivalent commodity platform. Both iOS and Android might be
| equivalent to the MS/DOS+Windows hegemony. But there isn't any
| equivalent of the balkanized and expensive Unix vendor market
| for phones, which technical students might aspire to. Linux
| didn't set out to rewrite the popular commercial OSs of the day
| from Apple and Microsoft.
| Ekaros wrote:
| Unix style command line where "everything" is text...
| nhgiang wrote:
| I thought that was a good idea? Why isn't it so? What should be
| the alternative?
| klysm wrote:
| Having some structure like power shell would be really nice.
| pajko wrote:
| Try this: https://fishshell.com/
| thesnide wrote:
| Printing & Bluetooth.
|
| It works mostly, until it fails without hints and is a mess to
| fix
| rektide wrote:
| I dont think Linux did wrong, but, were we to fund new kernels,
| distributed capabilities (likely via object capabilities) would
| be great. Thats a huge subject, with many avenues, but a kernel
| as an isolated thing seems like a less ambitious core than what
| we could be doing.
|
| Controversial, but I'd probably take QUIC or http3 & try to build
| distributed capabilities on that. Having fast QUIC in kernel, &
| available to userspace would be very much "heading towards where
| the puck is going".
|
| It's notable how bad Linux async i/o & others had been. Uring
| (its much more than io_uring these days) has totslly rewritten
| the rules, has been a giant leap into modernity. But it's so new!
| Leaning into uring style completeable syscalls would be
| essential.
|
| eBPF has shown that programmability of the kernel space opens
| hella doors. Trying amplify this winning wpuld be great.
|
| The past 10 years have really seen Linux grow all kinds of fast
| excellent capabilities, griw into itself. The above uring & ebpf
| examples are high examples of this. DMA-BUF has gone from up-and-
| comer to become _the_ core win for much of the kernel, for how
| desktops & media processing are fast & good & flexible. It'll be
| interesting to see, but I have a hard time imagining more big
| boom events that push us way forward again continuing.
| jazzyjackson wrote:
| whenever I try to install software on linux I inevitably end up
| googling errors to find out what dependencies I'm missing.
| Install failed because i'm missing "python.h" header for some C
| dependency, let me make sure python-dev is there, okay how about
| libffi-dev, apt install gcc-arm* fixed it for this rando on
| stackoverflow? okay now the installation fails in a different
| way, wait a minute does this python library expect rust is
| already installed? wtf?
|
| people complain about NPM but at least the dependency resolution
| works
| 6ue7nNMEEbHcM wrote:
| There used to be something like apt-build which downloaded
| sources of whatever you need using your distros source
| repositories. I don't know if i remember the name right. I
| don't think this is related with Linux only, but more cpp oss
| dev problem.
| marginalia_nu wrote:
| Tooling for webcams is very lackluster.
| yummypaint wrote:
| I think the linux dev community and foss developers in general
| could be much more aggressive about going after government grant
| money. Open source software is used in everything from biomedical
| research to fundamental science, to industry, to defense.
| Somehow, these key shared resources are still run on a budget
| that's barely a rounding error by comparison.
|
| I know writing grant proposals sucks and everyone wants to be
| having fun developing software, but if you pull in enough money
| initially you can pay people to write more grants and make things
| self sustaining in terms of funding. For how essential linux is
| to modern society there should be more paid people working on it
| full time.
| h2odragon wrote:
| Once it becomes "about money" that controls the enterprise,
| even when it was originally about software. Sure there's some
| projects that avoided that but its a tar pit and I can't fault
| anyone for avoiding it.
| comfypotato wrote:
| Is it, though? I find a lot of security in the knowledge that
| Ubuntu has a self-sustaining financial model. It's still
| close enough to the original love of software that Linus
| strongly approves. I really enjoyed your parent comment's
| take on grant-writing. I do, however, expect that this is
| already taking place in the appropriate areas of Linux
| development more than is commonly realized.
| favourable wrote:
| Not Linux, but Systemd[0] makes many people angry. Entire distros
| have purposefully not included it. Look at Devuan[1]
|
| [0] https://en.m.wikipedia.org/wiki/Systemd
|
| [1] https://www.devuan.org/
| wkdneidbwf wrote:
| people that are militantly anti-systemd confuse me greatly. the
| different and inconsistent init systems that preceded it were a
| nightmare.
|
| it led to a whole ecosystem of secondary system to manage apps,
| god, runit, monit, supervisord, etc.
|
| now i can just write a simple configuration file and have my
| app managed. i can describe network filesystem mounts as
| dependencies. blah blah.
|
| systemd made all of this trivial.
| traverseda wrote:
| 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 source code or whatever. You had one very flexible
| toolbox that you had to remember the options on.
|
| So as an example, how do I see what services are available
| under systemd? How can I reliable see what file systems are
| supposed to be mounted at boot? The answer to both of those
| tends to be "systemd spreads it's files and configuration all
| around the filesystem to you need to learn some bespoke
| systemd command that you'll only ever use for systemd".
|
| And while those previous init systems were inconsistent
| projects like openrc demonstrate that it's possible to
| accomplish systemd's goals, greatly simplify that init system
| mess, without breaking principles like locality of behavior
| or "everything is a file", and to keep it compatible with
| things like grep and tail and all that.
| 10000truths wrote:
| > 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?
| systemctl list-units --type=service
|
| > How can I reliable see what file systems are supposed to
| be mounted at boot?
|
| You can still use /etc/fstab, systemd will parse it at boot
| time. For mount units, you can use:
| systemctl list-unit-files --type=mount
|
| > The answer to both of those tends to be "systemd spreads
| it's files and configuration all around the filesystem to
| you need to learn some bespoke systemd command that you'll
| only ever use for systemd" /etc/systemd or
| /usr/lib/systemd for global stuff
| $HOME/.config/systemd for per-user stuff
|
| That's pretty much it for unit files.
| traverseda wrote:
| > 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.
| pramsky wrote:
| >> For example, want to list services? Just use `ls
| /etc/init.d/`
|
| You can do systemctl list-unit-files
|
| If you want to see the enabled services, then add
| --state=enabled , for disable --state=disabled. You can
| grep for those words as well.
|
| >> Want to monitor a log file? Use something like `tail -f
| /var/log/whatever`
|
| You can still do that.
|
| With systemd, You can use journalctl to tail the log file
| by journalctl -u <unit> -f , so something like journalctl
| -u postfix -f
|
| You can use journalctl to search for logs in a specified
| time period journalctl -u postfix --since "2022-09-30
| 15:10:00" --until "2022-10-01 02:00:00"
|
| Want to see a log for a specific boot ?
|
| journalctl --list-boots journalctl -b <boot id from the
| previous command>
|
| You can view more about journalctl at
| https://linuxhandbook.com/journalctl-command/
|
| >> How can I reliable see what file systems are supposed to
| be mounted at boot?
|
| I still use fstab for this.
|
| >> Sure, it wasn't super consistent but you used the same
| tools as you always used to.
|
| You can still use most of the same tools. I use
| tail,grep,awk like I used to, but I like the fact that with
| systemd I get a system configuration layer (which includes
| the init system) rather than having different tools in each
| distro.
|
| Do you prefer the old init system because it is something
| you are used to (and do not want to change) or do you have
| specific instances where systemd is broken for you ?
| traverseda wrote:
| >>You can do systemctl list-unit-files
|
| Sure, but how is that an improvement over locality-of-
| behavior and having unit files in easily known locations?
| Here's a rough list of places you can find unit files:
| #Places you can find systemd unit files
| /etc/systemd/system/* /run/systemd/system/*
| /lib/systemd/system/* ...
| $XDG_CONFIG_HOME/systemd/user/*
| $HOME/.config/systemd/user/* /etc/systemd/user/*
| $XDG_RUNTIME_DIR/systemd/user/*
| /run/systemd/user/* $XDG_DATA_HOME/systemd/user/*
| $HOME/.local/share/systemd/user/*
| /usr/lib/systemd/user/*
|
| Now if you simplified that list you wouldn't _need_ to
| learn a new tool and either memorize or look up a bunch
| of arguments. You could just have a sane directory
| structure and use some path globing.
|
| With a bit more work (or possibly just a different
| balancing of priorities, with more care taken to locality
| of behavior) I think you wouldn't _need_ some other tool.
|
| I think you're really missing the point here, unix (the
| philosophy, not the implementation) is a programming
| environment. Yes, systemd has created tools to let you do
| most of the things you used to be able to do using
| standard tools, but there's a big difference between
| having a tool box and having a program feature.
|
| A more complicated example, inotifyd is very useful, how
| could I go about triggering a script every time a log
| file is written to under systemd? When you start looking
| at these tools as part of a cohesive programming
| environment than you start to see systemd as full of
| edge-cases you have to account for. Lets say I want to
| count how many times a particular event appears in a log
| (quickly and easily, this isn't production) and send it
| to my cellphone. In unix-philosophy I can add something
| like this to my inotifyd-tab, `grep "some-event" | wc -l
| | pushbullet --push my stream`. How could I do something
| like that in systemd-land?
|
| >Do you prefer the old init system because it is
| something you are used to (and do not want to change) or
| do you have specific instances where systemd is broken
| for you ?
|
| I can see you're already dismissing the "unix philosophy"
| complaint, and really that is where I'd like to focus.
| Systemd will keep getting better in most cases, so that
| fact that I've had frustrations with it in the past isn't
| really a big deal. I'd be willing to deal with that if it
| was actually, you know, better than something like
| openrc.
|
| But since you've asked, here's a non-exhaustive list of
| points that I've been frustrated enough to actually
| document them. I imagine a lot of them have been fixed by
| now.
|
| Years ago I wanted to run debian on a kobo ereader.
| Unfortunately the built-in OS image was not running
| systemd, and the kernal was several revisions out of
| date. While I had no problem getting a debian chroot
| running, all of the services were designed to run under
| systemd, this made the whole project much more of a pain
| in the ass than it should have been.
|
| By default systemd will kill long-running processes when
| I log out. Processes like screen or tmux. This has since
| been resolved, presumably by my distro somewhere, but
| took a solid while to figure out when that behavior
| suddenly changed.
|
| When troubleshooting a raid array using a mipsel
| processor, I had persistent network issues. I took the
| boot media out for trouble shooting, but when I
| ~~chrooted~~ systemd-nspawned into the host to try to
| address the problem, I discovered that journalctl would
| segault. Thankfully /var/log still had all the entries I
| needed to fix the problem and binary logging wasn't
| enabled, or that would have been a much bigger problem.
| This appeared to be a general issue with running
| journalctl using qemu-static and binfmt.
|
| For some reason my mother's computer can no longer
| resolve DNS. Ripping out systemd-resolved seemes to have
| fixed it, but not before I lost a few more hours.
| pjmlp wrote:
| Except on big iron UNIXes that introduced such concepts
| years before it became such a big issue on Linux.
| traverseda wrote:
| 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.
| boundchecked wrote:
| >Not Linux, but Systemd
|
| Or maybe it is Linux's choice to not build an official default
| init system like BSDs that led to all the drama.
| thom_ wrote:
| The desktop experience is still a mess. They've become complacent
| with 'it works out of the box' but that's not the bar. Apple sets
| the bar and there's no prize for second place. You're on Apple or
| Linux or brain damaged and using Windows, but nobodies using two
| as their primary driver, and so one ecosystem dominates. I'm glad
| it's Apple because the GNU crowd are virtue signalers first and
| software developers second. For all their yapping the linux
| desktop speaks for itself
| peanut_worm wrote:
| If you think Apple sets the bar for desktop computers you are
| as brain damaged as a windows user
| wil421 wrote:
| Linux can't even do a "smooth" trackpad experience. Not to
| mention HiDPI monitors didn't work last time I tried.
|
| I use Linux when I specifically do not want a desktop. A
| headless server.
| nvr219 wrote:
| I use MATE as my daily driver and macOS for work. MATE
| multimonitor support is so much better that I'd rather stick
| with that and deal with the other stuff where it's not as good
| as macOS.
|
| See this about the multi monitor stuff on macOS:
| https://news.ycombinator.com/item?id=31361974
| heurisko wrote:
| > The desktop experience is still a mess.
|
| The closest I have seen to creating a good experience was
| Ubuntu Unity.
|
| I noticed it being used in universities, and in the office I
| used to work at.
|
| I'm disappointed that the Unity project wasn't taken forward,
| and it seems to me that Gnome just reimplemented it, but missed
| many best parts of the original.
| thom_ wrote:
| The 2d desktop is over anyway. Tomorrows desktop is 3d AR
| einherjae wrote:
| Right, with cold fusion powered jet packs as well i
| presume?
| heurisko wrote:
| I get motion sickness from headsets, so that will involve
| vomit all over my work area, constantly.
| anta40 wrote:
| Could you explain more about about the "messy desktop
| experience"?
|
| Many years ago, around 2006-2008, my PC exclusively ran
| Slackware after saying goodbye to XP. It wasn't really beefy,
| so I installed FVWM. I could do all the university assignments
| on it. Internet browsing, multimedia, USB plug n play, printing
| etc etc worked fine. Guess my use cases were kinda
| minimalistic.
|
| These days I mostly work on Mac, but still have a headless
| Linux PC running for personal tinkering. Probably I need to
| have another taste of Linux desktop experience :D
| Nextgrid wrote:
| The concept of device drivers being within the kernel is a
| terrible idea. It should instead offer a _stable_ ABI for drivers
| to be external and (within reason) be independent of the kernel
| version.
| 6ue7nNMEEbHcM wrote:
| This, a thousand times. But apparently it's much more difficult
| than it seems.
| metaltyphoon wrote:
| Isn't this what windows does?
| simfree wrote:
| 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.
| gkbrk wrote:
| This is exactly why on Windows open source drivers are a
| rounding error while on Linux open-source drivers are the norm.
| Nextgrid wrote:
| A proprietary driver that works is better than an open-source
| one that doesn't work or doesn't even exist.
| xt00 wrote:
| 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 actually benefit from that new
| driver. So you end up with a win win for people and
| companies. So in general closed source drivers end up
| sucking compared to open source drivers except for very
| rare situations.. and even after massive battles with say
| nvidia they are starting to realize they will end up
| benefiting from working with the open source community
| rather than against them..
| Nextgrid wrote:
| 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, that same
| team will be able to reverse-engineer & reimplement the
| closed-source driver just as well should it become
| necessary.
|
| On the topic of lack of stable ABI under Linux, I find
| that closed-source _Windows_ drivers have a much longer
| shelf-life than their Linux equivalents, so in practice I
| feel like the downside of drivers being closed-source in
| Windows is less of a problem because in practice you 're
| less likely to have to modify it.
|
| Distributing drivers is also a massive difference between
| the two models. With Windows, if someone builds a driver,
| that binary can be installed by any Windows user on a
| modern kernel (depending on what "level" of the ABI
| they're building against, the same driver can work all
| the way back to Windows 7). Once built, any Windows user
| can just install the binary, where as with Linux the
| built binary will only work for that very specific kernel
| version. The user-experience is definitely much better.
| traverseda wrote:
| 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.
| TheLoafOfBread wrote:
| 1 working proprietary driver is better than 5 half-assed
| open source drivers
| traverseda wrote:
| 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.
| TheLoafOfBread wrote:
| Making any changes in a code of a driver without driven
| device is a recipe for a disaster. You have no way how to
| verify that change you made did not affected
| functionality of the device.
| Nextgrid wrote:
| It's ironic that the Windows system of stable ABI is the
| reason NDISWrapper was feasible in the first place.
| traverseda wrote:
| 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.
| suprjami wrote:
| No it isn't. That thing breaks or doesn't update to a new
| API and suddenly you're screwed.
| deeter72 wrote:
| How Linux freezes under high memory usage, Mac OS and Windows
| both handle such situations well without requiring a hard reboot.
| atmosx wrote:
| 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.
| rrss wrote:
| 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.
| atmosx wrote:
| I guessed as much but I stand by my statement... If there
| was a serious problem, we would know by now.
| rrss wrote:
| We do know by now, which is why the LKML thread I linked
| is titled "the elephant in the room."
| rrss wrote:
| see also:
|
| https://lore.kernel.org/all/d9802b6a-949b-b327-c4a6-3dbca48
| 5...
|
| https://lore.kernel.org/all/20211130201652.2218636d@mail.in
| b...
| atmosx wrote:
| https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=macOS+
|
| So? What's the point here?
| rrss wrote:
| 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.
| metaltyphoon wrote:
| Systemd should've been a thing since the start.
| johndoe0815 wrote:
| I think one of the problems was to provide only the kernel and
| leave implementing the userland to people building different
| distributions. This has led to an incredible amount of
| replication of work, inconsistencies and incompatibilities and
| IMHO was one of the reasons Linux on the desktop never caught on.
| atmosx wrote:
| Messed the desktop experience. The level of main desktops (KDE,
| Gnome) compared to macOS / Windows experience is poor to the
| extend that I'm not sure why we have the level of fragmentation
| we do.
|
| On the other hand, window managers under linux are freaking
| awesome (no pun intended).
| pjmlp wrote:
| Not gather along one distribution with what it means to be Linux,
| just like every other OS.
|
| Every disagreement leads to a new snowflake distribution,
| fragmenting the community.
|
| Hence why the Year of Desktop Linux ended up being taken by a
| browser, a managed language runtime and running inside of VMs.
| jzwinck wrote:
| Disk I/O. It's basically all blocking except the fairly recent
| io_uring which is much more than disk I/O and perhaps a bit
| daunting for "I want to write some data without starving my main
| thread." I wish you could use select() and poll() on regular
| files on disk, like you can for almost all other file
| descriptors.
| viraptor wrote:
| Why not spawn a thread for disk io? It's a common pattern and
| frees up your main thread.
___________________________________________________________________
(page generated 2022-10-01 23:01 UTC)