[DNG] /usr to merge or not to merge... that is the question??
Hi Devuan followers, fans and friends, Debian as of the upcoming Buster release looks to be implementing a merged /usr by default. At this stage there is no plan to make it forced... but you never know what happens when their Technical Committee suddenly decides it's an issue they need to force a decision on... So... for Devuan, do we want to default to a merged /usr in our coming release of Beowulf or are we going to resist another pointless rearranging of the deck chairs... Keen to get some feedback on this Cheers, Daniel -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] /usr to merge or not to merge... that is the question??
A merger is when two or more entities become unified into one entity
like two companies becoming one single company. So, /usr merging
should require other directories becoming part of it. Googling brought
me a question on Ubuntu forums which asked: "Are {/bin, /lib, /sbin}
symlinks into /usr in Ubuntu?" If that is what is understood by this
'fearsome' unification then /bin, /lib and /sbin should become
symlinks with their usual contents moved to /usr. A program should
still be able to find files under /bin, /lib and /sbin provided there
are no two different files with the same name. A disadvantage of the
merger is a merged /usr requires more storage space than before. This
should not be a problem with modern hardware that is more energy
efficient, quieter, and smaller in physical size. Finally, a merger of
a system base directory should not bring instability problems like the
changing of an insufficiently debugged system core executable.
Problems may, however, arise with setups that specifically require
/usr to be unmerged. Here, the question should be how frequent these
setups are, and what role they play in setups that do not tolerate
downtime.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] /usr to merge or not to merge... that is the question??
So, respondents essentially are writing what I wrote, but in more grandiose writing styles. Instead of appealing to the general and writing in abstruct ways, they choose to write giving endless concrete describtions. Well, Pedagogy, the science of teaching methods, strongly insists on using concrete examples with children. Someone even proudly suggested they are going to do research reading like a diligent student doing an assignment! What is being discussed here is the merge of a set of system directories, not some concept requiring a PhD from Harvard or MIT. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fri, 16 Nov 2018 22:11:17 +1300 Daniel Reurich wrote: > Hi Devuan followers, fans and friends, > > Debian as of the upcoming Buster release looks to be implementing a > merged /usr by default. At this stage there is no plan to make it > forced... but you never know what happens when their Technical > Committee suddenly decides it's an issue they need to force a > decision on... > > So... for Devuan, do we want to default to a merged /usr in our coming > release of Beowulf or are we going to resist another pointless > rearranging of the deck chairs... > > Keen to get some feedback on this > > Cheers, > Daniel Can anybody explain the bad points of doing the merger ? I ask this because everything I can find says it is a good thing, but they said systemd was a good thing ;-) Rowland ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fri, 16 Nov 2018 22:11:17 +1300 Daniel Reurich wrote: > Hi Devuan followers, fans and friends, > > Debian as of the upcoming Buster release looks to be implementing a > merged /usr by default. At this stage there is no plan to make it > forced... but you never know what happens when their Technical > Committee suddenly decides it's an issue they need to force a > decision on... > > So... for Devuan, do we want to default to a merged /usr in our coming > release of Beowulf or are we going to resist another pointless > rearranging of the deck chairs... > > Keen to get some feedback on this Back in the what, 1970's, the Unix guys split /usr/sbin, /sbin, /usr/bin, and /bin to accommodate early boot, by separating out statically compiled stuff used in the earliest boot. But then initramfs made these separate directories unnecessary, so why in the world would we continue the split? Well, maybe because initramfs is a PITA many people choose to avoid. When things go wrong, it's the ultimate black box. And I'm very scared that one day Poettering/Redhat/Freedesktop.org will corner the market on initramfs makers, will make them systemd only, sans-systemd distros who have completed the merge will have the choice of backing out the merge or going to systemd. Initramfs (or initrd before it) is the ultimate black box. You can't get your normal voltmeter probes in there: You need to use special stuff that's hard to use. You can init the hard disk with /bin/bash, but not the initramfs. Oh, and not even the /bin/bash if the merge happens. Here's some info on dracut, the most prevalent initramfs maker: https://www.techradar.com/news/software/operating-systems/what-on-earth-is-dracut-1078647 Oooh, notice they say dracut is "based on udev events". If you're avoiding systemd, and Redhat has taken over udev, what could *possibly* go wrong? Here's some recommended reading on "the merge": https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/ https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ The gist of the preceding links is "hey, other programs conflate early with late boot programs, so don't blame us for doing it too. Oh, and by the way, most of those conflaters, like udev, are under our control. Conflation is another form of entanglement, but don't blame us." For those using ext4, assuming a kernel with ext4 compiled in, without need for root disk lvm, encryption, and raid, the init system can immediately use the static executables in /sbin to mount necessary disks and then go about the rest of the boot. Systemd loves to brag about their boot time, but on a system with ext4 drivers compiled into the kernel, a separate /sbin guaranteed on the root partition, and minimal use of udev in the boot (you *could* run it as a daemon, in parallel, using runit), boots would be quick indeed. Switch-root, killall5, and all the other stuff done before disks begin to mount, goes away. I vote against "the merge". SteveT Steve Litt November 2018 featured book: Manager's Guide to Technical Troubleshooting Brand new, second edition http://www.troubleshooters.com/mgr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fri, 16 Nov 2018 05:11:01 -0500 Steve Litt wrote: > On Fri, 16 Nov 2018 22:11:17 +1300 > Daniel Reurich wrote: > > > Hi Devuan followers, fans and friends, > > > > Debian as of the upcoming Buster release looks to be implementing a > > merged /usr by default. At this stage there is no plan to make it > > forced... but you never know what happens when their Technical > > Committee suddenly decides it's an issue they need to force a > > decision on... > > > > So... for Devuan, do we want to default to a merged /usr in our > > coming release of Beowulf or are we going to resist another > > pointless rearranging of the deck chairs... > > > > Keen to get some feedback on this > > Back in the what, 1970's, the Unix guys > split /usr/sbin, /sbin, /usr/bin, and /bin to accommodate early boot, > by separating out statically compiled stuff used in the earliest boot. > But then initramfs made these separate directories unnecessary, so why > in the world would we continue the split? > > Well, maybe because initramfs is a PITA many people choose to avoid. > When things go wrong, it's the ultimate black box. And I'm very scared > that one day Poettering/Redhat/Freedesktop.org will corner the market > on initramfs makers, will make them systemd only, sans-systemd distros > who have completed the merge will have the choice of backing out the > merge or going to systemd. > > Initramfs (or initrd before it) is the ultimate black box. You can't > get your normal voltmeter probes in there: You need to use special > stuff that's hard to use. You can init the hard disk with /bin/bash, > but not the initramfs. Oh, and not even the /bin/bash if the merge > happens. > > Here's some info on dracut, the most prevalent initramfs maker: > > https://www.techradar.com/news/software/operating-systems/what-on-earth-is-dracut-1078647 > > Oooh, notice they say dracut is "based on udev events". If you're > avoiding systemd, and Redhat has taken over udev, what could > *possibly* go wrong? > > Here's some recommended reading on "the merge": > > https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/ > > https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ > > The gist of the preceding links is "hey, other programs conflate early > with late boot programs, so don't blame us for doing it too. Oh, and > by the way, most of those conflaters, like udev, are under our > control. Conflation is another form of entanglement, but don't blame > us." > > For those using ext4, assuming a kernel with ext4 compiled in, without > need for root disk lvm, encryption, and raid, the init system can > immediately use the static executables in /sbin to mount necessary > disks and then go about the rest of the boot. > > Systemd loves to brag about their boot time, but on a system with ext4 > drivers compiled into the kernel, a separate /sbin guaranteed on the > root partition, and minimal use of udev in the boot (you *could* run > it as a daemon, in parallel, using runit), boots would be quick > indeed. Switch-root, killall5, and all the other stuff done before > disks begin to mount, goes away. > > I vote against "the merge". > > SteveT > So, after reading Steve's enlightening description, I am with him, the merge is only needed by systemd and seems to be a way of forcing it on everybody, so I am against it. Rowland ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Daniel Reurich wrote on 16.11.18 10:11: [...] > So... for Devuan, do we want to default to a merged /usr in our coming > release of Beowulf or are we going to resist another pointless > rearranging of the deck chairs... > > Keen to get some feedback on this [...] I cast my vote in favor of making merged /usr the default. My reasoning behind this is as follows (disclaimer: rant mode = medium): The practice of storing system files in a secondary hierarchy below /usr was born out of disk space constraints on hardware that has been obsoleted many, many decades ago. It is and has always been an ill conceived kludge that somehow managed to cross the times and still be present on some Unix-like operating systems. The artificial separation of system files into the "essential" and "non-essential" categories has always been a vague and arbitrary one, and in the Debian case is botched since at least Wheezy, effectively rendering the endeavor of making /usr a mount point for a separate disk partition a nontrivial task (think initramfs). The fact that split /usr has been abused to craft pathologic setups like network mounted /usr volumes shared across multiple installations is a moot point. This practice is demonstrably a recipe for disaster when used for anything but fun experiments on non-critical toy installations or as a demonstration piece on how to /not/ design a reliable system. Split /usr is an abomination that should have been put to rest long ago, only to be referred to as quirky anecdote in some obscure footnote. Merging /usr back is a small step on the long way to restore the FSH to what it was meant to be. (rant off) TL;DR: The Unix file system hierarchy is a mess. A merged /usr subtree brings back a tiny little bit of sanity. Thus I vote for it to be the default for new Devuan installations. Best regards, Urban -- Sapere aude! signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fri, Nov 16, 2018 at 10:19:30AM +, Rowland Penny wrote: [cut] > > So, after reading Steve's enlightening description, I am with him, the > merge is only needed by systemd and seems to be a way of forcing it on > everybody, so I am against it. > It would be actually more productive to base this discussion on solid technical arguments. I have no opinion on the matter at the moment, since I have done very little research on it, and I will try to understand what's the technical side of it before judging on the basis of a gut feeling. I guess it would be more useful if we could all do owr own research and construct an informed opinion before participating to this thread. This is what I will do. My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Steve Litt wrote on 16.11.18 11:11: > On Fri, 16 Nov 2018 22:11:17 +1300 > Daniel Reurich wrote: [...] >> So... for Devuan, do we want to default to a merged /usr in our coming >> release of Beowulf or are we going to resist another pointless >> rearranging of the deck chairs... >> >> Keen to get some feedback on this > > Back in the what, 1970's, the Unix guys > split /usr/sbin, /sbin, /usr/bin, and /bin to accommodate early boot, > by separating out statically compiled stuff used in the earliest boot. > But then initramfs made these separate directories unnecessary, so why > in the world would we continue the split? Steve, with all due respect, in think your reasoning suffers from some kind of slight misconception: The file system hierarchy split between / and /usr happened because the disk mounted at / on one particular machine was filling up. Neither was it a deliberate design decision, nor was it deemed elegant at the time (and still is not). It was nothing but a dirty makeshift botch to quickly compensate for some transient hardware constraint almost fifty years ago. It has nothing to do with the practice of using an initramfs (or similar construct) for early user space system initialization. In fact, if anything, a merged /usr obsoletes the need for an initramfs WRT mounting system partitions, as it is highly unlikely for /usr to reside on a separate volume when it is merged into the root hierarchy, where it belongs. If you dislike initramfs, you should go for a merged /usr tree to err on the safe side when it comes to ensure availability of essential system components during system initialization. And bringing anything related to systemd into the picture just because its proponents also happen to support merged /usr is a red herring. [Cut reasoning based on aforementioned misconception about the history of split /usr, and initramfs or systemd being relevant to the question at hand.] Best regards, Urban -- Sapere aude! signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Quoting Rowland Penny (rpe...@samba.org): > Can anybody explain the bad points of doing the merger ? > I ask this because everything I can find says it is a good thing, but > they said systemd was a good thing ;-) This topic has been obscured by a massive amount of special-pleading and rationalisation. I'll merely address my _own_ view reflecting my local policy as a Linux server administrator (not purporting applicability to Devuan or Debian or desktop computing, or anything else). Text below (drafted impromptu while-u-wait) serves as my rejoinder to several frequently-cited Web pages, primarily those from the Freedesktop.org and Fedora people, that make arguments I deem some combination of disingenuous and incompetent, FWIW. Said pages are liberally quoted (usually verbatim) in the 'Objection' paragraphs. (Strictly speaking, what follows will not argue against any distribution 'doing the merger'. It merely articulates that *I* will be un-doing any such merger impinging on my local systems from distro defaults, or similar, and why.) My view: I need the contents of /bin, /sbin, /lib, and /lib64 to be functional if /usr for any reason cannot be, or is not, mounted, because the role of those subtrees on my systems is to house tools the superuser might need for backup, recovery, system repair, and system diagnosis (collectively, 'rescue') in the absence of /usr. Objection: But Rob Landley reminded us at http://lists.busybox.net/pipermail/busybox/2010-December/074114.html that that isn't why Thompson and Richie invented the /usr split in 1971. Answer: True enough, but also blatantly, blazingly, and somewhat insultingly-to-our-intelligence irrelevant. It's what generations of sysadmins have found the /usr split useful for _since_ not long after 1971, and the split's origin in an ancient PDP-11 two-disk-pack kludge is amusing but has no bearing on more than four decades' subsequent best practices. Objection: But your /usr-less system won't work properly because of udev rules invoking binaries from /usr/bin, libs in /usr/lib, and/or data files in /usr/share, e.g., for udev-pci-db/udev-usb-db, PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, etc. Answer: My server systems' basic backup, recovery, system repair, and system diagnosis utilities aren't dependent on the latter (mostly) GNOME/freedesktop crud. If my systems _were_ dependent on, e.g., LVM, and I found it depended on components in /usr, I'd recompile those packages locally to remove what I regarded as a build error. Likewise, no udev rules on _my_ server systems depend on /usr. Moreover, I'm sufficiently unhappy with udev that I'm currently testing migration away from it to reduce system complexity and protect security. Objection: The roles of a proper minimal system is better filled by an initrd. Answer: I elect to run a simplified system without initrd, and greatly prefer that nothing on my server systems require one.. Moreover, I'm sufficiently unhappy with udev that I'm currently testing migration away from it to reduce system complexity and protect security. mdev's looking promising. (And no, I don't care if it's popular, as long as it's popular with me.) Objection: The role of a proper minimal rescue system is better filled using an initrd. Thus, the alleged historical justification no longer applies. Answer: That is an opinion I happen to not share. I elect instead to run a simplified system locally configured to run without initrd, and greatly prefer that nothing on my server systems require one. I'd in fact consider any system breakage in the absence of an initrd a critical bug, and would fix that immediately. Objection: It makes no sense for a Linux distribution in 2018 to default to supporting operation without initrd. Answer: Possibly so, yet utterly irrelevant to my server systems, which follow Rick Moen policy, if required overriding distro policy: My local system, my local rules. (By the way, that's called 'system administration'. Try it, some time.) Objection: How are you so sure that nothing in your /bin, /sbin, /lib, or /lib64 files needed for backup, recovery, system repair, and system diagnosis doesn't depend on /usr? Answer: Because I checked. 'ldd' isn't rocket science, y'know. And, if something I relied on for the indicated 'rescue' functions did suffer such a dependency, I would fix that, if necessary by recompiling statically. Objection: Why would you consider something as antediluvian as static binaries in 2018? Answer: Because I'm serious that those tools need to work with or without availability of /usr, and highly reliable operation for critical tools is more important than a small amount of extra binary footprint. Also, I didn't say I wanted to resort to static binaries. I said I'd _even_ resort to static binaries, rather than rely on
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fr, Nov 16, 2018 at 03:23:53 -0800, Rick Moen wrote: My view: I need the contents of /bin, /sbin, /lib, and /lib64 to be functional if /usr for any reason cannot be, or is not, mounted, because the role of those subtrees on my systems is to house tools the superuser might need for backup, recovery, system repair, and system diagnosis (collectively, 'rescue') in the absence of /usr. That’s fine for you and your server, but the question is what this distribution should do. Devuan is for servers and for desktops. And people are using distributions like Devuan to not recompile packages with other options. And for the record: since the time, /bin, /sbin and /lib are part of the same disc as /usr (in my case more then 15 years), I never had a need to recover /usr but still had access to /bin or /sbin. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fri, 16 Nov 2018 22:11:17 +1300 Daniel Reurich wrote: > At this stage there is no plan to make it forced... Not publicly. On the one hand, this is additional work. On the other hand, we've seen efforts focused toward fewer choices / committing to less development variety (though whether it's less actual development effort is debatable). I conclude this is a transitory step toward making this mandatory; something like propagating the idea to ease transitional pains. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Quoting Stephan Seitz (stse+dev...@fsing.rootsland.net): > That’s fine for you and your server, but the question is what this > distribution should do. Actually, no. That is _not_ the question I was answering. To reresh your memory, Rowland Perry asked: "Can anybody explain the bad points of doing the merger?" I did. Sorry my answer didn't meet your needs, but OTOH it wasn't your question I answered. > Devuan is for servers and for desktops. That's nice. Distro policy is significant and important. But it is not dispositive of questions like the one Rowland Perry asked. > And people are using distributions like Devuan to not recompile packages > with other options. 1. Most local customisations don't require that. Some do. 2. _Some_ people are using distributions like Devuan to completely avoid local compilation. Others are not. (E.g., you did not speak for me.) > And for the record: since the time, /bin, /sbin and /lib are part of > the same disc as /usr (in my case more then 15 years), I never had a > need to recover /usr but still had access to /bin or /sbin. I'm happy for your luck in not needing to follow system administration best practices in this area, just as I'm happy about domain owners scraping by with fewer than the minimum three authoritative DNS nameservers recommended in RFC 2182 section 5 but through good luck not suffering DNS outages. Good luck is to be celebrated, particularly when it overcomes avoidable risk. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fri, 16 Nov 2018 04:10:17 -0800 spiralofhope wrote: > I conclude this is a transitory step toward making this mandatory; > something like propagating the idea to ease transitional pains. Oh, and I suppose I could chime in on the notion of Devuan following suit. Of course it should. At this point, it must. From what I understand, not all Devuan-specific efforts have concluded. Every upstream change that's resisted is another burden that distracts from Devuan's core goals.. unless this becomes a discussion of broadening them. One could think that resisting Debian's choices in this matter could just become someone's pet project, and that the core project would not be diluted, but all this does is insert another effort and person as something like an expansion of the "bus factor".[1] I can't quite articulate it, but not following suit feels something like scope creep. [1] https://en.wikipedia.org/wiki/Bus_factor ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Hi Daniel. Daniel Reurich - 16.11.18, 10:11: > Debian as of the upcoming Buster release looks to be implementing a > merged /usr by default. At this stage there is no plan to make it > forced... but you never know what happens when their Technical > Committee suddenly decides it's an issue they need to force a > decision on... > > So... for Devuan, do we want to default to a merged /usr in our coming > release of Beowulf or are we going to resist another pointless > rearranging of the deck chairs... > > Keen to get some feedback on this I do not yet have a firm opinion on this. So for now I just like to share an experience I had with Debian without usrmerge: I downloaded a software – I do not remember that it was – from somewhere – I do not remember where that was at the moment – and there has been a shell script with the following shebang: #!/usr/bin/bash Of course it did not work on this Debian installation without changing it to "#!/bin/bash". I was surprised about this shell script, cause even with usrmerge usually there are symlinks that make all binaries available in '/bin' and '/sbin' as well. And I'd give it some transition time or use "#!/usr/bin/env bash" (or 'sh' where that is enough, but on Debian by default '/bin/sh' points to 'dash' and dash does not provide most of the usual bashisms). My personal view is that the FHS has quite some deficiencies. I agree with lots from: https://cr.yp.to/slashpackage.html https://cr.yp.to/slashpackage/studies.html But to move to a completely different standard would be 1) lots of work, 2) make it impossible to base Devuan on Debian. So in my opinion it is outside of the scope of Devuan for now. In any case: Regarding a decision I'd take the amount of effort into account which would be needed to divert from Debian's default. As long as Debian still supports the usr split, I bet that effort would be minimal, but as soon as packages appear that just stuff anything in '/usr', then diverting becomes more and more pointless or Devuan would need to carry packages with different directory layout. So for now no firm opinion. Maybe that means I do not care all that much about it. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 2018-11-16 4:11 a.m., Daniel Reurich wrote: Hi Devuan followers, fans and friends, Debian as of the upcoming Buster release looks to be implementing a merged /usr by default. At this stage there is no plan to make it forced... but you never know what happens when their Technical Committee suddenly decides it's an issue they need to force a decision on... So... for Devuan, do we want to default to a merged /usr in our coming release of Beowulf or are we going to resist another pointless rearranging of the deck chairs... Given the current "definition" of Devuan, I see little choice other than following Debian, it is after all the source of most packages used in Devuan. Merged /usr will creep in 100% over time and one day not to far away it will taint sid/ceres to the point that there is no choice anyway. The dodging of systemd is already a big enough chunk to gnaw away, it makes little sense to make the situation many times worse. Like it or not systemd and its limitations are forcing changes to the landscape and merged usr for little other reason, the once possible uniting force of LSB is done for. Systemd's preferred hierarchy _is_ the new LSB. Live with it or go it alone. Ideally Devuan would be the new Debian and calling the shots, but that is not happening soon, although at some point Devuan may be the required lifeboat for Debian passengers. There is likely a fairly solid Devuan installed base out there, but a lot of that is based on close Debian compatibility at least for initial install, IMHO we can't lose that or Devuan will quickly follow various niche distros into oblivion. Clarke ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fri, 16 Nov 2018 11:34:05 +0100 Irrwahn wrote: > I cast my vote in favor of making merged /usr the default. > > My reasoning behind this is as follows (disclaimer: rant mode = > medium): > > The practice of storing system files in a secondary hierarchy below > /usr was born out of disk space constraints on hardware that has been > obsoleted many, many decades ago. It is and has always been an ill > conceived kludge that somehow managed to cross the times and still be > present on some Unix-like operating systems. > > The artificial separation of system files into the "essential" and > "non-essential" categories has always been a vague and arbitrary one, > and in the Debian case is botched since at least Wheezy, effectively > rendering the endeavor of making /usr a mount point for a separate > disk partition a nontrivial task (think initramfs). > > The fact that split /usr has been abused to craft pathologic setups > like network mounted /usr volumes shared across multiple installations > is a moot point. This practice is demonstrably a recipe for disaster > when used for anything but fun experiments on non-critical toy > installations or as a demonstration piece on how to /not/ design a > reliable system. > > Split /usr is an abomination that should have been put to rest long > ago, only to be referred to as quirky anecdote in some obscure > footnote. Merging /usr back is a small step on the long way to > restore the FSH to what it was meant to be. Wait a minute. You and I are talking about two different things, so perhaps I should ask what the "/usr merge" really is. Urban, you seem to be against having both a /usr/bin and a /bin. Personally, I don't care about that. What *I'm* talking about is I want to continue having /sbin separate from /bin and /usr/bin, because the /sbin varieties holds statically compiled programs guaranteed to work at the earliest of boots, and in the case of /sbin, guaranteed to be available as soon as / is mounted. I want there to always exist a /sbin, where static executables become available the microsecond / is mounted. /sbin should be there only for statically compiled executables needed for early boot. As long as /sbin contains everything needed to boot in all but the craziest situations, I don't care what happens to /usr/sbin. But the minute somebody combines /sbin with /usr/bin or /usr/sbin, everything I said in my previous post becomes true. SteveT Steve Litt November 2018 featured book: Manager's Guide to Technical Troubleshooting Brand new, second edition http://www.troubleshooters.com/mgr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fri, 16 Nov 2018 11:43:21 +0100 KatolaZ wrote: > On Fri, Nov 16, 2018 at 10:19:30AM +, Rowland Penny wrote: > > [cut] > > > > > So, after reading Steve's enlightening description, I am with him, > > the merge is only needed by systemd and seems to be a way of > > forcing it on everybody, so I am against it. > > > > It would be actually more productive to base this discussion on solid > technical arguments. Here's your technical argument: If you get rid of /sbin AND you mount /usr on a separate partition, you cannot, under any circumstances, boot without an initramfs. SteveT Steve Litt November 2018 featured book: Manager's Guide to Technical Troubleshooting Brand new, second edition http://www.troubleshooters.com/mgr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fri, 16 Nov 2018 16:04:42 +0100 Martin Steigerwald wrote: > I do not yet have a firm opinion on this. So for now I just like to > share an experience I had with Debian without usrmerge: > > I downloaded a software – I do not remember that it was – from > somewhere – I do not remember where that was at the moment – and > there has been a shell script with the following shebang: > > #!/usr/bin/bash If this is the main disadvantage of the split, then a couple symlinks or hardlinks solves it. SteveT Steve Litt November 2018 featured book: Manager's Guide to Technical Troubleshooting Brand new, second edition http://www.troubleshooters.com/mgr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fri, 16 Nov 2018 12:08:34 +0100 Irrwahn wrote: > And bringing anything related to systemd into the picture just > because its proponents also happen to support merged /usr is a red > herring. That's just not true. We have a half a decade's history of seeing systemd stick its nose in the tent, and then keep pushing until the DIY human must leave the tent. I made very clear in my first post it's not a case of "just because its proponents also happen to support merged /usr". It's because eliminating /sbin (and also some others that Rick enumerated) forces use of an initramfs, and the systemd forces can easily acquire, monopolize and decompatablize the tools to create initramfs. After 5 years systemd observation, this is not paranoia, this is an educated guess based on past behavior. SteveT Steve Litt November 2018 featured book: Manager's Guide to Technical Troubleshooting Brand new, second edition http://www.troubleshooters.com/mgr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fri, 16 Nov 2018 12:27:50 -0500 Steve Litt wrote: > On Fri, 16 Nov 2018 16:04:42 +0100 > Martin Steigerwald wrote: > > > > I do not yet have a firm opinion on this. So for now I just like to > > share an experience I had with Debian without usrmerge: > > > > I downloaded a software – I do not remember that it was – from > > somewhere – I do not remember where that was at the moment – and > > there has been a shell script with the following shebang: > > > > #!/usr/bin/bash > > If this is the main disadvantage of the split, then a couple symlinks > or hardlinks solves it. > Bash is in /bin on Debian, but on Centos it is in /usr/bin and also in /bin, so the shell script was probably written by a red-hat user ;-) Rowland ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
I am personally against such a change as being default in Devuan. I view it as a change that makes things less forgiving to newbies and to people who occasionally make mistakes. An example of this is about three years ago, when I was new to Linux and accidentally blew away my /usr/bin directory and had to fix it. The common wisdom "reinstall" was not an option for me, as I couldn't because of technical restraints. After some time I fixed it, with the help of a friend and #debianfork. (i still use the system today and it is remarkably stable. I have had little issues with it, albeit I do not think any issues I have had were due to this mistake). It was a mistake of my own, but it was also a learning experience. Because /usr/bin was somewhat standalone from /bin I did not entirely hose my system. I shudder to think what would have happened if it was merged. While this is just one anecdote, it does make me wonder how many people might have had something like this happen while new or just mistype something. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
* On 2018 16 Nov 10:03 -0600, Edward Bartolo wrote:
> A merger is when two or more entities become unified into one entity
> like two companies becoming one single company. So, /usr merging
> should require other directories becoming part of it. Googling brought
> me a question on Ubuntu forums which asked: "Are {/bin, /lib, /sbin}
> symlinks into /usr in Ubuntu?" If that is what is understood by this
> 'fearsome' unification then /bin, /lib and /sbin should become
> symlinks with their usual contents moved to /usr. A program should
> still be able to find files under /bin, /lib and /sbin provided there
> are no two different files with the same name.
I recently did a clean install of Debian Buster and here is the current
configuration:
$ ls -l /
total 68
lrwxrwxrwx 1 root root 7 Oct 14 07:32 bin -> usr/bin/
drwxr-xr-x 4 root root 4096 Nov 4 14:34 boot/
drwxr-xr-x 21 root root 3600 Nov 13 20:01 dev/
drwxr-xr-x 130 root root 12288 Nov 16 08:00 etc/
drwxr-xr-x 5 root root 4096 Feb 25 2018 home/
lrwxrwxrwx 1 root root30 Oct 14 09:05 initrd.img ->
boot/initrd.img-4.18.0-2-amd64
lrwxrwxrwx 1 root root30 Oct 14 07:35 initrd.img.old ->
boot/initrd.img-4.18.0-1-amd64
lrwxrwxrwx 1 root root 7 Oct 14 07:32 lib -> usr/lib/
lrwxrwxrwx 1 root root 9 Oct 14 07:32 lib32 -> usr/lib32/
lrwxrwxrwx 1 root root 9 Oct 14 07:32 lib64 -> usr/lib64/
lrwxrwxrwx 1 root root10 Oct 14 07:32 libx32 -> usr/libx32/
drwx-- 2 root root 16384 Oct 14 07:32 lost+found/
drwxr-xr-x 4 root root 4096 Oct 14 12:06 media/
drwxr-xr-x 2 root root 4096 Oct 14 07:32 mnt/
drwxr-xr-x 11 root root 4096 Aug 23 06:37 opt/
dr-xr-xr-x 304 root root 0 Nov 13 20:00 proc/
drwx-- 6 root root 4096 Oct 30 20:22 root/
drwxr-xr-x 26 root root 720 Nov 15 07:43 run/
lrwxrwxrwx 1 root root 8 Oct 14 07:32 sbin -> usr/sbin/
drwxr-xr-x 2 root root 4096 Oct 14 07:32 srv/
dr-xr-xr-x 13 root root 0 Nov 13 20:00 sys/
drwxrwxrwt 20 root root 4096 Nov 16 11:50 tmp/
drwxr-xr-x 14 root root 4096 Oct 16 13:26 usr/
drwxr-xr-x 12 root root 4096 Oct 14 13:25 var/
lrwxrwxrwx 1 root root27 Oct 14 09:05 vmlinuz ->
boot/vmlinuz-4.18.0-2-amd64
lrwxrwxrwx 1 root root27 Oct 14 07:35 vmlinuz.old ->
boot/vmlinuz-4.18.0-1-amd64
As my systems are all desktops of one variety or another, I keep /home
on a separate partition where it makes sense to do so.
$ df -h
Filesystem Size Used Avail Use% Mounted on
udev7.8G 0 7.8G 0% /dev
tmpfs 1.6G 18M 1.6G 2% /run
/dev/sda520G 8.4G 9.8G 47% /
tmpfs 7.8G 100M 7.7G 2% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
/dev/sdb192G 67G 21G 77% /opt
/dev/sda1 511M 2.1M 509M 1% /boot/efi
/dev/sda6 359G 147G 205G 42% /home
tmpfs 1.6G 27M 1.6G 2% /run/user/1000
Given my layout, the merged directories are not an issue but just look
odd at first glance after 22 years of my seeing them as stand alone
directories.
- Nate
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB
signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Steve Litt wrote on 16.11.18 18:17:
> On Fri, 16 Nov 2018 11:34:05 +0100
> Irrwahn wrote:
>
>> I cast my vote in favor of making merged /usr the default.
[...]
>> Split /usr is an abomination that should have been put to rest long
>> ago, only to be referred to as quirky anecdote in some obscure
>> footnote. Merging /usr back is a small step on the long way to
>> restore the FSH to what it was meant to be.
>
> Wait a minute. You and I are talking about two different things, so
> perhaps I should ask what the "/usr merge" really is.
>
> Urban, you seem to be against having both a /usr/bin and a /bin.
> Personally, I don't care about that.
Steve,
since we're having this discussion in the light of Debian making (or at
least planning to make) merged /usr the default selection in the next
stable version installer, I guess we should consult the FAQ that comes
with the `usrmerge´ package in Debian, c.f.:
https://salsa.debian.org/md/usrmerge/raw/master/debian/README.Debian
Excerpt:
| * What is the purpose of this package?
| The usrmerge package will convert the system it is installed on to the
| everything-in-usr directories scheme, i.e. the /{bin,sbin,lib}/ directories
| become symbolic links to /usr/{bin,sbin,lib}/.
| [...]
| * Will usrmerge also merge /usr/bin/ and /usr/sbin/?
| No.
| * Does this require systemd?
| No.
| * Does this really not require systemd?
| Yes, I promise.
| * Does this require an initramfs?
| Only if /usr is on a standalone file system.
So, bin and sbin will stay separate, but /bin, /sbin and /lib will get
merged into, and replaced by symlinks to, their counterparts in /usr.
> What *I'm* talking about is I want to continue having /sbin separate
> from /bin and /usr/bin, because the /sbin varieties holds statically
> compiled programs guaranteed to work at the earliest of boots, and in
> the case of /sbin, guaranteed to be available as soon as / is mounted.
When was the last time you checked what actually resides in /sbin?
It may come as a surprise, but statically linked programs it's not.
Picking some random example, let's have a quick look at `getty´:
$ ldd /sbin/getty
linux-vdso.so.1 (0x7fff16f88000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3afe0ec000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f3afdee8000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f3afdccb000)
/lib64/ld-linux-x86-64.so.2 (0x7f3afe8a3000)
It's less surprising when taking into consideration that with all but
the most trivial of programs it's basically impossible to achieve
statical linkage with glibc, and it has been like that for years now.
If you really want statically linked executables you need to have a
look beyond glibc, e.g. at musl-libc. (Which is what I did in my past
experiments to build a small non-GNU Linux system around toybox and
clang/musl-libc.)
>
> I want there to always exist a /sbin, where static executables become
> available the microsecond / is mounted. /sbin should be there only for
> statically compiled executables needed for early boot. As long as /sbin
> contains everything needed to boot in all but the craziest situations,
> I don't care what happens to /usr/sbin.
>
> But the minute somebody combines /sbin with /usr/bin or /usr/sbin,
> everything I said in my previous post becomes true.
Only if you insist on mounting /usr separately from /. If your hardware
is no older than ~40 years there should exist no compelling /technical/
reason to do so. The only arguments pro separate /usr I came across so
far were all based on either ill advised practice to abuse the artificial
/usr split (e.g. shared /usr via NFS), or some variation of "but I always
did it that way".
If your mass storage devices are too tiny to allow for a single partition
to hold the combined content of /{bin,sbin,lib} and /usr, something else
is fundamentally amiss. Even on my kitchen sink desktop PC the entire /
hierarchy *including everything except /home*, amounts to a meager 10GB.
(1.4 GB of which is /var, BTW, for which there actually exist sound
technical reasons to have it on a separate partition, as is the case for
/home.)
Regards,
Urban
--
Sapere aude!
signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Daniel Reurich: ... > So... for Devuan, do we want to default to a merged /usr in our coming > release of Beowulf or are we going to resist another pointless > rearranging of the deck chairs... I don't want it. My view seems to coincide with Rich Moens. > Keen to get some feedback on this It is important to keep the boot setup simple, reliable and easy to manage for the local admin. Initrd provides an obstacle and is counterprodictive to that principle as is udev. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Steve Litt wrote on 16.11.18 18:35: > On Fri, 16 Nov 2018 12:08:34 +0100 > Irrwahn wrote: > > >> And bringing anything related to systemd into the picture just >> because its proponents also happen to support merged /usr is a red >> herring. > > That's just not true. Yes it is. (Thanks for making me feel >40 years younger! :-) If you are under the impression the merged /usr concept was invented by Redhat, or the freedesktop and/or the systemd people, you are demonstrably wrong. On System V Release 4 and later /bin has already been a symlink to /usr/bin, and Solaris implemented the /usr merge about a decade ago. Effectively, only some Unices and some Linux based distributions are the odd ones out in that respect. > > We have a half a decade's history of seeing systemd stick its nose in > the tent, and then keep pushing until the DIY human must leave the > tent. I made very clear in my first post it's not a case of "just > because its proponents also happen to support merged /usr". It's > because eliminating /sbin (and also some others that Rick enumerated) > forces use of an initramfs, and the systemd forces can easily acquire, > monopolize and decompatablize the tools to create initramfs. After 5 > years systemd observation, this is not paranoia, this is an educated > guess based on past behavior. In my reply to your other post I explain why the notion of a merged /usr allegedly forcing the use of an iniramfs is a myth, I won't repeat it here for the sake of brevity. The part about "acquire, monopolize and decompatablize the tools to create initramfs" is ridiculous, as an initrd is nothing more than an (optionally compressed) cpio archive, loaded by the Linux kernel itself. Put some statically linked executable (e.g. a shell) inside, renamed to /sbin/init, and you have the most bare-bone of Linux systems imaginable, without even the need for a "real" root file system. (Where I used to work we regularly built entire embedded Linux systems that consisted of nothing more than a boot loader, a kernel and an initrd - go figure.) Sorry, but no matter how educated, in this case your guess simply failed. Regards, Urban -- Sapere aude! signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
> Back in the what, 1970's, the Unix guys
> split /usr/sbin, /sbin, /usr/bin, and /bin to accommodate early boot,
> by separating out statically compiled stuff used in the earliest boot.
Close, not restricted to statically linked, but not dependant on
anything not available in /lib (which were very few) so many binaries
were static.
The *original* purpose was to be able to boot a machine to a state where
it supported network file systems (yes typically nfs, but also others)
and then mount /usr from the network.
In a typical organisation only one server would have very expensive
large hard disk capacity of 20MB or so which would be brought up first
to share its local /usr filesystem read-only to all other nodes.
This server would typically also be the only host with the application
software installed on it.
> But then initramfs made these separate directories unnecessary, so why
> in the world would we continue the split?
Eh? initramfs was originally introduced to provide kernel file and
driver *module* support to allow the kernel to control the hardware
device and read the root file system containing /etc /bin /sbin /lib.
> Well, maybe because initramfs is a PITA many people choose to avoid.
Trivial to work with, no different to the debootstrapping and chrooting
you are familiar with using looped files as devices.
> When things go wrongSNIP...
Agree 100%
>
> I vote against "the merge"
I also vote against the merge.
The concept of which is at fault anyway, if root file system network
support no longer required the merge should go the other way in any
case, it is /usr/{bin,sbin,lib} that is depreciated.
/usr/bin > /bin
/usr/sbin > /sbin
/usr/lib > /lib
with the exception of special cases which are frequently abused by
distros but are not supposed to be a part of the standard OS and should
stay under /usr.
e.g.
/usr/local
/usr/share
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
g4sra wrote on 16.11.18 21:19:
> The concept of which is at fault anyway, if root file system network
> support no longer required the merge should go the other way in any
> case, it is /usr/{bin,sbin,lib} that is depreciated.
>
> /usr/bin > /bin
> /usr/sbin > /sbin
> /usr/lib > /lib
>
> with the exception of special cases which are frequently abused by
> distros but are not supposed to be a part of the standard OS and should
> stay under /usr.
> e.g.
>
> /usr/local
> /usr/share
I once was on the same page, but have since changed my mind when I
realized that the other way round, i.e. /{bin,sbin,lib} -> /usr/...
actually to me makes more sense, as it keeps all the "static" files
that are part of the distribution neatly in one place. The only other
significant things left in / then are site specific configuration in
/etc and, if not already placed in a dedicated file system, persistent
variable data in /var.
This allows e.g. for things like rendering the entire "static" part
of the system effectively immutable simply by mounting /usr read-only.
(And yes, referring to other sub-threads, in that case one would
indeed have to mount /usr by means of an initrd, which is neither
brain science nor rocket surgery.)
Regards,
Urban
--
Sapere aude!
signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Quoting Irrwahn (irrw...@freenet.de): [...] > On System V Release 4 and later /bin has already been a symlink to > /usr/bin, and Solaris implemented the /usr merge about a decade ago. > Effectively, only some Unices and some Linux based distributions are > the odd ones out in that respect. I note without objection (but rather with active appreciation, on entertainment grounds) that every single one of your talking point so far -- including the one above -- appear to have been copied near-verbatim from the pair of Freedesktop.org UsrMerge advocacy Web pages I dissected in this forum yesterday. Nicely played, sir! The above appears to have been copied from: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ Myth #6: A split /usr is Unix “standard”, and a merged /usr would be Linux-specific Fact: On SysV Unix /bin traditionally has been a symlink to /usr/bin. A non-symlinked version of that directory is specific to non-SysV Unix and Linux. and Myth #1: Fedora is the first OS to implement the /usr merge Fact: Oracle Solaris has implemented the /usr merge in parts 15 years ago, and completed it in Solaris 11. Fedora is following suit here, it is not the pioneer. ...which is a profoundly silly argument, but one I touched on by saying Objection: Separate /usr hasn't been consistently standard, e.g., /bin was a symlink to /usr/bin on many Unixes. Answer: I don't give a rat's ass. It's standard on mine. Anyway, please do carry on with the retyping of other people's talking points (unless perhaps you are the uncredited author of one or both of those Freedesktop.org pages, which is also possible). It makes for amusing reading. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Quoting Steve Litt (sl...@troubleshooters.com): > What *I'm* talking about is I want to continue having /sbin separate > from /bin and /usr/bin, because the /sbin varieties holds statically > compiled programs guaranteed to work at the earliest of boots, and in > the case of /sbin, guaranteed to be available as soon as / is mounted. Steve, I'm not sure where you arrived at the notion that binaries in /sbin should be expected to be, or necessarily ought to be, static binaries. I'm not aware of any such norm. (Compiling static is a crude but certainly effective way to end some dependency issues, but not necessarily desirable.) In case you were not aware (and absolutely no condescension intended if you were already well aware of this), the 's' in 'sbin' signifies 'normally needed only by the superuser'. It doesn't signify static. (BTW, .signature below is #500. Entire herd gathers here: http://linuxmafia.com/pub/humour/sigs-rickmoen.html ) -- Cheers,"I never quarrel with a man who buys ink by the barrel." Rick Moen-- Rep. Charles B. Brownson (R-Indiana), ca. 1960 r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Irrwahn [11/16/18 9:10 PM]: > On System V Release 4 and later /bin has already been a symlink to > /usr/bin, and Solaris implemented the /usr merge about a decade ago. > Effectively, only some Unices and some Linux based distributions are > the odd ones out in that respect. And all the BSDs, macOS,... -- Hilsen Harald ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 11/16/18 4:42 PM, Rick Moen wrote: Quoting Steve Litt (sl...@troubleshooters.com): What *I'm* talking about is I want to continue having /sbin separate from /bin and /usr/bin, because the /sbin varieties holds statically compiled programs guaranteed to work at the earliest of boots, and in the case of /sbin, guaranteed to be available as soon as / is mounted. Steve, I'm not sure where you arrived at the notion that binaries in /sbin should be expected to be, or necessarily ought to be, static binaries. I'm not aware of any such norm. (Compiling static is a crude but certainly effective way to end some dependency issues, but not necessarily desirable.) In case you were not aware (and absolutely no condescension intended if you were already well aware of this), the 's' in 'sbin' signifies 'normally needed only by the superuser'. It doesn't signify static. I thought it was "system", but I don't even know who originated the separation. It certainly precedes Linux. As for the "statically linked binaries in /sbin", that may come from the (formerly?) common practice of having all the binaries needed for system startup statically linked in case something happened to /lib. It's scary how unreliable our systems used to be compared to now. -- Daniel Taylor ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fri, 16 Nov 2018 11:43:21 +0100, KatolaZ wrote in message <20181116104321.3kpm4g2wlbpjg...@katolaz.homeunix.net>: > On Fri, Nov 16, 2018 at 10:19:30AM +, Rowland Penny wrote: > > [cut] > > > > > So, after reading Steve's enlightening description, I am with him, > > the merge is only needed by systemd and seems to be a way of > > forcing it on everybody, so I am against it. > > > > It would be actually more productive to base this discussion on solid > technical arguments. ..this is primarily a matter of policy, and politics, on what sort of tools do you want to have available for whatever you wanna do, and, on what sort of tools do you want other people to have available for whatever you want them to do. ;o) ..once you have made up your mind on the above, those technical and tactical issues merely concern how best to make your decision happen. > I have no opinion on the matter at the moment, > since I have done very little research on it, and I will try to > understand what's the technical side of it before judging on the basis > of a gut feeling. ..most people can trust their gut feeling because your own gut is always on your side, precisely because your gut can not escape the painful ramifications of getting these bad things, badly wrong. > I guess it would be more useful if we could all do owr own research > and construct an informed opinion before participating to this > thread. This is what I will do. > > My2Cents > > KatolaZ > -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fri, 16 Nov 2018 21:50:11 +0100, Irrwahn wrote in message
:
> g4sra wrote on 16.11.18 21:19:
> > The concept of which is at fault anyway, if root file system network
> > support no longer required the merge should go the other way in any
> > case, it is /usr/{bin,sbin,lib} that is depreciated.
> >
> > /usr/bin > /bin
> > /usr/sbin > /sbin
> > /usr/lib > /lib
> >
> > with the exception of special cases which are frequently abused by
> > distros but are not supposed to be a part of the standard OS and
> > should stay under /usr.
> > e.g.
> >
> > /usr/local
> > /usr/share
>
> I once was on the same page, but have since changed my mind when I
> realized that the other way round, i.e. /{bin,sbin,lib} -> /usr/...
> actually to me makes more sense, as it keeps all the "static" files
> that are part of the distribution neatly in one place.
...which is a neat way to crash and burn when that neat one place fails.
> The only other
> significant things left in / then are site specific configuration in
> /etc and, if not already placed in a dedicated file system,
> persistent variable data in /var.
>
> This allows e.g. for things like rendering the entire "static" part
> of the system effectively immutable simply by mounting /usr
> read-only. (And yes, referring to other sub-threads, in that case one
> would indeed have to mount /usr by means of an initrd, which is
> neither brain science nor rocket surgery.)
..some of us has had to do such stunts to try escape expensive
ramifications.
--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Quoting Daniel Taylor (ran...@argle.org): > I thought it was "system" Could be -- but as, in effect, a synonym for superuser. , but I don't even know who originated the > separation. Thompson and Ritchie, as a kludge to deal with the need to span two disk packs on their PDP-11, back in 1971. (Subsequent functional use for the split of course differs.) Upthread, I provided the link to my friend Rob Landley telling the anecdote about that '71 kludge. > As for the "statically linked binaries in /sbin", that may come from > the (formerly?) common practice of having all the binaries needed > for system startup statically linked in case something happened to > /lib. Seems farfetched. Also, I've been in *ix for a long time, and haven't heard that particular concern. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fri, 16 Nov 2018 12:27:50 -0500, Steve wrote in message <20181116122750.5ab73...@mydesk.domain.cxm>: > On Fri, 16 Nov 2018 16:04:42 +0100 > Martin Steigerwald wrote: > > > > I do not yet have a firm opinion on this. So for now I just like to > > share an experience I had with Debian without usrmerge: > > > > I downloaded a software – I do not remember that it was – from > > somewhere – I do not remember where that was at the moment – and > > there has been a shell script with the following shebang: > > > > #!/usr/bin/bash > > If this is the main disadvantage of the split, then a couple symlinks > or hardlinks solves it. ..will such links solve our Debian /usr merge problem? As in, "let them do their idiot merge, we'll just toss in a coupla symlinks." -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fri, 16 Nov 2018 19:52:13 +0100
Irrwahn wrote:
> Steve Litt wrote on 16.11.18 18:17:
> > On Fri, 16 Nov 2018 11:34:05 +0100
> > Irrwahn wrote:
> >
> >> I cast my vote in favor of making merged /usr the default.
> [...]
> >> Split /usr is an abomination that should have been put to rest long
> >> ago, only to be referred to as quirky anecdote in some obscure
> >> footnote. Merging /usr back is a small step on the long way to
> >> restore the FSH to what it was meant to be.
> >
> > Wait a minute. You and I are talking about two different things, so
> > perhaps I should ask what the "/usr merge" really is.
> >
> > Urban, you seem to be against having both a /usr/bin and a /bin.
> > Personally, I don't care about that.
>
> Steve,
>
> since we're having this discussion in the light of Debian making (or
> at least planning to make) merged /usr the default selection in the
> next stable version installer, I guess we should consult the FAQ that
> comes with the `usrmerge´ package in Debian, c.f.:
>
> https://salsa.debian.org/md/usrmerge/raw/master/debian/README.Debian
>
> Excerpt:
>
> | * What is the purpose of this package?
> | The usrmerge package will convert the system it is installed on to
> the | everything-in-usr directories scheme, i.e. the /{bin,sbin,lib}/
> directories | become symbolic links to /usr/{bin,sbin,lib}/.
> | [...]
>
> | * Will usrmerge also merge /usr/bin/ and /usr/sbin/?
> | No.
>
> | * Does this require systemd?
> | No.
>
> | * Does this really not require systemd?
> | Yes, I promise.
Note the answer about initramfs below, and note that systemd and their
crew could easily monopolize initramfs makers. Note that dracut is
already built around Redhat owned udev.
>
> | * Does this require an initramfs?
> | Only if /usr is on a standalone file system.
Which is exactly what I said.
>
> So, bin and sbin will stay separate, but /bin, /sbin and /lib will
> get merged into, and replaced by symlinks to, their counterparts
> in /usr.
Which means if /usr is a mountpoint, you need an initramfs, which was
the basis of my objection.
[snip]
> > But the minute somebody combines /sbin with /usr/bin or /usr/sbin,
> > everything I said in my previous post becomes true.
>
> Only if you insist on mounting /usr separately from /.
A heck of a lot of people insist on a separate partition mounted
as /usr, and for them this requires an initramfs, which might become a
problem like udev or netword, etc, in the future.
Now personally, my root partition is on an ssd, and it includes /usr so
all my /usr/bin, /usr/local/bin, etc, come straight off SSD at
lightning speed. I like it like that. But a lot of people want /usr to
be mounted.
[snip remarks about tiny diskspace requiring the split: That's not the
source of my objection.]
SteveT
Steve Litt
November 2018 featured book: Manager's Guide to Technical
Troubleshooting Brand new, second edition
http://www.troubleshooters.com/mgr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fri, 16 Nov 2018 21:10:54 +0100 Irrwahn wrote: > The part about "acquire, monopolize and decompatablize the tools to > create initramfs" is ridiculous, The preceding half sentence encapsulates the belief difference that causes our different stances on merging /sbin with anything else. PRF (Poettering/Redhat/Freedesktop) has developers paid probably in excess of a million dollars a year to [work on | obfuscate] Linux, whereas guys like us must undo their obfuscations on our own time, between bouts of paid work. > as an initrd is nothing more than an > (optionally compressed) cpio archive, loaded by the Linux kernel > itself. The preceding is exactly like saying, "as an init system is nothing more than a PID1 and either some rc scripts, a process supervisor, or a combination of both". The nature of an initramfs can be changed just like the nature of an init can, and I have a feeling it could be done without changes to the kernel. Like an init system only more so, an initramfs runs in its own environment and is difficult to get your voltmeter probes into, so experimentation and troubleshooting necessary to back out PRF (Poettering/Redhat/Freedesktop) mods is difficult and time consuming. SteveT Steve Litt November 2018 featured book: Manager's Guide to Technical Troubleshooting Brand new, second edition http://www.troubleshooters.com/mgr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Am Samstag, 17. November 2018 schrieb Steve Litt: > On Fri, 16 Nov 2018 21:10:54 +0100 > Irrwahn wrote: > [...] > > as an initrd is nothing more than an > > (optionally compressed) cpio archive, loaded by the Linux kernel > > itself. > > The preceding is exactly like saying, "as an init system is nothing > more than a PID1 and either some rc scripts, a process supervisor, or a > combination of both". The nature of an initramfs can be changed just > like the nature of an init can, and I have a feeling it could be done > without changes to the kernel. Like an init system only more so, an > initramfs runs in its own environment and is difficult to get your > voltmeter probes into, so experimentation and troubleshooting necessary > to back out PRF (Poettering/Redhat/Freedesktop) mods is difficult and > time consuming. > > SteveT Ahm, no. The initrams tool provide a handy way to inspect/modify/rebuild initrd. But the debian documentation on how initrd works is wrong: it assumes a one part archive (which is what you would expect), but in fact it is a 2 part archive (first part uncomressed, second compressed). Take a look at /usr/bin/unmkinitramfs line 50 ff to see how it works. Also look at the referenced linux/lib/earlycpio.c for further detail. The most important point is this: processes started in initrd survive switch_root. There goes your "full disk encryption" myth. Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Sat, Nov 17, 2018 at 03:20:15AM -0500, Steve Litt wrote: > On Fri, 16 Nov 2018 21:10:54 +0100 > Irrwahn wrote: > > > > The part about "acquire, monopolize and decompatablize the tools to > > create initramfs" is ridiculous, > > The preceding half sentence encapsulates the belief difference that > causes our different stances on merging /sbin with anything else. PRF > (Poettering/Redhat/Freedesktop) has developers paid probably in excess > of a million dollars a year to [work on | obfuscate] Linux, whereas > guys like us must undo their obfuscations on our own time, between > bouts of paid work. > OK, before we continue with a flame about what is wrong and what is right: it seems that the transition to the merged usr is *not* mandatory so far, but it is actually performed at install time. I am currently trying to understand at which point during installation this happens, so that we could just make it optional (i.e, with an opt-in semantics). StayTuned KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Sat, Nov 17, 2018 at 11:45:03AM +0100, KatolaZ wrote: [cut] > > OK, before we continue with a flame about what is wrong and what is > right: it seems that the transition to the merged usr is *not* > mandatory so far, but it is actually performed at install time. I am > currently trying to understand at which point during installation this > happens, so that we could just make it optional (i.e, with an opt-in > semantics). > I should have waited a couple of minutes before writing: it looks like it is just an option in debootstrap. It should be fairly easy to make it optional by tweaking base-installer. Working on that. We will have it in the new beowulf installer. Regards KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Rich Moen: ... > Moreover, I'm > sufficiently unhappy with udev that I'm currently testing migration away > from it to reduce system complexity and protect security. mdev's > looking promising. (And no, I don't care if it's popular, as long as > it's popular with me.) ... I use a classic static /dev, and the only problem I have seen is with usb devices (apart from keyboards and mice i.e.). I concider that more a libusb problem than a udev problem. And yes, X works perfectly well without udev and I don't need nor want to automount usb disks or memory cards etc. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Martin Steigerwald - 16.11.18, 16:04: > In any case: Regarding a decision I'd take the amount of effort into > account which would be needed to divert from Debian's default. As long > as Debian still supports the usr split, I bet that effort would be > minimal, but as soon as packages appear that just stuff anything in > '/usr', then diverting becomes more and more pointless or Devuan > would need to carry packages with different directory layout. Some Debian developers who are involved with packaging Systemd and related stuff already started to move things to /usr that were in directories under / before: Please move libkmod to /usr/lib https://bugs.debian.org/894566 Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 16/11/18 at 11:43, KatolaZ wrote: > On Fri, Nov 16, 2018 at 10:19:30AM +, Rowland Penny wrote: > > [cut] > >> So, after reading Steve's enlightening description, I am with him, the >> merge is only needed by systemd and seems to be a way of forcing it on >> everybody, so I am against it. >> > It would be actually more productive to base this discussion on solid > technical arguments. I am one of those who can't do without initramfs because I mostly run GNU/Linux on laptops and for obvious security reasons they all run on fully encrypted filesystems, / included. However I do loath the / and /usr merge. I find it irritating that I am asked to provide with sound technical reasons to keep the two filesystems separated as I needed to justify 4 decades of sound sysadminiship practice when it's the proponents of the merge who in fact have been doing a poor job to justify the purported need of the merge. Their reasons all boil down to: "it's the way we want to do stuff". Fine, I too like and enjoy doing things my way on my systems, and when there are good reasons to keep things the way they've worked for decades and there are no compelling reasons to introduce such deep changes I just say no. The "good reasons to keep things the way they" are have been enumerated several times, but I'm happy to list them again: 1) complexity and bloat are the key enemies of resiliency; 2) the smaller the most critical OS components are, the more solid the whole system is; 3) the smaller / is the easier it is to repair, to secure and audit, to provide with alternative boot paths/rescue procedures; 4) merging / with /usr takes away significant degrees of freedom in customization and hacking into one's own system and GNU/Linux owes much of it's fortune in being a hacker-friendly system that is easy to customize, even to the extremes. An example of the last point is the possibility of having two similar yet different systems boot out of the same / but with separate /usr, like having a minuscule partition with only the basic stuff in / that's able to either mount a local partition on /usr or maybe one that is mounted over an NFS server. I expect Free(lol)desktop to object something like: "Why on earth would one want to do that?". Even before I listed the possible good reasons to do such a thing, I'd answer: "Why on earth would you take me the freedom to do that away? What compelling reasons do you have to diminish the flexibility and customizability of *my* OS?" Then, the main good reason to do that is: I want to have a laptop that did not have on it's disk utilities that could land me in trouble with the local authorities because in some country where I could travel they are not allowed (P2P software, cryptographic tools, VPN and Tor/I2P software, penetration testing, packet sniffing and IP spoofing utilities etc), while at home I have them available on a local NFS server or on an external disk. Having to give up on a separate /usr does expose some technically savvy people to much more serious consequences than having to remember if mkfs.ntfs is in /sbin or /usr/sbin (Free(lol)desktop people calling this an issue is ludicrous). In short: the / -> /usr merge lacks sound good reasons to be adopted as the only possible filesystem layout scheme in all of GNU/Linux's installs (Free(lol)desktop people's personal tastes are not), while it takes away freedom to hack and customize one's own system for uses that are important to some specific cases or even have not been thought of yet. That these uses are fringe cases or not yet here does not matter, it's the merge proponent's duty to justify the purported need to to take away the possibility to do these customizations in the least painfully possible way. Taking away the flexibility of the OS for no reason reduces it's Darwinistic Resiliency Index (DRI): the most easily adaptable systems are those most likely to adapt to the most diverse set of external circumstances. Of course, bloated systems that are monolithic, dependent on a single critical, unreplaceable component, that take away the possibility of doing thing differently tend to score lowest in the DRI scoreboard. I was already pissed in the past when they decided that there was no reason to have X11 applications live in their own filesystem, /usr/X11, so that I found myself dealing with a disgustingly overcrowded /usr/bin that made looking for TUI commands and utilities so obnoxiously time-consuming. I am determined to fight this crazy / -> /usr merge tooth and nail. Alessandro -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Sat, Nov 17, 2018 at 12:57:23PM +0100, Alessandro Selli wrote: > On 16/11/18 at 11:43, KatolaZ wrote: > > On Fri, Nov 16, 2018 at 10:19:30AM +, Rowland Penny wrote: > > > > [cut] > > > >> So, after reading Steve's enlightening description, I am with him, the > >> merge is only needed by systemd and seems to be a way of forcing it on > >> everybody, so I am against it. > >> > > It would be actually more productive to base this discussion on solid > > technical arguments. > > > I am one of those who can't do without initramfs because I mostly run > GNU/Linux on laptops and for obvious security reasons they all run on > fully encrypted filesystems, / included. > merged usr will be off by default in Devuan Beowulf, with the option of opting in in expert install, or by installing the usrmerge package provided in Debian. This shoud cover all the use cases and leave enough flexibility for the sysadmin to choose what is best for them. KISS KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Hi Katolaz, KatolaZ writes: > On Sat, Nov 17, 2018 at 11:45:03AM +0100, KatolaZ wrote: > > [cut] > >> >> OK, before we continue with a flame about what is wrong and what is >> right: it seems that the transition to the merged usr is *not* >> mandatory so far, but it is actually performed at install time. I am >> currently trying to understand at which point during installation this >> happens, so that we could just make it optional (i.e, with an opt-in >> semantics). > > I should have waited a couple of minutes before writing: it looks like > it is just an option in debootstrap. It should be fairly easy to make > it optional by tweaking base-installer. Working on that. We will have > it in the new beowulf installer. This reminded me of something I did to build my Devuan Docker images: passing --no-merged-usr to debootstrap. See https://gitlab.com/paddy-hack/devuan/blob/master/bootstrap.sh#L21 Just like */bin and */sbin are useful to distinguish between programs intended for general use and system administration use, the distinction between / and /usr is useful to tell critical and non-critical programs apart. Whether you make use of the distinction and how is the user's decision. You can put all of */bin and */sbin or just */bin in your PATH depending on your needs. You can put / and /usr on the same file system or put /usr in a place that makes sense to your use case. Removing the distinction takes the option away from the user. Whether a distribution wants to "pay the cost" of keeping this as an option for their user base is the distribution's decision. The user base can vote with its feet. # The cost is in terms of having to think about what should go where for # one's user base. As far as I can see the /usr merge is mostly just an # attempt to get rid of the need to think. Pointing out that others did # this already is lemming mentality. Saying that you need stuff in /usr # anyway is blindly assuming it is needed in all cases or refusal to fix # what your users consider to be a bug. I have / and /usr on the same file system on all of my machines but still appreciate the fact that I have a choice. I like to keep it that way. As for */bin and */sbin, the latter category is not in my PATH. I also like to keep exercising that as an option. The idea of grouping certain classes of files in different directories makes it just so much easier for homo sapiens to keep a grip on things. Just imagine what / would look like if hardware progress would have outpaced software developments in 1971. There would not have been any need for /usr and we might have ended up with /games and /include and /local and /share as well as /src. Actually, that doesn't look all bad but I'm glad that the lack of disk space in 1971 helped us identify the notion that there are critical and non-critical files on our computers. About that not looking all bad, perhaps the merge should be in the other direction, from /usr to / rather than from / to /usr. Or can we expect suggestions to move /var, /tmp, /dev, /run, /media etc. to /usr "because all the stuff in /usr needs it anyway"? # Those are a non-serious suggestion and a rethorical question, in case # that didn't come across. So, I'm against a *forced* /usr merge. I hope Debian does the right thing but if necessary, I would like to see Devuan correct the wrong. However, let's focus on init freedom (and beowulf) first! Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Hi Nik, Dr. Nikolaus Klepp writes: > [...] The initrams tool provide a handy way to inspect/modify/rebuild > initrd. But the debian documentation on how initrd works is wrong: it > assumes a one part archive (which is what you would expect), but in > fact it is a 2 part archive (first part uncomressed, second > compressed). Take a look at /usr/bin/unmkinitramfs line 50 ff to see > how it works. Also look at the referenced linux/lib/earlycpio.c for > further detail. The most important point is this: processes started > in initrd survive switch_root. There goes your "full disk encryption" > myth. Not sure I understand what's going on but if you have an unencrypted /boot, you, by definition, don't have full disk encryption. I'm using libreboot as my BIOS and have *all* of /dev/md0 encrypted. My BIOS asks me for a password to decrypt whatever is in /boot. Are you implying that even in my scenario the "full disk encryption" myth goes out of my window? Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Sat, Nov 17, 2018 at 09:14:06PM +0900, Olaf Meeuwissen wrote: [cut] > > # Those are a non-serious suggestion and a rethorical question, in case > # that didn't come across. > > So, I'm against a *forced* /usr merge. I hope Debian does the right > thing but if necessary, I would like to see Devuan correct the wrong. > However, let's focus on init freedom (and beowulf) first! > The current default in debootstrap from Debian is to merge /usr, so buster installs will have /usr merged. This is not a problem at all for Devuan atm, since we forked debootstrap and base-installer and can act there to put back the default to non-merged /usr in Beowulf, leaving the option to the user to choose otherwise. More choice == more freedom ;) HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 16/11/18 at 12:08, Irrwahn wrote: > Steve Litt wrote on 16.11.18 11:11: >> On Fri, 16 Nov 2018 22:11:17 +1300 >> Daniel Reurich wrote: > [...] >>> So... for Devuan, do we want to default to a merged /usr in our coming >>> release of Beowulf or are we going to resist another pointless >>> rearranging of the deck chairs... >>> >>> Keen to get some feedback on this >> Back in the what, 1970's, the Unix guys >> split /usr/sbin, /sbin, /usr/bin, and /bin to accommodate early boot, >> by separating out statically compiled stuff used in the earliest boot. >> But then initramfs made these separate directories unnecessary, so why >> in the world would we continue the split? > Steve, > > with all due respect, in think your reasoning suffers from some kind of > slight misconception: > > The file system hierarchy split between / and /usr happened because the > disk mounted at / on one particular machine was filling up. Neither was > it a deliberate design decision, nor was it deemed elegant at the time > (and still is not). It was nothing but a dirty makeshift botch to quickly > compensate for some transient hardware constraint almost fifty years ago. As Rick Moen already pointed out, this is irrelevant. Empty bricks might have been introduced just for the sake of economy (use less material and save on building costs) they but turned out to be a boon for other then unexpected reasons: they allow to do away with the concept of walls that serve as the sustaining elements of the building, being replaced by much more earthquake-resistant structures that only rely on thin, light and much more flexible steel and concrete beams to hold up the whole structure. A separate /usr might have been introduced for the silliest an maybe even wrongest of the reasons, fact is that it turned out to be a very good filesystem layout concept that introduced flexibility and the possibility of further separation of binaries into essential and inessential ones. Shifting the small complexity of a separate /usr into another, more complex solution (initramfs) is stupid. It's like telling experimental aircraft pilots to do away with they back-packed parachute because it's old technology that was invented by a guy that was afraid of riding hot air baloons and telling them that they should instead adopt a modern, more advanced solution: the jet back-pack. What's next, merging /var into /usr? Doing away with /boot? Going back having user's home directories in /usr, since that was it's original use? Shall we please stop the madness? > It has nothing to do with the practice of using an initramfs (or similar > construct) for early user space system initialization. It's the merge proponents who have been insisting that initramfs are the technology that makes a separate /usr useless: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ «Today, a separate /usr partition already must be mounted by the initramfs during early boot, thus making the justification for a split-off moot.» Which is ludicrous, as it's just their design decision to make the initramfs indispensable to mount /usr on early boot, as it could in fact be mounted from / resident scripts and boot procedures without any initramfs at all. And the reasons to want a separate /usr filesystem go well beyond not having an initramfs. > In fact, if anything, a merged /usr obsoletes the need for an initramfs > WRT mounting system partitions, Again, the reasons to want a separate /usr filesystem go well beyond not having an initramfs. In fact the separate /usr filesystem was a reality well before initrd and initramfs were introduced. > as it is highly unlikely for /usr to > reside on a separate volume when it is merged into the root hierarchy, > where it belongs. This is crazy. Free(lol)desktop people decide out of thin air that / stuff belongs to /usr, constrain the distributions they control into this layout, and then say: "See? It is highly unlikely for /usr to reside on a separate volume! Root stuff belongs to usr!" You're putting the cart in front of the horse. And when people point this out to you you tell them that's where the cart belongs as it's unlikely to have a cart behind the horse. > If you dislike initramfs, you should go for a merged > /usr tree to err on the safe side when it comes to ensure availability > of essential system components during system initialization. No, what you actually do is: you put essential system components in / and you let the system initialization procedures take care of mounting /usr. This can be done without initramfs as it has been done for many years before initramd was introduced. That is, the best thing you could do is just leave things as they are, because they work just great. -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: Ope
Re: [DNG] /usr to merge or not to merge... that is the question??
Il 16/11/18 23:44, Harald Arnesen ha scritto:
> Irrwahn [11/16/18 9:10 PM]:
>
>> On System V Release 4 and later /bin has already been a symlink to
>> /usr/bin, and Solaris implemented the /usr merge about a decade ago.
>> Effectively, only some Unices and some Linux based distributions are
>> the odd ones out in that respect.
> And all the BSDs, macOS,...
You just reminded me one of the reasons because I do not run any of those.
https://www.reddit.com/r/BSD/comments/2szofc/eli5_why_is_separating_binaries_into_bin_sbin/
"
ELI5: Why is separating binaries into /bin, /sbin, /usr/bin,
/usr/sbin, /usr/local/bin, /usr/local/sbin a good thing?
Whenever I ask anyone what the advangages of BSD are, I invariably get
the answer that all binaries, configurations etc. all reside inside
/usr/local/{bin,etc,share,sbin,man...}. I understand the ideology behind
doing this (keeping the base system separate and all) but I don't
understand the practical advantages.
It is even said that this makes the BSDs somehow advantageous when
installing and removing multiple desktop environments. This doesn't make
any sense to me. The location of the files installed by a package should
not matter because the package manager keeps the location of the
installed files in its database. In other words, when I want to
uninstall GNOME, my package manager figures out what packages are
installed by the GNOME group and removes the files those packages
installed. To the package manager, it doesn't matter which directory
those files are in because it knows where it put them when it installed
the package in the first place.
I'm very sorry if I'm wholly misunderstanding this concept and I'm more
than happy to be corrected.
Thanks!"
--
Alessandro Selli
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE
signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
KatolaZ - 17.11.18, 13:03: > On Sat, Nov 17, 2018 at 12:57:23PM +0100, Alessandro Selli wrote: > > On 16/11/18 at 11:43, KatolaZ wrote: > > > On Fri, Nov 16, 2018 at 10:19:30AM +, Rowland Penny wrote: > > > > > > [cut] > > > > > >> So, after reading Steve's enlightening description, I am with > > >> him, the merge is only needed by systemd and seems to be a way > > >> of forcing it on everybody, so I am against it. > > > > > > It would be actually more productive to base this discussion on > > > solid > > > technical arguments. > > > > I am one of those who can't do without initramfs because I mostly > > run GNU/Linux on laptops and for obvious security reasons they all > > run on fully encrypted filesystems, / included. > > merged usr will be off by default in Devuan Beowulf, with the option > of opting in in expert install, or by installing the usrmerge package > provided in Debian. > > This shoud cover all the use cases and leave enough flexibility for > the sysadmin to choose what is best for them. I am fine with that. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 17/11/18 at 13:14, Olaf Meeuwissen wrote: > Hi Katolaz, > > KatolaZ writes: > >> On Sat, Nov 17, 2018 at 11:45:03AM +0100, KatolaZ wrote: >> >> [cut] >> >>> OK, before we continue with a flame about what is wrong and what is >>> right: it seems that the transition to the merged usr is *not* >>> mandatory so far, but it is actually performed at install time. I am >>> currently trying to understand at which point during installation this >>> happens, so that we could just make it optional (i.e, with an opt-in >>> semantics). >> I should have waited a couple of minutes before writing: it looks like >> it is just an option in debootstrap. It should be fairly easy to make >> it optional by tweaking base-installer. Working on that. We will have >> it in the new beowulf installer. > This reminded me of something I did to build my Devuan Docker images: > passing --no-merged-usr to debootstrap. See > > https://gitlab.com/paddy-hack/devuan/blob/master/bootstrap.sh#L21 > > Just like */bin and */sbin are useful to distinguish between programs > intended for general use and system administration use, the distinction > between / and /usr is useful to tell critical and non-critical programs > apart. How long before Free(lol)desktop decides that the separation between bin and sbin is so old-fashioned and useless to modern systems? [...] > Removing the distinction takes the option away from the user. Whether a > distribution wants to "pay the cost" of keeping this as an option for > their user base is the distribution's decision. The user base can vote > with its feet. Right, I subscribe to this point of view. And I also fully agree to everything stated below. > # The cost is in terms of having to think about what should go where for > # one's user base. As far as I can see the /usr merge is mostly just an > # attempt to get rid of the need to think. Pointing out that others did > # this already is lemming mentality. Saying that you need stuff in /usr > # anyway is blindly assuming it is needed in all cases or refusal to fix > # what your users consider to be a bug. > > I have / and /usr on the same file system on all of my machines but > still appreciate the fact that I have a choice. I like to keep it that > way. As for */bin and */sbin, the latter category is not in my PATH. I > also like to keep exercising that as an option. > > The idea of grouping certain classes of files in different directories > makes it just so much easier for homo sapiens to keep a grip on things. > Just imagine what / would look like if hardware progress would have > outpaced software developments in 1971. There would not have been any > need for /usr and we might have ended up with /games and /include and > /local and /share as well as /src. Actually, that doesn't look all bad > but I'm glad that the lack of disk space in 1971 helped us identify the > notion that there are critical and non-critical files on our computers. > > About that not looking all bad, perhaps the merge should be in the other > direction, from /usr to / rather than from / to /usr. Or can we expect > suggestions to move /var, /tmp, /dev, /run, /media etc. to /usr "because > all the stuff in /usr needs it anyway"? > > # Those are a non-serious suggestion and a rethorical question, in case > # that didn't come across. > > So, I'm against a *forced* /usr merge. I hope Debian does the right > thing but if necessary, I would like to see Devuan correct the wrong. > However, let's focus on init freedom (and beowulf) first! > > Hope this helps, > -- > Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 > GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 > Support Free Softwarehttps://my.fsf.org/donate > Join the Free Software Foundation https://my.fsf.org/join > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Le 16/11/2018 à 10:50, Rowland Penny a écrit : On Fri, 16 Nov 2018 22:11:17 +1300 Daniel Reurich wrote: Hi Devuan followers, fans and friends, Debian as of the upcoming Buster release looks to be implementing a merged /usr by default. At this stage there is no plan to make it forced... but you never know what happens when their Technical Committee suddenly decides it's an issue they need to force a decision on... So... for Devuan, do we want to default to a merged /usr in our coming release of Beowulf or are we going to resist another pointless rearranging of the deck chairs... Keen to get some feedback on this Cheers, Daniel Can anybody explain the bad points of doing the merger ? I ask this because everything I can find says it is a good thing, but they said systemd was a good thing ;-) The advantage of separating /usr is it can be mounted after boot. /bin and /sbin (and /lib) contain the critical applications (and library) necessary to boot the system, and they are, by necessity, part of the root filesystem. Merging /usr means, actually merging /usr/bin with /bin, /usr/sbin with /sbin and /usr/lib with /lib. Merging /usr means all the bloat from /usr/bin and /usr/lib will now be in /bin and /lib (not so much bloat in /usr/sbin). This has very little to do with the use of an initramfs. Only in corner cases would it prevent booting without an initramfs. Initramfs has been in use for at least 15 years in Debian and you cannot escape it if you use the stock Debian/Devuan kernel. You can write your own initramfs along with compiling your own kernel if you fancy something special, it's relatively easy and sometimes necessary, but you must take care that the Devuan init system finds the OS in the same state it finds it after the stock initramfs. If you want to boot directly to the disk, then don't use a distro. This isn't anything new. Initramfs is the easy way for distros to provide all possible device drivers as module. Otherwise, your kernel should be compiled according to the hardware detected by the installer. The kernel is able to do such things as booting to a root filesystem on a RAID or to a root filesystem mounted through NFS. These techniques have been implemented long before the advent of initramfs, but a custom initramfs can allow you to do it with more flexibility. The only serious issue with the "merge" is "do we want all that bloat in /bin and /lib?" Personnally I would prefer to break it down into /usr/editors, /usr/internet, /usr/office, /usr/games etc... Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 16/11/18 at 13:24, spiralofhope wrote: > On Fri, 16 Nov 2018 04:10:17 -0800 > spiralofhope wrote: > >> I conclude this is a transitory step toward making this mandatory; >> something like propagating the idea to ease transitional pains. > Oh, and I suppose I could chime in on the notion of Devuan following > suit. > > Of course it should. At this point, it must. > > From what I understand, not all Devuan-specific efforts have concluded. > Every upstream change that's resisted is another burden that distracts > from Devuan's core goals.. unless this becomes a discussion of > broadening them. If one narrowingly defined Devuan's scopes into "doing away with systemd" then the merge matter lays outside them. In instead those scopes were defined broadly as "design a sane Unix Veteran Admin-friendly OS" then it does not and has to be taken care of. -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 17/11/18 at 13:03, KatolaZ wrote: > On Sat, Nov 17, 2018 at 12:57:23PM +0100, Alessandro Selli wrote: >> On 16/11/18 at 11:43, KatolaZ wrote: >>> On Fri, Nov 16, 2018 at 10:19:30AM +, Rowland Penny wrote: >>> >>> [cut] >>> So, after reading Steve's enlightening description, I am with him, the merge is only needed by systemd and seems to be a way of forcing it on everybody, so I am against it. >>> It would be actually more productive to base this discussion on solid >>> technical arguments. >> >> I am one of those who can't do without initramfs because I mostly run >> GNU/Linux on laptops and for obvious security reasons they all run on >> fully encrypted filesystems, / included. >> > merged usr will be off by default in Devuan Beowulf, with the option > of opting in in expert install, or by installing the usrmerge package > provided in Debian. > > This shoud cover all the use cases and leave enough flexibility for > the sysadmin to choose what is best for them. Good choice . 👍 -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Alessandro Selli [11/17/18 1:48 PM]: > > Il 16/11/18 23:44, Harald Arnesen ha scritto: >> Irrwahn [11/16/18 9:10 PM]: >> >>> On System V Release 4 and later /bin has already been a symlink to >>> /usr/bin, and Solaris implemented the /usr merge about a decade ago. >>> Effectively, only some Unices and some Linux based distributions are >>> the odd ones out in that respect. >> And all the BSDs, macOS,... > > > You just reminded me one of the reasons because I do not run any of those. Your reason for not running BSD is that is has separate /bin and /usr/bin? -- Hilsen Harald ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Sat, Nov 17, 2018 at 02:02:17PM +0100, Alessandro Selli wrote: > > > > Just like */bin and */sbin are useful to distinguish between programs > > intended for general use and system administration use, the distinction > > between / and /usr is useful to tell critical and non-critical programs > > apart. > > > How long before Free(lol)desktop decides that the separation between > bin and sbin is so old-fashioned and useless to modern systems? I'd expect them to preserve the distiction so as to make it harder for users to find out whats going on under the hood. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Sat, Nov 17, 2018 at 01:43:14PM +0100, Alessandro Selli wrote: > > A separate /usr might have been introduced for the silliest an maybe > even wrongest of the reasons, fact is that it turned out to be a very > good filesystem layout concept that introduced flexibility and the > possibility of further separation of binaries into essential and > inessential ones. I separated /usr on my server long ago because it made allocation of disk space to partitions more flexible. This was in the days before LVM. LVM is great, but it makes allocation of nonLVM partitions more difficult (because so much disk space is in the LVM partition). And I've always wondered if LVM gets in the way of atomicity requirements for data bases. Shifting the small complexity of a separate /usr into > another, more complex solution (initramfs) is stupid. It's like telling > experimental aircraft pilots to do away with they back-packed parachute > because it's old technology that was invented by a guy that was afraid > of riding hot air baloons and telling them that they should instead > adopt a modern, more advanced solution: the jet back-pack. > > What's next, merging /var into /usr? Doing away with /boot? Going back > having user's home directories in /usr, since that was it's original use? I remember those days. It confused me for a few minutes when I first saw they were in /home instead. Then I saw the advantages. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Didier: ... > If you want to boot directly to the disk, then don't use a distro. ,,, I boot directly to disk, why shouldn't I use a distro ? I see no downside of using a distro, I just choose what parts I want to use. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Hi Olaf! Am Samstag, 17. November 2018 schrieb Olaf Meeuwissen: > Hi Nik, > > Dr. Nikolaus Klepp writes: > > > [...] The initrams tool provide a handy way to inspect/modify/rebuild > > initrd. But the debian documentation on how initrd works is wrong: it > > assumes a one part archive (which is what you would expect), but in > > fact it is a 2 part archive (first part uncomressed, second > > compressed). Take a look at /usr/bin/unmkinitramfs line 50 ff to see > > how it works. Also look at the referenced linux/lib/earlycpio.c for > > further detail. The most important point is this: processes started > > in initrd survive switch_root. There goes your "full disk encryption" > > myth. > > Not sure I understand what's going on but if you have an unencrypted > /boot, you, by definition, don't have full disk encryption. > > I'm using libreboot as my BIOS and have *all* of /dev/md0 encrypted. My > BIOS asks me for a password to decrypt whatever is in /boot. > > Are you implying that even in my scenario the "full disk encryption" > myth goes out of my window? Just for the fun of applied paranoia: How do you ensure that nobody tempered with your eeprom? Did you seal it propperly after you made the chip readonly? If not, then you still have the same problem, just a level higher. Or did you go the way of heads ( https://github.com/osresearch/heads ) ? Last time I checked, there was still a "full disk encryption" in the debian installer. I know that's just markeing blahblah, but still it gives a false sense of security to the not-so-paranoid user. There's even a bugreport about that misnomer: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858009 Nik > > Hope this helps, > -- > Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 > GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 > Support Free Softwarehttps://my.fsf.org/donate > Join the Free Software Foundation https://my.fsf.org/join > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fri, Nov 16, 2018 at 08:31:33PM +0100, k...@aspodata.se wrote: > Daniel Reurich: > ... > > So... for Devuan, do we want to default to a merged /usr in our coming > > release of Beowulf or are we going to resist another pointless > > rearranging of the deck chairs... > > I don't want it. > My view seems to coincide with Rich Moens. > > > Keen to get some feedback on this > > It is important to keep the boot setup simple, reliable and easy to > manage for the local admin. > > Initrd provides an obstacle and is counterprodictive to that principle > as is udev. Especially if not enough system comes up to run the programs needed to unpack, modify, and repack initrd. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Quoting Didier Kryn (k...@in2p3.fr): > If you want to boot directly to the disk, then don't use a distro. I very much do not concur. Since 1992 -- with a gap when I was lazy for a long time -- I've found it useful to construct bespoke kernels for my systems that compile inline the essential drivers and build as modules drivers that might or might not be needed later at runtime. But nothing about that local policy contraindicates my using a distribution, and never has. I love using Linux distributions, leveraging the work of talented package maintainers so as not to need to revert to the bad old days. Why would I not? The advantages to me are considerable, among those a smaller and faster kernel image, a smaller attack surface, less to go wrong, and eliminating the need for an initramfs. Your dichotomy makes no sense to me. > This isn't anything new. Initramfs is the easy way for distros to > provide all possible device drivers as module. But some of us don't want all possible dervice drivers as modules. > Otherwise, your kernel should be compiled according to the hardware > detected by the installer. Sounds good to me. The more I encounter the compromises made wile formulating distro policy, e.g., 'we need to stick with the world's most bloated bootloader because there are edge cases Syslinux cannot handle', and 'we need to make the system rely on an initrd because otherwise some edge cases involving md5-mirrored or dm-crypt or NFS root systems cannot boot', the more I'm glad I can easily override distro policy in favour of local policy. -- Cheers,"I never quarrel with a man who buys ink by the barrel." Rick Moen-- Rep. Charles B. Brownson (R-Indiana), ca. 1960 r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Il 16/11/18 16:46, Clarke Sideroad ha scritto: > On 2018-11-16 4:11 a.m., Daniel Reurich wrote: >> Hi Devuan followers, fans and friends, >> >> Debian as of the upcoming Buster release looks to be implementing a >> merged /usr by default. At this stage there is no plan to make it >> forced... but you never know what happens when their Technical Committee >> suddenly decides it's an issue they need to force a decision on... >> >> So... for Devuan, do we want to default to a merged /usr in our coming >> release of Beowulf or are we going to resist another pointless >> rearranging of the deck chairs... >> >> > Given the current "definition" of Devuan, I see little choice other > than following Debian, it is after all the source of most packages > used in Devuan. > Merged /usr will creep in 100% over time and one day not to far away > it will taint sid/ceres to the point that there is no choice anyway. > The dodging of systemd is already a big enough chunk to gnaw away, it > makes little sense to make the situation many times worse. If Devuan is going to have a brilliant future it is going to disenfranchise itself from Debian. Being forever a Debian without systemd will keep it in the backseat, vulnerable to all the odd decisions and arguable development directions that Devuan/FD are going to take. I think eventually going our own way will to prove no more a hassle that will be striving to be just like Debian except for fundamental, deep elements of that OS. > Like it or not systemd and its limitations are forcing changes to the > landscape and merged usr for little other reason, the once possible > uniting force of LSB is done for. Did you miss the fact that Devuan exists just for this reason, providing people with an alternative to what systemd is forcing down their throats? What you wrote is to me a reason to want to persevere even more strongly in own own direction. > Systemd's preferred hierarchy _is_ the new LSB. Live with it or go > it alone. Did you miss the news? Devuan's VUAs decided time ago to go it alone. > Ideally Devuan would be the new Debian and calling the shots, but that > is not happening soon, although at some point Devuan may be the > required lifeboat for Debian passengers. Devuan cannot forever be just a lifeboat. Let's be a little ambitious! Let's strive to have Devan have a life of it's own, not just being a lesser Debian. > There is likely a fairly solid Devuan installed base out there, but a > lot of that is based on close Debian compatibility at least for > initial install, IMHO we can't lose that or Devuan will quickly follow > various niche distros into oblivion. So long as compatibility is guaranteed with a generic GNU/Linux distribution, we're not going to cut Devuan out of the market that is feeding Linux. What matters is having a distribution that Just Works, is solid, reliable, secure and suffers not from inconsistencies or odd design decisions and can be easily tinkered with to be adapted to a large number of use cases. Could it be proven that Devuan was better than Debian in this regard, it could well surpass it in number of installations. GNU/Linux started as an operating clone of the generic Unix SysV, do you recall? Do you remember what happened next? -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Quoting Alessandro Selli (alessandrose...@linux.com): > I am one of those who can't do without initramfs because I mostly run > GNU/Linux on laptops and for obvious security reasons they all run on > fully encrypted filesystems, / included. True enough. One of several legitimate edge cases. > However I do loath the / and /usr merge. I find it irritating that I > am asked to provide with sound technical reasons to keep the two > filesystems separated as I needed to justify 4 decades of sound > sysadminiship practice when it's the proponents of the merge who in fact > have been doing a poor job to justify the purported need of the merge. > Their reasons all boil down to: "it's the way we want to do stuff". Ding! Exactly the recurring pattern with Freedesktop.org/GNOME talking points: What's irritating isn't their wishing to do things for uncompelling reasons, but rather justifications built from circular reasoning and illogic, implying their authors think readers are a bit dim. My response tend to be: Fine, run with your bad choices, and enjoy life, but kindly spare us the tiresome stemwinders about how any other view is wrong. I'll either avoid running your code or correct your blunders, and then we'll both be happy. One sometimes must override a distro's policies, too, but the difference is that they by and large aren't laying down a fog layer of badly written propaganda to justify what they wish to do. (Well, except Fedora. ;-> ) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 2018-11-17 14:08, Alessandro Selli wrote: Devuan cannot forever be just a lifeboat. Let's be a little ambitious! Let's strive to have Devuan have a life of it's own, not just being a lesser Debian. And just what will your contribution(s) be towards making that a reality (besides cheering us on)? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Fri, Nov 16, 2018 at 02:20:30PM -0800, Rick Moen wrote: > I note without objection (but rather with active appreciation, on > entertainment grounds) that every single one of your talking point so > far -- including the one above -- appear to have been copied > near-verbatim from the pair of Freedesktop.org UsrMerge advocacy Web > pages I dissected in this forum yesterday. Nicely played, sir! > > The above appears to have been copied from: > https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ Just to add fuel to the fire, I'll note that among the benefits listed is this gem: Improved compatibility with current upstream development: In order to minimize the delta from your Linux distribution to upstream development the /usr merge is key. If upstream signifies freedesktop.org (and who else could it be?) I think this is a pretty frank expression of their direction. cheers -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Quoting Daniel Reurich:: > I don't want it. > My view seems to coincide with Rich Moens. I'm still curious who these Rich Moens are. Perhaps a clone conspiracy as in Orphan Black -- or a franchise like Dread Pirate Roberts[tm]? ;-> -- Cheers,"I never quarrel with a man who buys ink by the barrel." Rick Moen-- Rep. Charles B. Brownson (R-Indiana), ca. 1960 r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 17/11/18 at 15:56, Harald Arnesen wrote:
> Alessandro Selli [11/17/18 1:48 PM]:
>> Il 16/11/18 23:44, Harald Arnesen ha scritto:
>>> Irrwahn [11/16/18 9:10 PM]:
>>>
On System V Release 4 and later /bin has already been a symlink to
/usr/bin, and Solaris implemented the /usr merge about a decade ago.
Effectively, only some Unices and some Linux based distributions are
the odd ones out in that respect.
>>> And all the BSDs, macOS,...
>>
>> You just reminded me one of the reasons because I do not run any of those.
> Your reason for not running BSD is that is has separate /bin and /usr/bin?
Sorry, I quoted a wrong URL. I was misled by the sentence: "I
invariably get the answer that all binaries, configurations etc. all
reside inside /usr/local/{bin,etc,share,sbin,man...}.", but rereading it
I see that only user software that is not involved in the boot process
is placed there.
Yet, the points that guy lists against the BSD /usr/local and / merge
apply well even against the proposed merge: the merge does not make
software installation easier or less prone to confusion, because
regardless where the package is going to place it's files, whether under
/ or /usr or /usr/local, it keeps track of its own files in the
installed packages' DB.
--
Alessandro Selli
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE
signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Alessandro Selli wrote: > If Devuan is going to have a brilliant future it is going to disenfranchise > itself from Debian. Being forever a Debian without systemd will keep it in > the backseat, vulnerable to all the odd decisions and arguable development > directions that Devuan/FD are going to take. In the long term, Devuan is likely to slowly diverge from Debian - and hopefully will gather support from Debian devs/package maintainers fed up with the Debian shenanigans. it's even possible to foresee a time when Devuan overtakes Debian and Debian ends up as a derivative of Devuan - but a long time off I think. In the meantime, there simply are not enough Devuan devs to simply dump Debian as an upstream. At the moment, most packages available in Devuan are unmodified Debian packages - there simply is no justification for re-inventing loads of stuff that doesn't need re-inventing, it would be a waste of effort. In the meantime, the devs the Devuan project does have can tackle those packages that need work - mostly de-systemdising broken packages and making substitutes for some bits. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 17/11/18 at 22:22, Joel Roth wrote: > On Fri, Nov 16, 2018 at 02:20:30PM -0800, Rick Moen wrote: > >> I note without objection (but rather with active appreciation, on >> entertainment grounds) that every single one of your talking point so >> far -- including the one above -- appear to have been copied >> near-verbatim from the pair of Freedesktop.org UsrMerge advocacy Web >> pages I dissected in this forum yesterday. Nicely played, sir! >> >> The above appears to have been copied from: >> https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ > Just to add fuel to the fire, I'll note that among the > benefits listed is this gem: > > Improved compatibility with current upstream development: In > order to minimize the delta from your Linux distribution to > upstream development the /usr merge is key. > > If upstream signifies freedesktop.org (and who else could it > be?) I think this is a pretty frank expression of their > direction. Right, what they stated amounts to declaring: "FD is *the* standard, FD is Linux." We're moving from GNU/Linux to FD/Linux, people! This reminds me of the past Gnome people's tech design and HR blunders, like when they decided people have no right to develop their own Gnome themes because that would dilute Gnome's "brand value" or when they tried bullying Transmission developers into adapting their software to fit Gnome 3's bad GUI designs: https://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/ «GNOME dev Allan Day writes: I’m particularly surprised by the inclusion of themes. It seems bizarre… [...] The point is that it decreases our brand presence.» https://trac.transmissionbt.com/ticket/3685 «I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I'm sorry that this is the case but it wasn't GNOME's fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry. It is my hope that you are a GNOME app.» Now it's Free(lol)desktop's turn to try to bully everyone into their breeding pen. What could possibily go wrong? -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Sat, 17 Nov 2018 02:53:27 -0500, Steve wrote in message <20181117025327.5e5ba...@mydesk.domain.cxm>: > Now personally, my root partition is on an ssd, and it includes /usr > so all my /usr/bin, /usr/local/bin, etc, come straight off SSD at > lightning speed. I like it like that. But a lot of people want /usr to > be mounted. ...e.g. on its own SSD. > [snip remarks about tiny diskspace requiring the split: ...which is easily solved if you bother to learn LVM, e.g.: https://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux) https://en.wikipedia.org/wiki/Logical_volume_management ...and this gem: https://www.howtoforge.com/linux_lvm Nobody ever saw this Debian Etch image as a viable start point for devuan? Hindsight is annoying... > That's not the source of my objection.] -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 17/11/18 at 22:25, Rick Moen wrote: > Quoting Daniel Reurich:: > >> I don't want it. >> My view seems to coincide with Rich Moens. > I'm still curious who these Rich Moens are. How many of you are there? Aren't you rich? 😃 -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Sat, Nov 17, 2018 at 11:22:59AM -1000, Joel Roth wrote: > On Fri, Nov 16, 2018 at 02:20:30PM -0800, Rick Moen wrote: > > I note without objection (but rather with active appreciation, on > > entertainment grounds) that every single one of your talking point so > > far -- including the one above -- appear to have been copied > > near-verbatim from the pair of Freedesktop.org UsrMerge advocacy Web > > pages I dissected in this forum yesterday. Nicely played, sir! > > > > The above appears to have been copied from: > > https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ Heh. It's been raised on #debian-devel today, too. The hard question was: 14:18 < bunk> mbiebl_: What are the "of course" benefits of merged /usr for a user? For a distribution I see the benefits of moving to merged /usr only, but I honestly don't know in what cases "Installing the usrmerge package will solve your problem." would be a correct answer to a user problem. Obviously, none of usrmerge proponents provided such an use case. Note that UsrMerge is not about dropping support for booting with a split fs and no initrd -- that's already done, and was a matter of reducing developer effort in return for hurting a very rare user use case. Here, the DNG thread revolves around this piece -- but UsrMerge (as in, the usrmerge package and debootstrap option) is only about pointlessly moving files. > Just to add fuel to the fire, I'll note that among the > benefits listed is this gem: > > Improved compatibility with current upstream development: In > order to minimize the delta from your Linux distribution to > upstream development the /usr merge is key. > > If upstream signifies freedesktop.org (and who else could it > be?) I think this is a pretty frank expression of their > direction. The thing is, the Red Hat world is rapidly going away. It's very hard to gauge the use share of distributions as 1. various use cases have different needs, 2. the vast majority of such use cases are hidden. Among what little solid data we have, it's probably easiest to measure web server share: all RPM distributions together are around 20% while they were at 65% just a few years ago. I imagine other use types to be alike. Thus, Red Hat is the new Solaris. It already went through dropping use share, and has just been snarfed by a corporation whose primary mode is wringing few lucrative customers dry. Like Solaris, I expect it to last less than a decade before the core team is laid off, major future releases cancelled... then to live in a zombie state for decades, like AIX or HP-UX. It will continue to make big s for IBM. Heck, COBOL still processes a good part of financial data. But no one among us even see anything COBOL. With the Red Hat ship sinking, so will freedesktop.org (as they're merely one of Red Hat's subprojects). On the other hand, systemd will survive in the medium term -- it was carefully designed as monolithic in a good part to make jumping ship hard, thus even in the worst (for them) case it'll get forked and continued by Ubuntu or Arch. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ I was born a dumb, ugly and work-loving kid, then I got swapped on ⠈⠳⣄ the maternity ward. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 17/11/18 at 23:24, Simon Hobson wrote: > Alessandro Selli wrote: > >> If Devuan is going to have a brilliant future it is going to disenfranchise >> itself from Debian. Being forever a Debian without systemd will keep it in >> the backseat, vulnerable to all the odd decisions and arguable development >> directions that Devuan/FD are going to take. > In the long term, Devuan is likely to slowly diverge from Debian - and > hopefully will gather support from Debian devs/package maintainers fed up > with the Debian shenanigans. it's even possible to foresee a time when Devuan > overtakes Debian and Debian ends up as a derivative of Devuan - but a long > time off I think. > In the meantime, there simply are not enough Devuan devs to simply dump > Debian as an upstream. At the moment, most packages available in Devuan are > unmodified Debian packages - there simply is no justification for > re-inventing loads of stuff that doesn't need re-inventing, it would be a > waste of effort. In the meantime, the devs the Devuan project does have can > tackle those packages that need work - mostly de-systemdising broken packages > and making substitutes for some bits. I'm well aware of the present limitations that make it impossible to let Devuan be an indipendent distribution: too little manpower behind it and too llittle corporate/VC support for it. It could well be that Devuan will never be anything more than a systemd-less-Debian, always behind it's parent distribution and always trying to catch up to their design implementations. Of course I wouldn't call this success. I was just stating the obvious: a distribution that succeeds is one that sets the path, not one that keeps trailing the trend-setters. Devuan was born to remedy a wrong turn taken by Debian's Technical Committee, the VUAs who launched the project decided to take into their hands the burden of reinstating to the fullest user's freedom of choice. Now there's another pending decision that might erode again this freedom. It could well be that Devuan will have to give in given it's manpower and budget constrains. Shall this happen it will mean Devuan failed to show the world it's principles and directions were sounder than Debian's, but I think that trying to achieve the success I deem it deserves implies sticking with taking the brave decision to keep undoing the wrong turns Debian's TC takes. Shall the market consider Devuan, decades after the split from Debian, still nothing more that a copy of Debian with some minor changes, it will likely fail to impress enough to be seriously considered and alternative in critical installations and deployments. "the Devuan project does have can tackle those packages that need work - mostly de-systemdising broken packages" Of course you understand that the / -> /usr merge fits systemd/FD's design goals, flattening all GNU/Linux distributions into the same mold, making alternative designs very hard to implement and maintain and letting the few FD's blessed distributions stand out as the Most Perfect ones and the only one deserving any consideration from CTOs and corporate decision-makers. Shall you agree with this, you should understand that the reasons to want to de-systemdise "broken packages" apply to the de-unmerging / and /usr as well. Devuan could fail to do this, of course. I hope it will not. Shall it not fail it will necessarily rise into prominence among the crowd of the alternative Linux distributions. Again, I think I'm stating the obvious here. -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Sat, 17 Nov 2018 12:32:59 +0100, Martin wrote in message <44080848.gBCAc932W8@merkaba>: > Martin Steigerwald - 16.11.18, 16:04: > > In any case: Regarding a decision I'd take the amount of effort into > > account which would be needed to divert from Debian's default. As > > long as Debian still supports the usr split, I bet that effort > > would be minimal, but as soon as packages appear that just stuff > > anything in '/usr', then diverting becomes more and more pointless > > or Devuan would need to carry packages with different directory > > layout. > > Some Debian developers who are involved with packaging Systemd and > related stuff already started to move things to /usr that were in > directories under / before: > > Please move libkmod to /usr/lib > https://bugs.debian.org/894566 ..to clarify, "Please move libkmod to /usr/lib" is the title of https://bugs.debian.org/894566 and is what the systemd people wanna do to Debian, and what we should not wanna do to Devuan. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 17/11/18 at 21:35, goli...@dyne.org wrote: > On 2018-11-17 14:08, Alessandro Selli wrote: >> >> Devuan cannot forever be just a lifeboat. Let's be a little >> ambitious! Let's strive to have Devuan have a life of it's own, not >> just >> being a lesser Debian. >> > > And just what will your contribution(s) be towards making that a > reality (besides cheering us on)? Isn't cheering you up enough? What do you expect me to do, to be able to express my views on what would constitute Devuan's success? -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 11/17/2018 06:26 PM, Arnt Karlsen wrote: On Sat, 17 Nov 2018 12:32:59 +0100, Martin wrote in message <44080848.gBCAc932W8@merkaba>: Martin Steigerwald - 16.11.18, 16:04: In any case: Regarding a decision I'd take the amount of effort into account which would be needed to divert from Debian's default. As long as Debian still supports the usr split, I bet that effort would be minimal, but as soon as packages appear that just stuff anything in '/usr', then diverting becomes more and more pointless or Devuan would need to carry packages with different directory layout. Some Debian developers who are involved with packaging Systemd and related stuff already started to move things to /usr that were in directories under / before: Please move libkmod to /usr/lib https://bugs.debian.org/894566 ..to clarify, "Please move libkmod to /usr/lib" is the title of https://bugs.debian.org/894566 and is what the systemd people wanna do to Debian, and what we should not wanna do to Devuan. You did see the date on that first message right? Subject: Please move libkmod to /usr/lib Date: Sun, 01 Apr 2018 18:10:28 +0200 Borg is, Borg does. The problem is not the Borg collective but the borg collectives, one trying to assimilate the other. Anything the helps FD, systemd, I say no. Keep moving forward. That's all I have to say about that. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Sun, Nov 18, 2018 at 12:22:18AM +0100, Alessandro Selli wrote: > I'm well aware of the present limitations that make it impossible to > let Devuan be an indipendent distribution: too little manpower behind it > and too llittle corporate/VC support for it. It could well be that > Devuan will never be anything more than a systemd-less-Debian, always > behind it's parent distribution and always trying to catch up to their > design implementations. Of course I wouldn't call this success. I think that instead of making Devuan independent, we should strive to kill it. Just not in the way Lennart wants. By keeping all unbelievers to a ghetto, systemd proponents make way for an excuse for putting Debian even deeper into the systemd land. Thus, widening the gap is IMHO the worst thing you can do. Instead, any package diff from Debian should be considered a problem to be fixed. Any patches, instead of removing systemd support, should make things work both with systemd and modular init/rc systems. And be upstreamed as soon as possible. And once Devuan differs only by some graphics and the default state of a checkbox in the installer, I'd call the mission accomplished. But today, there's even no checkbox in the installer... Meow! -- ⢀⣴⠾⠻⢶⣦⠀ .globl _start↵.data↵rc: .ascii "/etc/init.d/rcS\0"↵.text↵_start ⣾⠁⢰⠒⠀⣿⡁ mov $57,%rax↵syscall↵cmp $0,%rax↵jne child↵parent:↵mov $61,%rax ⢿⡄⠘⠷⠚⠋⠀ mov $-1,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall↵jmp parent↵child: ⠈⠳⣄ mov $59,%rax↵mov $rc,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 11/17/18 3:18 PM, Didier Kryn wrote: The advantage of separating /usr is it can be mounted after boot. /bin and /sbin (and /lib) contain the critical applications (and library) necessary to boot the system, and they are, by necessity, part of the root filesystem. Merging /usr means, actually merging /usr/bin with /bin, /usr/sbin with /sbin and /usr/lib with /lib. Merging /usr means all the bloat from /usr/bin and /usr/lib will now be in /bin and /lib (not so much bloat in /usr/sbin). This has very Two more questions: 1. Installing (too many) software from repositories tends to fill in /usr to the point it screams for space (particularly in older machines with smaller HDD). However it seems to me that the root filesystem is still happy in such cases. But what in case of merger? Can the whole system be rendered unusable? (Or screaming?) 2. What about local compilations of various 3rd party software that usually go to /usr/local/bin, sbin, lib, ... in case of merger will they all go to the root filesystem? More potential trouble? Yes/No? Tnx. Misko ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 2018-11-17 17:26, Alessandro Selli wrote: On 17/11/18 at 21:35, goli...@dyne.org wrote: On 2018-11-17 14:08, Alessandro Selli wrote: Devuan cannot forever be just a lifeboat. Let's be a little ambitious! Let's strive to have Devuan have a life of it's own, not just being a lesser Debian. And just what will your contribution(s) be towards making that a reality (besides cheering us on)? Isn't cheering you up enough? Finding more work for US to do does not cheer me up. In fact, just the opposite. It would cheer me UP if you rolled up your sleeves and contributed something tangible to making the Devuan of your dreams a reality. What do you expect me to do, to be able to express my views on what would constitute Devuan's success? Everyone has a right to their views but talk, as they say, is cheap. IOW, actions speak louder than words. ;) Feel free to come play with us! :D ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Sun, 18 Nov 2018 01:21:05 +0100, Miroslav wrote in message <075cb09d-9f17-1610-ced5-7ad556f5e...@uns.ac.rs>: > On 11/17/18 3:18 PM, Didier Kryn wrote: > > > > > > > > The advantage of separating /usr is it can be mounted after > > boot. /bin and /sbin (and /lib) contain the critical applications > > (and library) necessary to boot the system, and they are, by > > necessity, part of the root filesystem. Merging /usr means, > > actually merging /usr/bin with /bin, /usr/sbin with /sbin > > and /usr/lib with /lib. > > > > Merging /usr means all the bloat from /usr/bin and /usr/lib > > will now be in /bin and /lib (not so much bloat in /usr/sbin). This > > has very > > > Two more questions: > > 1. Installing (too many) software from repositories tends to fill in > /usr to the point it screams for space (particularly in older > machines with smaller HDD). However it seems to me that the root > filesystem is still happy in such cases. But what in case of merger? > Can the whole system be rendered unusable? (Or screaming?) ..easily IME, just put _everything_ in / , then fire up aptitude and pick the "Not Installed Packages (42209)" and see what happens. ;o) ..I killed it at 160%+81.something% load to bail out this time. :o) > 2. What about local compilations of various 3rd party software that > usually go to /usr/local/bin, sbin, lib, ... in case of merger will > they all go to the root filesystem? More potential trouble? Yes/No? > Tnx. ..you want these on its own disk, or at least on their own disk partitions, like your /home tree. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Sat, 17 Nov 2018 18:53:59 -0500, etech3 wrote in message <5bf0aa17.9030...@e-tech-systems.com>: > On 11/17/2018 06:26 PM, Arnt Karlsen wrote: > > On Sat, 17 Nov 2018 12:32:59 +0100, Martin wrote in message > > <44080848.gBCAc932W8@merkaba>: > > > >> Martin Steigerwald - 16.11.18, 16:04: > >>> In any case: Regarding a decision I'd take the amount of effort > >>> into account which would be needed to divert from Debian's > >>> default. As long as Debian still supports the usr split, I bet > >>> that effort would be minimal, but as soon as packages appear that > >>> just stuff anything in '/usr', then diverting becomes more and > >>> more pointless or Devuan would need to carry packages with > >>> different directory layout. > >> Some Debian developers who are involved with packaging Systemd and > >> related stuff already started to move things to /usr that were in > >> directories under / before: > >> > >> Please move libkmod to /usr/lib > >> https://bugs.debian.org/894566 > > ..to clarify, "Please move libkmod to /usr/lib" is the title of > > https://bugs.debian.org/894566 and is what the systemd people > > wanna do to Debian, and what we should not wanna do to Devuan. > > > You did see the date on that first message right? > Subject: Please move libkmod to /usr/lib > Date: Sun, 01 Apr 2018 18:10:28 +0200 > Borg is, Borg does. The problem is not the Borg collective but the > borg collectives, one trying to assimilate the other. Anything the > helps FD, systemd, I say no. Keep moving forward. > > That's all I have to say about that. ..as April 1'st jokes go, this one is fairly elaborate, check out Message #10 and below, maybe they have some flying-under-the-radar fun coming on Monday April 1'st 2019? ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Sun, Nov 18, 2018 at 02:28:25AM +0100, Arnt Karlsen wrote: > On Sun, 18 Nov 2018 01:21:05 +0100, Miroslav wrote in message > <075cb09d-9f17-1610-ced5-7ad556f5e...@uns.ac.rs>: > > > On 11/17/18 3:18 PM, Didier Kryn wrote: > > > > > > > > > > > > > > The advantage of separating /usr is it can be mounted after > > > boot. /bin and /sbin (and /lib) contain the critical applications > > > (and library) necessary to boot the system, and they are, by > > > necessity, part of the root filesystem. Merging /usr means, > > > actually merging /usr/bin with /bin, /usr/sbin with /sbin > > > and /usr/lib with /lib. > > > > > > Merging /usr means all the bloat from /usr/bin and /usr/lib > > > will now be in /bin and /lib (not so much bloat in /usr/sbin). This > > > has very > > > > > > Two more questions: > > > > 1. Installing (too many) software from repositories tends to fill in > > /usr to the point it screams for space (particularly in older > > machines with smaller HDD). However it seems to me that the root > > filesystem is still happy in such cases. But what in case of merger? > > Can the whole system be rendered unusable? (Or screaming?) > > ..easily IME, just put _everything_ in / , then fire up aptitude and > pick the "Not Installed Packages (42209)" and see what happens. ;o) > > ..I killed it at 160%+81.something% load to bail out this time. :o) > > > > 2. What about local compilations of various 3rd party software that > > usually go to /usr/local/bin, sbin, lib, ... in case of merger will > > they all go to the root filesystem? More potential trouble? Yes/No? > > Tnx. > > ..you want these on its own disk, or at least on their own disk > partitions, like your /home tree. I can see no reason why /usr/local shouldn't be mounted as a separate partition even if /usr isn't. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 11/17/2018 08:43 PM, Arnt Karlsen wrote: On Sat, 17 Nov 2018 18:53:59 -0500, etech3 wrote in message <5bf0aa17.9030...@e-tech-systems.com>: On 11/17/2018 06:26 PM, Arnt Karlsen wrote: On Sat, 17 Nov 2018 12:32:59 +0100, Martin wrote in message <44080848.gBCAc932W8@merkaba>: Martin Steigerwald - 16.11.18, 16:04: In any case: Regarding a decision I'd take the amount of effort into account which would be needed to divert from Debian's default. As long as Debian still supports the usr split, I bet that effort would be minimal, but as soon as packages appear that just stuff anything in '/usr', then diverting becomes more and more pointless or Devuan would need to carry packages with different directory layout. Some Debian developers who are involved with packaging Systemd and related stuff already started to move things to /usr that were in directories under / before: Please move libkmod to /usr/lib https://bugs.debian.org/894566 ..to clarify, "Please move libkmod to /usr/lib" is the title of https://bugs.debian.org/894566 and is what the systemd people wanna do to Debian, and what we should not wanna do to Devuan. You did see the date on that first message right? Subject: Please move libkmod to /usr/lib Date: Sun, 01 Apr 2018 18:10:28 +0200 Borg is, Borg does. The problem is not the Borg collective but the borg collectives, one trying to assimilate the other. Anything the helps FD, systemd, I say no. Keep moving forward. That's all I have to say about that. ..as April 1'st jokes go, this one is fairly elaborate, check out Message #10 and below, maybe they have some flying-under-the-radar fun coming on Monday April 1'st 2019? ;o) OK, one more thing about that... yea I saw #10. I don't we have to wait for 2019. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ANSWER: because of systemd, FD... I have to laugh because, about 6 weeks ago started seeing some creep when doing a test upgrade from Devuan Jessie to Ascii. trying to prepare for a new test install of asterisk and stuff. I had finally got mondoresue to work in Devaun Jessie with a bunch of changes. After upgrading to Ascii, on rebooot system went into initramfs command line. Mondo worked fine in Devuan Jessie after upgrading kernel to ascii 4.9. restore went fine until after full dist-upgrade to ascii, system went BORK. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 18/11/18 at 02:01, goli...@dyne.org wrote: > On 2018-11-17 17:26, Alessandro Selli wrote: >> On 17/11/18 at 21:35, goli...@dyne.org wrote: >>> On 2018-11-17 14:08, Alessandro Selli wrote: Devuan cannot forever be just a lifeboat. Let's be a little ambitious! Let's strive to have Devuan have a life of it's own, not just being a lesser Debian. >>> >>> And just what will your contribution(s) be towards making that a >>> reality (besides cheering us on)? >> >> >> Isn't cheering you up enough? >> > > Finding more work for US to do does not cheer me up. In fact, just the > opposite. It would cheer me UP if you rolled up your sleeves and > contributed something tangible to making the Devuan of your dreams a > reality. It's not me who found more work for you. It's the Free(lol!)desktop people and Debian's Technical Committee. >> What do you expect me to do, to be able to express my views on what >> would constitute Devuan's success? >> > > Everyone has a right to their views but talk, as they say, is cheap. Does this mean: "Have your views, but abstain from expressing them on the mailing list?" > IOW, actions speak louder than words. ;) Feel free to come play with > us! :D My question is yet unanswered. Regards, -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 2018-11-17 21:36, Alessandro Selli wrote: On 18/11/18 at 02:01, goli...@dyne.org wrote: On 2018-11-17 17:26, Alessandro Selli wrote: On 17/11/18 at 21:35, goli...@dyne.org wrote: On 2018-11-17 14:08, Alessandro Selli wrote: Devuan cannot forever be just a lifeboat. Let's be a little ambitious! Let's strive to have Devuan have a life of it's own, not just being a lesser Debian. And just what will your contribution(s) be towards making that a reality (besides cheering us on)? Isn't cheering you up enough? Finding more work for US to do does not cheer me up. In fact, just the opposite. It would cheer me UP if you rolled up your sleeves and contributed something tangible to making the Devuan of your dreams a reality. It's not me who found more work for you. It's the Free(lol!)desktop people and Debian's Technical Committee. This is true. But finding problems does not SOLVE them. What do you expect me to do, to be able to express my views on what would constitute Devuan's success? Everyone has a right to their views but talk, as they say, is cheap. Does this mean: "Have your views, but abstain from expressing them on the mailing list?" Of course not. I think something is getting lost in translation. I just suggesting to take action to translate those views into tangible solutions in the Devuan repos. IOW, actions speak louder than words. ;) Feel free to come play with us! :D My question is yet unanswered. I think it has been answered and more than once. ;) Cheers! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Hi Nik, Dr. Nikolaus Klepp writes: > Hi Olaf! > > Am Samstag, 17. November 2018 schrieb Olaf Meeuwissen: >> Hi Nik, >> >> Dr. Nikolaus Klepp writes: >> >> > [...] The initrams tool provide a handy way to inspect/modify/rebuild >> > initrd. But the debian documentation on how initrd works is wrong: it >> > assumes a one part archive (which is what you would expect), but in >> > fact it is a 2 part archive (first part uncomressed, second >> > compressed). Take a look at /usr/bin/unmkinitramfs line 50 ff to see >> > how it works. Also look at the referenced linux/lib/earlycpio.c for >> > further detail. The most important point is this: processes started >> > in initrd survive switch_root. There goes your "full disk encryption" >> > myth. >> >> Not sure I understand what's going on but if you have an unencrypted >> /boot, you, by definition, don't have full disk encryption. >> >> I'm using libreboot as my BIOS and have *all* of /dev/md0 encrypted. My >> BIOS asks me for a password to decrypt whatever is in /boot. >> >> Are you implying that even in my scenario the "full disk encryption" >> myth goes out of my window? > > Just for the fun of applied paranoia: How do you ensure that nobody > tempered with your eeprom? Did you seal it propperly after you made > the chip readonly? If not, then you still have the same problem, just > a level higher. If someone tampered with the eeprom I guess I'd have a problem and someone might be eavesdropping on my disk I/O but my disks would still be fully encrypted as in I could give you one of the disks from my RAID1 setup and you wouldn't be able to find out what's on it. > Or did you go the way of heads (https://github.com/osresearch/heads)? Libreboot is coreboot w/o the blobs and I went down a path similar to that taken by heads. The BIOS has a GRUB payload capable of decrypting enough of the disk(s) to pass the buck to the OS. > Last time I checked, there was still a "full disk encryption" in the > debian installer. I know that's just markeing blahblah, but still it > gives a false sense of security to the not-so-paranoid user. There's > even a bugreport about that misnomer: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858009 :-) Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Hi KatolaZ, KatolaZ writes: > On Sat, Nov 17, 2018 at 09:14:06PM +0900, Olaf Meeuwissen wrote: > > [cut] > >> >> # Those are a non-serious suggestion and a rethorical question, in case >> # that didn't come across. >> >> So, I'm against a *forced* /usr merge. I hope Debian does the right >> thing but if necessary, I would like to see Devuan correct the wrong. >> However, let's focus on init freedom (and beowulf) first! >> > > The current default in debootstrap from Debian is to merge /usr, so > buster installs will have /usr merged. This is not a problem at all > for Devuan atm, since we forked debootstrap and base-installer and can > act there to put back the default to non-merged /usr in Beowulf, > leaving the option to the user to choose otherwise. > > More choice == more freedom ;) ACK. Just like to point out that Devuan might run into packages that have already moved programs that really ought to be in /bin or /sbin over to /usr/bin and /usr/sbin. Image bash getting installed in /usr/bin/bash. With the merged /usr scenario that's not a problem because /bin is a symlink to /usr/bin and all you #!/bin/bash scripts will continue to work just fine. In the non-merged scenario /bin/bash will not exist and all hell breaks loose. Ditto for /sbin and /lib. Now bash is an extreme example but there may be a few extra packages that may need to be forked :-( Alternatively, an usr-un-merge package could provide dpkg-hooks that move things to there right place and/or add a symlink from one place to the other. Just a thought. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Sun, Nov 18, 2018 at 12:22:18AM +0100, Alessandro Selli wrote: [cut] > > Devuan was born to remedy a wrong turn taken by Debian's Technical > Committee, the VUAs who launched the project decided to take into their > hands the burden of reinstating to the fullest user's freedom of > choice. Now there's another pending decision that might erode again > this freedom. It could well be that Devuan will have to give in given > it's manpower and budget constrains. Shall this happen it will mean > Devuan failed to show the world it's principles and directions were > sounder than Debian's, but I think that trying to achieve the success I > deem it deserves implies sticking with taking the brave decision to keep > undoing the wrong turns Debian's TC takes. > Besides the drama: we built yesterday a preliminary version of the debian-installer for beowulf which has an explicit opt-in question for usrmerge: https://pkgmaster.devuan.org/devuan/dists/unstable/main/installer-amd64/current/ and defaults to the classical behaviour (/bin and /sbin proper folders under /). Please use the mini.iso, and do not report any bug related to desktop thingies not working, since elogind and polkit-stuff are not there yet. Regards KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Sun, Nov 18, 2018 at 01:08:41AM +0100, Adam Borowski wrote: > On Sun, Nov 18, 2018 at 12:22:18AM +0100, Alessandro Selli wrote: > > I'm well aware of the present limitations that make it impossible to > > let Devuan be an indipendent distribution: too little manpower behind it > > and too llittle corporate/VC support for it. It could well be that > > Devuan will never be anything more than a systemd-less-Debian, always > > behind it's parent distribution and always trying to catch up to their > > design implementations. Of course I wouldn't call this success. > > I think that instead of making Devuan independent, we should strive to kill > it. Just not in the way Lennart wants. > > By keeping all unbelievers to a ghetto, systemd proponents make way for an > excuse for putting Debian even deeper into the systemd land. Thus, widening > the gap is IMHO the worst thing you can do. > > Instead, any package diff from Debian should be considered a problem to be > fixed. Any patches, instead of removing systemd support, should make things > work both with systemd and modular init/rc systems. And be upstreamed as > soon as possible. This is not gonna happen, given for instance the way our presence in debian-devel has been "cheered up" (with aggressive posts and personal insults). The truth is that too many people have a problem with other people not liking systemd and not wanting it around. So I am sorry but Devuan will stay around. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Sun, Nov 18, 2018 at 04:51:43PM +0900, Olaf Meeuwissen wrote: [cut] > > ACK. Just like to point out that Devuan might run into packages that > have already moved programs that really ought to be in /bin or /sbin > over to /usr/bin and /usr/sbin. > > Image bash getting installed in /usr/bin/bash. With the merged /usr > scenario that's not a problem because /bin is a symlink to /usr/bin and > all you #!/bin/bash scripts will continue to work just fine. In the > non-merged scenario /bin/bash will not exist and all hell breaks loose. > Let's solve first the problems that we have now, instead of trying to solve the problems that we do not have as yet (and might not ever have at all), OK? :) There is no reason so far for the packagers of basic utilities to massively move their stuff under /usr/bin and/or /usr/sbin. So let's keep calm and carry on ;) HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
hi Olaf! Am Sonntag, 18. November 2018 schrieb Olaf Meeuwissen: > > Just for the fun of applied paranoia: How do you ensure that nobody > > tempered with your eeprom? Did you seal it propperly after you made > > the chip readonly? If not, then you still have the same problem, just > > a level higher. > > If someone tampered with the eeprom I guess I'd have a problem and > someone might be eavesdropping on my disk I/O but my disks would still > be fully encrypted as in I could give you one of the disks from my RAID1 > setup and you wouldn't be able to find out what's on it. Or inject a keylogger into your grub payload - which is quite easy. Sniffed keystrokes could be stored in the very same eeprom (or cmos ram or ...). Or intercept the grub boot command, as at that point the kernel + initrd are already loaded from the decrypted boot partition, but kernel has not taken over control now. Modifying initrd on the fly would be quite nice ... > Hope this helps, > -- > Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 > GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 > Support Free Softwarehttps://my.fsf.org/donate > Join the Free Software Foundation https://my.fsf.org/join > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
KatolaZ - 18.11.18, 09:40: > On Sun, Nov 18, 2018 at 04:51:43PM +0900, Olaf Meeuwissen wrote: […] > > ACK. Just like to point out that Devuan might run into packages > > that > > have already moved programs that really ought to be in /bin or /sbin > > over to /usr/bin and /usr/sbin. > > > > Image bash getting installed in /usr/bin/bash. With the merged /usr > > scenario that's not a problem because /bin is a symlink to /usr/bin > > and all you #!/bin/bash scripts will continue to work just fine. > > In the non-merged scenario /bin/bash will not exist and all hell > > breaks loose. > Let's solve first the problems that we have now, instead of trying to > solve the problems that we do not have as yet (and might not ever have > at all), OK? :) > > There is no reason so far for the packagers of basic utilities to > massively move their stuff under /usr/bin and/or /usr/sbin. So let's > keep calm and carry on ;) As pointed out already… kmod in Debian is already changed to having libkmod in /usr instead of /lib¹. kmod is being maintained by Debian developers who are also involved with Systemd. Thus… /usr mounted later… all drivers in order to actually mount /usr would have to be compiled into the kernel with that updated kmod package already. And they just moved the library, not the binary for now. Worrying themselves they may break to much by moving the binaries. However so far, that is just one package I am aware of. Devuan could have its own version of it. Likely not all Debian developers propagate the usrmerge. [1] Please move libkmod to /usr/lib https://bugs.debian.org/894566 -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
KatolaZ - 18.11.18, 09:36: > On Sun, Nov 18, 2018 at 01:08:41AM +0100, Adam Borowski wrote: > > On Sun, Nov 18, 2018 at 12:22:18AM +0100, Alessandro Selli wrote: > > > I'm well aware of the present limitations that make it > > > impossible to let Devuan be an indipendent distribution: too > > > little manpower behind it and too llittle corporate/VC support > > > for it. It could well be that Devuan will never be anything more > > > than a systemd-less-Debian, always behind it's parent > > > distribution and always trying to catch up to their design > > > implementations. Of course I wouldn't call this success.> > > I think that instead of making Devuan independent, we should strive > > to kill it. Just not in the way Lennart wants. > > > > By keeping all unbelievers to a ghetto, systemd proponents make way > > for an excuse for putting Debian even deeper into the systemd land. > > Thus, widening the gap is IMHO the worst thing you can do. > > > > Instead, any package diff from Debian should be considered a problem > > to be fixed. Any patches, instead of removing systemd support, > > should make things work both with systemd and modular init/rc > > systems. And be upstreamed as soon as possible. > > This is not gonna happen, given for instance the way our presence in > debian-devel has been "cheered up" (with aggressive posts and personal The most important aspect here is: "has been". Its in the past already and it does not determine the future. > insults). The truth is that too many people have a problem with other > people not liking systemd and not wanting it around. So I am sorry > but Devuan will stay around. Maybe… not just yet. But there certainly is a potential. I am glad about the wonderful cooperation between some Devuan and some Debian developers. Of course, re-uniting and still providing the choice between any other init system and systemd or usr-split and usr-merge would require to solve quite some technical challenges as well. I'd say it is not impossible, but it could be challenging. However… I certainly agree with you on working with what is important now and focus with the wonderful collaboration that some may have thought would be totally impossible. Move on from what we have… instead of focusing of what we do not appear to have yet. Focus on the abundance, instead of on the lack. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Sun, Nov 18, 2018 at 10:40:47AM +0100, Martin Steigerwald wrote: > KatolaZ - 18.11.18, 09:40: > > On Sun, Nov 18, 2018 at 04:51:43PM +0900, Olaf Meeuwissen wrote: > […] > > > ACK. Just like to point out that Devuan might run into packages > > > that > > > have already moved programs that really ought to be in /bin or /sbin > > > over to /usr/bin and /usr/sbin. > > > > > > Image bash getting installed in /usr/bin/bash. With the merged /usr > > > scenario that's not a problem because /bin is a symlink to /usr/bin > > > and all you #!/bin/bash scripts will continue to work just fine. > > > In the non-merged scenario /bin/bash will not exist and all hell > > > breaks loose. > > Let's solve first the problems that we have now, instead of trying to > > solve the problems that we do not have as yet (and might not ever have > > at all), OK? :) > > > > There is no reason so far for the packagers of basic utilities to > > massively move their stuff under /usr/bin and/or /usr/sbin. So let's > > keep calm and carry on ;) > > As pointed out already… kmod in Debian is already changed to having > libkmod in /usr instead of /lib¹. kmod is being maintained by Debian > developers who are also involved with Systemd. > > Thus… /usr mounted later… all drivers in order to actually mount /usr > would have to be compiled into the kernel with that updated kmod package > already. And they just moved the library, not the binary for now. > Worrying themselves they may break to much by moving the binaries. This is actually from yesterday night :D We'll have a look and decide how to proceed. My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 18/11/18 at 09:32, KatolaZ wrote: > On Sun, Nov 18, 2018 at 12:22:18AM +0100, Alessandro Selli wrote: > > [cut] > >> Devuan was born to remedy a wrong turn taken by Debian's Technical >> Committee, the VUAs who launched the project decided to take into their >> hands the burden of reinstating to the fullest user's freedom of >> choice. Now there's another pending decision that might erode again >> this freedom. It could well be that Devuan will have to give in given >> it's manpower and budget constrains. Shall this happen it will mean >> Devuan failed to show the world it's principles and directions were >> sounder than Debian's, but I think that trying to achieve the success I >> deem it deserves implies sticking with taking the brave decision to keep >> undoing the wrong turns Debian's TC takes. >> > Besides the drama: we built yesterday a preliminary version of the > debian-installer for beowulf which has an explicit opt-in question for > usrmerge: > > > https://pkgmaster.devuan.org/devuan/dists/unstable/main/installer-amd64/current/ > > and defaults to the classical behaviour (/bin and /sbin proper folders > under /). Please use the mini.iso, and do not report any bug related > to desktop thingies not working, since elogind and polkit-stuff are > not there yet. Great! As I already wrote: I think this is the best solution for this issue, letting users choose defaulting to a sane, time-proven default. Thank you! -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 18-11-18 09:36, KatolaZ wrote: > This is not gonna happen, given for instance the way our presence in > debian-devel has been "cheered up" (with aggressive posts and personal > insults). The truth is that too many people have a problem with other > people not liking systemd and not wanting it around. So I am sorry but > Devuan will stay around. > > HND > > KatolaZ That had been to be expected the origins of Devuan were not a polite conversation and language used on this list against debian-devs still contains harsh words. If only possible i would advise to stay present on debian-devel so they never can have the say Devuan does not want cooperation. (And to remind them daily what bad choice they made with their systemd only. Which is the origin of their aggressive posts now.) Just my 2 cents. Grtz. Nick signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 18/11/18 at 10:46, Martin Steigerwald wrote: > KatolaZ - 18.11.18, 09:36: >> This is not gonna happen, given for instance the way our presence in >> debian-devel has been "cheered up" (with aggressive posts and personal > The most important aspect here is: "has been". Its in the past already > and it does not determine the future. Maybe not. If my English Grammar is still worth the schoolbook paper it was printed on, "has been" is the Present Continuous Tense, that is used "to express the idea that something is happening now, at this very moment. It can also be used to show that something is not happening now." So, the main use is for "something is happening now", sometimes for "something [that] is not happening now." Hopefully KatolaZ used it in the second sense, but I'm afraid he meant it in the first sense, which is statistically predominant. >> insults). The truth is that too many people have a problem with other >> people not liking systemd and not wanting it around. So I am sorry >> but Devuan will stay around. > Maybe… not just yet. > > But there certainly is a potential. I am glad about the wonderful > cooperation between some Devuan and some Debian developers. While I do not doubt this is *sometimes* indeed happening, I think Debian developers and sysadmins for the most part are, like the majority of people in any context, lazy(*), resistant to change and proud with developing what is considered the (second) oldest GNU/Linux distribution. A long term tradition, pride and the wish to get the job done with the minimum effort and time spent are not the best ingredients for changing one's ways. Adopting systemd and proposing the / -> /usr merge do are changes, I know, but they are motivated by the promise (or hope) they are going to diminish the work needed to take a different approach. In other words, they are an investment in a future of more abundant laziness. And we are part of the people who are disrupting their quest for pride in laziness, we are the youngsters who are bothering Grandpa, it's all too natural that most of Debianers feel Devuaners like smoke in their eyes. It's going to take time and a careful, diplomatic way of interacting with the traditionalist, lazy Granpas to be listened to and eventually be accepted as part of the family instead of a bunch of bothersome kids. I strongly hope Grandpa will eventually not just accept the kids, but be happy to have them around. I have no idea however what the chances are that this is going to happen. Of course, getting Devuan into prominence among the Debian spinoffs (and some corporate/VC support and a few relevant, high profile use cases) would help a lot. Grandpa is not stupid, he does notice these things. And of course the kids will eventually leave home to have a life of their own, if they are to grow up into adults. But this is longer term. *) Laziness in a broad sense, meaning the natural predisposition to choose the easiest and shortest path to get the job done. -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 18/11/18 at 13:09, info at smallinnovations dot nl wrote: > Just my 2 cents. 👍 -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Sun, 18 Nov 2018 13:24:51 +0100 Alessandro Selli wrote: > On 18/11/18 at 10:46, Martin Steigerwald wrote: > > > KatolaZ - 18.11.18, 09:36: > >> This is not gonna happen, given for instance the way our presence > >> in debian-devel has been "cheered up" (with aggressive posts and > >> personal > > The most important aspect here is: "has been". Its in the past > > already and it does not determine the future. > > > Maybe not. If my English Grammar is still worth the schoolbook > paper it was printed on, "has been" is the Present Continuous Tense, > that is used "to express the idea that something is happening now, at > this very moment. It can also be used to show that something is not > happening now." > > So, the main use is for "something is happening now", sometimes for > "something [that] is not happening now." > Nope, your schoolbook paper wasn't worth the paper it was written on ;-) 'has been' denotes something that has happened e.g 'That guy is an has been' or 'the book has been found'. Your 'schoolbook' is probably where the misuse of 'since' comes from as well. Rowland ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
