Debian GNU/Linux 9 'Stretch' Installer Gets GNU Screen, Linux Kernel 4.7 Support (softpedia.com) 58
"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.
"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.
EditorDavid, do you even edit? (Score:1, Insightful)
Seems like EditorDavid isn't actually a real editor in any sense of the word. You see, a real editor would have taken one look at this submission and said, "What a minute... these 3 disconnected paragraphs don't make it clear what 'Stretch' is or why an 8th alpha release is special enough to warrant a post on Slashdot. This was clearly written by someone who may or may not understand the subject well, but doesn't know how to accurately and concisely communicate that knowledge to others. This isn't fit to
Seriously (Score:1)
Why am I interested in alpha build software? In the alpha stages you're lucky it even boots. They now support "screen"? Gee I've been using that for over two decades now. What next, color framebuffer and gopher support?
Re: (Score:1)
This is not about including screen as one of the packages you can install. It's about making it available during network installs[1].
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819988
https://lists.debian.org/debian-boot/2016/04/msg00308.html
Re: (Score:1)
The ability to use a text based window manager during a network install? Exactly zero people will use that, along with this mess of an OS.
Re: (Score:1)
Right. Because no one ever accesses a system via the network or a serial port. God help you if you want to install through one of those ugly interfaces.
(read: systems exist that don't have a gfx console. I have a room full of hardware that doesn't have video chips of any kind. Most of the hardware Sun/Oracle makes has no gfx console.)
Re: (Score:1)
For people who use linux for Real Work(tm), this has been wanted for years. Run an install on headless (serial or network only) hardware and see how much you like the single terminal screen interface. You can't see any logs. You cannot get to a shell to do things outside ("in spite of") the installer. (without exiting the installer)
Re: (Score:3)
Thanks but no.
The question should be; is systemd still optional? Because Debian 8 works fine without it.
Re: (Score:2, Insightful)
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
All linked in /usr ? (Score:5, Informative)
All binary & lib dirs linked in /usr ? /usr existed in the 1st place ?
That's incredibly STUPID
Don't they know why
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. /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. /usr (as read-only) to all of them. New software needed on all workstations ? Just put-it on the shared /usr
Unfortunately the hard drives at the time were very small so / was running out of space. Thus a new hard-drive was mounted at
This also allowed universities to have labs full of workstations with very small and cheap HDDs and NFS-mount a single
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 ? (Score:5, Informative)
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 ? (Score:5, Insightful)
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: (Score:3)
I beg to differ: http://www.linfo.org/sbin.html [linfo.org]
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 you
Re: (Score:2, Interesting)
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: (Score:1)
The analogies reasonably extend to usage on SSD + HDD systems...
Re: (Score:2, Interesting)
The analogies reasonably extend to usage on SSD + HDD systems...
Or server systems that boot from usb stick.
Re: (Score:3, Informative)
All binary & lib dirs linked in /usr ? /usr existed in the 1st place ?
That's incredibly STUPID
Don't they know why
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... [lwn.net] /usr existed in the first place.
Of course they know why
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 de
Re: (Score:2)
Debian will not lose any significant users over this, because anyone who has any sense and uses Linux to Get Things Done already left quite some time ago.
Really? I love Debian. Rock solid, I install it on all my servers.
Re: (Score:1)
Debian is committed to migrate to a full redhat derivative status. Each move to adopt redhat standards allows those who object to bluster, leave.or fold. So far there has been no push back against the process that has had any appreciable change to the direction taken by the distro.
Re: (Score:2)
If you don't want to have binaries & libraries separated into / and /usr/ JUST PUT EVERYTHING IN / DAMMIT !
Things still puke if / fills up. That's why we have /usr and /var today. Keep them. They're good.
Re: (Score:2)
These days you can use LVM and grow filesystems, etc etc. So yeah, that's annoying, I agree. But it's not a show-stopper.
Re: (Score:1)
I agree. On a PC, with the idiotic 4 partition layout, multiple partitions never made much sense. Even when distro's wanted to be all SunOS-like with 18 partitions, I always selected the "put everything in root" option -- if it had one, or went around it's back to do it anyway. (I've actually been doing that to Solaris installs for decades, too. And it does know how big those partitions need to be.)
The largest issue with linux is the lack of any codified standard on what goes where. Even if there were, nobo
Re: (Score:2)
The "all in /usr" comes out of the containerized web monkeys that is running the userspace Linux show these days...
What they do is they boot the "node" (aka computer) via a compressed boot image (initramfs), and then once that has set thing up, they just remount / read only to a SAN backend.
Hell, systemd is basically built around this being the expected way. This to the point that said boot image needs to get dbus up before handing things over to systemd loaded from /. Systemd will then use that for its ear
Re: (Score:1)
Yeah i'll happily take a pass on screen. BTW the binary is setuid root and the source is chaotic. What was that a standard recipe for, again?
This is why NetBSD now has tmux in base and no more screen, BTW.
Re: (Score:1)
Actually, it's setGid (group), so it can mess with utmp. If you don't care about it fucking with utmp, then run it as a normal user. It hasn't needed root for a long time.
(not that anyone cares, but I've run screen on solaris as a normal user for decades. Installed in $HOME/bin even)
Re: (Score:3)
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), th
Just ... screen? (Score:2)
Do they know abut byobu [byobu.co] and tmux [github.io]?
Re: (Score:2)
Re:Just ... screen? (Score:4, Informative)
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... [debian.org]
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 ...
Re: (Score:2)
Re: (Score:1)
It's been in Debian for ages. It's now part of the install disk image.
Dayum (Score:2)
One week after I installed with debootstrap because the old kernel and installer didn't work for me. It was a pain in the ass.
Isn't the 4.7.x Kernel End-of-Life ? (Score:1)
I understand that this is simply the installer, but the 4.7.x Kernel recently went EoL ...
https://www.kernel.org/. [kernel.org]
-- kjh
Re: (Score:2)
how about a choice of init system (Score:2)
Devuan: a fork of Debian without systemd. (Score:2)
Yes, its called Devuan [devuan.org].
"Devuan GNU+Linux is a fork of Debian without systemd."