Systemd Works On More Btrfs Functionality

[phoronix]

Phoronix: Systemd Works On More Btrfs Functionality

With the systemd developers pursuing their vision for how distributions/software should be distributed, more Btrfs specific functionality is being added to the init manager...

http://www.phoronix.com/scan.php?page=news_item&px=Systemd-More-Btrfs

[blackout23]

I'm more excited about the Limba approach to software bundling. Technically the systemd vision sounds really elegant where a distro update, framework updates and apps are all basically the same (btrfs subvolumes) and you get your incremental updates, rollbacks, dedup etc. but that's also very invasive.
I'm also not sure if big runtimes are the right thing. We probably don't even want to end up in a situation where there are 20 runtime provides. A Gnome Runtime would also include libraries that aren't from Gnome. I think the experimental Gnome 3.16 runtime also ships a glibc, but Gnome probably doesn't care as much about glibc as the glibc project. So glibc should be provided and bundled by the glibc devs. There would be exactly one glibc bundle per version on Linux, with one hash, and the enviroment that the app was developed in is constructed from all the upstream bundles on the fly.

http://blog.tenstral.net/2015/03/limba-project-progress.html

[gens]

There would be exactly one glibc bundle per version on Linux, with one hash, and the enviroment that the app was developed in is constructed from all the upstream bundles on the fly.

glibc should be a C standard library
imo almost all extensions should be thrown out, except the couple that should/will/are pushed to ANSI/POSIX
glibc is great, with some cleanup it would be API compatible for decades to come


bdw, has anyone tried to delete a 10gig file off of btrfs ?

[justmy2cents]

I'm more excited about the Limba approach to software bundling. Technically the systemd vision sounds really elegant where a distro update, framework updates and apps are all basically the same (btrfs subvolumes) and you get your incremental updates, rollbacks, dedup etc. but that's also very invasive.
I'm also not sure if big runtimes are the right thing. We probably don't even want to end up in a situation where there are 20 runtime provides. A Gnome Runtime would also include libraries that aren't from Gnome. I think the experimental Gnome 3.16 runtime also ships a glibc, but Gnome probably doesn't care as much about glibc as the glibc project. So glibc should be provided and bundled by the glibc devs. There would be exactly one glibc bundle per version on Linux, with one hash, and the enviroment that the app was developed in is constructed from all the upstream bundles on the fly.

http://blog.tenstral.net/2015/03/lim...-progress.html

i think you're judging too much on first try

in ideal world you'd see smaller runtimes each providing API/ABI stable versioned implementation. i'd imagine gtk being outed from gnome runtime too. something like C runtime > Gtk runtime > Gnome base runtime > Gnome apps. in this case each runtime can be upgraded under same version as long as it can provide same API/ABI as previous one, when API/ABI breaks you just add new version

something as C or Gtk runtime (once it hits 4.0 it will probably be much easier) should be able to keep API/ABI stability much longer than desktop. but, main thing is that number of them doesn't really matter as you only care about correct version.

[gens]

please don't put a libc and a gnome lib in the same basket
only one of those actually cares about backward (and forward) compatibility

[RahulSundaram]

please don't put a libc and a gnome lib in the same basket
only one of those actually cares about backward (and forward) compatibility

Whatever library is within the GNOME Platform must maintain ABI compatibility for the entire major version. So not that different.

[Nille]

only one of those actually cares about backward (and forward) compatibility

You can't mean the glibc ... like there abi break in 2.19

[iwbcman]

