Re: [Dng] [dng] vdev status update and milestone
Le 25/03/2015 18:04, Jude Nelson a écrit : 3) I don't think this is a great place for unsubstantiated attacks on Ulrich Drepper or on Ulrich Drepper's leadership of glibc. Ulrich Drepper's bad attitude is cited as one of the main reasons Debian switched from glibc to eglibc. Source: http://blog.aurel32.net/47. -Jude I see two flaws in the glibc: first it is bloated, second the static version does not contain all functions. To my knowledge, the second flaw is by the personal will of Ulrich Drepper. These are two reasons to prefer Musl libc. Nevertheless, Glibc designs the standard and this is not without merit. And I am not advocating to convert Devuan to Musl :-) there are more important things to do. Thanks Jude! Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update and milestone
3) I don't think this is a great place for unsubstantiated attacks on Ulrich Drepper or on Ulrich Drepper's leadership of glibc. Ulrich Drepper's bad attitude is cited as one of the main reasons Debian switched from glibc to eglibc. Source: http://blog.aurel32.net/47. -Jude On Wed, Mar 25, 2015 at 1:01 PM, Tor Myklebust tmykl...@csclub.uwaterloo.ca wrote: On Wed, 25 Mar 2015, T.J. Duchene wrote: For some, it does have to do with the GPL, but for many it has to do with the fact that GCC is a mess. One of the previous maintainers, Ulrich Drepper, was famous for ignoring bug reports. Are you for real? If so: 1) Drepper maintained glibc, not gcc. These are two separate projects. 2) Clang is a C and C++ frontend for LLVM. It does not contain a C library. 3) I don't think this is a great place for unsubstantiated attacks on Ulrich Drepper or on Ulrich Drepper's leadership of glibc. 4) I also don't think this is a great place for unsubstantiated attacks on a compiler suite. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update and milestone
-Original Message- From: Joerg Reisenweber [mailto:reisenwe...@web.de] Sent: Tuesday, March 24, 2015 10:33 PM To: dng@lists.dyne.org Subject: Re: [Dng] [dng] vdev status update and milestone On Tue 24 March 2015 22:17:20 Steve Litt wrote: This systemd debacle increased by an order of magnitude the Linux users who understand the underpinnings of the system and are prepared to take control. [T.J. ] I don't really think so, honestly. I think that those who have would have been motivated for other reasons. 2015-02-18T14:43:35.751937+01:00 localhost kernel: [1566879.692218] systemd[1]: segfault at 1fc6ac0 ip 01fc6ac0 sp 7fff9f2ab858 error 15 [T.J. ] It should be important to note that a segfault can be caused by any number of things, that can be unrelated to systemd itself. I do grant you that systemd has its share of undesirables, but it could be exposing a flaw in the lower libraries as well. A lot of the time, the glibc library is also to blame. If there was ever any piece of software on Linux that needs a serious overhaul, beyond X11, it is the libc and GCC suite. That is why a lot of people are eying over Clang very seriously. For some, it does have to do with the GPL, but for many it has to do with the fact that GCC is a mess. One of the previous maintainers, Ulrich Drepper, was famous for ignoring bug reports. It has been my experience (having used just about every major version of Linux at one time or another since the 90s) that Linux versions get pushed out the door, regardless of how many critical bugs are still unfixed. The usual attitude is that we will fix them later, or they wait for upstream to do so. Some versions are better than others. I must admit that Debian seems to do a good job at squashing bugs. on my desktop system, with all the collateral damage like var/log/messages empty after logrotate etc, and NO way to debug. *No more* 'customize and tweak everything I like' :-/ [T.J. ] To be fair, there is always a way to be debug, but like most things these days, systemd is designed to be hands off unless you are a C programmer. Which makes it very attractive to people who just want to build a distribution and not get into the guts. That also means that it gets in the way of the people who do want to get into the details. As for your comments about logging, I agree - systemd should not be logging by default. On Debian, it doesn't actually - even if it is installed. Most other distributions have systemd logging on be default though. It is also true that you can disable systemd logging should you wish it. Now devuan is my only hope for the future of linux - alternative: move to another unix. When I wanted an OS like systemd cabal and RH is planning for, I would have chosen the original from beginning: Redmond M$ lock-in for sheep. [T.J. ] I think you are being just a bit overdramatic. I do agree that the number of binary distributions that do not use systemd are shrinking to zero, but then the binary distributions were created in the first place for people who do not care about the internal guts of the system. You can always build Linux yourself to exclude systemd or you can even try Gentoo if you are so inclined. T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update and milestone
Are you for real? [T.J. ] Just to clear things up. If so: 1) Drepper maintained glibc, not gcc. These are two separate projects. True. I always treat GCC and glibc as somewhat synonymous since they go hand in hand. You can't have one without the other for all intents as far as Linux is concerned. 2) Clang is a C and C++ frontend for LLVM. It does not contain a C library. Good point. It is however far superior to GCC in many regards. 3) I don't think this is a great place for unsubstantiated attacks on Ulrich Drepper or on Ulrich Drepper's leadership of glibc. Attacking Drepper or his reputation was never my intention, so clearly this is only a misunderstanding on your part. I know my comments about him ignoring bug reports are correct, I've read the reports myself. That is 100% accurate. Although obviously when I wrote the comment I should have said glibc instead of GCC. I used both in the previous sentences and did not specifically separate them when I mentioned Drepper. Like everyone else, I am only human and occasionally make errors. Thank you for the correction. Mea Culpa. 4) I also don't think this is a great place for unsubstantiated attacks on a compiler suite. Unsubstantiated? I must humbly disagree. GCC has a long history of open bugs that do not get corrected for years. This one took 10 years - 10 YEARS - for to be corrected: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501. I'd hardly call that criticism unsubstantiated. Saying that the GCC is a mess is perhaps subjective, but it is hardly unfair. It is a complex piece of software that like X11, to needs its development be shaken up every now and again. GCC has been completely replaced by a fork once already. EGCS replaced GCC and simply took the old name GCC name. T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update and milestone
KatolaZ, [T.J. ] What I said was: It should be important to note that a segfault can be caused by any number of things, that can be unrelated to systemd itself. I do grant you that systemd has its share of undesirables, but it could be exposing a flaw in the lower libraries as well. A lot of the time, the glibc library is also to blame. If there was ever any piece of software on Linux that needs a serious overhaul, beyond X11, it is the libc and GCC suite. I said that systemd COULD be (not IS) be exposing a flaw in lower libraries (which is not unreasonable to say, given that it DOES happen). I said that a lot of the time the glibc library is ALSO to blame - as in addition to when certain problems arise. I agree with you that I definitely should have qualified that better. Defaults are not necessarily caused by glibc itself, but glibc DOES have certain quirks. It is not perfect and sometimes does not follow conformant behavior. One example would be realloc violates C99. I don't know if it still does, you will have to look for yourself. Software that is compiled against one libc is not the same as compiled against another.Glibc has a history of shortcomings, just as much as its successes. That does not make it a bad piece of software, but it is hardly flawless. That is has been forked or replaced multiple times in its history says something about it. So please, do not blame glibc for faults that are not its own. On the other If you can prove that glibc/gcc is causing the segfaults of systemd then please provide links to those *facts*, otherwise what you are saying is just unsopported FUD. I agree that it is good that you desire accuracy, but you could ask for it without saying I am chanting unsupported FUD. Laters T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update and milestone
Defaults are not necessarily caused by glibc itself Defaults = Segfaults. Don't you just hate autocorrect? T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update and milestone
If something goes wrong somewhere and X11 segfaults (which I think does not happen more than once in a few decades, at least with the stable version of Xorg), then we might complain and make a fuss, but in the end is not that big deal. Having systemd as PID 1 segfaulting is a completely different story, and blaming other libraries does not help systemd acquiring more credibility. PID1 *cannot* segfault, or we are just back to the dark days of BSODs. Fullstop. [T.J. ] That's fine. =) I only meant that glibc and GCC are far from flawless and which may cause problems with software that is built with them. I have personally seen C/C++ code segfault on Linux simply because a single line (having nothing to do with anything other than standard C/C++ libraries) was written one way over another, when both ways should have worked. I apologize the commentary is not specific enough for some, it has been a number of years since the last instance, and I do not remember the exact code. It might have been on an Alpha processor if that matters - perhaps it was x86. I have not worked with anything besides X64 now for some time, hence why I do not remember the specifics. As for my mentioning realloc and C99, you are certainly welcome to look that up to see what the general state of things are. In fact, I will go so far as to publicly withdraw my comments as too generalized, and save anyone else the trouble. I have absolutely no more time to waste on the topic, and I do not think that it is fair to anyone else to spend any more time on this either. T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update and milestone
On Wed, Mar 25, 2015 at 04:31:47PM -0500, T.J. Duchene wrote: KatolaZ, [T.J. ] What I said was: It should be important to note that a segfault can be caused by any number of things, that can be unrelated to systemd itself. I do grant you that systemd has its share of undesirables, but it could be exposing a flaw in the lower libraries as well. A lot of the time, the glibc library is also to blame. If there was ever any piece of software on Linux that needs a serious overhaul, beyond X11, it is the libc and GCC suite. I said that systemd COULD be (not IS) be exposing a flaw in lower libraries (which is not unreasonable to say, given that it DOES happen). I still don't get the relationship between segfaults in systemd and quirks in glibc, so I am sorry but your statement remains unclear and unsubstantiated, IMHO. Anyway, the fact that systemd depends on mamy more libraries than sysv-init is exactly why we don't want systemd as PID 1, controlling everything from mounting of devices to networking to logging. It is just a single point of fault with too many potential (and actual) reasons that can cause it to fail. If something goes wrong somewhere and X11 segfaults (which I think does not happen more than once in a few decades, at least with the stable version of Xorg), then we might complain and make a fuss, but in the end is not that big deal. Having systemd as PID 1 segfaulting is a completely different story, and blaming other libraries does not help systemd acquiring more credibility. PID1 *cannot* segfault, or we are just back to the dark days of BSODs. Fullstop. My2Cents KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update and milestone
moreover on libudev looking at Debian bug 735275 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735275 and the wide impact it has on upstream (nodejs, webkit, chrome etc. are affected by the bump to libudev.1) I'd rather keep libudev.0 around as a vdev patched version, would that be possible? I understand this would gain Devuan even more backward compatibility with upstream distributed binaries. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update and milestone
HOORAY! KUDOS! can't wait giving it a try /j On Tue 24 March 2015 05:37:04 Jude Nelson wrote: Hey everyone, I'm pleased to announce that vdev can successfully boot to a console on the Devuan vagrant image! [...] -Jude 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] [dng] vdev status update and milestone
On Tue, Mar 24, 2015 at 05:37:04AM -0400, Jude Nelson wrote: Hey everyone, I'm pleased to announce that vdev can successfully boot to a console on the Devuan vagrant image! It creates all requisite device files and loads all requisite kernel drivers, both for the pre-boot initramfs environment (so init can mount root) and in the early boot environment (while root is mounted read-only). I'd like to thank you all for your patience and That's great news Jude, indeed! Looking forward to seeing vdev up and running, as soon as I manage to solve some problems I have with vagrant :) AdMaiora KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update and milestone
Jude Nelson wrote: Hey everyone, I'm pleased to announce that vdev can successfully boot to a console on the Devuan vagrant image! It creates all requisite device files and loads all requisite kernel drivers, both for the pre-boot initramfs environment (so init can mount root) and in the early boot environment (while root is mounted read-only). I'd like to thank you all for your patience and support, with a special shoutout to the individual who goes by the name Scooby on this list who helped me find and fix early-boot bugs. Thanks Jude. I think it's a great contribution to the community. -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update and milestone
On Tue 24 March 2015 22:17:20 Steve Litt wrote: This systemd debacle increased by an order of magnitude the Linux users who understand the underpinnings of the system and are prepared to take control. Indeed. I never really bothered much, and happily lived along with (Open)Suse since... it became available. Never really cared about which distro I use, they all needed heavy customization to make me feel at home anyway. The reason why I chosen unix/linux to start with, even for my phone: I can customize and tweak everything I like. And then recently I first ran into public systemd schism (though I failed to notice it when deciding which init to use in Opensuse12(?), otherwise I should have known more early) and - ironically - later on into 2015-02-18T14:43:35.751937+01:00 localhost kernel: [1566879.692218] systemd[1]: segfault at 1fc6ac0 ip 01fc6ac0 sp 7fff9f2ab858 error 15 on my desktop system, with all the collateral damage like var/log/messages empty after logrotate etc, and NO way to debug. *No more* 'customize and tweak everything I like' :-/ Now devuan is my only hope for the future of linux - alternative: move to another unix. When I wanted an OS like systemd cabal and RH is planning for, I would have chosen the original from beginning: Redmond M$ lock-in for sheep. /j 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] [dng] vdev status update and milestone
On Tue, 24 Mar 2015 22:21:30 -0400 Clarke Sideroad clarke.sider...@gmail.com wrote: As history marks the rise and fall of systemd, contributions such as yours will make the the bigger picture of this time period net positive. Thank you, Clarke That's so true, Clarke! This systemd debacle increased by an order of magnitude the Linux users who understand the underpinnings of the system and are prepared to take control. This is a Renaissance in the Linux community. Well, except for Debian :-) SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update and milestone
On Tue, 24 Mar 2015 05:37:04 -0400 Jude Nelson jud...@gmail.com wrote: Hey everyone, I'm pleased to announce that vdev can successfully boot to a console on the Devuan vagrant image! It creates all requisite device files and loads all requisite kernel drivers, both for the pre-boot initramfs environment (so init can mount root) and in the early boot environment (while root is mounted read-only). I'd like to thank you all for your patience and support, with a special shoutout to the individual who goes by the name Scooby on this list who helped me find and fix early-boot bugs. We're well on our way now to replacing udev entirely. The only big-ticket item remaining prior to an official alpha release is patching libudev so it does not need to talk to udevd to query devices. This is only necessary for applications that require libudev. -Jude * * \ o / \|/ | O U T S T A N D I N G ! ! ! / \ _ / \/ / - This is spectacular news. Thank you Jude. I wasn't looking forward to all the manual driver setup and mknodding I would have had to do in order to solder-bridge around udev. Now I don't have to. This is also a great moment of credibility for Devuan. Keep up the excellent work! SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update and milestone
As history marks the rise and fall of systemd, contributions such as yours will make the the bigger picture of this time period net positive. Thank you, Clarke ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status update and milestone
Hi Jaromil, outstanding good news! congrats :^) if we manage to include vdev in Devuan for upcoming releases you may acquire rather wide testing grounds for your software. Thanks for the encouragement :) When it comes to packaging vdev, what I'll do is add an /etc/alternatives entry for the system's device manager, and modify the device manager init script and initramfs hooks to use it. It should be possible for the user to install and select between multiple different device managers. This way, people can use whatever works for them. I'm curious how you think we should plan this? as with all udev, also libudev is now part of systemd, part of their tactical move to lockin everyone rather than keep the codebases separate. The tie-in to systemd comes through its increasing dependence on some string utility methods systemd has (nothing that can't be put into a small util.c file in libudev), as well as the recent switch-over to including the hardware database parser in systemd. I'll just lift out the hwdb parser and put it back into libudev (or get a copy from eudev). libudev doesn't really do that much. It's basically a front-end for (1) reading data from sysfs, (2) querying the hardware database, and (3) getting information from udevd. I've already had to address a good chunk of (1) in the Linux port of vdevd, and most of (3) can be handled simply by watching /dev for changes and looking up newly-added device node metadata from sysfs. how many applications actually require using libudev? Lots of middleware programs do. udisks2, lvm2, mountall, ConsoleKit, bluez, gvfs, kde-workspace-bin, pulseaudio, plymouth, multipath-tools, spacefm, v4l-utils, vlc-nox, and xserver-xorg-core are all compiled to rely on libudev, for example. shall we fork libudev back out of systemd (libvdev?) That's my plan. I'm calling it libudev-compat, though (libvdev is already taken--it holds common code between vdevd and vdevfs). vdevd doesn't need a library to communicate with it. It stores all the information you'd get from udevadm under /dev/vdev/NAME_OF_DEVICE as a set of files, so programs can just read it or inotify-watch it directly. what else? we may also advertise to upstream developers the alternative and ask them to include a --with-vdev flag or so, linking to your api. Hopefully not even that. If I can supply a libudev workalike, they shouldn't have to do anything. -Jude On Tue, Mar 24, 2015 at 6:36 AM, Jaromil jaro...@dyne.org wrote: On Tue, 24 Mar 2015, Jude Nelson wrote: I'm pleased to announce that vdev can successfully boot to a console on the Devuan vagrant image!* It creates all requisite device files and loads all requisite kernel drivers, both for the pre-boot initramfs environment (so init can mount root) and in the early boot environment (while root is mounted read-only).* outstanding good news! congrats :^) if we manage to include vdev in Devuan for upcoming releases you may acquire rather wide testing grounds for your software. We're well on our way now to replacing udev entirely.* The only big-ticket item remaining prior to an official alpha release is patching libudev so it does not need to talk to udevd to query devices.* This is only necessary for applications that require libudev. I'm curious how you think we should plan this? as with all udev, also libudev is now part of systemd, part of their tactical move to lockin everyone rather than keep the codebases separate. how many applications actually require using libudev? shall we fork libudev back out of systemd (libvdev?) what else? we may also advertise to upstream developers the alternative and ask them to include a --with-vdev flag or so, linking to your api. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
