6 ms·

GNOME Discusses Becoming a Linux-only Project

87 points by pdelgallego 15y ago

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.
daeken 15y ago
If you're going down the Gnome-as-an-OS rabbit hole, why not just build a distro? Integrate things as tightly as possible and provide the best possible user experience. This just seems like a poor choice otherwise.
fingerprinter 15y ago
This is absolutely absurd on so many levels. There is a thread going around the desktop-devel mailing lists about the GnomeOS. I just don't get the rationale and, frankly, I think the Gnome community is being myopic and shortsighted. However, I think there might be something more subtle at play here. Redhat. It's well known for some time that Redhat was providing the majority of funding for Gnome either in dollars or people hours. If Redhat could exert their influence over the rather influential Gnome project (Gnome is not known for strong internal leadership nor strong political/business acumen), it could potentially pull of something it has been trying to do for years: hurt Ubuntu. That being said, it seems Ubuntu has been making the moves necessary to be less dependent on Gnome/GTK. I hate to sound all corporate espionagy but this really feels less about Gnome and more about the corporate players. And leaving the tinfoil hat realm, if this is all about Gnome and what they want...I feel this is going to be a rough road and they don't have an idea what it really means to build an OS and being responsible for everything: upstream development, apps, drivers, hardware....the list goes on.
- bretthoerner 15y ago
  How does this hurt Ubuntu?
  - skymt 15y ago
    Not that much. Ubuntu of course has its own init system, Upstart, and it's unlikely they'll abandon it for systemd after so much development and integration work. They also have Unity, which fills GNOME-Shell's role. If GNOME-Shell depends on systemd, it will be much harder for Ubuntu users to run GNOME-Shell, but the basic distribution won't be affected.
  - fingerprinter 15y ago
    It hurts Ubuntu like it hurts other downstream distros: more work they have to do to use Gnome bits. Check the thread on desktop-devel about adding something to control center. The common practice would be to fork something and carry patches, which is work and not something downstreams would be too keen on doing. Yes, core gnome would still be "available", but it would be more work and harder to get to the interesting bits and break away from the stuff that, frankly, Gnome doesn't do well for which better alternatives exist. Gnome is going monolithic instead of modular, and that is bad for everyone that won't use a stock gnome.
tspiteri 15y ago
I'm not sure GNOME is becoming a Linux-only project, but if it were, I wouldn't see anything wrong with that. I think it is somehow similar to the window manager issue from a few years ago, where some people wanted GNOME to support lots of different window managers, which meant they had to work around the quirks in each of them, or limit the functionality to the lowest common denominator. Sometimes, an issue in the desktop environment needs some deep digging for proper fixing. Having to dig deep into each of the supported platforms is daunting and will probably lead to a worse user experience. So I think they should just pick their platform and work on it. Nobody expects Apple, for example, to support the Mac OS X UI on different kernels/platforms, even though Darwin is very Unix-like. Apple actually go one further and only support their own hardware. Why can't GNOME focus like Apple does?
- ciupicri 15y ago
  Because GNOME is supposed to be an open, not closed system. At least that's how I've always seen it. P.S. Since I got 2 downvotes, could someone please explain me what's wrong with writing a personal opinion?
  - tspiteri 15y ago
    I'm not sure I understand you. How is focusing your own work on the one platform you care about the same as being closed? Everything is still open, and if a platform wants to support GNOME, they are free to do the work themselves; I'm sure patches would be accepted.
    - ciupicri 15y ago
      Being limited to only one operating system would make it more closed. P.S. Quoting from Wikipedia: "Open systems are computer systems that provide some combination of interoperability, _portability_, and open software standards." [1] Also the name GNOME is an acronym of GNU Network Object Model Environment. It refers to GNOME’s original intention of creating a distributed object framework similar to Microsoft's OLE. [2] If GNOME is considered an open system despite working only on Linux, the same could be said about OLE, but I doubt many would agree with this. [1] http://en.wikipedia.org/wiki/Open_system_%28computing%29 http://en.wikipedia.org/wiki/Open_system_%28computing%29 [2] http://en.wikipedia.org/wiki/GNOME#Name http://en.wikipedia.org/wiki/GNOME#Name
