Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
GNU is Not Unix Linux

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.

This discussion has been archived. No new comments can be posted.

Debian GNU/Linux 9 'Stretch' Installer Gets GNU Screen, Linux Kernel 4.7 Support

Comments Filter:
  • by Anonymous Coward

    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

    • 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?

      • by Anonymous Coward

        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

        • 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.

          • by Cramer ( 69040 )

            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)

  • All linked in /usr ? (Score:5, Informative)

    by psergiu ( 67614 ) on Sunday November 13, 2016 @11:58PM (#53278917)

    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 !

    • by lordlod ( 458156 ) on Monday November 14, 2016 @12:39AM (#53279057)

      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.

      • by Anonymous Coward on Monday November 14, 2016 @01:44AM (#53279209)

        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.

        • by waveclaw ( 43274 )

          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 [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)

        by 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.

    • by Anonymous Coward

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

      • Re: (Score:2, Interesting)

        by Anonymous Coward

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

        Or server systems that boot from usb stick.

    • Re: (Score:3, Informative)

      by cerberusss ( 660701 )

      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... [lwn.net]
      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 de

    • by Anonymous Coward

      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.

    • 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.

    • by hitmark ( 640295 )

      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

  • Do all the news headlines about Debian boil down to ... screen?
    Do they know abut byobu [byobu.co] and tmux [github.io]?
    • It's Debian - they'll enter Stable in 2027.
    • Comment removed based on user account deletion
      • by Anonymous Coward

        It's been in Debian for ages. It's now part of the install disk image.

  • 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.

  • - Bump Linux kernel version from 4.6.0-1 to 4.7.0-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

  • instead of forcing all debian users to systemD, include the option to choose which init system to use during the install of the operating system? that would be nice to have an init agnostic Linux distro,

Never test for an error condition you don't know how to handle. -- Steinbach

Working...