5 ms·

Not trying to be a sarcastic jerk... any death is tragic and sad. Yet the Linux maintainers' average age is probably going up every year... so the community wil

Not trying to be a sarcastic jerk... any death is tragic and sad. Yet the Linux maintainers' average age is probably going up every year... so the community will have figure out a way to bring new blood in /and/ pass the reins. The sub-systems will fall into obsolescence otherwise...

deleted 8y ago
[deleted]
FractalParadigm 8y ago
I wouldn't be surprised to see a lot of software and sub-systems re-written, rather than maintained. systemd largely comes to mind; everyone seemed to be perfectly okay with init until systemd came along and vastly simplified the boot process. Now it's standard across virtually every mainstream distro. It's a similar story with Wayland vs. Xorg. How many network managers do we have now, too? As new technologies arise, it's almost always easier to write something new, from scratch, than to muck about in legacy code (that you probably didn't even write in the first place). md is great and works exceptionally well, but it's only a matter of time before a newer, better, more well-supported software RAID is born and md goes the way of init and Xorg
- deleted 8y ago
  [deleted]
- Uberphallus 8y ago
  > systemd > simplified I like systemd, but it never simplified anything, especially with the huge amount of dependencies. At most, it made things relatively uniform across Linux distros, but in the end of the day each distro has to maintain their own .service files anyway. Lightweight and embedded Linux distros won't use systemd by default in the foreseeable future because it's anything but simple.
  - avar 8y ago
    > it never simplified anything, especially with the huge amount of dependencies[...] That's an odd way of looking at things. Ultimately it's software accomplishing task X. How are things simpler if instead of depending on other projects they'd have implemented those things on their own? Then you'd be carrying duplicate work. > [...]but in the end of the day each distro has to maintain their own .service files anyway. Sure, but e.g. on Debian /etc/systemd/system/sshd.service is 22 lines. The still-carried shellscript version is 162 lines, and that's before counting any of the per-distro shellscript libraries systemd removed the need for. That's a big reduction in complexity even if systemd didn't have any advantages over shellscript init, which it does.
    - null_content 8y ago
      > Sure, but e.g. on Debian /etc/systemd/system/sshd.service is 22 lines. The still-carried shellscript version is 162 lines, and that's before counting any of the per-distro shellscript libraries systemd removed the need for. That's a big reduction in complexity even if systemd didn't have any advantages over shellscript init, which it does. And for that "simplicity" all you need is a daemon that depends on dbus, glibc and cgroups (IIRC), just to name a few - which makes it non-portable for anything that isn't Linux and non-usable for anything that doesn't want to depend on, say, glibc. And if they got their way, dbus would have been shoved into the kernel (kdbus, bus1, or whatever they called it) - adding a bloated mess of an IPC mechanism into the kernel. Simplicity. Right.
      - makomk 8y ago
        Worse still, some of the code in that daemon exists pretty much solely to replace functionality in that one shell script: the negated ConditionPathExists seems to be used only by sshd.service, with the non-negated version being used only to decide whether to launch getty. We've essentially replaced complexity in a shell script with complexity in an always-running process written in C.
      - avar 8y ago
        I think it's legitimate to complain about systemd not being portable, but it's odd to do so in terms of the non-portability not being "simple". Imagine how much more complex systemd would be for even common things like "start this daemon and make sure neither it or any of its sub-processes collectively use more than 1GB of memory" would be if it had to run on z/OS, AIX, Solaris, OpenBSD, HP/UX, Windows, Mac OS X etc. And let's be clear, systemd is perfectly usable for things that don't want to depend on glibc, for example it works just fine for starting Go programs, or your random C program you've linked to uClibc. What you can't do is not have a glibc on your system at all. Given how tiny glibc is in terms of modern hardware resources, if you can't have it on your system you probably weren't the target audience for systemd in the first place.
  - bitwize 8y ago
    Systemd simplified things the Mac way: by taking away control and building in a lot of smarts and vendor-supplied defaults. So, less simple in terms of number of moving parts, but simpler in terms of how much you have to know to deal with it. As in all things, it's a tradeoff.
- gruturo 8y ago
  systemd is a simplification of init? You couldn't have picked a wronger example. It's literally missing a NOT statement in the middle.
  - emmelaich 8y ago
    It simplifies our lives by absorbing complexity. That is literally the point of software.
    - pessimizer 8y ago
      Our lives may be simpler, but the software isn't. Absorbing complexity is literally the opposite of simplification.
      - bhhaskin 8y ago
        Totally. The complexity has to go somewhere.
- pjc50 8y ago
  That sounds like a recipe for disaster. Rewrites are incredibly hard, and these things tend to suffer from second-system effect.
- upofadown 8y ago
  >...everyone seemed to be perfectly okay with init until systemd came along... Everyone was definitely not OK with sysV init. That was the problem. The distros extended it in various incompatible and not very good ways. Regular sysV init was OK for what it did but hardly anyone used it that way. Systemd was not a rewrite of sysV; it was its own thing. The question of how to do stuff in a Unix like OS is still very much open, making systemd did not magically make the question go away.
  - JdeBP 8y ago
    Indeed, although the thing that actually was "regular System V init" was partly replaced with a new service manager subsystem several years before Linux was even invented. * https://news.ycombinator.com/item?id=18788974 https://news.ycombinator.com/item?id=18788974 The motivation for writing systemd, and what it was initially intended to replace, was upstart, the software that preceded systemd on both Ubuntu and Fedora. The idea that only van Smoorenburg init+rc and systemd existed is a common fallacy. * http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ (https://news.ycombinator.com/item?id=8488235 https://news.ycombinator.com/item?id=8488235)
giancarlostoro 8y ago
I fear for whoever replaces Linus the most, whether it be one person or a committee. If they don't hold the kernel up to his standards it just might not be the same. Worse yet will be if any given corporation gains control of Linux at which point, either through a fork or otherwise. Sadder yet is I'm less concerned about Microsoft supporting Linux than I would be Google.
- PakG1 8y ago
  If I could bet on this, I'd actually bet on Oracle taking the torch. Not because I think that's a good idea, just rather it'd unfortunately continue the trend (OpenOffice, MySQL, Java, etc) and everyone would bet against it, giving me a huge payoff when it happens. Fortunately, there's no way for them to "acquire" Linux, I believe.
  - Aissen 8y ago
    Jenkins, LibreOffice, MariaDB (and others) are doing just fine without Oracle.
    - PakG1 8y ago
      Yes, but those are all forks. I was answering the question only, nothing more. If Oracle took on Linux (whatever that would mean), I have no doubt another fork would start as well. edit: and this is a really contrived subject and example, because honestly, I can't think of how Oracle would take control of Linux anyway.
    - rhinoceraptor 8y ago
      Illumos isn't, it has a couple companies propping it up but outside of that hardly anyone uses it.
  - rhinoceraptor 8y ago
    They would need buy-in from all of the maintainers/contributors for that to happen. And there are a lot of them. I'm seeing 2466 unique maintainers (curl -s 'https://raw.githubusercontent.com/torvalds/linux/master/MAINTAINERS' https://raw.githubusercontent.com/torvalds/linux/master/MAIN... | grep -P "M:\t" | uniq | wc -l), and only 10 of them with @oracle.com emails. They're the 11th biggest contributor by company.
djohnston 8y ago
i think this guy was pretty young, looks to be in his 30s or 40s

deleted 8y ago

[deleted]

FractalParadigm 8y ago

I wouldn't be surprised to see a lot of software and sub-systems re-written, rather than maintained. systemd largely comes to mind; everyone seemed to be perfectly okay with init until systemd came along and vastly simplified the boot process. Now it's standard across virtually every mainstream distro. It's a similar story with Wayland vs. Xorg. How many network managers do we have now, too? As new technologies arise, it's almost always easier to write something new, from scratch, than to muck about in legacy code (that you probably didn't even write in the first place). md is great and works exceptionally well, but it's only a matter of time before a newer, better, more well-supported software RAID is born and md goes the way of init and Xorg

deleted 8y ago
[deleted]
Uberphallus 8y ago
> systemd > simplified I like systemd, but it never simplified anything, especially with the huge amount of dependencies. At most, it made things relatively uniform across Linux distros, but in the end of the day each distro has to maintain their own .service files anyway. Lightweight and embedded Linux distros won't use systemd by default in the foreseeable future because it's anything but simple.
- avar 8y ago
  > it never simplified anything, especially with the huge amount of dependencies[...] That's an odd way of looking at things. Ultimately it's software accomplishing task X. How are things simpler if instead of depending on other projects they'd have implemented those things on their own? Then you'd be carrying duplicate work. > [...]but in the end of the day each distro has to maintain their own .service files anyway. Sure, but e.g. on Debian /etc/systemd/system/sshd.service is 22 lines. The still-carried shellscript version is 162 lines, and that's before counting any of the per-distro shellscript libraries systemd removed the need for. That's a big reduction in complexity even if systemd didn't have any advantages over shellscript init, which it does.
  - null_content 8y ago
    > Sure, but e.g. on Debian /etc/systemd/system/sshd.service is 22 lines. The still-carried shellscript version is 162 lines, and that's before counting any of the per-distro shellscript libraries systemd removed the need for. That's a big reduction in complexity even if systemd didn't have any advantages over shellscript init, which it does. And for that "simplicity" all you need is a daemon that depends on dbus, glibc and cgroups (IIRC), just to name a few - which makes it non-portable for anything that isn't Linux and non-usable for anything that doesn't want to depend on, say, glibc. And if they got their way, dbus would have been shoved into the kernel (kdbus, bus1, or whatever they called it) - adding a bloated mess of an IPC mechanism into the kernel. Simplicity. Right.
    - makomk 8y ago
      Worse still, some of the code in that daemon exists pretty much solely to replace functionality in that one shell script: the negated ConditionPathExists seems to be used only by sshd.service, with the non-negated version being used only to decide whether to launch getty. We've essentially replaced complexity in a shell script with complexity in an always-running process written in C.
    - avar 8y ago
      I think it's legitimate to complain about systemd not being portable, but it's odd to do so in terms of the non-portability not being "simple". Imagine how much more complex systemd would be for even common things like "start this daemon and make sure neither it or any of its sub-processes collectively use more than 1GB of memory" would be if it had to run on z/OS, AIX, Solaris, OpenBSD, HP/UX, Windows, Mac OS X etc. And let's be clear, systemd is perfectly usable for things that don't want to depend on glibc, for example it works just fine for starting Go programs, or your random C program you've linked to uClibc. What you can't do is not have a glibc on your system at all. Given how tiny glibc is in terms of modern hardware resources, if you can't have it on your system you probably weren't the target audience for systemd in the first place.
- bitwize 8y ago
  Systemd simplified things the Mac way: by taking away control and building in a lot of smarts and vendor-supplied defaults. So, less simple in terms of number of moving parts, but simpler in terms of how much you have to know to deal with it. As in all things, it's a tradeoff.
gruturo 8y ago
systemd is a simplification of init? You couldn't have picked a wronger example. It's literally missing a NOT statement in the middle.
- emmelaich 8y ago
  It simplifies our lives by absorbing complexity. That is literally the point of software.
  - pessimizer 8y ago
    Our lives may be simpler, but the software isn't. Absorbing complexity is literally the opposite of simplification.
    - bhhaskin 8y ago
      Totally. The complexity has to go somewhere.
pjc50 8y ago
That sounds like a recipe for disaster. Rewrites are incredibly hard, and these things tend to suffer from second-system effect.
upofadown 8y ago
>...everyone seemed to be perfectly okay with init until systemd came along... Everyone was definitely not OK with sysV init. That was the problem. The distros extended it in various incompatible and not very good ways. Regular sysV init was OK for what it did but hardly anyone used it that way. Systemd was not a rewrite of sysV; it was its own thing. The question of how to do stuff in a Unix like OS is still very much open, making systemd did not magically make the question go away.
- JdeBP 8y ago
  Indeed, although the thing that actually was "regular System V init" was partly replaced with a new service manager subsystem several years before Linux was even invented. * https://news.ycombinator.com/item?id=18788974 https://news.ycombinator.com/item?id=18788974 The motivation for writing systemd, and what it was initially intended to replace, was upstart, the software that preceded systemd on both Ubuntu and Fedora. The idea that only van Smoorenburg init+rc and systemd existed is a common fallacy. * http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ (https://news.ycombinator.com/item?id=8488235 https://news.ycombinator.com/item?id=8488235)

giancarlostoro 8y ago

I fear for whoever replaces Linus the most, whether it be one person or a committee. If they don't hold the kernel up to his standards it just might not be the same. Worse yet will be if any given corporation gains control of Linux at which point, either through a fork or otherwise. Sadder yet is I'm less concerned about Microsoft supporting Linux than I would be Google.

PakG1 8y ago
If I could bet on this, I'd actually bet on Oracle taking the torch. Not because I think that's a good idea, just rather it'd unfortunately continue the trend (OpenOffice, MySQL, Java, etc) and everyone would bet against it, giving me a huge payoff when it happens. Fortunately, there's no way for them to "acquire" Linux, I believe.
- Aissen 8y ago
  Jenkins, LibreOffice, MariaDB (and others) are doing just fine without Oracle.
  - PakG1 8y ago
    Yes, but those are all forks. I was answering the question only, nothing more. If Oracle took on Linux (whatever that would mean), I have no doubt another fork would start as well. edit: and this is a really contrived subject and example, because honestly, I can't think of how Oracle would take control of Linux anyway.
  - rhinoceraptor 8y ago
    Illumos isn't, it has a couple companies propping it up but outside of that hardly anyone uses it.
- rhinoceraptor 8y ago
  They would need buy-in from all of the maintainers/contributors for that to happen. And there are a lot of them. I'm seeing 2466 unique maintainers (curl -s 'https://raw.githubusercontent.com/torvalds/linux/master/MAINTAINERS' https://raw.githubusercontent.com/torvalds/linux/master/MAIN... | grep -P "M:\t" | uniq | wc -l), and only 10 of them with @oracle.com emails. They're the 11th biggest contributor by company.

djohnston 8y ago

i think this guy was pretty young, looks to be in his 30s or 40s