5 ms·

> Things used to be done kernel up. But these days it seems that things are happening DE down. The software hierarchy in order of importance, starting with mos

> Things used to be done kernel up. But these days it seems that things are happening DE down. The software hierarchy in order of importance, starting with most important: 1. User's needs/wants 2. User's applications 3. User's operational environment 4. application APIs 5. OS services 6. OS Kernel. The point of a OS is to make it easier to write and run applications. That is it. The 'kernel on up' design is fantasy and is NEVER how it was done in Linux or GNU or anywhere. GNU knew that User/User applications were primary importance. This is why they designed the OS following established APIs designed to help with application compatibility. Those APIs and GNU environment dictated the design of the kernel. Now as the requirements on OS rise so does the complexity. New needs/wants/desires dictate new design choices, of which filter from application on down. Besides that it is pretty obvious that the standardization of systemd and the elimination of distribution-specific scripts and services has resulted in massive reduction of bugs and complexity in the Linux OS. Accounting for each distribution individually, counting those bugs up, adding all them into one lump sum... I am willing to bet that for every 1 bug that systemd introduces into the OS it has resolved at least a 1000.

erpellan 10y ago
> Besides that it is pretty obvious that the standardization of systemd and the elimination of distribution-specific scripts and services has resulted in massive reduction of bugs and complexity in the Linux OS. Accounting for each distribution individually, counting those bugs up, adding all them into one lump sum... I am willing to bet that for every 1 bug that systemd introduces into the OS it has resolved at least a 1000 Citation needed.
notalaser 10y ago
I'm not a fan of the kernel-up/desktop-down dichotomy, but please remember that "1. User's needs/wants and 2. User's application" are a) not necessarily desktop applications (in fact, for 99% of the places where Linux is deployed on this planet, it's anything but desktop applications) and b) depend on systems software, which is anything but pleasant to write and integrate with community non-players like systemd. This binary, "user needs = true, programmer needs = irrelevant" dichotomy is very toxic to an environment that still, by and large, depends on community support for its existence.
- rkangel 10y ago
  > in fact, for 99% of the places where Linux is deployed on this planet, it's anything but desktop applications Don't forget that by device count, by far the largest deployment of Linux is Android. Technically not 'desktop', but close enough in this categorisation.
  - notalaser 10y ago
    I stand corrected :-). However, Android is far more restrictive in the type of applications that run on it and in the type of environment that they run in, and runs a very different stack of system tools (which doesn't include systemd). My exposure to writing Android applications is far too limited to comment on the matter without making a fool of myself.
  - pjmlp 10y ago
    Despite what many think, Android is not the same as GNU/Linux. The NDK is so constrained, with quite a few API features removed (e.g. no UNIX IPC APIs), that Google could replace the kernel by something else and only the OEMs would notice. Access to native code is only there for games and implementing Java native methods. Google likes it so much that Brillo makes these constraints even more explicit, although it is all native code.
  - snaky 10y ago
    I'm not so sure. I don't have a numbers, but if we count all the embedded Linux devices from routers to wearables and smart-meters, and all the Linux server VMs running this very second at all the cloud providers worldwide - I'm not sure Android would win.
    - rkangel 10y ago
      If you were to count all of the embedded Linux devices (wearables, routers, smart meter) together in one category along with server VMs, then you might win. But that isn't a fair comparison. I didn't say that Android was the majority of deployments, just the largest group.
craigsmansion 10y ago
> Besides that it is pretty obvious that the standardization [..] has resulted in massive reduction of bugs and complexity. If that were true it would be easy to see the difference in outstanding bugs between distributions that adopted SystemD and those who haven't, since their bug-numbers would be orders of magnitudes larger. To my knowledge this isn't so. From a larger perspective you are arguing for the benefits consolidation and unification, as in 'If only we had one X (where X can be a Desktop Environment, GUI toolkit, Editor, etc), every developer could focus their effort on that, innovation would be quicker and adoption of the OS would be better (and we would finally have "the year of the desktop"). It is a pretty idea, to boost productivity through standardisation, but by now decades of free OS development (and proprietary OS development, to illustrate the value of mono-cultures and cathedral planning) have shown it does not work. As of now, SystemD adoption hinders the development of: -alternative cgroup managers -non-affiliated container development -DE development on non-linux systems -GNU running on alternative kernels -adoption and development of alternative init systems Now none of these directly affect the Desktop Experience, so many will not care. But standardisation is not necessarily a direct benefit, or even a net benefit from a larger--long-term--context, especially in the Free Software world.
- tveita 10y ago
  Successful standardization of protocols and formats tend to benefit the entire software ecosystem, both open source and otherwise. Standardization on a specific implementation has a greater risk of stagnation, and encourages fragile software relying on undocumented and sometimes unintended behavior.
  - snaky 10y ago
    > Successful standardization of protocols and formats tend to benefit the entire software ecosystem It depends on how good those protocols and formats are. Let's look at OSI protocol stack which is failed miserably on that task exactly.
Corrado 10y ago
I think you are missing the parent's point. By "kernel up" I think they mean that the kernel can stand alone without any other software. It's not very useful, but it does work. Then you add system executables (sh, ls, etc.) and the only thing they require is the kernel (and maybe each other). You keep adding more and more layers, each depending on the previous but not the next. The top of the stack is, as you say, what the user wants/needs and it is dependent on all of the previous layers. The current situation with systemd is that this hierarchy is no longer valid and low level components are now relying on things above them in the stack. So much so that, for example, if the web browser stops working you have to reboot the computer because it hung a kernel process somewhere. That doesn't seem like a very good system to me.
- digi_owl 10y ago
  Indeed. Take a look at Wayland for example. While you can pretty much fire up X on top of anything running as pid1, Wayland expects polkit to be present to handle access privileges. And polkit begets logind begets systemd.
  - snaky 10y ago
    And the main problem is the fact almost nobody see that interdependence mess as a problem at all.

erpellan 10y ago

> Besides that it is pretty obvious that the standardization of systemd and the elimination of distribution-specific scripts and services has resulted in massive reduction of bugs and complexity in the Linux OS. Accounting for each distribution individually, counting those bugs up, adding all them into one lump sum... I am willing to bet that for every 1 bug that systemd introduces into the OS it has resolved at least a 1000 Citation needed.

notalaser 10y ago

I'm not a fan of the kernel-up/desktop-down dichotomy, but please remember that "1. User's needs/wants and 2. User's application" are a) not necessarily desktop applications (in fact, for 99% of the places where Linux is deployed on this planet, it's anything but desktop applications) and b) depend on systems software, which is anything but pleasant to write and integrate with community non-players like systemd. This binary, "user needs = true, programmer needs = irrelevant" dichotomy is very toxic to an environment that still, by and large, depends on community support for its existence.