A lot of the stuff that Redhat is working on is really cool tech. The stuff they are planning with BTFS is incredibly promising and exciting. However I do feel as though the changes necessary to make such a reality may actually threaten the hands-on tinkering which has historically driven Linux. I started playing with Linux in 1994 and installed SuSE as my primary desktop back in 95/96. I used SuSE for 5 years and learned nothing about Linux(which is perhaps how it should be ) In 2001 I jumped on the portage(Gentoo) bandwagon and was hooked, used it exclusively for almost 6 years and wow did I learn a lot. I always found the Debian community offputting to the extreme and it took me quite a while to warm up to Ubuntu, which I really loved the first handful of years it was out. Now that I Grok the Debain/Ubuntu way I can work well with those systems and I usually install Mint nowadays for day to day stuff. Fedora I have only used infrequently and I have to admit the only time I get scared installing Linux anymore is dealing with Fedora. I grok Fedora/Redaht at roughly the same level as I grok Debain/Ubuntu, whereas I understand Gentoo,Funtoo and Linux from scratch. ( never used Slackware, or Arch). Some of the changes being envisioned by Poettering and friends represent radical changes in Linux land, which for the most part I welcome, however I wonder if these things ever come to fruition whether I will still be able to roll my own. From my perspective Nixos does already most of they want to do, just in a different fashion(and they don't have things like BTFS dedup/subvolumes etc.) I think Poettering gets a lot of bad press because he and his gang ( ) are absolute system control freaks. They are on a grand quest to eliminate bugs (!features ).

When an application becomes an entire runtime framework, cryptographically verifiable all the way down, when I install an app on my system it and all of it's dependencies all the way down are identical to what you have on your machine when you install said app. From a bug fighting POV this is the Holy Grail. Any bugs can be absolutely isolated, identified and triaged whereas nowadays there are so many variables (which version of what compiled against which version of what, with which configure options beings passed, which system libraries vs. in-house bundled versions etc.). From a dev's point of view a clean build environment make all the difference in the world, both Debain and Fedora kind of suck on this front in contrast to the Gentoo/Funtoo, but thats because Debian/Fedora aren't tailored to compiling (being binary distributions) unlike Gentoo/LFS. Nixos fights everything you do every step of the way unless everything you do is the Nixos way, neat in theory, horrific in practice unless you spend all of your time learning functional programming to to program Nixos to compile for you(Debian and Fedora are also similar in this way, Nixos just takes everything to the next level and is perfectly self-referential/consistent. Conary also did something related to this stuff providing a degree of certainty that any library against which an app was linked was itself a product of compilation against the same deps and configure options. BTFS brings dedups and subvolumes to the table which prevent you from having to have 35 different versions of a given library on your system at once. I used journalctl for the first time a couple of days ago and made a quick mental note to myself, NEVER simply copy journalctl output and post to a forum unless you want to reveal the exact name of each and every file gvfs barfed on during metadata processing to the entire world. Again from the sysop perspective systemd and friends is GAWD-like. Talk about a power trip. If what you want is control, then Poettering et al are hell bent on realizing it. These are things I can really appreciate. However I ran Linux for 7-8 without ever needing to have an initrd, compiling my own kernel and modules-I am not sure if this is even doable in the scenario they are envisioning. I also can't really imagine SuSE and Ubuntu and Debian and Arch and x,y,z all jumping on the same bandwagon to realize these plans. And if they did what exactly would be the difference between them, ie. why one vs. another. Then there's the issue that we will probably never be completely free of proprietary stuff, whether the nvidia blob, or my mobo BIOS, or wifi firmware, which will radically reduce the scope of total GAWD-powers pursued by said developers.

Don't get me wrong, being able to influence the kernel design(kdbus/kms etc), the init system (systemd) and the filesystem(BTFS) all at the same time is pretty heady stuff and the possibilities that derive from such are profound, enabling stuff hitherto completely unimagined. I get it, I can see the appeal. But at the end of the day this is Redhat, not Linux(although this may change) and as much as I can appreciate it, I am wondering what will be left of Linux independent of the distros.

[AJSB]

...on other news, Devuan, Debian fork that cleans it up of systemd, selected XFCE 4.12 as default DE for their project.

Right now my only only Linux distro in use is Slackware but i'm looking forward to test Devuan.

[pal666]

...on other news, Devuan, Debian fork that cleans it up of systemd, selected XFCE 4.12 as default DE for their project.

Right now my only only Linux distro in use is Slackware but i'm looking forward to test Devuan.

systemd haters totally deserve xfce instead of desktop environment