GNOME 3.13.2 Temporarily Depends On Systemd

[stevenc]

You really believe that everything has to work on a 1980s Unix kernel and nothing new is allowed beyond drivers.

^^ I actually like the sound of this. Still leaves plenty of room to improve things in userland, having a dependable core system, then trying to fulfil every conceivable use case by extending it, toward a better user experience for everyone.

That's fine, but the rest of us would like to move forward.

By throwing away the existing interfaces, on which years' worth of software was developed? Most of it still around for having proven itself, become well understood, well documented in literature?

Your idea of moving forward sounds like rewriting everything anew, to be buggy again, to be learned again, perhaps only advantageous in specific use cases. And rinse and repeat this process every couple of years...

[psychoticmeow]

By throwing away the existing interfaces, on which years' worth of software was developed? Most of it still around for having proven itself, become well understood, well documented in literature?

Unfortunately in reality, we have Xorg and Makefiles and sysvinit, each of which has proven itself to be a burden in its own special way, and not particularly well documented either. Almost nobody understands how Xorg works, or how Makefiles work and unless you've been writing sysvinit scripts for years it comes across as a completely batshit solution.

Your idea of moving forward sounds like rewriting everything anew, to be buggy again, to be learned again, perhaps only advantageous in specific use cases. And rinse and repeat this process every couple of years...

So you've seen the future? Or are you just trying to strawman the hell out of us?

[kpedersen]

^^ I actually like the sound of this. Still leaves plenty of room to improve things in userland, having a dependable core system, then trying to fulfil every conceivable use case by extending it, toward a better user experience for everyone.

Heh, yeah. I also like this idea.
Admittedly the slow release rate seems to work extremely well for Windows and I notice that Mac OS X also mutates at a much slower rate than Linux. If I was developing a large project over a 10 year period, I would certainly think twice about using Linux (and I did. Thats why we are using FreeBSD).

That said, I believe Oracle might be seeing a market here in that their "Unbreakable Linux" project actually provides a standard (stable) RHEL6 userland but with their own kernel which is as modern as version 3.8.13. This is brilliant. All the modern driver support without all the stupid ignorant Linux bullshit of modern distros

[Krejzi]

if it is dbus communication, then linking simply makes no sense at all. you provide connecting interface as part of your app and that is it. if it wouldn't be so, then whole point of dbus would make no sense. with dbus communication... YOU DON'T implement innards, that is up to server providing interface. so, if sysv somehow satisfied dbus interface for logind... why not? client should not notice any difference

so, yea this is surely temporary fast hack. it is simply faster to set up environment like that and later abstract it by defining connecting interface+remove dependancy. the only way where you would depend on original interface is if that interfaces definition would be abstracted from its owner in order to provide base for other implementors. i don't like gnome how it evolves, but that won't make me bash it where it doesn't deserve

Actually, mutter links to libsystemd for one and only one function:

src/backends/native/meta-launcher.c:  if (sd_pid_get_session (getpid (), &session_id) < 0)

From man page: sd_pid_get_session() may be used to determine the login session identifier of a process identified by the specified process identifier.

[Akka]

Heh, yeah. I also like this idea.
Admittedly the slow release rate seems to work extremely well for Windows and I notice that Mac OS X also mutates at a much slower rate than Linux. If I was developing a large project over a 10 year period, I would certainly think twice about using Linux (and I did. Thats why we are using FreeBSD).

That said, I believe Oracle might be seeing a market here in that their "Unbreakable Linux" project actually provides a standard (stable) RHEL6 userland but with their own kernel which is as modern as version 3.8.13. This is brilliant. All the modern driver support without all the stupid ignorant Linux bullshit of modern distros

Red hat Enterprise 6 came 2010 and end its extended life phase ends Q4 2023 according to wikipedia

[kpedersen]

Red hat Enterprise 6 came 2010 and end its extended life phase ends Q4 2023 according to wikipedia