darklajid 15y ago
Erm. No. OSNews is inaccurate and so is the title. Or in a short message to the masses, < 140 chars: https://twitter.com/#!/jdub/statuses/71218014703468545 https://twitter.com/#!/jdub/statuses/71218014703468545
beza1e1 15y ago
Summary: Some Gnome devs would like to require systemd. Unfortunately, systemd is currently not ported to anything but Linux, so this would make Gnome Linux-only. However, porting systemd to Solaris and BSD does not look hard.
- riffraff 15y ago
  as someone who does not really understand it, it does look non trivial: """ Which Linux-specific functionality does systemd use and what's the advantage of this over a solution that is portable to other operating systems? There's quite a bit of Linux-specific functionality we rely on. The first that comes to mind is probably cgroups (short for "Control Groups") which is a Linux kernel feature that may be used to create hierarchical groups of processes, label them, and optionally apply resource limits or other rules to them. But there's a lot more. Systemd tightly integrates with the Linux-specific udev system for hot-plug events. And then, the disk read-ahead solution we include in systemd uses the Linux-specific fanotify() call. Or we support spawning processes in their own file system namespaces or with limited capability sets, both of which are Linux specific features. Or we support the Linux-specific automounter and other mount APIs such as polling mount changes via /proc/self/mountinfo which do not exist on other OSes. Internally we use a lot of newer API calls, such as timerfd() or signalfd() which are not available outside of Linux. These latter calls could be emulated on other OSes, but using them greatly simplifies our own code. And many of the other Linux features we use have no suitable counterparts on other Unixes at all. """ from http://fosdem.org/2011/interview/lennart-poettering http://fosdem.org/2011/interview/lennart-poettering
- tobylane 15y ago
  So how sane is the first step, changing the internal part to something somewhat unportable?
chalst 15y ago
David Nielsen in a well-referenced post: http://davidnielsen.wordpress.com/2011/05/18/systemd-in-gnome-packagekit-and-what-gnome-as-an-os-really-means/ http://davidnielsen.wordpress.com/2011/05/18/systemd-in-gnom... >Lennart in follow ups to his proposal explains that systemd could be separated into a core set of interfaces which could take replacement backends that support e.g. FreeBSD so long as it implements the interfaces systemd cares about or as it was their init system. So the idea is not to abandon non-Linux targets, but to offer varying levels of support for them.
- masklinn 15y ago
  > but to offer varying levels of support for them. That means no support. Offering bulletproof vests with varying supports of bulletproofness means the vest is not bulletproof.
cmiles74 15y ago
If Gnome transforms their product into it's own operating system, not only will the Gnome environment itself become more monolithic and less modular but the distribution they produce will suffer that same fate. It's not a given, but it's easy to imagine the non-negotiable dependencies for the Gnome OS growing over time and becoming even more obscure than which init system is used. Personally, I like being able to make some of these choices about the components that make up my operating system. On the whole, I think modularity is feature that I find more compelling than the sort of tight integration that some other OS vendors (like Apple) are providing.
- Someone 15y ago
  I agree that having a bunch of Lego bricks that you can combine at will is nice, but the disadvantage of that is that what you build with it always will be less streamlined (in software, there will have to be code to handle slight interface differences), and may fall apart easier (if there are zillions of ways to combine parts, the probability that your way to combine them has been tested can rapidly go to zero) There must be an optimum somewhere in the middle. Big question is: where? For some things, the answer seems clear (sometimes after a couple of decades of experimentation). For example: - there seems to be consensus that pluggable file systems are a good idea. But even there, there is no consensus on the interface, as shown by the VFS vs ZFS discussion. - Pluggable printer drivers? I have never heard somebody argue that was a bad idea. On the other hand, there may be room for consolidation here, just as has happened on the terminal front (how many different terminal protocols are in active use?) - Pluggable windowing systems? On Linux, it appears that X has won (for now). For others, there is no agreement: - Pluggable schedulers? At least a few years ago, there was disagreement about the question whether that was a good idea. - Pluggable window managers? From what I read on the internet, these seem popular, but I think there is some selection bias there. - Pluggable GUIs? I think that is a bad idea. You can build a system where, say, gnome apps and KDE apps and Java apps all look more or les the same, but I have never seen one where the Lego bricks did not shine through. - Pluggable character sets (aka code pages)? Unicode has won that battle (because it is the best of all the abominations we can choose from :-)) In summary: I like flexibility, but I also think you cannot get a nice coherent system without limiting that. Designing is making choices. If I wanted to create a Linux system for the general public, I would probably have to sacrifice a lot of flexibility to get such a system in a reasonable timeframe.
