Re: [DNG] Devuan with usr merge?
Le 13/11/2021 à 00:26, John Morris via Dng a écrit : > So yes, it is time to eliminate /bin, /sbin and /lib. Seems I've got it wrong. My understanding was that /usr/bin and /usr/sbin were merged into /bin and /sbin. You assume the opposite and probably so does Steve. Needs clarifications. -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan with usr merge?
John Morris via Dng said on Fri, 12 Nov 2021 17:26:52 -0600 >On Tue, 2021-11-09 at 01:56 -0500, Steve Litt wrote: >> >> The logic is still the same. I need a guaranteed place on the root >> partition to find the programs necessary to mount all the other >> partitions, or else I'll need to run an initramfs. > >Been following this debate. Admit that a few years ago I'd have >reflexively said keep /bin and /sbin but now? The assumptions have >changed so much it no longer makes much sense. > >The size of the OS is just so small now, compared to storage media and >data files. Even a small SSD will easily hold all of /usr for all but >the most bloated installs on old obsolete storage media. So simply >including /usr in the root filesystem makes sense for almost all use >cases. I see what you mean. In fact, I use an SSD for /usr, /etc, /lib etc and mount everything else on spinning rust. As a matter of fact, on my Void Linux installation: === [slitt@mydesk ~]$ ls -ld /usr drwxr-xr-x 10 root root 4096 May 5 2021 /usr [slitt@mydesk ~]$ ls -ld /bin lrwxrwxrwx 1 root root 7 May 4 2021 /bin -> usr/bin [slitt@mydesk ~]$ ls -ld /sbin lrwxrwxrwx 1 root root 7 May 4 2021 /sbin -> usr/bin [slitt@mydesk ~]$ ls -ld /usr/sbin lrwxrwxrwx 1 root root 3 May 4 2021 /usr/sbin -> bin [slitt@mydesk ~]$ === So I've been using usr merge for years and I'm still alive. Which brings up another beef I have: Why don't they build Ext4 and maybe a couple other mainstream filesystems into the kernel, so if I want, I can boot without initramfs? What would it cost? Everybody is ooohing and ahhing about sytemd's boot speed. If you want to REALLY improve boot speed, get rid of initramfs and just do mounts and encrypting from files on the root drive. Of course, this means you can't have an encrypted root drive. Well, if you want an encrypted root partition, use an initramfs. > On the other hand, putting everything in /usr makes some >interesting options possible, like making it a read only mount point >except during updates. > >Back in olden days being able to reliably boot into a minimal >environment for rescue and recovery was important. Now a rescue >distribution on a USB stick is far more effective when things go wrong. This isn't how I see it. Needing to look into a running initramfs is awful. Of course, systemd has some kind of periscope to look into the initramfs. If one drives on that side of the road. I'm not saying initramfs (or initrd that preceded it) is completely without use. It brought us Knoppix and all the live CDs that followed. It enables us to have any conceivable encryption or filesystem or filesystem addon such as LVM, on each partition, without jamming the kernel with all sorts of seldom used stuff. All I'm saying is I'd prefer distros don't make initramfs mandatory (without doing all sorts of fancy footwork every time you upgrade your kernel), for those of us with basic systems. >So yes, it is time to eliminate /bin, /sbin and /lib. I won't phrase it quite that strongly, but yeah, given your point about not gaining much from a mounted /usr, it's not a big issue. > >Wish I could say the same thing about the X11 vs Wayland divide. See >the cold logic and theory in the Wayland argument but keep looking at >the current reality and Wayland comes up short. As far as I know, Wayland is the child prodegy of FreeDesktop.Org, one of the most effective sales organizations for systemd, and probably *the* most effective proponent of massive, unnecessary complexification. Hence, I'll ride the X11 train til the bitter end. LOL, and the day I switch to Wayland, my dmenu stops working, and dmenu is probably *the* most important component in my work flow. I use dmenu over 100 times per day. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan with usr merge?
On Tue, 2021-11-09 at 01:56 -0500, Steve Litt wrote: > > The logic is still the same. I need a guaranteed place on the root > partition to find the programs necessary to mount all the other > partitions, or else I'll need to run an initramfs. Been following this debate. Admit that a few years ago I'd have reflexively said keep /bin and /sbin but now? The assumptions have changed so much it no longer makes much sense. The size of the OS is just so small now, compared to storage media and data files. Even a small SSD will easily hold all of /usr for all but the most bloated installs on old obsolete storage media. So simply including /usr in the root filesystem makes sense for almost all use cases. On the other hand, putting everything in /usr makes some interesting options possible, like making it a read only mount point except during updates. Back in olden days being able to reliably boot into a minimal environment for rescue and recovery was important. Now a rescue distribution on a USB stick is far more effective when things go wrong. So yes, it is time to eliminate /bin, /sbin and /lib. Wish I could say the same thing about the X11 vs Wayland divide. See the cold logic and theory in the Wayland argument but keep looking at the current reality and Wayland comes up short. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] SOLVED: gdb won't run
Now this is even funnier. I installed libsource-highlight-dev and wrote a short program whose only relevant expression is: srchilite::SourceHighlight *X = new srchilite::SourceHighlight(); Then: 1015-north:tmp$ g++ foo.C /usr/bin/ld: /tmp/ccn6kzOe.o: in function `main': foo.C:(.text+0x46): undefined reference to `srchilite::SourceHighlight::SourceHighlight(std::__cxx11::basic_string, std::allocator > const&)' collect2: error: ld returned 1 exit status 1016-north:tmp$ g++ foo.C -l source-highlight 1017-north:tmp$ gdb -q --args ./a.out Reading symbols from ./a.out... (No debugging symbols found in ./a.out) (gdb) break main Breakpoint 1 at 0x11a9 (gdb) run Starting program: /home/ale/tmp/a.out [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, 0x51a9 in main () (gdb) q A debugging session is active. Inferior 1 [process 21681] will be killed. Quit anyway? (y or n) y So, gdb can run without symbols. 1018-north:tmp$ g++ -g foo.C -l source-highlight 1019-north:tmp$ gdb -q --args ./a.out Reading symbols from ./a.out... (gdb) break main Breakpoint 1 at 0x11b0: file foo.C, line 6. (gdb) run Starting program: /home/ale/tmp/a.out [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, main () at foo.C:6 gdb: symbol lookup error: gdb: undefined symbol: _ZN9srchilite15SourceHighlightC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE Although the symbol is probably the same... 1020-north:tmp$ ldd a.out linux-vdso.so.1 (0x7ffcbf1eb000) libsource-highlight.so.4 => /usr/local/lib/libsource-highlight.so.4 (0x7f9d18b3e000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f9d18971000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f9d18957000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f9d18792000) libboost_regex.so.1.49.0 => /usr/lib/libboost_regex.so.1.49.0 (0x7f9d18669000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f9d18525000) /lib64/ld-linux-x86-64.so.2 (0x7f9d18e57000) libicuuc.so.48 => /usr/lib/x86_64-linux-gnu/libicuuc.so.48 (0x7f9d1816b000) libicui18n.so.48 => /usr/lib/x86_64-linux-gnu/libicui18n.so.48 (0x7f9d17d3f000) libicudata.so.48 => /usr/lib/x86_64-linux-gnu/libicudata.so.48 (0x7f9d169cf000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f9d169c4000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f9d169a2000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f9d1699c000) That's the culprit, /usr/local/lib/libsource-highlight.so.4 installed in 2016. Removed it, now gdb works. Sorry for the noise Ale On Fri 12/Nov/2021 17:41:30 +0100 Alessandro Vesely wrote: Hi all, don't know since when this happened, maybe since I upgraded to Chimaera. When I run gdb I get: src$ gdb -n -q --args ./anyexec Reading symbols from ./anyexec... (gdb) break main Breakpoint 1 at 0x7c7a: file anyexec.c, line 10. (gdb) run Starting program: /home/ale/tmp/src/anyexec [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, main (argc=3, argv=0x7fffe1c8) at anyexec.c:10 gdb: symbol lookup error: gdb: undefined symbol: _ZN9srchilite15SourceHighlightC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE src$ echo $? 127 Demangled symbol seems to be: srchilite::SourceHighlight::SourceHighlight(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&) I cannot strace gdb, so I don't know where it looks for that missing symbol. I tried to remove and reinstall gdb, reinstall all libsource-highlight*, to no avail. Any idea? TIA Ale ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] gdb won't run
Hi all, don't know since when this happened, maybe since I upgraded to Chimaera. When I run gdb I get: src$ gdb -n -q --args ./anyexec Reading symbols from ./anyexec... (gdb) break main Breakpoint 1 at 0x7c7a: file anyexec.c, line 10. (gdb) run Starting program: /home/ale/tmp/src/anyexec [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, main (argc=3, argv=0x7fffe1c8) at anyexec.c:10 gdb: symbol lookup error: gdb: undefined symbol: _ZN9srchilite15SourceHighlightC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE src$ echo $? 127 Demangled symbol seems to be: srchilite::SourceHighlight::SourceHighlight(std::__cxx11::basic_string, std::allocator > const&) I cannot strace gdb, so I don't know where it looks for that missing symbol. I tried to remove and reinstall gdb, reinstall all libsource-highlight*, to no avail. Any idea? TIA Ale -- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
