8 ms·

"The argument in favour of just focussing on Linux exclusively goes like this: why should GNOME be held back by advances in technology simply because Solaris an

by leif 15y ago

"The argument in favour of just focussing on Linux exclusively goes like this: why should GNOME be held back by advances in technology simply because Solaris and the BSDs can't keep up with the fast pace of development in the Linux kernel?" What on earth does systemd need that it can't get from solaris/bsd, or are systemd and the gnome team just lazy?

hasenj 15y ago
I think it's more that if the BSD guys are interested in keeping gnome available for BSD, they have the freedom to port it, or implement the interfaces that gnome requires/expects.
- leif 15y ago
  Why should it be bsd's job to port code they didn't write, when gnome can do it for far fewer man-months because they already know what will need porting? If gnome really wants some fancy linux feature, they can ask bsd to implement it. Is there a history of such requests going unserved? I doubt there is even a history of such requests.
  - wmf 15y ago
    Virtually all of the people who write GNOME use Linux; why should they spend any effort porting GNOME to a platform they don't use? If GNOME really wants some fancy Linux feature, they can ask BSD to implement it. And the BSD developers don't have the manpower to do that. Is there a history of such requests going unserved? See Project Utopia, ALSA, DRM, KMS, cgroups, etc. BSD and Solaris cannot afford to keep up with Linux. They just can't. So the question is whether Linux people should subsidize OSes that they don't use or just let them fail.
    - codehalo 15y ago
      wow... a linux republican....
adestefan 15y ago
I didn't hold much hope for systemd when I realized it was being done by the same people that came up with PulseAudio.
joe_the_user 15y ago
I know nothing about systemd in particular. One thing you can say about current Linux windows managers is that they are held-back by the overall system's latency. That is, some random script starts somewhere starts while you're in the middle of typing something and you're like "why am I suddenly crawling?" In that sense, demanding that the graphic system have more control over services in general actually seems rational. Today, BSD, Linux and Solaris have lots of resources as server OSes but its pretty clear none of the server developers give a toss about the latency issues of the Linux Desktop. Concentrating on one OS would let them patch-to-suit so this might actually quite good. At the same time, the reason the current Gnome panels main-menu takes umpteen seconds to appear is that they feel compelled to each time parse the pathological menus format specified by Freedesktop.org. And so there's lots of other stuff to do to go present to a desktop that "spritely".
- leif 15y ago
  This is exactly why I don't run gnome: I don't like running a bunch of code that only serves to slow me down. I ran gnome on freebsd for a while and it was noticeably faster. This is due in part to the fact that I wasn't running all the crap ubuntu installs these days (why am I running a couchdb server on my laptop?), but also due to the fact that freebsd I think does a lot of things better, including fairer scheduling, and it has a sane init system.
  - ciupicri 15y ago
    Speaking of scheduling, the author of systemd suggested something to improve this [1] and if I remember correctly it will be available by default on systems with systemd. [1] http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html http://www.webupd8.org/2010/11/alternative-to-200-lines-kern...