tytso 15y ago
The question of portable code vs. taking advantage of the best possible system interfaces is a very hard problem indeed. On the one hand, the number of people using non-Linux POSIX compliant OS's have dropped significantly in the last decade. As a percentage of the installed base, either by machine or by user, what's left? The *BSD's, where I'm not sure there is hard evidence that they are growing even by absolute numbers, never mind as a percentage of the total market. Solaris, which Oracle is busily killing by increasing support costs to the point where people are quickly bailing to other alternatives --- in the end I won't be surprised if aside from the one or two big iron databases servers, there are very few other Solaris installations left. AIX? HPUX? Don't make me laugh. The only POSIX compliant OS that is growing is MAC OS X --- and Apple isn't afraid to add new incompatible features to their kernel, and then release software which only runs on MacOS --- and usually people don't wag their fingers at Apple complaining that they are releasing non-portable programs. Instead, Apple is usually lauded for keeping a solid eye on usability and writing programs that have a deep sympathy for the end user. So why is it that a lot of people are kvetching at GNOME for wanting to use kernel-specific features in the name of improving the user experience, when the same complaints aren't leveled at Apple? I think there's a bit of a double standard being applied here....
- itgoon 15y ago
  I think the difference is "interoperability" v. "integration". The OSS community has typically favored the former, while denigrating MS for the latter. There's benefit to the integration path. MS' tools play very nicely with one another, and it would be nice to see improvements on the OSS side. However, I don't think the Gnome project should go that route. Part of its success has been its modularity - it has been long-lived, and used in unlikely places. Choosing the integration route significantly reduces future options. Heck, what if Oracle decides they don't want the expense of Solaris, and spin it off into its own company (yea, yea, I know)? If Canonical (or other downstream) chose to do something like this, I would think it was a great decision. Ubuntu could end up with a superior experience, if done right. I don't see the point of a core project doing this. There's nothing about the current model which prevents implementing this downstream, or as an add-on for those that are interested.
orenmazor 15y ago
so? It'll just fork and you'll have two camps that spend most of their time porting features across.

87 points by pdelgallego 15y ago

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.

daeken 15y ago

If you're going down the Gnome-as-an-OS rabbit hole, why not just build a distro? Integrate things as tightly as possible and provide the best possible user experience. This just seems like a poor choice otherwise.

fingerprinter 15y ago

This is absolutely absurd on so many levels. There is a thread going around the desktop-devel mailing lists about the GnomeOS. I just don't get the rationale and, frankly, I think the Gnome community is being myopic and shortsighted. However, I think there might be something more subtle at play here. Redhat. It's well known for some time that Redhat was providing the majority of funding for Gnome either in dollars or people hours. If Redhat could exert their influence over the rather influential Gnome project (Gnome is not known for strong internal leadership nor strong political/business acumen), it could potentially pull of something it has been trying to do for years: hurt Ubuntu. That being said, it seems Ubuntu has been making the moves necessary to be less dependent on Gnome/GTK. I hate to sound all corporate espionagy but this really feels less about Gnome and more about the corporate players. And leaving the tinfoil hat realm, if this is all about Gnome and what they want...I feel this is going to be a rough road and they don't have an idea what it really means to build an OS and being responsible for everything: upstream development, apps, drivers, hardware....the list goes on.

bretthoerner 15y ago
How does this hurt Ubuntu?
- skymt 15y ago
  Not that much. Ubuntu of course has its own init system, Upstart, and it's unlikely they'll abandon it for systemd after so much development and integration work. They also have Unity, which fills GNOME-Shell's role. If GNOME-Shell depends on systemd, it will be much harder for Ubuntu users to run GNOME-Shell, but the basic distribution won't be affected.
- fingerprinter 15y ago
  It hurts Ubuntu like it hurts other downstream distros: more work they have to do to use Gnome bits. Check the thread on desktop-devel about adding something to control center. The common practice would be to fork something and carry patches, which is work and not something downstreams would be too keen on doing. Yes, core gnome would still be "available", but it would be more work and harder to get to the interesting bits and break away from the stuff that, frankly, Gnome doesn't do well for which better alternatives exist. Gnome is going monolithic instead of modular, and that is bad for everyone that won't use a stock gnome.

