Debian GNU/Linux 9 'Stretch' Installer Gets GNU Screen, Linux Kernel 4.7 Support (softpedia.com)

"Debian developer Cyril Brulebois was pleased to announce this past weekend the release and immediate availability of the eighth Alpha development snapshot of the Debian GNU/Linux 9 'Stretch' installer," reports Softpedia. An anonymous reader quotes their article: It's been four long months since Alpha 7 of Debian GNU/Linux 9 "Stretch" hit the testing channels back in July, but the wait was worth it as the Alpha 8 release adds a huge number of changes, starting with initial support for the GNU Screen terminal multiplexer and lots of debootstrap fixes, which now defaults to merged-/usr.

"debootstrap now defaults to merged-/usr, that is with /bin, /sbin, /lib* being symlinks to their counterpart in /usr (more details on: https://lists.debian.org/debian-devel/2016/09/msg00269.html)," wrote Cyril Brulebois in the mailing list announcement, where it states that default debootstrap mirror was switched to deb.debian.org.

Comments

All linked in /usr ?

[psergiu]

All binary & lib dirs linked in /usr ?
That's incredibly STUPID
Don't they know why /usr existed in the 1st place ?

Story time:

Back in the days when today's grumpy old beardy Unix Admins were young PFYs, the Unix operating system and it's ilk were gaining more and more libraries and utilities.
Unfortunately the hard drives at the time were very small so / was running out of space. Thus a new hard-drive was mounted at /usr, and all the binaries and libraries not needed to boot the system into multiuser were moved from /bin, /sbin & /lib into /usr/bin, /usr/sbin & /usr/lib.
This also allowed universities to have labs full of workstations with very small and cheap HDDs and NFS-mount a single /usr (as read-only) to all of them. New software needed on all workstations ? Just put-it on the shared /usr

So:

Those days we have large enough storage devices for huge / partitions and cheap enough that we don't need to NFS-mount them on lots of computers.

If you don't want to have binaries & libraries separated into / and /usr/ JUST PUT EVERYTHING IN / DAMMIT !

Re:All linked in /usr ?

[lordlod]

All binary & lib dirs linked in /usr ? That's incredibly STUPID Don't they know why /usr existed in the 1st place ?

Story time: [...]

Of course they know why /usr existed in the first place, the article references two discussions about the merits and downsides of such a move. To me the critical argument is that the original use case you cited of late mounting /usr to a networked filesystem is already broken, mostly by udev, and fixing it is not realistic or worthwhile.

As for shifting everything to root, I agree reflexively but there are advantages to having /usr, high on the list is the fact that people expect it and that it is the approach that Fedora takes. A move like that would impose considerable work on the entire ecosystem without any clear benefit.

The Bottom Line though is this is a change to the default. Debian does and will continue in the future to support both arrangements. So long as people see advantages in having a separated /bin and /usr/bin and configure their systems that way they will continue to exist as a configurable option.

Re:All linked in /usr ?

[Anonymous Coward]

Of course they know why /usr existed in the first place, the article references two discussions about the merits and downsides of such a move. To me the critical argument is that the original use case you cited of late mounting /usr to a networked filesystem is already broken, mostly by udev, and fixing it is not realistic or worthwhile.

I'm not sure that they remember why the path existed in the first place. I remember the unnecessary joining of /usr/local and /usr/X11R6. I am pretty sure they also forgot that the 'S' in sbin stands for static und not superuser.

Regardless of this it is a bad design decision to change a well thought out file system layout because someone misplaced their files (Hello udev, hello systemd). That would have been far easier changes with less repercussions and kept the system more flexible.

Re:All linked in /usr ?

[Anonymous Coward]

The analogies reasonably extend to usage on SSD + HDD systems...

Or server systems that boot from usb stick.

Re:All linked in /usr ?

[cerberusss]

All binary & lib dirs linked in /usr ?
That's incredibly STUPID
Don't they know why /usr existed in the 1st place ?

If you had read the fffffine article, you'd seen the link to an article that condenses the pros and cons: https://lwn.net/Articles/67007...
Of course they know why /usr existed in the first place.

Basically what it comes down to, is that only embedded systems want that separation. And everyone acknowledges that: "The discussion thus eventually turned toward whether or not Debian would risk losing a significant number of embedded users by not addressing their specific concerns. That question remains open to debate, given its speculative nature."

In the end, it seems the advantages of one /usr directory outweighted the advantages and tradition of separate /usr, /sbin and /lib directories.

Re:All linked in /usr ?

[Anonymous Coward]

Seems the people behind udev break previous utility through weak design resulting in shifts in policy to compensate. They do this repeatedly with all the code they write. They final move is to co-opt all main distros as the only way to enforce policy.

It should not be necessary to fix this. The design should be better to begin with. That might not be realistic but it would have been worthwhile.

Re:All linked in /usr ?

[waveclaw]

I am pretty sure they also forgot that the 'S' in sbin stands for static und not superuser.

I beg to differ: http://www.linfo.org/sbin.html

These file in /sbin were system binaries. That is why /sbin directories are usually not on the default path for users.

Now, /usr/sbin, that one is confusing unless you know the sorrid history of /usr as a shared NFS mount. Files in /bin and /sbin may be statically linked or not even on real UNIX. For boot-time on Linux like Debian, static linking is for stuff in your initrd, rescue images or really really badly written software (*cough* Zabbix *cough*).

The changes directly impact two groups. Power users are going to need to know about /bin, /sbin, /usr, etc. as they are going to mess with their system directly. Package Maintainers are going to have another thing to pull hair out over when converting the raw sewage seeping out of poor developers into functional shipping things to end-users.

Until this impacts regular users or Joe X Windows who runs SteamOS it's like the mechanic changing the brand of shocks in your car. Someone who knows better will be using the correct tools to do the correct thing. Or everyone will hang them out to dry when your transmission drops out of the car on the highway.

Re:Still poisoned by systemd?

[myowntrueself]

Thanks but no.

The question should be; is systemd still optional? Because Debian 8 works fine without it.

Re:screen?

[Phil Hands]

tmux is bigger from what I remember (if you include all the libraries it pulls in that are not already present in Debian Installer).

Also, screen gives you the ability to talk to serial ports, which might be quite useful for embedded use, which is one of the primary use-cases for this (since that is a time where you're talking to the installer over a serial/ssh connection and therefore don't have access to multiple virtual terminals)

If you're already a user of such software, and prefer tmux (as I do too), then using screen for d-i means you can simply type Ctrl-A, rather than needing to escape Ctrl-B to deal with nested tmuxs.

Re:Still poisoned by systemd?

[Anonymous Coward]

Not strictly true, it works with an alternative init, but system D is still everywhere else. The state of maintenance of the alternative inits is far from good and systemd-shim is being abandoned.

It's systemd/debian now, get over it. Accept it or see it as damage

Re:Just ... screen?

[gustygolf]

Thanks, I was wondering what GNU Screen was doing in an installer ... except that your post doesn't actually really illuminate the situation at all.

Anyway, I followed your links for a bit and here's (some) description of it : https://lists.debian.org/debia...

I have a new idea on d-i/network-console: multi-console support (screen/tmux).

For d-i on normal PC, we can simply press alt-F2 to get a console
almost anytime during install, but it's not easy for current
network-console if there's no serial console.
So I'm wondering whether it's possible to add screen/tmux support.

Yeah, it's not worth much, but now I can actually see the use ...