Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs

But Systemd the project keeps absorbing other projects and integrating them tightly with the daemon, which makes it much harder to use them independently. The obvious example of this is that Gnome 3 depends on logind.

Ok, I might be wrong here, but IIRC logind didn't existed before systemd - so systemd absorbed nothing here.

The two projects that I'm aware that was absorbed by systemd are udev and consolekit. Both projects was developed by systemd developers before. IIRC you should be able to build and use udev without systemd, also you can build an old consolekit http://cgit.freedesktop.org/ConsoleKit/tree/ - it's there, no one deleted it. It's just not maintained anymore.

[rdnetto]

I've got one message to all peoples that like to complain about systemd - just write your own software, fork existing or use other os'es if you don't like it.

Your all flame wars are just fucking boring over the years.

tldr; It's not the software, it's how it's managed.

I use Systemd, but I understand why people are upset about it. It's not about the software at all, it's about the way the project is run. Systemd the init daemon is great, which is why everyone is adopting it. But Systemd the project keeps absorbing other projects and integrating them tightly with the daemon, which makes it much harder to use them independently. The obvious example of this is that Gnome 3 depends on logind, which added a hard requirement on systemd. Normally this would have been fixed by moving the required cgroups functionality out into a separate module, but since logind is part of the systemd project there was no interest in doing so.
This kind of monolithic integration is directly opposed to modularity. Until recently, there was no connection between which file system, init daemon and desktop environment you used, and that was great because it increased customizability and lowered the friction for experimentation. The way things are going, that might not be the case in a decade's time.

[anda_skoa]

"almost" in your comment should tell you everything. was much more specific in my later comment.

So, when did the syscall interface for sockets change ABI? I don't think it ever did.
I think, but could be wrong, that the ABI of libc changed once, but then again an older libc would still work due to the kernel not having changed.

"Almost" doesn't tell us anything here, the system interface is one of the most stable, also when compared to other platforms.

actually, i can't see this in his proposal, since he also specifies whole required /usr is carried in runtime snapshot. that would implicate that we could have one dbus in kde snapshot and one in gnome where they could be incompatible if dbus broke ABI and communication protocol between the 2 versions and that would take Linux desktop few years back, not forward

That doesn't change the fact that libraries such as Qt have always used the existing name mechanism to make ABI incompatible version installable in parallel and ABI breaks are mapped into bumps of the major version like you suggested.

On the note of D-Bus, are you referring to the convenience library for implementing the protocol or the protocol itself?
The latter has been implemented in other ways than using the convenience library, a change in ABI of one implementation, e.g. GDBus, does not effect any other implementation.

The convenience library has not changed ABI even once, btw.

Cheers,
_

[ryao]

now take your example in this scenario. rhythmbox never was updated because it works, dbus changes ABI and communication and all remote like apps for rhythmbox either don't work or they are forced to use same old runtime. you get stuck with same old runtime for ages just because one relevant application didn't update/fix. now if those remote apps were part of desktop, will you also use old desktop on that same runtime just because new one would break rhythmbox?

