SoylentNews is people
SoylentNews
Phoronix reports the systemd developers are having their first conference. Here is a direct link to the YouTube video channel.
Whether you love systemd or hate it, it looks like it's not going away. If you dislike it maybe one of these videos might change your mind.
This discussion has been archived.
No new comments can be posted.
'systemd' Developers Have First Conference
|
Log In/Create an Account
| Top
| 105 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
The clothes have no emperor.
-- C. A. R. Hoare, commenting on ADA.
(Score: 5, Interesting) by Zz9zZ on Tuesday November 10 2015, @05:58AM
Systemd does some very cool stuff, no doubt about it. However, from LP's own talk about cgroups there is little need for all this magic on desktops! So why isn't this a server optimized package to be optionally installed for those who need such capabilities?
From the same talk, systemd now controls all permissions, and a lot of it happens automatically. The system will manage everything for you, and you must only request what you need to have it magically delivered.
Here's a rough quote: "There shall be only one writer to the cgroup tree! Except when delegation is involved. Delegation, again, means that this other manager manages this specific subtree of the big tree. To give an example, LXE currently puts itself on the top level of the tree. SO that there's systemd, then next to it is this other tree with its own cgroups. And that is not allowed, but what is allowed now is that systemd has the big tree, then lxe asks for its own little unit where it gets what it needs and does what it wants."
On one hand you have a system that is able to manage all the sub-processes, however it also means that compromising Systemd will give any process full access to anything on the system. You are no longer able to compartmentalize a system.
"We are basically stalling on the kernel people to do their work and fully port all the remaining controllers to the Unified Hierarchy."
Is it just me or does this sound like a cyberpunk spinoff of LOTR?
Diversity is good, diversity breeds strength. Unification and specialization breeds a certain kind of strength, but one flaw becomes an Achille's Heel.
~Tilting at windmills~
(Score: 2, Informative) by liquibyte on Tuesday November 10 2015, @07:20AM
package.mask
kde-misc/kcmsystemd
sys-apps/gentoo-systemd-integration
sys-apps/systemd
sys-apps/systemd-readahead
sys-apps/systemd-sysv-utils
sys-apps/systemd-ui
sys-devel/systemd-m4
(Score: 3, Insightful) by Anonymous Coward on Tuesday November 10 2015, @08:24AM
Umm, systemd is pushed by the Freedesktop people (those trying to turn Linux into a Windows 8 competitor). Server people tend to be the graybeards that the systemd developers despise, because they want systems that work, never change ("never change a working system", "if it works, don't fix it") and can do whatever the admin needs with a few lines of shell scripting (another thing the systemd developers hate).
(Score: 4, Insightful) by FatPhil on Tuesday November 10 2015, @09:18AM
Yours, Greybeard, one of the latter.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by opinionated_science on Tuesday November 10 2015, @11:44AM
The AC is onto something. LP has made it clear one of the central goals of systemd is to give the distro wars a way to make peace.
Systemd + BTRFS would make it possible to run applications with specific version of libraries without reconfiguring your system.
Combine this with a patching linux kernel, and it become possible to imagine a very stable end result.
Unless you are administering *millions* of machines (i.e. like Android), it might be hard to see the vision that is behind this...
I am not (administering anything past this one!) but I did watch a few you tube snippets a few years ago...
My summary - it works quite well, but the interface is a bit of a "challenge" sometimes...
(Score: 3, Informative) by LoRdTAW on Tuesday November 10 2015, @01:21PM
We already do that with chroot environments.
(Score: 2) by opinionated_science on Tuesday November 10 2015, @01:33PM
Sure and I use LD_LIBRARY_PATH to reroute applications. But what was proposed (on his blog) was that say Redhat has deployed some neat application v2.0 and you are using Debian and they only have v1.0. In principle you could mix version of a wholelotta stuff , but with out having to mess with the system. The "subvolume" feature of BTRFS would allow just the files need to be export.
The vision presented was that instead of package managers holding the components of the distribution, the whole distro becomes a volume.
The advantage of a volume would that it could be signed etc... but (and I am guessing there) I think it means applications would be distributed as subvolumes with all their dependencies.
I know it sounds whacky, but if you want reliability on a large scale, this is one of the ways...
(Score: 3, Insightful) by LoRdTAW on Tuesday November 10 2015, @02:07PM
So they poorly reimplemented namespaces and a vfs like plan9 did over three decades ago. This is just more unnecessary "oh shiny!" complexity layered on top of existing complexity.
(Score: 4, Insightful) by LoRdTAW on Tuesday November 10 2015, @04:12PM
Okay, this part I missed. It is wacky, completely bonkers if you ask me.
If you think mixing a bunch of mutually incompatible applications through some partitioning scheme promotes large scale reliability, you have another thing coming. I can only imagine the mess this will promote as people upgrade by adding partitioned apps while leaving old code in place. Before you know it, you have a tangled web of mutually incompatible applications running on top outdated code. Sound familiar? Oh sure you can upgrade the OS underneath but why not do that to begin with? I can only see this encouraging bad upgrade paths by allowing people to perpetually run old bug ridden security swiss cheese code because it's easier to pop in that new app container and be done with it. You can argue all day how these scenarios can be mitigates by best practices but let's be honest here, the vast majority is lazy to varying degrees including you and I.
And this isn't an easy problem to solve. We have so many different pieces of software talking to each other that it is very difficult to get everyone on the same page. Libraries, apps, kernels, userspace tools, api's, protocols, frameworks, etc., all add in enormous amounts of complexity and weave a delicate web that is your OS. I think we are at a point where there are so many miles of shit piled up, we have no choice but to pile on more shit held on by duct tape to keep it all from falling apart. One thing Rob Pike was right about, we have completely stagnated in the area of OS research. And that is hurting us.
(Score: 0) by Anonymous Coward on Tuesday November 10 2015, @04:14PM
Unix has retarded OS research by 10 years and linux has retarded it by 20.
— Dennis Ritchie as quoted by by Boyd Roberts in 9fans.
(Score: 2) by LoRdTAW on Tuesday November 10 2015, @04:22PM
I think Linux is retarding it by more than 20 years thanks to systemd. Worse is better, should be the mantra. Features only add unnecessary bloat and do nothing for the consumer and torture the developer along with IT.
(Score: 2) by opinionated_science on Tuesday November 10 2015, @04:26PM
you should see opensuse leap. Essentially I agree that it is going to seem messy, but I give LP some leeway because Pulseaudio started as awful and is now indispensable.
Seriously, I can have audio flying via bluetooth or HDMI and it just works.
I am a bit miffed about the huge package shift that occurs every now and again (e.g. Opensuse tumbleweed tried to address this), so it might actually be the opposite of complicated.
It may actually permit small changes?
Trying to be constructive, because I know that *I* am not writing any of the code, and I am happy someone is!!!!!
(Score: 0) by Anonymous Coward on Friday November 13 2015, @03:24AM
Pulseaudio is still awful though...
(Score: 1) by Alias on Wednesday November 11 2015, @03:09AM
So, basically... Containers...
(Score: 1) by Alias on Wednesday November 11 2015, @03:05AM
"Systemd + BTRFS would make it possible to run applications with specific version of libraries without reconfiguring your system."
That was possible before systemd. There are a variety of ways to do it. One way is to just link the app executable against the version of the library you want. The unversioned entries in /lib are usually just symlinks to the latest version of a library. Unless you remove the other versions, the other ones can be there happily forever. You could also just statically link binaries, thereby making this a total non-issue. There are some other benefits to static linking too. There is also chroot. There are really a lot of solutions to this that have been around for a long time.
(Score: 2) by opinionated_science on Wednesday November 11 2015, @03:36AM
you'll get no argument from me, I have used all of those methods! The one being proposed (AFAIK) is that with BTRFS there is high compression, security (against hacking) and automatic deduping. And it is a proper volume. So distros can use that hard work of making sure packages work together, and users can run what they need.
Let me be clear; BTRFS nearly killed my SSD (the actual comment in the sources was "shred") so I haven't touched it in a year. I am using ZFS. I have had my own fights with systemd that were pretty stupid security holes. But I overcame and I guess they patched it!
But I really do see a need for linux to become considerably more robust, so we can get sufficient momentum to exploit the enormous size of the Android ecosystem, and perhaps raise the percentage of desktops to....5%?
Seriously though, I watched a couple of the talks and I get the strong sense they are "down in the weeds" developers and they want it all to work *really* well.
I think that after a while some folks just want to argue - there certainly aren't as many developers as there are detractors!!!
My $0.02.
(Score: 1) by Alias on Wednesday November 11 2015, @05:27AM
"But I really do see a need for linux to become considerably more robust, so we can get sufficient momentum to exploit the enormous size of the Android ecosystem, and perhaps raise the percentage of desktops to....5%?"
I do think app sandboxen that could keep their sand thoroughly contained and prevent it from smelling or poking any part of the underlying HW/SW would be good. I'm not really comfortable with the level of permeability that containers seem to have.
I don't think the Android or Steam ecosystems will be truly available on a Linux desktop with free graphics drivers that work well until someone invents a way to make "secure" UEFI the only boot environment for desktops, at which point, we will all be ants in Microsoft's ant farm anyway, and I will probably become a lawyer because it will be the only remaining way to make any money in North America.
(Score: 2) by opinionated_science on Wednesday November 11 2015, @12:40PM
well there is a chrome plugin that runs android apps? So if you create a VM and run android in it....might be useful? Just throwing a few things out there, as computers are getting faster, somethings just become possible. Virtualisation for example, is almost turnkey, but maybe a bit complicated?
(Score: 3, Insightful) by novak on Wednesday November 11 2015, @12:27AM
systemd is pushed by the Freedesktop people (those trying to turn Linux into a Windows 8 competitor). Server people tend to be the graybeards that the systemd developers despise, because they want systems that work
I think that's part of their bait and switch. When talking to server people they say, "oh, I realize you don't want many of these features but we are using them to develop great cross-distro desktops." And the server guys say "well, ok then." When talking to desktop users, they say, "Yeah it might have a bug or two but the server guys need it yesterday for containers and cgroup features that you don't understand."
I often see people say "I'm not qualified to comment on systemd technically." That right there should raise red flags, you're running a system that you can't understand? Who fixes it when it breaks? It's probable that no one with one or fewer PhDs is qualified to comment on it technically. And that is a pretty harsh technical comment.
Systemd, perhaps best described as an object oriented dependency network for changing system state reminds me in many ways of certain object oriented languages which seem too try to add as many features as possible and then allow you to concatenate them all. Is C++ better than FORTRAN? In what cases? How do you measure it? Does it not depend on which features are used? And, of course, the kicker: If C++ is better on average does this mean we should deprecate FORTRAN bindings in all libraries and compilers so that people can't use it?
novak
(Score: 0) by Anonymous Coward on Saturday November 14 2015, @09:47AM
Do not confuse true server graybeard with devops/*aaS/web bleached hipster beard.
The latter is basically about cramming a would be desktop distro (used to be Canonical's Ubunutu, seem to be shifting towards Fedora workstation or Arch) into a "container" and calling it a web service/app.
(Score: 4, Interesting) by VLM on Tuesday November 10 2015, @01:36PM
Systemd does some very cool stuff, no doubt about it. However ... there is little need for all this magic on desktops
I find it ironic that the end result of the whole disaster of systemd, after enormous agony and effort switching at work and home to freebsd, is I now have cool new stuff available that I actually use, like ZFS and PF and CBSD/jails and ports.
So now that the pain of having to abandon Debian after roughly 20 years is over, I really enjoy the new features systemd brought me. ZFS absolutely rocks! Thanks systemd! Without systemd I'd never have upgraded!
I did scrub thru some of the systemd youtube videos (this is from last week or so?) and I didn't see anything I was missing and I don't miss anything I saw. Its kind of like a high school reunion, in that way.