tspiteri 15y ago

I'm not sure GNOME is becoming a Linux-only project, but if it were, I wouldn't see anything wrong with that. I think it is somehow similar to the window manager issue from a few years ago, where some people wanted GNOME to support lots of different window managers, which meant they had to work around the quirks in each of them, or limit the functionality to the lowest common denominator. Sometimes, an issue in the desktop environment needs some deep digging for proper fixing. Having to dig deep into each of the supported platforms is daunting and will probably lead to a worse user experience. So I think they should just pick their platform and work on it. Nobody expects Apple, for example, to support the Mac OS X UI on different kernels/platforms, even though Darwin is very Unix-like. Apple actually go one further and only support their own hardware. Why can't GNOME focus like Apple does?

ciupicri 15y ago
Because GNOME is supposed to be an open, not closed system. At least that's how I've always seen it. P.S. Since I got 2 downvotes, could someone please explain me what's wrong with writing a personal opinion?
- tspiteri 15y ago
  I'm not sure I understand you. How is focusing your own work on the one platform you care about the same as being closed? Everything is still open, and if a platform wants to support GNOME, they are free to do the work themselves; I'm sure patches would be accepted.
  - ciupicri 15y ago
    Being limited to only one operating system would make it more closed. P.S. Quoting from Wikipedia: "Open systems are computer systems that provide some combination of interoperability, _portability_, and open software standards." [1] Also the name GNOME is an acronym of GNU Network Object Model Environment. It refers to GNOME’s original intention of creating a distributed object framework similar to Microsoft's OLE. [2] If GNOME is considered an open system despite working only on Linux, the same could be said about OLE, but I doubt many would agree with this. [1] http://en.wikipedia.org/wiki/Open_system_%28computing%29 http://en.wikipedia.org/wiki/Open_system_%28computing%29 [2] http://en.wikipedia.org/wiki/GNOME#Name http://en.wikipedia.org/wiki/GNOME#Name

darklajid 15y ago

Erm. No. OSNews is inaccurate and so is the title. Or in a short message to the masses, < 140 chars: https://twitter.com/#!/jdub/statuses/71218014703468545 https://twitter.com/#!/jdub/statuses/71218014703468545

beza1e1 15y ago

Summary: Some Gnome devs would like to require systemd. Unfortunately, systemd is currently not ported to anything but Linux, so this would make Gnome Linux-only. However, porting systemd to Solaris and BSD does not look hard.

riffraff 15y ago
as someone who does not really understand it, it does look non trivial: """ Which Linux-specific functionality does systemd use and what's the advantage of this over a solution that is portable to other operating systems? There's quite a bit of Linux-specific functionality we rely on. The first that comes to mind is probably cgroups (short for "Control Groups") which is a Linux kernel feature that may be used to create hierarchical groups of processes, label them, and optionally apply resource limits or other rules to them. But there's a lot more. Systemd tightly integrates with the Linux-specific udev system for hot-plug events. And then, the disk read-ahead solution we include in systemd uses the Linux-specific fanotify() call. Or we support spawning processes in their own file system namespaces or with limited capability sets, both of which are Linux specific features. Or we support the Linux-specific automounter and other mount APIs such as polling mount changes via /proc/self/mountinfo which do not exist on other OSes. Internally we use a lot of newer API calls, such as timerfd() or signalfd() which are not available outside of Linux. These latter calls could be emulated on other OSes, but using them greatly simplifies our own code. And many of the other Linux features we use have no suitable counterparts on other Unixes at all. """ from http://fosdem.org/2011/interview/lennart-poettering http://fosdem.org/2011/interview/lennart-poettering
tobylane 15y ago
So how sane is the first step, changing the internal part to something somewhat unportable?

chalst 15y ago

David Nielsen in a well-referenced post: http://davidnielsen.wordpress.com/2011/05/18/systemd-in-gnome-packagekit-and-what-gnome-as-an-os-really-means/ http://davidnielsen.wordpress.com/2011/05/18/systemd-in-gnom... >Lennart in follow ups to his proposal explains that systemd could be separated into a core set of interfaces which could take replacement backends that support e.g. FreeBSD so long as it implements the interfaces systemd cares about or as it was their init system. So the idea is not to abandon non-Linux targets, but to offer varying levels of support for them.