as good as it sounds (mind you, i love systemd and i'm mostly fond of lennarts ideas), issue here is that as much as it makes it "just works" it also provides excuse in a way of "no need to update/fix, we provide you with OUR runtime". another questionable thing here is where the developers "runtime" ends. if they used some custom tweaked kernel/glibc, that one app might just force you to boot in whole new other os. and here is the nightmare, let's say some adobe comes and provides this plagued version of whole os as runtime leading to other vendors following them...

i'd be much happier if this idea wouldn't go so low and if frameworks would be sandboxed and created the same way steam-runtime is. here it is, build it for your self for your distro. at the moment you create this runtime package you're ok to run anything requiring "xyz-3.x". but, same way would needed to be done from apps where first thing that app should do is saying "i require qt-3, dbus-1... ABI runtimes" and then started with correct environment

This is the same problem that Windows has. That is why a single CVE for libpng for instance becomes hundreds of patches and even more that are never made. I suspect that Lennart's automation will deal with this as long as there is a human maintainer telling the package manager what to do. It just needs to provide updates on each individual container in parallel. Problems will likely arise on packages from third party repositories when there is no maintainer.

[ryao]

OMG, a proposal for higher-level Linux features that finally involves a modern file system.
If there is one thing I dislike about Linux (having used BeOS way back, btw), it is that while Linux has many fancy file systems, the feature set is mostly unused by higher-level tools as they are apparently designed to run on file systems from the 1980s.

BeOS implemented something similar to what many people today know as Spotlight, Baloo, etc. directly on the file system: No extra caches or indexes. Under BeOS it way easy to tell an individual file that a particular app has to open it ? it was saved as extended attribute.

If that proposal would come true, finally a new base line for file systems under Linux would be set and then such BeOS-ish features get implemented as well.

I think you are making the mistake of hearing something that sounds cool to you and assuming that means you will get other stuff that you thought was cool. Things do not work that way.

My general understanding of BeOS is that its creamy smoothness came from pervasive use of concurrency via threading. Every UI element had its owndedicated thread that allowed painting to be done independently of anything else. None of this affects that at all. If you want that, you should get in touch with the guy who ported Haiku's userland to Linux:

http://www.freelists.org/post/haiku-...tatus-of-Haiku

That being said, Lennart is correct to mention CoreOS already does this for server systems. I read this as him and others trying to assimiliate the approach in Fedora such that it can be used in desktop systems too. However, I think he is falling into the following trap when he says that he is going to make things work for all use cases:

http://xkcd.com/927/

I also think that Lennart and his friends will consider whatever they create to be hamstrung by insufficient packaging resources. The existing selection of packages for RHEL is limited and that is unlikely to change. The idea to try to assimilate existing binary distributions might help somewhat, but unless Redhat can secure sufficient revenue from it to justify allocating significantly greater additional resources to it, it will be no better than the Solaris desktop, which sees only slow incremental improvements and a limited selection of packages.

Lastly, I think his btrfs plans will require approval from Oracle. ZFS and btrfs are similiar enough that I find it unlikely that btrfs is not subject to the ZFS patent portfolio. If it is subject, then the only company that can use the btrfs source code in a product without risk of a lawsuit is Oracle itself. This is much like how only Microsoft could use the Linux FAT code that implemented both short and long names. If Lennart's btrfs ideas get into RHEL without something being done about Oracle's software patents, Redhat would be an enormous target for Oracle's lawyers.

Some theorecize that Oracle's contribution of the btrfs code without an explicit patent grant makes its reuse in commercial products okay, but I am not certain of that. The patent system exists to stifle innovation for the benefit of those that filed ideas first courtesy of America Invents and was not much better before then. While I am not a lawyer, I cannot imagine a legal defense along the lines of "the code was published for reuse under a license that did not give us a patent grant so we ought to have one" would go very well. That being said, OpenZFS does have an explicit patent grant through the CDDL, so whatever Lennart and his friends create likely could be adapted to use that without risk of producing something that steps on Oracle's ZFS patent portfolio.

[justmy2cents]

The problem is, the same thing could also be done with ZFS, which is both the anti-lennart and BSD fanboys' committee's darling. It's going to be difficult to explain why btrfs is a Trojan horse of the Lennart conspiracy when ZFS is holy.

good catch sadly, there is not enough popcorn for that combo in the world

[uksuperdude]

There is some seriously cool ideas that Lennart is putting forward here, and as many have pointed out are not new.

VMS has used some of the ideas, albeit not in packaging, http://en.wikipedia.org/wiki/Files-11 but the FS of VMS (Open or otherwise) is something to remember fondly.

Also others have mentioned ZFS, which was also an awesome FS, but sadly politics and corporations got in the way there. I actually worked with some of the FS guys who left SUN and moved on to other (dedup/FS projects) and they were some of the best developers I've met.... Of course when your FS craps out, you're not really caring if the dev team was full of good blokes or not

I think we're forgetting a few things here, as a community; one of them is to actually be excited that there are new things being tried and some may work and some may not and some may take a while... It's not always fair to ask someone to 'write a patch or design something better', but seriously, consider what this (or other projects) may bring to not just yourselves, but to the many many different use cases of the Linux community.

Also there is a group of people working on this (backed by RedHat), it's not just Mr Pottering who is driving this, and from the sounds of things, he is including and listening to a great many people who have a great deal at stake and a great deal of knowledge in this area.

I think a big misconception here is the 'move to one linux to rule all', this plan actually gives the end user (developer, administrator and distributor let's not forget) to choose how to manage their system(s). Not happy with not getting an update to a critical package - get a binary diff/patch and this will do it for you without busting your package manager/distro. Snapshot, try a new version of a desktop. Install something else side by side and not care what version of what library is where. Want ARM as well as x86_64 - you can do it.... The de-dup in BTRFS makes it feasible space wise, read-only metadata makes it safe(r) and also lets large systems choose how to allocate LUNs for different workloads. This could make Linux king of embedded to enterprise (even more so in many cases). This is really cool computer science people - I urge you to have a read into some of the concepts and appreciate what this team is looking to do.

I reckon it's worth the time to have a look, and even if it doesn't work often times that's when even cooler ideas are born.

[jacob]

i'm guessing anti lennart comitee now hates btrfs and we're at brink of comment flood where ppl ask "why does btrfs needs to be in kernel?". my chips is ready



ohhh, dear... this image is so awesome, maybe michael should use this to tag lennart topics.

The problem is, the same thing could also be done with ZFS, which is both the anti-lennart and BSD fanboys' committee's darling. It's going to be difficult to explain why btrfs is a Trojan horse of the Lennart conspiracy when ZFS is holy.

I've got one message to all peoples that like to complain about systemd - just write your own software, fork existing or use other os'es if you don't like it.

Your all flame wars are just fucking boring over the years.

[liam]

Sure it does. I can install the required Runtime. It doesn't get in the way from something other. As example, i have an older application that require runtime 0.5 thats since 1 year no longer support. There is nothing against to install this image. And it doesn't affect the rest of the system.

As a other Example. Why not Build Runtime and Frameworks specific for the Linux Standard Base? So i can use it and even my older application that maybe depend on 2.0 can work on a recent system without troubles.

That's always a solution, but he specified 10 year support. Sure, using git you can rebuild the runtime but that's something you can do now.
It's of course possible for major projects to maintain every runtime for X years but I'm not about to assume that.