
GNOME Discusses Becoming a Linux-only Project - pdelgallego
http://www.osnews.com/story/24762/GNOME_Discusses_Becoming_a_Linux-only_Project
======
fingerprinter
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
How does this hurt Ubuntu?

~~~
fingerprinter
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
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
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
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
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>

[2] <http://en.wikipedia.org/wiki/GNOME#Name>

------
tytso
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
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.

~~~
tytso
Do you really think GNOME owes its "success" to it being able to be used in
unlikely places? How are you defining "success"?

If you define success by its ability to run in obscure places, then sure, any
change which limits this is going to cause GNOME to be a "failure". But that's
not the only definition of "success" and "failure". Personally, I think the
ability to run GNOME on obscure operating systems isn't all that interesting.
For similar reasons, it really isn't impressive to me that NetBSD can run on
ancient Amiga hardware. And in, fact, NetBSD's obsession of supporting legacy
hardware slowed down their ability to run on modern hardware, I'd consider it
bad and a direct cause of their "failure" in terms of market share as compared
to say, Linux.

There's a similar issue going on here with GNOME and obscure/irrelevant
operating systems. If that slows them down, then they should (IMHO) figure
ways of not slowing them down. And in fact, it's not a complete abandonment of
those lesser/legacy systems. There would be cut down systemd releases that
would support what ever limited functionality that might be provided by that
operating system. If Solaris doesn't have cgroups to provide resource
isolation, then there's not much GNOME or the systemd/Solaris adapter layer
can do to ameliorate the situation.

------
daeken
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.

------
leif
"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?

~~~
asomiv
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
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.

~~~
asomiv
What the hell, why is my post downvoted? I wrote a very informative post. If
someone disagrees with me then come clean and give me a rational reason, not
just clicking on the downvote button!

But to answer your question: no, it's not inetd. Inetd is very inefficient in
terms of CPU and memory usage and has scalability issues thanks to the fact
that it spawns a new process for every client. Systemd does not do that: it
waits until someone connects to the socket, then starts the service and have
the service handle all clients on the socket. Systemd then waits until the
service has exited. The service can use I/O events or threads or whatever
efficient mechanism to handle multiple clients on the server socket, all
within a single process.

This in itself does not require Linux-specific features. However the GNOME
discussion is about depending on systemd which happens to be Linux-specific at
the time for other reasons, not about GNOME wanting to be Linux-only (which is
sensationalist headline). One of the reasons systemd is Linux-only is because
it uses cgroups, which I explained here:
<http://news.ycombinator.com/item?id=2565801>

~~~
demallien
I can't speak for others, but I nearly downvoted you for the first sentence
which was just a gratuitous snark. I ended up not downvoting you precisely
because the rest of the post was informative.

~~~
asomiv
The first sentence is not a snark, it is a clarification. The question why
systemd was invented instead of just using launchd had been raised in the
past. Distributions avoided launchd because of licensing.

------
darklajid
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>

------
beza1e1
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
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>

------
cmiles74
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
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.

------
chalst
David Nielsen in a well-referenced post:
[http://davidnielsen.wordpress.com/2011/05/18/systemd-in-
gnom...](http://davidnielsen.wordpress.com/2011/05/18/systemd-in-gnome-
packagekit-and-what-gnome-as-an-os-really-means/)

>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
> 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.

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