ciupicri 15y ago
It's not necessarily that systemd needs something available only under Linux, but it was designed from the start to run only on Linux. Its author didn't want to care about other operating systems and wanted to use all the nice things available under Linux, e.g. cgroups.
- leif 15y ago
  Hence my question: what nice things? Let me elaborate. Good Programmers write Portable Code. This means checking for supported features and using them if they exist, falling back to less desirable methods otherwise. So either the systemd guys are too lazy to do this (and therefore I probably don't want to run their code even if my OS is supported) or there is something linux has exclusively, that is so damn awesome that systemd would suck if it didn't have it. To my knowledge, group scheduling is not that awesome. In fact, as far as I know, freebsd's kernel and userland apis are superior to linux's in many ways, and if this is false, I would like very much to know why. I was tempted to call gnome and systemd lazy, but thought I should learn more first. Full disclosure: I don't run gnome (apart from gtk) and probably never will, but only as a matter of personal preference, not philosophy.
  - asomiv 15y ago
    Writing portable code slows you down. With every change you have to think "hey is this available on all the other OSes too, and if not, how do I fallback?". This distracts you from your main goal, especially if that main goal can be better implemented with platform-specific APIs. I can very much understand not trying to bother and instead relying on contributors to port things to other OSes. Is there anything wrong with lazy? Remember that people have limited time and man power. There's a very good reason for using cgroups: to completely clean up a service's process tree even in the face of abusive behavior. A service can spawn a child process that calls setsid(). By using cgroups systemd can kill that child process too. Traditional POSIX APIs like killpg() do not allow that and give processes the ability to escape supervision. You say FreeBSD's kernel APIs are superior. It makes me wonder why you think that. There are only two things that I think are better on FreeBSD than on Linux: kqueue is better than epoll, and the OpenBSD firewall is easier to learn than iptables. As for everything else I've yet to see hard evidence that FreeBSD beats Linux.
asomiv 15y ago
Systemd is inspired by Apple's launchd (which has an unfortunate license) and has a few really nice features: - Many traditional init systems are based on a bunch of shell scripts with some metadata. Each service is started through a shell script that supports the start/stop/restart argument. While this makes the implementation very simple, it also makes it inefficient. To start a service the init system must create a new process (the shell script) which in turn invokes a bunch more processes (because almost anything you do in a shell script requires external commands) before finally invoking the service itself. This is expensive in terms of both CPU usage and disk I/O, and the latter really matters for boot time. Systemd accepts a bunch of service description files and handles the starting and stopping for you. - Traditional init systems are about starting and stopping services. Systemd is also about keeping services running. For example if a daemon crashes, with most init systems you have to restart it manually or hook it to some external monitoring system. External monitoring systems usually rely on polling to check whether services are still alive. Systemd on the other hand just forks() the service, waitpids() on it, and gets notified by the kernel when the services crashes. No polling involved. Polling wastes CPU and reduces battery life. Polling also makes leaves a small time gap during which the service is temporarily dead but hasn't been restarted yet. This latter can be mitigated with a smaller polling interval but the smaller this interval the more CPU you use. - Systemd supports on-demand starting of services. It starts a service as soon as a program needs it. This works by having systemd allocating server sockets and listening on them. When a client connects to a server socket, systemd will not accept() the client; instead systemd will figure out which service it belongs to, then starts that service, passing it the server socket. The service then accept()s the client. This is great for saving CPU, memory and disk I/O until it's really necessary. It saves battery life and reduces boot time. EDIT: It's not (x)inetd, see my reply. Unfortunately most people slam GNOME and systemd for being NIH or crazy without understanding the reasons. I hope this post makes some people understand the rationale behind systemd.
- leif 15y ago
  So it's like a local service inetd. Since you seem to know a lot about it, could you answer my question? What linux-specific features are necessary? EDIT: I don't know, I upvoted your comment, it was very helpful.
uriel 15y ago
> What on earth does systemd need that it can't get from solaris/bsd Poettering. In the long term this will be a competitive edge for *BSD over Linux.

by leif 15y ago

hasenj 15y ago

I think it's more that if the BSD guys are interested in keeping gnome available for BSD, they have the freedom to port it, or implement the interfaces that gnome requires/expects.

leif 15y ago
Why should it be bsd's job to port code they didn't write, when gnome can do it for far fewer man-months because they already know what will need porting? If gnome really wants some fancy linux feature, they can ask bsd to implement it. Is there a history of such requests going unserved? I doubt there is even a history of such requests.
- wmf 15y ago
  Virtually all of the people who write GNOME use Linux; why should they spend any effort porting GNOME to a platform they don't use? If GNOME really wants some fancy Linux feature, they can ask BSD to implement it. And the BSD developers don't have the manpower to do that. Is there a history of such requests going unserved? See Project Utopia, ALSA, DRM, KMS, cgroups, etc. BSD and Solaris cannot afford to keep up with Linux. They just can't. So the question is whether Linux people should subsidize OSes that they don't use or just let them fail.
  - codehalo 15y ago
    wow... a linux republican....

adestefan 15y ago

I didn't hold much hope for systemd when I realized it was being done by the same people that came up with PulseAudio.

joe_the_user 15y ago

I know nothing about systemd in particular. One thing you can say about current Linux windows managers is that they are held-back by the overall system's latency. That is, some random script starts somewhere starts while you're in the middle of typing something and you're like "why am I suddenly crawling?" In that sense, demanding that the graphic system have more control over services in general actually seems rational. Today, BSD, Linux and Solaris have lots of resources as server OSes but its pretty clear none of the server developers give a toss about the latency issues of the Linux Desktop. Concentrating on one OS would let them patch-to-suit so this might actually quite good. At the same time, the reason the current Gnome panels main-menu takes umpteen seconds to appear is that they feel compelled to each time parse the pathological menus format specified by Freedesktop.org. And so there's lots of other stuff to do to go present to a desktop that "spritely".

leif 15y ago
This is exactly why I don't run gnome: I don't like running a bunch of code that only serves to slow me down. I ran gnome on freebsd for a while and it was noticeably faster. This is due in part to the fact that I wasn't running all the crap ubuntu installs these days (why am I running a couchdb server on my laptop?), but also due to the fact that freebsd I think does a lot of things better, including fairer scheduling, and it has a sane init system.
- ciupicri 15y ago
  Speaking of scheduling, the author of systemd suggested something to improve this [1] and if I remember correctly it will be available by default on systems with systemd. [1] http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html http://www.webupd8.org/2010/11/alternative-to-200-lines-kern...

ciupicri 15y ago

It's not necessarily that systemd needs something available only under Linux, but it was designed from the start to run only on Linux. Its author didn't want to care about other operating systems and wanted to use all the nice things available under Linux, e.g. cgroups.

leif 15y ago
Hence my question: what nice things? Let me elaborate. Good Programmers write Portable Code. This means checking for supported features and using them if they exist, falling back to less desirable methods otherwise. So either the systemd guys are too lazy to do this (and therefore I probably don't want to run their code even if my OS is supported) or there is something linux has exclusively, that is so damn awesome that systemd would suck if it didn't have it. To my knowledge, group scheduling is not that awesome. In fact, as far as I know, freebsd's kernel and userland apis are superior to linux's in many ways, and if this is false, I would like very much to know why. I was tempted to call gnome and systemd lazy, but thought I should learn more first. Full disclosure: I don't run gnome (apart from gtk) and probably never will, but only as a matter of personal preference, not philosophy.
- asomiv 15y ago
  Writing portable code slows you down. With every change you have to think "hey is this available on all the other OSes too, and if not, how do I fallback?". This distracts you from your main goal, especially if that main goal can be better implemented with platform-specific APIs. I can very much understand not trying to bother and instead relying on contributors to port things to other OSes. Is there anything wrong with lazy? Remember that people have limited time and man power. There's a very good reason for using cgroups: to completely clean up a service's process tree even in the face of abusive behavior. A service can spawn a child process that calls setsid(). By using cgroups systemd can kill that child process too. Traditional POSIX APIs like killpg() do not allow that and give processes the ability to escape supervision. You say FreeBSD's kernel APIs are superior. It makes me wonder why you think that. There are only two things that I think are better on FreeBSD than on Linux: kqueue is better than epoll, and the OpenBSD firewall is easier to learn than iptables. As for everything else I've yet to see hard evidence that FreeBSD beats Linux.

asomiv 15y ago

Systemd is inspired by Apple's launchd (which has an unfortunate license) and has a few really nice features: - Many traditional init systems are based on a bunch of shell scripts with some metadata. Each service is started through a shell script that supports the start/stop/restart argument. While this makes the implementation very simple, it also makes it inefficient. To start a service the init system must create a new process (the shell script) which in turn invokes a bunch more processes (because almost anything you do in a shell script requires external commands) before finally invoking the service itself. This is expensive in terms of both CPU usage and disk I/O, and the latter really matters for boot time. Systemd accepts a bunch of service description files and handles the starting and stopping for you. - Traditional init systems are about starting and stopping services. Systemd is also about keeping services running. For example if a daemon crashes, with most init systems you have to restart it manually or hook it to some external monitoring system. External monitoring systems usually rely on polling to check whether services are still alive. Systemd on the other hand just forks() the service, waitpids() on it, and gets notified by the kernel when the services crashes. No polling involved. Polling wastes CPU and reduces battery life. Polling also makes leaves a small time gap during which the service is temporarily dead but hasn't been restarted yet. This latter can be mitigated with a smaller polling interval but the smaller this interval the more CPU you use. - Systemd supports on-demand starting of services. It starts a service as soon as a program needs it. This works by having systemd allocating server sockets and listening on them. When a client connects to a server socket, systemd will not accept() the client; instead systemd will figure out which service it belongs to, then starts that service, passing it the server socket. The service then accept()s the client. This is great for saving CPU, memory and disk I/O until it's really necessary. It saves battery life and reduces boot time. EDIT: It's not (x)inetd, see my reply. Unfortunately most people slam GNOME and systemd for being NIH or crazy without understanding the reasons. I hope this post makes some people understand the rationale behind systemd.

leif 15y ago
So it's like a local service inetd. Since you seem to know a lot about it, could you answer my question? What linux-specific features are necessary? EDIT: I don't know, I upvoted your comment, it was very helpful.

uriel 15y ago

> What on earth does systemd need that it can't get from solaris/bsd Poettering. In the long term this will be a competitive edge for *BSD over Linux.