What benefits are there of localizing the workstation even more and making it less portable?

Localization means this:

- more work for permission settings
- more time in setting up workstation
- more work in keeping systems up to date properly
- more costly workstation PC versus low cost terminal
- less easy to lock out systems on the network
- isolated systems don't have redundancy and if loss occurs means more downtime

Networkization means this:

- less time in permission settings
- less time in system updates
- terminals only require a minimal upgrade meaning less is pushed out over the network saving bandwidth.
- easier to lock out unauthorized terminals from network services
- lower cost of terminal units versus full sized workstation
- redundancy increases loss prevention

I think people are missing the point here. The issue is not whether /bin and /lib should be merged into /usr or not. It's that udev and systemd are dependent on the contents of /usr during early boot. That is the underlying problem. The answer is to make early boot self-contained, but that will require work and it's easier for Lennart and Co to simply declare a separate /usr filesystem unsupported and ignore the fact that many sysadmins already rely on the ability to do this.


If something needs to be available during early boot, then to me the obvious place to put it would be /boot. If that means having to implement a udev-lite for early boot and then the full-function udev in /usr that takes over later when everything is in place, then so be it.

We get the advantages of all the system binaries in one place (/usr) and still get all the advantages of having it separate and shareable.

1 members found this post helpful.

I am not advocating Localization.

/usr move has benefits to both sides as well. The costs of the move are minimal if you read online about why Solaris and Fedora decided to move them.
Solaris is far from a local machine.
There is costs to everything.

Mercury... you're missing the point. The point of what Lennart and Company are wanting to do is to create a monolithic system to where it requires localization to gain access to system resources that it shouldn't without permission.

/usr is not a local system directory, it's a network extension directory the same as /opt is. In fact, /opt, /home, and /usr are the exact same directory types. A system independent directory.

The benefits of not having /usr localized are far more reaching than what I hinted at. In fact it's more secure to have less localization because less is accessible from a local machine that could be compromised.

Think about this...

How much data could you steal off a machine that has everything localized with a simple Ubuntu Live Disk.

Pretty much, everything. In fact, I hack people's broken PCs with an Ubuntu Live disk to reset lost passwords, retrieve data, and scan for malware. I can even use a tool to break through NTFS's EFS with ease.

How much data could you extract off a system that only has a read-only root file system?

Only the data that is immediately there and nothing else. And not only that, if a network permission system is setup on the local terminal, I can not access server resources.

You can include systemd in the initrd for that. I think this is now recommended over busybox init but both should work. That is obviously their preferred solution.
You could still use a PXE boot using a remote initrd that can mount a remote /usr, thus eliminating any localized content on the thin client. This is just more work.
System data is not valuable to steal. The /usr merge does not prevent you from hosting /home and /var elsewhere, so any local theft would be relatively harmless.

2 members found this post helpful.

@T3Slider

I would like to mention that you do write a lot of credible stuff on LQ and I learn things from you. Sure there will be times we might disagree. I didn't want to come off at you in that type of way while writing in here. I have no hard feelings towards you. Its always good to learn from each other.
regards

1 members found this post helpful.

Yes, and Network Admins want to cut down on work needed to reduce downtime, increase productivity, and have one less problem to stress them out. However having PXE would solve some problems but introduce others as well such as slower boot times because everything would still need to be accessed over the network and if the network is down then the system doesn't boot. If it used a localized /(root) only partition the system could be scripted also to wait at the boot process until the network becomes available such as a steady read, check, and sleep for X time if the network is down and then repeat the process.

Or even then load the local system and then have the user log in to /home using the bash terminal and load everything from /usr and such file systems upon accessing their files. The possible configurations are many.

However, you want to be able to access the right stuff at the right time, and with the right permissions, security clearances, and with the right configurations.

That's true, that should fine for thin clients, and they rely on PXE already so it's not that much of a change. A bit more work, but probably not that big a deal.

Regular servers (VMs or containers) are a different story, IMHO. Today, you can have a farm of web servers running off the same shared /usr mount point, while at the same time keeping essential boot binaries local.

To me, that's as close to the ideal scenario as you can get. Moving the system binaries into /usr complicates things, and the only realistic way around it is a rather large initrd (it has to include kernel modules as well, as /lib is also supposed to move to /usr). If you're currently not using initrds at all (I'm not), this is not what I'd call a trivial change.

We'd only be doing this for one reason: systemd can't handle /usr being mounted later in the boot process. While I don't like being ambushed by developers who wish to make sweeping changes to the system that has served me well for many years, that's actually not my main issue with this proposed change. That part that scares me, is that the existence of the /usr split evidently came as a surprise to the systemd developers. There are a few books on Unix and Linux system administrations they must have missed. Like, all of them.

The fact that a daemon designed to be the ultimate solution to all things hotplug couldn't deal with /usr popping up later in the boot process, is really hilarious. Or it would be, if it hadn't caused all this trouble.

4 members found this post helpful.

It only just now occurred to me that you think my comment was referring to you. It certainly wasn't, and I'm sorry if the context made it appear as if it was.

1 members found this post helpful.

yes i realized that later. my bad. The "lazy admins" was a result to that statement and was kinda like a backlash at the wunderkind. You guys are good people. We are still on the same boat even if we may disagree on certain things.
The admins and developers need to end this friction between each other.
Developers need to listen to the admins more on specific problems instead of the Lennart way of doing things, and admins need to ask the developers more before making statements on things they don't fully understand. The end result will be better harmony for both sides.

Peace

Do you guys actually know about the --enable-split-usr flag when you build systemd from source ?

1 members found this post helpful.

The whole debate started because the option was marked as deprecated quite some time ago.

Sorry I tought the discussion was about the fact that /bin, /lib, etc.. should be symlinked in /usr/.
As for the /usr on a separate partition, who does that anyway?

Networked systems that serve as redundancy and mirrors.

I have to say this for Lennart Poettering... I now dislike him even more as to his lack of understanding of Networked Operating Systems is now ever more so blatantly clear. His lack of knowledge in areas he is trying to change drastically is becoming ever more so profound.

That article from the FreeBSD people http://forums.freebsd.org/showthread.php?t=22444 , especially Phoenix's comment really makes you wonder if all this "change" to Linux is going correctly:

Even I'll dare to say it... Let's not push too hard on our house of cards (the fundamental GNU/Linux OS), lest the house collapse and it takes forever to rebuild everything from scratch.

You can still pre-mount it from the initramfs so everything will be ok. I don't understand what is the problem.