rkangel 10y ago
> in fact, for 99% of the places where Linux is deployed on this planet, it's anything but desktop applications Don't forget that by device count, by far the largest deployment of Linux is Android. Technically not 'desktop', but close enough in this categorisation.
- notalaser 10y ago
  I stand corrected :-). However, Android is far more restrictive in the type of applications that run on it and in the type of environment that they run in, and runs a very different stack of system tools (which doesn't include systemd). My exposure to writing Android applications is far too limited to comment on the matter without making a fool of myself.
- pjmlp 10y ago
  Despite what many think, Android is not the same as GNU/Linux. The NDK is so constrained, with quite a few API features removed (e.g. no UNIX IPC APIs), that Google could replace the kernel by something else and only the OEMs would notice. Access to native code is only there for games and implementing Java native methods. Google likes it so much that Brillo makes these constraints even more explicit, although it is all native code.
- snaky 10y ago
  I'm not so sure. I don't have a numbers, but if we count all the embedded Linux devices from routers to wearables and smart-meters, and all the Linux server VMs running this very second at all the cloud providers worldwide - I'm not sure Android would win.
  - rkangel 10y ago
    If you were to count all of the embedded Linux devices (wearables, routers, smart meter) together in one category along with server VMs, then you might win. But that isn't a fair comparison. I didn't say that Android was the majority of deployments, just the largest group.

craigsmansion 10y ago

> Besides that it is pretty obvious that the standardization [..] has resulted in massive reduction of bugs and complexity. If that were true it would be easy to see the difference in outstanding bugs between distributions that adopted SystemD and those who haven't, since their bug-numbers would be orders of magnitudes larger. To my knowledge this isn't so. From a larger perspective you are arguing for the benefits consolidation and unification, as in 'If only we had one X (where X can be a Desktop Environment, GUI toolkit, Editor, etc), every developer could focus their effort on that, innovation would be quicker and adoption of the OS would be better (and we would finally have "the year of the desktop"). It is a pretty idea, to boost productivity through standardisation, but by now decades of free OS development (and proprietary OS development, to illustrate the value of mono-cultures and cathedral planning) have shown it does not work. As of now, SystemD adoption hinders the development of: -alternative cgroup managers -non-affiliated container development -DE development on non-linux systems -GNU running on alternative kernels -adoption and development of alternative init systems Now none of these directly affect the Desktop Experience, so many will not care. But standardisation is not necessarily a direct benefit, or even a net benefit from a larger--long-term--context, especially in the Free Software world.

tveita 10y ago
Successful standardization of protocols and formats tend to benefit the entire software ecosystem, both open source and otherwise. Standardization on a specific implementation has a greater risk of stagnation, and encourages fragile software relying on undocumented and sometimes unintended behavior.
- snaky 10y ago
  > Successful standardization of protocols and formats tend to benefit the entire software ecosystem It depends on how good those protocols and formats are. Let's look at OSI protocol stack which is failed miserably on that task exactly.

Corrado 10y ago

I think you are missing the parent's point. By "kernel up" I think they mean that the kernel can stand alone without any other software. It's not very useful, but it does work. Then you add system executables (sh, ls, etc.) and the only thing they require is the kernel (and maybe each other). You keep adding more and more layers, each depending on the previous but not the next. The top of the stack is, as you say, what the user wants/needs and it is dependent on all of the previous layers. The current situation with systemd is that this hierarchy is no longer valid and low level components are now relying on things above them in the stack. So much so that, for example, if the web browser stops working you have to reboot the computer because it hung a kernel process somewhere. That doesn't seem like a very good system to me.

digi_owl 10y ago
Indeed. Take a look at Wayland for example. While you can pretty much fire up X on top of anything running as pid1, Wayland expects polkit to be present to handle access privileges. And polkit begets logind begets systemd.
- snaky 10y ago
  And the main problem is the fact almost nobody see that interdependence mess as a problem at all.