Exactly. Which is a great lifespan for an OS. However by that point the RHEL 6 kernel will be so old that it will not support newer hardware.
This is where Oracle's repackage of RHEL might work really well. By keeping the kernel much more up to date but leaving the rest of the userland intact.

From what I can see, the kernel that comes with Oracle's version of RHEL 6 is even newer than RedHat's RHEL 7.

[Scimmia]

^^ I actually like the sound of this. Still leaves plenty of room to improve things in userland, having a dependable core system, then trying to fulfil every conceivable use case by extending it, toward a better user experience for everyone.

I guess we need to go back to 16 bit computing, then. 16MB memory limits. No virtualization. No core improvements allowed.

By throwing away the existing interfaces, on which years' worth of software was developed? Most of it still around for having proven itself, become well understood, well documented in literature?

Your idea of moving forward sounds like rewriting everything anew, to be buggy again, to be learned again, perhaps only advantageous in specific use cases. And rinse and repeat this process every couple of years...

Not throwing away, adding to. Yes, it has to be done, new functionality that advances computing is a good thing. I'm sorry that you can't see this.

[Chousuke]

There are differences Chousuke:

• The BSDs base software consists of applications that perform a limited, well definined function. They're also independent of each other, if something in your cat binary breaks its not going to affect any other binary unless cat is a specific dependency. In systemd, they're all tied together. udev is the main duct-tape, glue, whatever term you'd want to use for systemd-udev. If anything breaks udev, the entire monolith breaks apart.
• The BSD userland is mostly POSIX compliant and can be run on top of the Linux kernel, or the illumos kernel without much difficulty, unlike systemd on BSD, which will never happen at least for FreeBSD and OpenBSD, and I doubt illumos is interested either.

• This point is flat out wrong, and not a difference, since systemd is exactly the same. Killing either udevd or journald doesn't do anything... they just restart. Of course, if you have problems with either at a critical time, you lose the services they provide, and might run into trouble. Do you think the BSDs could boot without /dev? dbus seems to be the only thing that can't quite automatically recover from dying (It might be just Gnome... killing dbus killed my gnome session and it seems I couldn't get a terminal up with just ctrl-alt-f2, though I didn't spend much time trying... Maybe I needed to press some other keys as well? I just pressed ctrl-alt-del to reboot (which happened cleanly, so the rest of the system was still running okay. And it took about 4 or 5 seconds counting from when I pressed the keys, so it's not like I had much downtime )
  
• There's no need for systemd to be portable... Just like there's no need for the BSD core tools to be portable to other kernels. However, systemd does use dbus interfaces quite thoroughly, so it is certainly possible for alternative tools to provide those same interfaces (No-one seems interested in doing that, though)

[Chousuke]

Expanding on my earlier response, I think I know why my terminal didn't appear. X (VTY1) uses my Radeon GPU, whle console VTYs appear on my integrated graphics output since that's my boot GPU, and it outputs via VGA to a monitor that is also plugged in to the Radeon via HDMI, and I didn't think to switch the inputs from the monitor... So I guess even dbus crashing isn't that big a deal. Also I can apparently do mixed multimonitor console+X. I'm not sure if that'll ever be very useful, but it's pretty neat anyway.

[kpedersen]

I guess we need to go back to 16 bit computing, then. 16MB memory limits. No virtualization. No core improvements allowed.

Not throwing away, adding to. Yes, it has to be done, new functionality that advances computing is a good thing. I'm sorry that you can't see this.

With regards to virtualization, 5 years ago around 90% of machines that consumers would buy supported it. Now because everyone is buying crippled Microsoft Surfaces or other crappy tablet devices, virtualization support is actually now less common
I wouldnt be overly suprised if VT support was removed from the default kernel again haha.

If we are going to be dragged more and more into the cloud by bad decisions. There is no reason why future machines wont be limited to 16MB to make sure we are completely reliant on external servers.

The bright side is that it could be a good excuse to trim some fat off Linux I guess