masklinn 15y ago
> but to offer varying levels of support for them. That means no support. Offering bulletproof vests with varying supports of bulletproofness means the vest is not bulletproof.

cmiles74 15y ago

If Gnome transforms their product into it's own operating system, not only will the Gnome environment itself become more monolithic and less modular but the distribution they produce will suffer that same fate. It's not a given, but it's easy to imagine the non-negotiable dependencies for the Gnome OS growing over time and becoming even more obscure than which init system is used. Personally, I like being able to make some of these choices about the components that make up my operating system. On the whole, I think modularity is feature that I find more compelling than the sort of tight integration that some other OS vendors (like Apple) are providing.

Someone 15y ago
I agree that having a bunch of Lego bricks that you can combine at will is nice, but the disadvantage of that is that what you build with it always will be less streamlined (in software, there will have to be code to handle slight interface differences), and may fall apart easier (if there are zillions of ways to combine parts, the probability that your way to combine them has been tested can rapidly go to zero) There must be an optimum somewhere in the middle. Big question is: where? For some things, the answer seems clear (sometimes after a couple of decades of experimentation). For example: - there seems to be consensus that pluggable file systems are a good idea. But even there, there is no consensus on the interface, as shown by the VFS vs ZFS discussion. - Pluggable printer drivers? I have never heard somebody argue that was a bad idea. On the other hand, there may be room for consolidation here, just as has happened on the terminal front (how many different terminal protocols are in active use?) - Pluggable windowing systems? On Linux, it appears that X has won (for now). For others, there is no agreement: - Pluggable schedulers? At least a few years ago, there was disagreement about the question whether that was a good idea. - Pluggable window managers? From what I read on the internet, these seem popular, but I think there is some selection bias there. - Pluggable GUIs? I think that is a bad idea. You can build a system where, say, gnome apps and KDE apps and Java apps all look more or les the same, but I have never seen one where the Lego bricks did not shine through. - Pluggable character sets (aka code pages)? Unicode has won that battle (because it is the best of all the abominations we can choose from :-)) In summary: I like flexibility, but I also think you cannot get a nice coherent system without limiting that. Designing is making choices. If I wanted to create a Linux system for the general public, I would probably have to sacrifice a lot of flexibility to get such a system in a reasonable timeframe.

tytso 15y ago

The question of portable code vs. taking advantage of the best possible system interfaces is a very hard problem indeed. On the one hand, the number of people using non-Linux POSIX compliant OS's have dropped significantly in the last decade. As a percentage of the installed base, either by machine or by user, what's left? The *BSD's, where I'm not sure there is hard evidence that they are growing even by absolute numbers, never mind as a percentage of the total market. Solaris, which Oracle is busily killing by increasing support costs to the point where people are quickly bailing to other alternatives --- in the end I won't be surprised if aside from the one or two big iron databases servers, there are very few other Solaris installations left. AIX? HPUX? Don't make me laugh. The only POSIX compliant OS that is growing is MAC OS X --- and Apple isn't afraid to add new incompatible features to their kernel, and then release software which only runs on MacOS --- and usually people don't wag their fingers at Apple complaining that they are releasing non-portable programs. Instead, Apple is usually lauded for keeping a solid eye on usability and writing programs that have a deep sympathy for the end user. So why is it that a lot of people are kvetching at GNOME for wanting to use kernel-specific features in the name of improving the user experience, when the same complaints aren't leveled at Apple? I think there's a bit of a double standard being applied here....

itgoon 15y ago
I think the difference is "interoperability" v. "integration". The OSS community has typically favored the former, while denigrating MS for the latter. There's benefit to the integration path. MS' tools play very nicely with one another, and it would be nice to see improvements on the OSS side. However, I don't think the Gnome project should go that route. Part of its success has been its modularity - it has been long-lived, and used in unlikely places. Choosing the integration route significantly reduces future options. Heck, what if Oracle decides they don't want the expense of Solaris, and spin it off into its own company (yea, yea, I know)? If Canonical (or other downstream) chose to do something like this, I would think it was a great decision. Ubuntu could end up with a superior experience, if done right. I don't see the point of a core project doing this. There's nothing about the current model which prevents implementing this downstream, or as an add-on for those that are interested.

orenmazor 15y ago

so? It'll just fork and you'll have two camps that spend most of their time porting features across.