* [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' • The Register @ 2024-06-13 14:56 Charles H Sauer (he/him) 2024-06-13 15:33 ` [TUHS] " Dan Cross ` (2 more replies) 0 siblings, 3 replies; 160+ messages in thread From: Charles H Sauer (he/him) @ 2024-06-13 14:56 UTC (permalink / raw) To: The Eunuchs Hysterical Society https://www.theregister.com/2024/06/13/version_256_systemd/ I don't see the boast at https://github.com/systemd/systemd/releases/tag/v256, but ... Charlie -- voice: +1.512.784.7526 e-mail: sauer@technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/Twitter: CharlesHSauer ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-13 14:56 [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' • The Register Charles H Sauer (he/him) @ 2024-06-13 15:33 ` Dan Cross 2024-06-13 15:35 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy 2024-06-13 15:39 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Clem Cole 2 siblings, 0 replies; 160+ messages in thread From: Dan Cross @ 2024-06-13 15:33 UTC (permalink / raw) To: Charles H Sauer (he/him); +Cc: The Eunuchs Hysterical Society On Thu, Jun 13, 2024 at 10:56 AM Charles H Sauer (he/him) <sauer@technologists.com> wrote: > https://www.theregister.com/2024/06/13/version_256_systemd/ > > I don't see the boast at > https://github.com/systemd/systemd/releases/tag/v256, but ... That "boast" seems to come from a random mastodon post? - Dan C. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register 2024-06-13 14:56 [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' • The Register Charles H Sauer (he/him) 2024-06-13 15:33 ` [TUHS] " Dan Cross @ 2024-06-13 15:35 ` Larry McVoy 2024-06-13 15:41 ` Alan D. Salewski 2024-06-13 15:55 ` Steve Nickolas 2024-06-13 15:39 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Clem Cole 2 siblings, 2 replies; 160+ messages in thread From: Larry McVoy @ 2024-06-13 15:35 UTC (permalink / raw) To: Charles H Sauer (he/him); +Cc: The Eunuchs Hysterical Society "The new alternative does no such sleight of hand. Instead, it just gets the systemd daemon to run the command for you, using a special form of the existing systemd-run command." Sounds like a new path for exploits. We'll see if Mr Systemd has to eat some crow in the future. Said by a guy who _hates_ systemd. On Thu, Jun 13, 2024 at 09:56:04AM -0500, Charles H Sauer (he/him) wrote: > https://www.theregister.com/2024/06/13/version_256_systemd/ > > I don't see the boast at > https://github.com/systemd/systemd/releases/tag/v256, but ... > > Charlie > -- > voice: +1.512.784.7526 e-mail: sauer@technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/LinkedIn/Twitter: CharlesHSauer -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register 2024-06-13 15:35 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy @ 2024-06-13 15:41 ` Alan D. Salewski 2024-06-13 15:55 ` Steve Nickolas 1 sibling, 0 replies; 160+ messages in thread From: Alan D. Salewski @ 2024-06-13 15:41 UTC (permalink / raw) To: Larry McVoy, Charles H Sauer (he/him); +Cc: TUHS (The Unix Heritage Society) On Thu, Jun 13, 2024, at 11:35, Larry McVoy wrote: > "The new alternative does no such sleight of hand. Instead, it just gets the > systemd daemon to run the command for you, using a special form of the existing > systemd-run command." > > Sounds like a new path for exploits. We'll see if Mr Systemd has to eat > some crow in the future. Said by a guy who _hates_ systemd. Eating sudo, eating crow...I guess systemd is /still/ hungry: https://i.kym-cdn.com/photos/images/original/000/925/966/8d2.gif -Al ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register 2024-06-13 15:35 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy 2024-06-13 15:41 ` Alan D. Salewski @ 2024-06-13 15:55 ` Steve Nickolas 1 sibling, 0 replies; 160+ messages in thread From: Steve Nickolas @ 2024-06-13 15:55 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Thu, 13 Jun 2024, Larry McVoy wrote: > "The new alternative does no such sleight of hand. Instead, it just gets the > systemd daemon to run the command for you, using a special form of the existing > systemd-run command." > > Sounds like a new path for exploits. We'll see if Mr Systemd has to eat > some crow in the future. Said by a guy who _hates_ systemd. systemd is the thing that should not be. If I had successfully gotten my project up (trying to get a standalone kernel/libc/clang build environment up and running - either Linux/musl or NetBSD) it would run a rewrite of the SysV init system (not "sysvinit", that's GPL). -uso. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-13 14:56 [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' • The Register Charles H Sauer (he/him) 2024-06-13 15:33 ` [TUHS] " Dan Cross 2024-06-13 15:35 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy @ 2024-06-13 15:39 ` Clem Cole 2024-06-13 16:47 ` Arrigo Triulzi via TUHS 2 siblings, 1 reply; 160+ messages in thread From: Clem Cole @ 2024-06-13 15:39 UTC (permalink / raw) To: Charles H Sauer (he/him); +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1681 bytes --] Thank Charlie. But I just threw up after I read it. Sadly, UNIX's "prime directive" was to "keep it simple." Or, as someone else describes it, create "small tools that did one job well." On the PDP-11, the lack of address space somewhat enforced this. With the 32-bit vax, we see cat -v and the like. I think "frameworks" are just a modern term for IBM's "access methods" of the 1960s. John Lions observed that the entire documentation set for UNIX V6 could be kept in a 3-ring binder, and, as his book showed, given the size, anyone could understand all of the kernel and the core systems ideas. FWIW, Linux is not the first to fail. Years ago, I pointed out to Dennis that the System V Release 3 bootloader for the 3B was larger than the entire V6 kernel. I have not looked at the size of systemd, but do you want to bet that it fails the same test? But I digress. Someone (Henry Spencer, maybe) once said, "Good Taste is subjective. I have it, and you don't seem to." IMO systemd, was >>not<< a net positive - it falls so many of these tests WRT to good programming and good ideas. Sigh ... Clem ᐧ ᐧ On Thu, Jun 13, 2024 at 10:56 AM Charles H Sauer (he/him) < sauer@technologists.com> wrote: > https://www.theregister.com/2024/06/13/version_256_systemd/ > > I don't see the boast at > https://github.com/systemd/systemd/releases/tag/v256, but ... > > Charlie > -- > voice: +1.512.784.7526 e-mail: sauer@technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/LinkedIn/Twitter > <https://technologists.com/sauer/Facebook/Google/LinkedIn/Twitter>: > CharlesHSauer > [-- Attachment #2: Type: text/html, Size: 3947 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-13 15:39 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Clem Cole @ 2024-06-13 16:47 ` Arrigo Triulzi via TUHS 2024-06-13 18:39 ` segaloco via TUHS 2024-06-13 20:26 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Dave Horsfall 0 siblings, 2 replies; 160+ messages in thread From: Arrigo Triulzi via TUHS @ 2024-06-13 16:47 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society On 13 Jun 2024, at 17:39, Clem Cole <clemc@ccc.com> wrote: > IMO systemd, was >>not<< a net positive - it falls so many of these tests WRT to good programming and good ideas. Binary logs, ’nuff said. Good sysadmins live & die by grep and being able to visually detect departures from the norm by just looking at the “shape” of logs scrolling down a screen (before), terminal window now. Yours disgusted since v1 of that abomination. Arrigo ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-13 16:47 ` Arrigo Triulzi via TUHS @ 2024-06-13 18:39 ` segaloco via TUHS 2024-06-13 18:45 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Mychaela Falconia ` (2 more replies) 2024-06-13 20:26 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Dave Horsfall 1 sibling, 3 replies; 160+ messages in thread From: segaloco via TUHS @ 2024-06-13 18:39 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Thursday, June 13th, 2024 at 9:47 AM, Arrigo Triulzi via TUHS <tuhs@tuhs.org> wrote: > On 13 Jun 2024, at 17:39, Clem Cole clemc@ccc.com wrote: > > > IMO systemd, was >>not<< a net positive - it falls so many of these tests WRT to good programming and good ideas. > > > Binary logs, ’nuff said. > > Good sysadmins live & die by grep and being able to visually detect departures from the norm by just looking at the “shape” of logs scrolling down a screen (before), terminal window now. > > Yours disgusted since v1 of that abomination. > > Arrigo Part of what irks me is the lack of choice. Just like many outlets will use GNU extensions to otherwise POSIX components, leaving the rest of the world out in the rain, several bits of the Linux ecosystem have backed systemd as the one true way and are hobbled if even usable at all with other init systems out there. User software shouldn't have any attachment to a particular init system, it isn't meant to provide "services" beyond run this script at this time based on the conditions of boot, manage terminal lines, and maybe offer some runlevels to compartmentalize operating environments. I've seen it said elsewhere that the amount of surface area being shoved into PID 1 can only lead to disaster. Are there any known attempts in the modern age to roll Linux with something resembling research/BSD init? That would be a nice counter to the proliferation of systemd. Even if it doesn't make a dent in the actual uptake, at least it'd feel cathartic to have an alternative in the opposite direction. - Matt G. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register 2024-06-13 18:39 ` segaloco via TUHS @ 2024-06-13 18:45 ` Mychaela Falconia 2024-06-14 8:59 ` Ralph Corderoy 2024-06-13 18:54 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Dan Cross 2024-06-13 19:37 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Alan D. Salewski 2 siblings, 1 reply; 160+ messages in thread From: Mychaela Falconia @ 2024-06-13 18:45 UTC (permalink / raw) To: tuhs, segaloco Matt G. wrote: > Are there any known attempts in the modern age to roll Linux with something > resembling research/BSD init? That would be a nice counter to the > proliferation of systemd. I use Slackware and will never give it up. It uses sysvinit, which isn't as good as research/BSD init, but a helluvalot better than systemd! There is also Devuan, a sans-systemd fork of Debian, for those who aren't hard-core enough to go full Slackware. M~ ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register 2024-06-13 18:45 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Mychaela Falconia @ 2024-06-14 8:59 ` Ralph Corderoy 0 siblings, 0 replies; 160+ messages in thread From: Ralph Corderoy @ 2024-06-14 8:59 UTC (permalink / raw) To: tuhs Hi, The Arch Linux wiki if often useful for non-Arch systems. It has details of alternative init systems to systemd, including s6 mentioned elsewhere in the thread: https://wiki.archlinux.org/title/Init -- Cheers, Ralph. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-13 18:39 ` segaloco via TUHS 2024-06-13 18:45 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Mychaela Falconia @ 2024-06-13 18:54 ` Dan Cross 2024-06-12 19:29 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' " Greg A. Woods 2024-06-13 19:37 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Alan D. Salewski 2 siblings, 1 reply; 160+ messages in thread From: Dan Cross @ 2024-06-13 18:54 UTC (permalink / raw) To: segaloco; +Cc: The Eunuchs Hysterical Society On Thu, Jun 13, 2024 at 2:39 PM segaloco via TUHS <tuhs@tuhs.org> wrote: > On Thursday, June 13th, 2024 at 9:47 AM, Arrigo Triulzi via TUHS <tuhs@tuhs.org> wrote: > > On 13 Jun 2024, at 17:39, Clem Cole clemc@ccc.com wrote: > > > IMO systemd, was >>not<< a net positive - it falls so many of these tests WRT to good programming and good ideas. > > > > Binary logs, ’nuff said. > > > > Good sysadmins live & die by grep and being able to visually detect departures from the norm by just looking at the “shape” of logs scrolling down a screen (before), terminal window now. > > > > Yours disgusted since v1 of that abomination. > > Part of what irks me is the lack of choice. Just like many outlets will use GNU extensions to otherwise POSIX components, leaving the rest of the world out in the rain, several bits of the Linux ecosystem have backed systemd as the one true way and are hobbled if even usable at all with other init systems out there. User software shouldn't have any attachment to a particular init system, it isn't meant to provide "services" beyond run this script at this time based on the conditions of boot, manage terminal lines, and maybe offer some runlevels to compartmentalize operating environments. I've seen it said elsewhere that the amount of surface area being shoved into PID 1 can only lead to disaster. I agree about the lack of choice, but I think the reasoning here shows a bit of an impedance mismatch between what systemd is, and what people think that it should be. In particular, it left merely being an "init system" behind a long time ago, and is now the all-singing, all-dancing service and resource management platform for the system. That's not a terrible thing to have, if the goal of your system is to be able to, well, run services and manage resources. But is systemd, as an expression of that idea, a good thing? I don't really think so. My arguments here tend to be somewhat vague, but I do believe that there is valid criticism beyond just, "It's new! It's different! I hate it!!" Portability is a good argument. Where I think many of the arguments against systemd break down is by dismissing the real problems that it solves; off the top of my head, this may include automatically restarting dependent services when a daemon crashes and is restarted. But again, just because a tool solves a real problem doesn't mean that it's a good tool, or even a good tool for solving that problem. I suspect much of the rush to systemd is driven less by enthusiasm for how it does things, and more for it being the only thing out there that solves some problem that the distro maintainers consider important (ie, that they get asked about frequently). > Are there any known attempts in the modern age to roll Linux with something resembling research/BSD init? Alpine Linux may come closest? And of course the BSDs still exist. > That would be a nice counter to the proliferation of systemd. Even if it doesn't make a dent in the actual uptake, at least it'd feel cathartic to have an alternative in the opposite direction. There are still some Linux distributions that don't ship with systemd, but I think they're just delaying the inevitable. On a more meta point, there are big differences between production server systems, user-oriented systems, and research systems. Systemd feels very much like it comes from the first of those, to me; very mainframe-y. - Dan C. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-13 18:54 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Dan Cross @ 2024-06-12 19:29 ` Greg A. Woods 2024-06-13 20:03 ` Dan Cross 0 siblings, 1 reply; 160+ messages in thread From: Greg A. Woods @ 2024-06-12 19:29 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 1687 bytes --] At Thu, 13 Jun 2024 14:54:51 -0400, Dan Cross <crossd@gmail.com> wrote: Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register > > I agree about the lack of choice, Personally I don't see any lack of choice. There are more than three good BSD derived systems that together cover almost any imaginable set of requirements. The sheep will follow the herd though..... > this may include automatically restarting dependent services when a > daemon crashes and is restarted. If your daemon's are crashing and in need of restarting so often that a tool is needed to restart them then you have a myriad of other far more pressing problems you should be dealing with first! > being the only thing out there that solves some problem that the > distro maintainers consider important (ie, that they get asked about > frequently). If it were so simple I would expect that claim to be more widely advertised, yet we fall back on "it restarts daemons that crash". Personally I think systemd trying to solve the rather high demands and diverse requirements of mobile laptop systems and is trying to meet or match MS Windows in this regard. (personally I think macos has them both beat by a country mile!) It sure as heck isn't of any use in production server environments! If it were more about servers then it would look more like SMF, or maybe launchd, and it's code wouldn't look like it was written by a grade school student. -- Greg A. Woods <gwoods@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> [-- Attachment #2: OpenPGP Digital Signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-12 19:29 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' " Greg A. Woods @ 2024-06-13 20:03 ` Dan Cross 2024-06-13 17:07 ` Greg A. Woods 2024-06-14 14:17 ` Grant Taylor via TUHS 0 siblings, 2 replies; 160+ messages in thread From: Dan Cross @ 2024-06-13 20:03 UTC (permalink / raw) To: The Unix Heritage Society mailing list On Thu, Jun 13, 2024 at 3:18 PM Greg A. Woods <woods@robohack.ca> wrote: > [snip] > > this may include automatically restarting dependent services when a > > daemon crashes and is restarted. > > If your daemon's are crashing and in need of restarting so often that a > tool is needed to restart them then you have a myriad of other far more > pressing problems you should be dealing with first! I may be in a bit of a grumpy mood, so forgive me if this is snarkier than I intend, but statements like this bother me. First, there are a number of reasons that programs crash in the real world, in production environments. Often, the people in charge of keeping them running are not the people who wrote the software; nevermind that sometimes the reason for a crash has nothing to do with the software itself; hardware soft-failures, for instance (that is, where a momentary hardware blip kills a process on some machine but isn't serious enough to drain the computer and reschedule the work elsewhere; particularly where the OS can partition off a bad component, such as a disk or a chunk of RAM or a CPU). When you actually run systems at scale, you engineer them under an expectation of failure and to be resilient. That means automatically restarting services when they crash, among many other things. Second, there are many reasons beyond just "lol it crashed" that you may want to restart dependent services; for example, perhaps you are upgrading a system and part of the upgrade process is restarting your dependents. Having a system that does things like that for you is useful. > > being the only thing out there that solves some problem that the > > distro maintainers consider important (ie, that they get asked about > > frequently). > > If it were so simple I would expect that claim to be more widely > advertised, yet we fall back on "it restarts daemons that crash". See above. > Personally I think systemd trying to solve the rather high demands and > diverse requirements of mobile laptop systems and is trying to meet or > match MS Windows in this regard. (personally I think macos has them > both beat by a country mile!) > > It sure as heck isn't of any use in production server environments! That's not an argument, it's an assertion, and one that isn't well supported. > If it were more about servers then it would look more like SMF, or maybe > launchd, and it's code wouldn't look like it was written by a grade > school student. Sorry, but this is exactly the sort of overly dismissive attitude that I was referring to earlier. You undermine your own argument by mentioning SMF (which can automatically restart services when the crash), for example. - Dan C. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-13 20:03 ` Dan Cross @ 2024-06-13 17:07 ` Greg A. Woods 2024-06-14 14:17 ` Grant Taylor via TUHS 1 sibling, 0 replies; 160+ messages in thread From: Greg A. Woods @ 2024-06-13 17:07 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 1506 bytes --] At Thu, 13 Jun 2024 16:03:30 -0400, Dan Cross <crossd@gmail.com> wrote: Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register > > On Thu, Jun 13, 2024 at 3:18 PM Greg A. Woods <woods@robohack.ca> wrote: > > [snip] > > If it were more about servers then it would look more like SMF, or maybe > > launchd, and it's code wouldn't look like it was written by a grade > > school student. > > Sorry, but this is exactly the sort of overly dismissive attitude that > I was referring to earlier. You undermine your own argument by > mentioning SMF (which can automatically restart services when the > crash), for example. No, that's exactly my point! SMF isn't the anywhere near the nearly-bootable monster systemd seems to be, and it isn't filled with grade-school-level code, and it _is_ written much more in keeping with the Unix tool philosophy. It manages services, it does it in a well defined and predictable way, and it doesn't try to take over the universe. Launchd isn't quite so clean and Unix-like, but it's still a well designed more-or-less single-purpose tool! (Albeit one with a rather wide set of specifications.) Some of Apples other "frameworks" tend to look a bit more like some of systemd, but that's different part of the problem. -- Greg A. Woods <gwoods@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> [-- Attachment #2: OpenPGP Digital Signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-13 20:03 ` Dan Cross 2024-06-13 17:07 ` Greg A. Woods @ 2024-06-14 14:17 ` Grant Taylor via TUHS 2024-06-16 5:48 ` Alexis 2024-06-16 21:56 ` David Arnold 1 sibling, 2 replies; 160+ messages in thread From: Grant Taylor via TUHS @ 2024-06-14 14:17 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 1942 bytes --] On 6/13/24 15:03, Dan Cross wrote: > I may be in a bit of a grumpy mood, so forgive me if this is snarkier > than I intend, but statements like this bother me. ;-) > Second, there are many reasons beyond just "lol it crashed" that > you may want to restart dependent services; for example, perhaps you > are upgrading a system and part of the upgrade process is restarting > your dependents. Having a system that does things like that for you > is useful. It's my understanding that systemd as a service lifecycle manager is starting to take on some aspects of what cluster service managers used to do. E.g. - Are all the other dependencies this service needs up and running -> is it okay to start this service on this system? - Is the service running and responding like it should be? -> periodically check to make sure the system is returning expected results; is DNS answering queries / can I send a test email - Stop the service when it's operating outside acceptable parameters (read: failing). - Notify other related services that this service has been stopped. I'm anti-systemd *cough*Master Control Program*cough* and it's associated suite of utilities for many reasons. But I've come to accept that systemd is not just an init system. It's role of a service life cycle manager is a superset of what an init system does. It's a relatively new world (at least comparatively). I also have seriouis doubts about systemd's stability as a services life cycle manager. I've seen too many times when systems get into a wedged state that require a power fail / reset (or sys request if enabled) to recover. I've seen too many times when a systemd based system won't shut down because of some circular configuration it's gotten itself into. Without the complication of NFS servers being unreachable after taking down the network. -- Grant. . . . [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4033 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-14 14:17 ` Grant Taylor via TUHS @ 2024-06-16 5:48 ` Alexis 2024-06-15 8:48 ` Greg A. Woods 2024-06-16 6:43 ` Wesley Parish 2024-06-16 21:56 ` David Arnold 1 sibling, 2 replies; 160+ messages in thread From: Alexis @ 2024-06-16 5:48 UTC (permalink / raw) To: Grant Taylor; +Cc: The Unix Heritage Society Grant Taylor via TUHS <tuhs@tuhs.org> writes: > I'm anti-systemd *cough*Master Control Program*cough* and it's > associated suite of utilities for many reasons. But I've come > to > accept that systemd is not just an init system. It's role of a > service life cycle manager is a superset of what an init system > does. > It's a relatively new world (at least comparatively). Indeed: it doesn't just do init, but also _service supervision_ (making sure that a service that _should_ be up, _is_ up) and _service management_ (enabling, disabling, starting, stopping, dependencies, etc.). Hence why phrases like "the init wars" are such a misnomer. As described in the potted history outlined in the "known problems with System 5 rc" article i linked to upthread, Sys V rc's issues with service supervision and service management have been known for decades: > In 1999, Luke Mewburn worked on replacing the /etc/rc system in > NetBSD. netbsd.tech.userlevel mailing list discussions from the > time show several criticisms of the System 5 rc and System 5 > init systems, and encouragement not to repeat their mistakes in > the BSD world. The resultant rc.d system was roughly > contemporary with Daniel Robbins producing OpenRC, another > System 5 rc replacement that replaced the (Bourne/Bourne Again) > shell with a different script interpreter, nowadays named > /sbin/openrc, that provided a whole lot of standard service > management functionality as pre-supplied functions. The NetBSD > rc.d system likewise reduced rc.d scripts to a few variable > assignments and function calls (in about two thirds of cases). The initial release of OpenRC - still Gentoo's 'native' system for service management - was in April 2007; the initial release of systemd was in March 2010. But although both OpenRC and systemd address various pain points of Sys V rc on Linux, systemd has _also_ had the backing of an 800-pound gorilla in the Linux world - Red Hat - which has _implicitly_ forced its adoption over alternatives by distros that don't have the same level of resources behind them. Here's an excerpt from something i wrote on the Gentoo forum back in April: > There's been so much anger and vitriol expressed about > systemd. Has that significantly slowed the systemd juggernaut? > Not really. Not least because, as in the case of D-Bus, and as > in the case of Wayland, it addresses very real issues for > significant numbers of people. > > For example: unlike on, say, OpenBSD, which has developed a > pretty clean shell-script-based service management system, with > a 'standard library' in the form of rc.subr(8), the situation on > Linux was a mess. Many of the (usually volunteers) who maintain > packages for Linux don't want to have to learn the complexities > of shell scripting and the subtle issues that can arise, or > develop and maintain workarounds for race conditions, and so > on. systemd comes along and says: "Hey, with systemd, you'll be > able to write service definitions declaratively; you won't need > to wrangle shell scripts." That's a pretty attractive > proposition to a number of package maintainers, and in the > absence of systemd alternatives explicitly providing such an > interface - not just saying "oh that could be done on our > alternative" - those maintainers are going to be inclined > towards systemd, regardless of what design and implementation > issues are involved in systemd's approach. > > So in wanting to try to ensure that myself and others have > choices and alternatives available, i feel that ranting against > the incoming tide, like a tech King Cnut, is typically far less > effective than actually putting in the work to develop and > support those choices and alternatives. Alexis. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-16 5:48 ` Alexis @ 2024-06-15 8:48 ` Greg A. Woods 2024-06-16 19:44 ` Clem Cole 2024-06-17 1:01 ` Alexis 2024-06-16 6:43 ` Wesley Parish 1 sibling, 2 replies; 160+ messages in thread From: Greg A. Woods @ 2024-06-15 8:48 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 1024 bytes --] At Sun, 16 Jun 2024 15:48:15 +1000, Alexis <flexibeast@gmail.com> wrote: Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register > > Here's an excerpt from something i wrote > on the Gentoo forum back in April: > > > [[...]] the situation on > > Linux was a mess. Many of the (usually > > volunteers) who maintain packages for > > Linux don't want to have to learn the > > complexities of shell scripting and the > > subtle issues that can arise That pretty much says it all about the state of the GNU/linux world right there. In the "Unix world" everyone learns shell scripting, some better than others of course, and some hate it at the same time too, but I would say from my experience it's a given. You either learn shell scripting or you are "just a user" (even if you also write application code). -- Greg A. Woods <gwoods@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> [-- Attachment #2: OpenPGP Digital Signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-15 8:48 ` Greg A. Woods @ 2024-06-16 19:44 ` Clem Cole 2024-06-17 0:10 ` Peter Yardley 2024-06-17 1:01 ` Alexis 1 sibling, 1 reply; 160+ messages in thread From: Clem Cole @ 2024-06-16 19:44 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 2044 bytes --] On Sun, Jun 16, 2024 at 2:50 PM Greg A. Woods <woods@robohack.ca> wrote: > In the "Unix world" everyone learns shell scripting, some better than > others of course, and some hate it at the same time too, but I would say > from my experience it's a given. You either learn shell scripting or > you are "just a user" (even if you also write application code). > Side story - I think you can tell a lot about a person by what is on their bookshelf at work and what books they have read. A few years ago, I discovered this same flaw in using UNIX (Linux) well with some of the new hires (from really good schools, too), and it was worse because they often had never seen the true Bourne shell (nor knew much/anything about Algol, much less A68). Many thought "bash" was the UNIX shell because they never knew better (chuckle). I realized it was a huge hole in their education, so I got my admin to order each copies of K&R2 and UPE for their desks. I said I expected them to do the exercises in them as part of their "training." I could usually tell a lot about each person by the questions they asked during that period. Many often griped about having to learn to use ed and nroff. I think those that were already EMACS folks thought I was a little bonkers but my comment was that you'll understand the other tools better/be a lot more effective with the shell in particular. Many had seen Latex, so the >>idea<< of a document compiler was not always completely foreign. But they crawled through each book. But it was interesting when it was done. To a person, they all said they were much better with the UNIX tool kit after UPE, and because they actually read K&R2, they often learned a few things about C they never realized. Once they "graduated" also I gave them a copy of APUE, if they were doing networking stuff, UNP too. Most would start doing the APUE and UNP problems also as I would get some of them coming to my office with questions, but I never said they had to do them. Clem ᐧ [-- Attachment #2: Type: text/html, Size: 3298 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-16 19:44 ` Clem Cole @ 2024-06-17 0:10 ` Peter Yardley 2024-06-17 0:29 ` Clem Cole 0 siblings, 1 reply; 160+ messages in thread From: Peter Yardley @ 2024-06-17 0:10 UTC (permalink / raw) To: Clem Cole; +Cc: The Unix Heritage Society mailing list Algol has been a dead language for many years, for good reasons too. > On 17 Jun 2024, at 5:44 AM, Clem Cole <clemc@ccc.com> wrote: > > > > On Sun, Jun 16, 2024 at 2:50 PM Greg A. Woods <woods@robohack.ca> wrote: > In the "Unix world" everyone learns shell scripting, some better than > others of course, and some hate it at the same time too, but I would say > from my experience it's a given. You either learn shell scripting or > you are "just a user" (even if you also write application code). > Side story - I think you can tell a lot about a person by what is on their bookshelf at work and what books they have read. > > A few years ago, I discovered this same flaw in using UNIX (Linux) well with some of the new hires (from really good schools, too), and it was worse because they often had never seen the true Bourne shell (nor knew much/anything about Algol, much less A68). Many thought "bash" was the UNIX shell because they never knew better (chuckle). I realized it was a huge hole in their education, so I got my admin to order each copies of K&R2 and UPE for their desks. I said I expected them to do the exercises in them as part of their "training." I could usually tell a lot about each person by the questions they asked during that period. Many often griped about having to learn to use ed and nroff. I think those that were already EMACS folks thought I was a little bonkers but my comment was that you'll understand the other tools better/be a lot more effective with the shell in particular. Many had seen Latex, so the >>idea<< of a document compiler was not always completely foreign. But they crawled through each book. > > But it was interesting when it was done. To a person, they all said they were much better with the UNIX tool kit after UPE, and because they actually read K&R2, they often learned a few things about C they never realized. Once they "graduated" also I gave them a copy of APUE, if they were doing networking stuff, UNP too. Most would start doing the APUE and UNP problems also as I would get some of them coming to my office with questions, but I never said they had to do them. > > Clem > ᐧ Peter Yardley peter.martin.yardley@gmail.com ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-17 0:10 ` Peter Yardley @ 2024-06-17 0:29 ` Clem Cole 0 siblings, 0 replies; 160+ messages in thread From: Clem Cole @ 2024-06-17 0:29 UTC (permalink / raw) To: Peter Yardley; +Cc: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 3291 bytes --] Except A68 is the core of Bourne Shell. Truth is original Algol’s DNA - much less A68 - lived on in most programming languages we use today. Not knowing anything about both puts you at a huge disadvantage. Linux at its core is the Unix ideas (core IP) not the source code. Trying to rid it of so called “bad ideas” shows how little respect those taking such actions have. In others word, their taste is rather disappointing if not out right poor. Frankly my major complaint with much of the modern world is that when we ignore the past and we are cursed for forgetting its lessons. As had been said many times before, we are better served when we stand on the shoulders of great people rather than stepping on their toes. This discussion wrt the systemd is a prefect example. Sent from a handheld expect more typos than usual On Sun, Jun 16, 2024 at 8:11 PM Peter Yardley < peter.martin.yardley@gmail.com> wrote: > Algol has been a dead language for many years, for good reasons too. > > > On 17 Jun 2024, at 5:44 AM, Clem Cole <clemc@ccc.com> wrote: > > > > > > > > On Sun, Jun 16, 2024 at 2:50 PM Greg A. Woods <woods@robohack.ca> wrote: > > In the "Unix world" everyone learns shell scripting, some better than > > others of course, and some hate it at the same time too, but I would say > > from my experience it's a given. You either learn shell scripting or > > you are "just a user" (even if you also write application code). > > Side story - I think you can tell a lot about a person by what is on > their bookshelf at work and what books they have read. > > > > A few years ago, I discovered this same flaw in using UNIX (Linux) well > with some of the new hires (from really good schools, too), and it was > worse because they often had never seen the true Bourne shell (nor knew > much/anything about Algol, much less A68). Many thought "bash" was the > UNIX shell because they never knew better (chuckle). I realized it was a > huge hole in their education, so I got my admin to order each copies of > K&R2 and UPE for their desks. I said I expected them to do the exercises > in them as part of their "training." I could usually tell a lot about each > person by the questions they asked during that period. Many often griped > about having to learn to use ed and nroff. I think those that were already > EMACS folks thought I was a little bonkers but my comment was that you'll > understand the other tools better/be a lot more effective with the shell in > particular. Many had seen Latex, so the >>idea<< of a document compiler was > not always completely foreign. But they crawled through each book. > > > > But it was interesting when it was done. To a person, they all said they > were much better with the UNIX tool kit after UPE, and because they > actually read K&R2, they often learned a few things about C they never > realized. Once they "graduated" also I gave them a copy of APUE, if they > were doing networking stuff, UNP too. Most would start doing the APUE and > UNP problems also as I would get some of them coming to my office with > questions, but I never said they had to do them. > > > > Clem > > ᐧ > > Peter Yardley > peter.martin.yardley@gmail.com > > [-- Attachment #2: Type: text/html, Size: 4165 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-15 8:48 ` Greg A. Woods 2024-06-16 19:44 ` Clem Cole @ 2024-06-17 1:01 ` Alexis 2024-06-17 1:21 ` Warner Losh 2024-06-17 1:25 ` Larry McVoy 1 sibling, 2 replies; 160+ messages in thread From: Alexis @ 2024-06-17 1:01 UTC (permalink / raw) To: The Unix Heritage Society mailing list "Greg A. Woods" <woods@robohack.ca> writes: > At Sun, 16 Jun 2024 15:48:15 +1000, Alexis > <flexibeast@gmail.com> > wrote: > Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix > philosophy' The Register >> >> Here's an excerpt from something i wrote >> on the Gentoo forum back in April: >> >> > [[...]] the situation on >> > Linux was a mess. Many of the (usually >> > volunteers) who maintain packages for >> > Linux don't want to have to learn the >> > complexities of shell scripting and the >> > subtle issues that can arise > > That pretty much says it all about the state of the GNU/linux > world > right there. > > In the "Unix world" everyone learns shell scripting, some better > than > others of course, and some hate it at the same time too, but I > would > say > from my experience it's a given. You either learn shell > scripting or > you are "just a user" (even if you also write application code). i feel this comment is unfair. The specific thing i wrote was: > the _complexities_ of shell scripting and the _subtle issues_ > that can arise [emphasis added] The issue isn't about learning shell scripting _per se_. It's about the extent to which _volunteers_ have to go beyond the _basics_ of shell scripting to learn about the _complexities_ and _subtle issues_ involved in using it to provide _robust_ service management. Including learning, for example, that certain functionality one takes for granted in a given shell isn't actually POSIX, and can't be assumed to be present in the shell one is working with (not to mention that POSIX-compatibility might need to be actively enabled, as in the case of e.g. ksh, via POSIXLY_CORRECT). Here's a FreeBSD thread from 2014, about how service(8) wasn't providing the same environment to scripts that boot did: https://lists.freebsd.org/pipermail/svn-src-head/2014-July/060519.html i'm a BSD user as well as a Linux user - i've been maintaining OpenBSD servers for several years. i certainly have my own criticisms of Linux versus OpenBSD - for example, i'm, mm, 'not a fan' of the somewhat cavalier attitude towards documentation that can often be found in the Linux world, so i'm grateful for people like Alejandro Colomar and his extensive work on the Linux man-pages project. But i feel the above thread suggests that either the FreeBSD devs are clueless about shell scripting or - as i feel is actually the case - that service management via shell scripting isn't as straightforward as one might assume. Alexis. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-17 1:01 ` Alexis @ 2024-06-17 1:21 ` Warner Losh 2024-06-17 1:25 ` Larry McVoy 1 sibling, 0 replies; 160+ messages in thread From: Warner Losh @ 2024-06-17 1:21 UTC (permalink / raw) To: Alexis; +Cc: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 3454 bytes --] On Sun, Jun 16, 2024, 7:01 PM Alexis <flexibeast@gmail.com> wrote: > "Greg A. Woods" <woods@robohack.ca> writes: > > > At Sun, 16 Jun 2024 15:48:15 +1000, Alexis > > <flexibeast@gmail.com> > > wrote: > > Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix > > philosophy' The Register > >> > >> Here's an excerpt from something i wrote > >> on the Gentoo forum back in April: > >> > >> > [[...]] the situation on > >> > Linux was a mess. Many of the (usually > >> > volunteers) who maintain packages for > >> > Linux don't want to have to learn the > >> > complexities of shell scripting and the > >> > subtle issues that can arise > > > > That pretty much says it all about the state of the GNU/linux > > world > > right there. > > > > In the "Unix world" everyone learns shell scripting, some better > > than > > others of course, and some hate it at the same time too, but I > > would > > say > > from my experience it's a given. You either learn shell > > scripting or > > you are "just a user" (even if you also write application code). > > i feel this comment is unfair. > > The specific thing i wrote was: > > > the _complexities_ of shell scripting and the _subtle issues_ > > that can arise > > [emphasis added] > > The issue isn't about learning shell scripting _per se_. It's > about the extent to which _volunteers_ have to go beyond the > _basics_ of shell scripting to learn about the _complexities_ and > _subtle issues_ involved in using it to provide _robust_ service > management. Including learning, for example, that certain > functionality one takes for granted in a given shell isn't > actually POSIX, and can't be assumed to be present in the shell > one is working with (not to mention that POSIX-compatibility might > need to be actively enabled, as in the case of e.g. ksh, via > POSIXLY_CORRECT). > > Here's a FreeBSD thread from 2014, about how service(8) wasn't > providing the same environment to scripts that boot did: > > https://lists.freebsd.org/pipermail/svn-src-head/2014-July/060519.html > > i'm a BSD user as well as a Linux user - i've been maintaining > OpenBSD servers for several years. i certainly have my own > criticisms of Linux versus OpenBSD - for example, i'm, mm, 'not a > fan' of the somewhat cavalier attitude towards documentation that > can often be found in the Linux world, so i'm grateful for people > like Alejandro Colomar and his extensive work on the Linux > man-pages project. But i feel the above thread suggests that > either the FreeBSD devs are clueless about shell scripting or - as > i feel is actually the case - that service management via shell > scripting isn't as straightforward as one might assume. > "Exactly the same" turned out to be harder than one would naively assume. That thread, and others like it elsewhere, hammered out what the differences were and how to fix them. The thread you found is the internal one used to point out issues from changes made... and was 10 years ago... FreeBSD developers, as a whole, are quite adept at shell acripting and the myriad of subtle issues around it. Every time I've committed something that missed one or more of the relevant ones, I've got email.... sometimes, though, it takes a village to know all the subtly in play. It's been 25 or more years since it all could be done by one brilliant person... Warner Alexis. > [-- Attachment #2: Type: text/html, Size: 4791 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-17 1:01 ` Alexis 2024-06-17 1:21 ` Warner Losh @ 2024-06-17 1:25 ` Larry McVoy 2024-06-17 1:32 ` Warner Losh ` (2 more replies) 1 sibling, 3 replies; 160+ messages in thread From: Larry McVoy @ 2024-06-17 1:25 UTC (permalink / raw) To: Alexis; +Cc: The Unix Heritage Society mailing list On Mon, Jun 17, 2024 at 11:01:40AM +1000, Alexis wrote: > "Greg A. Woods" <woods@robohack.ca> writes: > > >At Sun, 16 Jun 2024 15:48:15 +1000, Alexis <flexibeast@gmail.com> > >wrote: > >Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix > >philosophy' The Register > >> > >>Here's an excerpt from something i wrote > >>on the Gentoo forum back in April: > >> > >>> [[...]] the situation on > >>> Linux was a mess. Many of the (usually > >>> volunteers) who maintain packages for > >>> Linux don't want to have to learn the > >>> complexities of shell scripting and the > >>> subtle issues that can arise > > > >That pretty much says it all about the state of the GNU/linux world > >right there. > > > >In the "Unix world" everyone learns shell scripting, some better than > >others of course, and some hate it at the same time too, but I would > >say > >from my experience it's a given. You either learn shell scripting or > >you are "just a user" (even if you also write application code). > > i feel this comment is unfair. > > The specific thing i wrote was: > > >the _complexities_ of shell scripting and the _subtle issues_ that can > >arise > > [emphasis added] > > The issue isn't about learning shell scripting _per se_. It's about the > extent to which _volunteers_ have to go beyond the _basics_ of shell > scripting to learn about the _complexities_ and _subtle issues_ involved in > using it to provide _robust_ service management. Including learning, for > example, that certain functionality one takes for granted in a given shell > isn't actually POSIX, and can't be assumed to be present in the shell one is > working with (not to mention that POSIX-compatibility might need to be > actively enabled, as in the case of e.g. ksh, via POSIXLY_CORRECT). This is sort of off topic but maybe relevant. When I was running my company, my engineers joked that if it were invented after 1980 I wouldn't let them use it. Which wasn't true, we used mmap(). But the underlying sentiment sort of was true. Even though they were all used to bash, I tried very hard to not use bash specific stuff. And it paid off, in our hey day, we supported SCO, AIX, HPUX, SunOS, Solaris, Tru64, Linux on every architecture from tin to IBM mainframes, Windows, Macos on PPC and x86, etc. And probably a bunch of other platforms I've forgotten. *Every* time they used some bash-ism, it bit us in the ass. I kept telling them "our build environment is not our deployment environment". We had a bunch of /bin/sh stuff that we shipped so we had to go for the common denominator. I did relax things to allow GNU Make, there were some features that they really wanted and that is build environment, so, shrug. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-17 1:25 ` Larry McVoy @ 2024-06-17 1:32 ` Warner Losh 2024-06-17 19:21 ` Stuff Received 2024-06-20 20:14 ` Alexander Schreiber 2 siblings, 0 replies; 160+ messages in thread From: Warner Losh @ 2024-06-17 1:32 UTC (permalink / raw) To: Larry McVoy; +Cc: Alexis, The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 3084 bytes --] On Sun, Jun 16, 2024, 7:25 PM Larry McVoy <lm@mcvoy.com> wrote: > On Mon, Jun 17, 2024 at 11:01:40AM +1000, Alexis wrote: > > "Greg A. Woods" <woods@robohack.ca> writes: > > > > >At Sun, 16 Jun 2024 15:48:15 +1000, Alexis <flexibeast@gmail.com> > > >wrote: > > >Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix > > >philosophy' The Register > > >> > > >>Here's an excerpt from something i wrote > > >>on the Gentoo forum back in April: > > >> > > >>> [[...]] the situation on > > >>> Linux was a mess. Many of the (usually > > >>> volunteers) who maintain packages for > > >>> Linux don't want to have to learn the > > >>> complexities of shell scripting and the > > >>> subtle issues that can arise > > > > > >That pretty much says it all about the state of the GNU/linux world > > >right there. > > > > > >In the "Unix world" everyone learns shell scripting, some better than > > >others of course, and some hate it at the same time too, but I would > > >say > > >from my experience it's a given. You either learn shell scripting or > > >you are "just a user" (even if you also write application code). > > > > i feel this comment is unfair. > > > > The specific thing i wrote was: > > > > >the _complexities_ of shell scripting and the _subtle issues_ that can > > >arise > > > > [emphasis added] > > > > The issue isn't about learning shell scripting _per se_. It's about the > > extent to which _volunteers_ have to go beyond the _basics_ of shell > > scripting to learn about the _complexities_ and _subtle issues_ involved > in > > using it to provide _robust_ service management. Including learning, for > > example, that certain functionality one takes for granted in a given > shell > > isn't actually POSIX, and can't be assumed to be present in the shell > one is > > working with (not to mention that POSIX-compatibility might need to be > > actively enabled, as in the case of e.g. ksh, via POSIXLY_CORRECT). > > This is sort of off topic but maybe relevant. > > When I was running my company, my engineers joked that if it were invented > after 1980 I wouldn't let them use it. Which wasn't true, we used mmap(). > > But the underlying sentiment sort of was true. Even though they were > all used to bash, I tried very hard to not use bash specific stuff. > And it paid off, in our hey day, we supported SCO, AIX, HPUX, SunOS, > Solaris, Tru64, Linux on every architecture from tin to IBM mainframes, > Windows, Macos on PPC and x86, etc. And probably a bunch of other > platforms I've forgotten. > > *Every* time they used some bash-ism, it bit us in the ass. I kept > telling them "our build environment is not our deployment environment". > We had a bunch of /bin/sh stuff that we shipped so we had to go for > the common denominator. > The fallout of the Unix Wars was that this denominator was kept too low for too long. Warner I did relax things to allow GNU Make, there were some features that they > really wanted and that is build environment, so, shrug. > [-- Attachment #2: Type: text/html, Size: 4262 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-17 1:25 ` Larry McVoy 2024-06-17 1:32 ` Warner Losh @ 2024-06-17 19:21 ` Stuff Received 2024-06-17 19:28 ` Larry McVoy 2024-06-17 22:34 ` Steve Nickolas 2024-06-20 20:14 ` Alexander Schreiber 2 siblings, 2 replies; 160+ messages in thread From: Stuff Received @ 2024-06-17 19:21 UTC (permalink / raw) To: tuhs On 2024-06-16 21:25, Larry McVoy wrote (in part): [...] > *Every* time they used some bash-ism, it bit us in the ass. This is so true for a lot of OS projects (on Github, for example). Most -- sometimes all -- the scripts that start with /bin/sh but are full of bashisms because the authors run systems where /bin/sh is really bash. S. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-17 19:21 ` Stuff Received @ 2024-06-17 19:28 ` Larry McVoy 2024-06-17 22:34 ` Steve Nickolas 1 sibling, 0 replies; 160+ messages in thread From: Larry McVoy @ 2024-06-17 19:28 UTC (permalink / raw) To: Stuff Received; +Cc: tuhs On Mon, Jun 17, 2024 at 03:21:47PM -0400, Stuff Received wrote: > On 2024-06-16 21:25, Larry McVoy wrote (in part): > [...] > >*Every* time they used some bash-ism, it bit us in the ass. > > This is so true for a lot of OS projects (on Github, for example). Most -- > sometimes all -- the scripts that start with /bin/sh but are full of > bashisms because the authors run systems where /bin/sh is really bash. I think it is less of an issue these days, it's mostly Windows, MacOS, Linux and bash is available there. That said, anything I care about is v7 compat. No need to get fancy, if I need fancy, there is C. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-17 19:21 ` Stuff Received 2024-06-17 19:28 ` Larry McVoy @ 2024-06-17 22:34 ` Steve Nickolas 2024-06-16 7:57 ` Greg A. Woods 2024-06-21 15:38 ` Chet Ramey via TUHS 1 sibling, 2 replies; 160+ messages in thread From: Steve Nickolas @ 2024-06-17 22:34 UTC (permalink / raw) To: tuhs On Mon, 17 Jun 2024, Stuff Received wrote: > On 2024-06-16 21:25, Larry McVoy wrote (in part): > [...] >> *Every* time they used some bash-ism, it bit us in the ass. > > This is so true for a lot of OS projects (on Github, for example). Most -- > sometimes all -- the scripts that start with /bin/sh but are full of bashisms > because the authors run systems where /bin/sh is really bash. Which is why I'm glad Debian's /bin/sh is dash (fork of ash) instead. -uso. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-17 22:34 ` Steve Nickolas @ 2024-06-16 7:57 ` Greg A. Woods 2024-06-17 23:44 ` Warner Losh 2024-06-18 1:52 ` Steve Nickolas 2024-06-21 15:38 ` Chet Ramey via TUHS 1 sibling, 2 replies; 160+ messages in thread From: Greg A. Woods @ 2024-06-16 7:57 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 1766 bytes --] At Mon, 17 Jun 2024 18:34:06 -0400 (EDT), Steve Nickolas <usotsuki@buric.co> wrote: Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register > > Which is why I'm glad Debian's /bin/sh is dash (fork of ash) instead. Well, to be pedantic "dash" was a direct descendant of NetBSD's /bin/sh, which in turn was the shell from 4.4BSD, which was of course originally Kenneth Almquist's Ash. Quite a few changes were made to the shell in BSD between the time it was imported (1991), and the 4.4 release (1995). Unfortunately Dash now lags very far behind NetBSD's /bin/sh code. If they had just kept it as a port of the upstream code and continued to update it from upstream then "they" would now have a much better shell (as much development has occurred in NetBSD since 1997), but no it's a full-on fork that's basically ignored its upstream parent since day one. It is doomed now to need fixes for the same bugs again, often in incompatible ways, and probably inevitably new features will be added to it, also in incompatible ways. Then again OpenBSD and FreeBSD (and its derivatives) have also continued forked development of the 4.4BSD shell (and most of the rest of the system) with only very occasional sharing of code back and forth with NetBSD. I guess this forking of code is also somewhat a part of "Unix" practice, even if it goes against the strict tenets of Unix philosophy. I don't think it's as egregious as the N.I.H. "doctrine" (of which systemd could be the result of, and cmake is definitely the result of), but it is problematic. -- Greg A. Woods <gwoods@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> [-- Attachment #2: OpenPGP Digital Signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-16 7:57 ` Greg A. Woods @ 2024-06-17 23:44 ` Warner Losh 2024-06-18 0:06 ` Larry McVoy 2024-06-18 22:44 ` Greg A. Woods 2024-06-18 1:52 ` Steve Nickolas 1 sibling, 2 replies; 160+ messages in thread From: Warner Losh @ 2024-06-17 23:44 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 3300 bytes --] On Mon, Jun 17, 2024, 5:30 PM Greg A. Woods <woods@robohack.ca> wrote: > At Mon, 17 Jun 2024 18:34:06 -0400 (EDT), Steve Nickolas < > usotsuki@buric.co> wrote: > Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix > philosophy' The Register > > > > Which is why I'm glad Debian's /bin/sh is dash (fork of ash) instead. > > Well, to be pedantic "dash" was a direct descendant of NetBSD's /bin/sh, > which in turn was the shell from 4.4BSD, which was of course originally > Kenneth Almquist's Ash. Quite a few changes were made to the shell in > BSD between the time it was imported (1991), and the 4.4 release (1995). > > Unfortunately Dash now lags very far behind NetBSD's /bin/sh code. > > If they had just kept it as a port of the upstream code and continued to > update it from upstream then "they" would now have a much better shell > (as much development has occurred in NetBSD since 1997), but no it's a > full-on fork that's basically ignored its upstream parent since day one. > It is doomed now to need fixes for the same bugs again, often in > incompatible ways, and probably inevitably new features will be added to > it, also in incompatible ways. > > Then again OpenBSD and FreeBSD (and its derivatives) have also continued > forked development of the 4.4BSD shell (and most of the rest of the > system) with only very occasional sharing of code back and forth with > NetBSD. > Yea. Personality squabbles trump common sense. Some areas have reconverged, and those are bright points. I guess this forking of code is also somewhat a part of "Unix" practice, > even if it goes against the strict tenets of Unix philosophy. I don't > think it's as egregious as the N.I.H. "doctrine" (of which systemd could > be the result of, and cmake is definitely the result of), but it is > problematic. > Yea. It's more of a people problem and for the first 15 or 20 years of 4.4BSD the tools to reconverge weren't up to the task, even if the political will had been there to bless it. Diff was just one part. The easy part. But knowing why things differed. What mattered, why it was different (often with only the log message "fix. Ok xxx" to go on). Once it morphed organically for even 5 years, going back was hard. There was no upstream anymore. Csrg was gone, and all successor BSD projects assumed they were the new upstream. It was rarely clear whichnproject has the rights to that claim as the answer was patjologically different for different parts of the system. The NIH stuff sunk adopting jails, geom, smp, etc from FreeBSD and almost sunk make from unifying some years ago. Too much ego and wanting perfect code so all that other code is junk... It's a hard problem because continuing engineering is actually hard and boring work nobody wants to do as their fun hobby... not least because it requires a lot of time to keep up and the skills of a diplomat, which previous few people have.. plus a perception that mere merging never advances the state of the art... Warner -- > Greg A. Woods <gwoods@acm.org> > > Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> > Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> > [-- Attachment #2: Type: text/html, Size: 4713 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-17 23:44 ` Warner Losh @ 2024-06-18 0:06 ` Larry McVoy 2024-06-18 22:44 ` Greg A. Woods 1 sibling, 0 replies; 160+ messages in thread From: Larry McVoy @ 2024-06-18 0:06 UTC (permalink / raw) To: Warner Losh; +Cc: The Unix Heritage Society mailing list On Mon, Jun 17, 2024 at 05:44:40PM -0600, Warner Losh wrote: > Once it morphed > organically for even 5 years, going back was hard. There was no upstream > anymore. Csrg was gone, and all successor BSD projects assumed they were > the new upstream. It was rarely clear whichnproject has the rights to that > claim as the answer was patjologically different for different parts of the > system. I've said before, and I'll say it again. The BSD community couldn't decide who was going to drive the big red fire truck. Instead of doing that, they each took their own toy fire truck and we have the vision of grown men driving around on toy trucks. All while the Linux community let Linus drive. The results speak for themselves, we've got Android Linux on a zillion cell phones, I believe all of the top 500 super computers are Linux, Linux even has some use on the desktop. BSD has what? MacOS but that's a closed off fork, it's not helping BSD in any way other than marketing. It's sad, I started out as a BSD/Sun guy and loved it. But when the forks happened I could see the writing on the wall and went over to Linux. Shoulda, coulda, woulda (again). ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-17 23:44 ` Warner Losh 2024-06-18 0:06 ` Larry McVoy @ 2024-06-18 22:44 ` Greg A. Woods 2024-06-19 2:33 ` David Arnold 1 sibling, 1 reply; 160+ messages in thread From: Greg A. Woods @ 2024-06-18 22:44 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 1467 bytes --] At Mon, 17 Jun 2024 17:44:40 -0600, Warner Losh <imp@bsdimp.com> wrote: Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register > > .... There was no upstream > anymore. Csrg was gone, and all successor BSD projects assumed they were > the new upstream. Hmmm.... I never really thought of it that way before! I guess I had hoped everyone would come to realize a new one-size-fits-all upstream would be a "good thing", or perhaps even a necessity, and that none would automatically slip into thinking they were it without first reaching some consensus with other projects -- at least between NetBSD and FreeBSD for starters (and I suppose all hope of this had long evaporated before any of the other off-shoots formed). > The NIH stuff sunk adopting jails, geom, smp, etc from FreeBSD and almost > sunk make from unifying some years ago. Too much ego and wanting perfect > code so all that other code is junk... It's a hard problem because > continuing engineering is actually hard and boring work nobody wants to do > as their fun hobby... not least because it requires a lot of time to keep > up and the skills of a diplomat, which previous few people have.. plus a > perception that mere merging never advances the state of the art... Indeed! -- Greg A. Woods <gwoods@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> [-- Attachment #2: OpenPGP Digital Signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-18 22:44 ` Greg A. Woods @ 2024-06-19 2:33 ` David Arnold 0 siblings, 0 replies; 160+ messages in thread From: David Arnold @ 2024-06-19 2:33 UTC (permalink / raw) To: The Unix Heritage Society mailing list > On 19 Jun 2024, at 08:44, Greg A. Woods <woods@robohack.ca> wrote: > > At Mon, 17 Jun 2024 17:44:40 -0600, Warner Losh <imp@bsdimp.com> wrote: > Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register >> >> .... There was no upstream >> anymore. Csrg was gone, and all successor BSD projects assumed they were >> the new upstream. > > Hmmm.... I never really thought of it that way before! > > I guess I had hoped everyone would come to realize a new > one-size-fits-all upstream would be a "good thing", or > perhaps even a necessity, and that none would automatically > slip into thinking they were it without first reaching some > consensus with other projects A somewhat similar thing has happened with Plan9. There are multiple “successor” projects, some basically single-person projects, others semi-official with legal structure, others larger groups of like-minded developers. The are high levels of acrimony between the groups, and no accepted processes for evolving together. Periodically, some naive passerby will suggest a common core repository, perhaps even using a popular technology, and they’ll get barbecued in the resulting flamefest. So it goes. d ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-16 7:57 ` Greg A. Woods 2024-06-17 23:44 ` Warner Losh @ 2024-06-18 1:52 ` Steve Nickolas 2024-06-18 4:52 ` segaloco via TUHS 2024-06-21 15:41 ` [TUHS] " Chet Ramey via TUHS 1 sibling, 2 replies; 160+ messages in thread From: Steve Nickolas @ 2024-06-18 1:52 UTC (permalink / raw) To: The Unix Heritage Society mailing list On Sun, 16 Jun 2024, Greg A. Woods wrote: > At Mon, 17 Jun 2024 18:34:06 -0400 (EDT), Steve Nickolas <usotsuki@buric.co> wrote: > > Well, to be pedantic "dash" was a direct descendant of NetBSD's /bin/sh, > which in turn was the shell from 4.4BSD, which was of course originally > Kenneth Almquist's Ash. Quite a few changes were made to the shell in > BSD between the time it was imported (1991), and the 4.4 release (1995). > > Unfortunately Dash now lags very far behind NetBSD's /bin/sh code. > > If they had just kept it as a port of the upstream code and continued to > update it from upstream then "they" would now have a much better shell > (as much development has occurred in NetBSD since 1997), but no it's a > full-on fork that's basically ignored its upstream parent since day one. > It is doomed now to need fixes for the same bugs again, often in > incompatible ways, and probably inevitably new features will be added to > it, also in incompatible ways. It's still possible to port NetBSD's /bin/sh to Debian (I've done it, called it "nash", but don't have any official release because I don't really see a point). And it's basically the "sh" I'm currently using in my projects because I don't have the talent to write my own. :P -uso. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-18 1:52 ` Steve Nickolas @ 2024-06-18 4:52 ` segaloco via TUHS 2024-06-18 22:50 ` Greg A. Woods 2024-06-21 15:41 ` [TUHS] " Chet Ramey via TUHS 1 sibling, 1 reply; 160+ messages in thread From: segaloco via TUHS @ 2024-06-18 4:52 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Monday, June 17th, 2024 at 6:51 PM, Steve Nickolas <usotsuki@buric.co> wrote: > On Sun, 16 Jun 2024, Greg A. Woods wrote: > > > At Mon, 17 Jun 2024 18:34:06 -0400 (EDT), Steve Nickolas usotsuki@buric.co wrote: > > > > Well, to be pedantic "dash" was a direct descendant of NetBSD's /bin/sh, > > which in turn was the shell from 4.4BSD, which was of course originally > > Kenneth Almquist's Ash. Quite a few changes were made to the shell in > > BSD between the time it was imported (1991), and the 4.4 release (1995). > > > > Unfortunately Dash now lags very far behind NetBSD's /bin/sh code. > > > > If they had just kept it as a port of the upstream code and continued to > > update it from upstream then "they" would now have a much better shell > > (as much development has occurred in NetBSD since 1997), but no it's a > > full-on fork that's basically ignored its upstream parent since day one. > > It is doomed now to need fixes for the same bugs again, often in > > incompatible ways, and probably inevitably new features will be added to > > it, also in incompatible ways. > > > It's still possible to port NetBSD's /bin/sh to Debian (I've done it, > called it "nash", but don't have any official release because I don't > really see a point). > > And it's basically the "sh" I'm currently using in my projects because I > don't have the talent to write my own. :P > > -uso. Dash is my go-to /bin/sh on minimal Linux systems I prepare owing to its similar minimalism. I've considered that angle and hearing of your success has me tempted to pursue something along those lines. There are projects out there that have propped up a BSD userland over the Linux kernel too. I've not really tinkered with such things myself but I wonder if, given enough time, such a combo could gain more traction or fill a want/need not being met otherwise? Technically it's another way for Linux-sans-systemd. Systemd does seem to cover a diverse spread of use-cases, some better than others. For a personal system, it feels a bit much, but many folks have made valid points, particularly regarding systems you create and walk away from. I think of things so often from the interactive, personal system angle, but many systems don't have one person sitting at them with a handful of xterms open. I imagine the Linux world is steered a bit more in the server and enterprise directions as far as there is money to be made, naturally. Upstream wants to satisfy this crowd so personal user systems dip into the same systemd pool. My only major concern still is a sort of homogenization of the Linux userland, the same as exists in the marriage of Linux and GNU. Much of the software out there assumes if you'd got a Linux kernel, you've a GNU C library and some supporting bits, and vice versa. That's not to diminish the real help of things like autotools and CMake, but if someone is liable to use a non-portable thing, it's probably a GNU extension or Linux-ism. This isn't critique of either or, rather, the weight of their combined influence. If systemd gains comparable eminence in the overwhelming majority of Linux distros to the GNU C library itself, similarly one will find themselves with daemons that may only behave themselves under systemd's piercing gaze. Maybe it's only natural, systemd does seem to satisfy the needs of more than it offends. They can't take my sysvinit away from me though. It "just works" but my needs are also narrow. - Matt G. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-18 4:52 ` segaloco via TUHS @ 2024-06-18 22:50 ` Greg A. Woods 2024-06-18 23:03 ` Warner Losh 2024-06-19 0:08 ` Luther Johnson 0 siblings, 2 replies; 160+ messages in thread From: Greg A. Woods @ 2024-06-18 22:50 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 654 bytes --] At Tue, 18 Jun 2024 04:52:51 +0000, segaloco via TUHS <tuhs@tuhs.org> wrote: Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register > > That's not > to diminish the real help of things like autotools and CMake, Oh, that strikes a nerve. CMake is the very antithesis of a good tool. It doesn't help. I think it is perhaps the worst abomination EVER in the world of software tools, and especially amongst software construction tools. -- Greg A. Woods <gwoods@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> [-- Attachment #2: OpenPGP Digital Signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-18 22:50 ` Greg A. Woods @ 2024-06-18 23:03 ` Warner Losh 2024-06-18 23:27 ` ron minnich ` (3 more replies) 2024-06-19 0:08 ` Luther Johnson 1 sibling, 4 replies; 160+ messages in thread From: Warner Losh @ 2024-06-18 23:03 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 870 bytes --] On Tue, Jun 18, 2024, 4:50 PM Greg A. Woods <woods@robohack.ca> wrote: > At Tue, 18 Jun 2024 04:52:51 +0000, segaloco via TUHS <tuhs@tuhs.org> > wrote: > Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix > philosophy' The Register > > > > That's not > > to diminish the real help of things like autotools and CMake, > > Oh, that strikes a nerve. > > CMake is the very antithesis of a good tool. It doesn't help. I think > it is perhaps the worst abomination EVER in the world of software tools, > and especially amongst software construction tools. > Someone clearly never used imake... Warner -- > Greg A. Woods <gwoods@acm.org> > > Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> > Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> > [-- Attachment #2: Type: text/html, Size: 1890 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-18 23:03 ` Warner Losh @ 2024-06-18 23:27 ` ron minnich 2024-06-19 1:38 ` Greg 'groggy' Lehey ` (2 subsequent siblings) 3 siblings, 0 replies; 160+ messages in thread From: ron minnich @ 2024-06-18 23:27 UTC (permalink / raw) To: Warner Losh; +Cc: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 1014 bytes --] but it rhymes with mistake! On Tue, Jun 18, 2024 at 4:12 PM Warner Losh <imp@bsdimp.com> wrote: > > > On Tue, Jun 18, 2024, 4:50 PM Greg A. Woods <woods@robohack.ca> wrote: > >> At Tue, 18 Jun 2024 04:52:51 +0000, segaloco via TUHS <tuhs@tuhs.org> >> wrote: >> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix >> philosophy' The Register >> > >> > That's not >> > to diminish the real help of things like autotools and CMake, >> >> Oh, that strikes a nerve. >> >> CMake is the very antithesis of a good tool. It doesn't help. I think >> it is perhaps the worst abomination EVER in the world of software tools, >> and especially amongst software construction tools. >> > > Someone clearly never used imake... > > Warner > > -- >> Greg A. Woods <gwoods@acm.org> >> >> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> >> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> >> > [-- Attachment #2: Type: text/html, Size: 2318 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-18 23:03 ` Warner Losh 2024-06-18 23:27 ` ron minnich @ 2024-06-19 1:38 ` Greg 'groggy' Lehey 2024-06-19 1:42 ` Warner Losh 2024-06-19 2:38 ` David Arnold 2024-06-19 22:52 ` Greg A. Woods 3 siblings, 1 reply; 160+ messages in thread From: Greg 'groggy' Lehey @ 2024-06-19 1:38 UTC (permalink / raw) To: Warner Losh; +Cc: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 730 bytes --] On Tuesday, 18 June 2024 at 17:03:07 -0600, Warner Losh wrote: > On Tue, Jun 18, 2024, 4:50 PM Greg A. Woods <woods@robohack.ca> wrote: >> >> CMake is the very antithesis of a good tool. It doesn't help. I think >> it is perhaps the worst abomination EVER in the world of software tools, >> and especially amongst software construction tools. > > Someone clearly never used imake... I've used both. I'm with Greg (Woods): cmake takes the cake. Greg -- Sent from my desktop computer. Finger grog@lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 1:38 ` Greg 'groggy' Lehey @ 2024-06-19 1:42 ` Warner Losh 2024-06-19 23:28 ` Greg A. Woods 0 siblings, 1 reply; 160+ messages in thread From: Warner Losh @ 2024-06-19 1:42 UTC (permalink / raw) To: Greg 'groggy' Lehey; +Cc: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 892 bytes --] On Tue, Jun 18, 2024, 7:38 PM Greg 'groggy' Lehey <grog@lemis.com> wrote: > On Tuesday, 18 June 2024 at 17:03:07 -0600, Warner Losh wrote: > > On Tue, Jun 18, 2024, 4:50 PM Greg A. Woods <woods@robohack.ca> wrote: > >> > >> CMake is the very antithesis of a good tool. It doesn't help. I think > >> it is perhaps the worst abomination EVER in the world of software tools, > >> and especially amongst software construction tools. > > > > Someone clearly never used imake... > > I've used both. I'm with Greg (Woods): cmake takes the cake. > Cmake actually works though... Warner Greg > -- > Sent from my desktop computer. > Finger grog@lemis.com for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA.php > [-- Attachment #2: Type: text/html, Size: 1792 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 1:42 ` Warner Losh @ 2024-06-19 23:28 ` Greg A. Woods 2024-06-20 5:01 ` Scot Jenkins via TUHS 2024-06-20 8:05 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register Steve Nickolas 0 siblings, 2 replies; 160+ messages in thread From: Greg A. Woods @ 2024-06-19 23:28 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 2795 bytes --] At Tue, 18 Jun 2024 19:42:59 -0600, Warner Losh <imp@bsdimp.com> wrote: Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register > > On Tue, Jun 18, 2024, 7:38 PM Greg 'groggy' Lehey <grog@lemis.com> wrote: > > > On Tuesday, 18 June 2024 at 17:03:07 -0600, Warner Losh wrote: > > > On Tue, Jun 18, 2024, 4:50 PM Greg A. Woods <woods@robohack.ca> wrote: > > >> > > >> CMake is the very antithesis of a good tool. It doesn't help. I think > > >> it is perhaps the worst abomination EVER in the world of software tools, > > >> and especially amongst software construction tools. > > > > > > Someone clearly never used imake... > > > > I've used both. I'm with Greg (Woods): cmake takes the cake. > > > > Cmake actually works though... Well, maybe, sometimes, for some limited set of pre-tested targets. Which was true for imake as well, but.... Last time I had to use cmake it took significantly longer to build the monster than it did to build the entire current-at-the-time GCC release. When it runs it usually chews through far more CPU cycles and requires far more RAM than the equivalent Autotools configure script, even including running autoconf et al to build the script first. Its design and implementation ignores the entire history and legacy and knowledge bank of existing tools and lore used to build portable software and throws the one or two existing tools it does pay homage to in your face to spite you. It couldn't ignore Unix philosophy harder and more completely than it does. For example it can't generate a working makefile or script that can then be used without it! At least I couldn't convince it to do so. At the time I was hacking on a project that claimed to require it, it couldn't even properly parse a string and had trouble with parenthesis. I don't remember the details, but it was very ugly and required stupidly obtuse and self-limiting workarounds. I used to think libtool was the worst software construction tool imagined (well worse than the rest of Autotools), but cmake is many orders of magnitude worse. I will not ever allow cmake to run, or even exist, on the machines I control. Sometimes some tools are just too dangerous to have in the house or workshop, no matter how handy others claim they might be. Using cmake is like _forcing_ you to use a flame thrower to light your portable gas barbecue at a camp site in a tinder-dry forest. Inevitably someone or something is going to get hurt/destroyed. Sorry, cmake is a hot button for me, as you can see. -- Greg A. Woods <gwoods@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> [-- Attachment #2: OpenPGP Digital Signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 23:28 ` Greg A. Woods @ 2024-06-20 5:01 ` Scot Jenkins via TUHS 2024-06-20 5:09 ` Luther Johnson 2024-06-20 18:34 ` Greg A. Woods 2024-06-20 8:05 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register Steve Nickolas 1 sibling, 2 replies; 160+ messages in thread From: Scot Jenkins via TUHS @ 2024-06-20 5:01 UTC (permalink / raw) To: tuhs "Greg A. Woods" <woods@robohack.ca> wrote: > I will not ever allow cmake to run, or even exist, on the machines I > control... I'm not a fan of cmake either. How do you deal with software that only builds with cmake (or meson, scons, ... whatever the developer decided to use as the build tool)? What alternatives exist short of reimplementing the build process in a standard makefile by hand, which is obviously very time consuming, error prone, and will probably break the next time you want to update a given package? If there is some great alternative, I would like to know about it. scot ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 5:01 ` Scot Jenkins via TUHS @ 2024-06-20 5:09 ` Luther Johnson 2024-06-20 5:18 ` Luther Johnson 2024-06-20 18:34 ` Greg A. Woods 1 sibling, 1 reply; 160+ messages in thread From: Luther Johnson @ 2024-06-20 5:09 UTC (permalink / raw) To: tuhs I just avoid tools that build with CMake altogether, I look for alternative tools. The tool has already told me, what I can expect from a continued relationship, by its use of CMake ... On 06/19/2024 10:01 PM, Scot Jenkins via TUHS wrote: > "Greg A. Woods" <woods@robohack.ca> wrote: > >> I will not ever allow cmake to run, or even exist, on the machines I >> control... > I'm not a fan of cmake either. > > How do you deal with software that only builds with cmake (or meson, > scons, ... whatever the developer decided to use as the build tool)? > What alternatives exist short of reimplementing the build process in > a standard makefile by hand, which is obviously very time consuming, > error prone, and will probably break the next time you want to update > a given package? > > If there is some great alternative, I would like to know about it. > > scot > ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 5:09 ` Luther Johnson @ 2024-06-20 5:18 ` Luther Johnson 0 siblings, 0 replies; 160+ messages in thread From: Luther Johnson @ 2024-06-20 5:18 UTC (permalink / raw) To: tuhs That being said, I must confess there is a very smll number of tools I use, which I build from source, keep up with patches and updates for, etc. I don't have the same problems as a sysadmin for a large community using many open source projects, those issues are real but since I'm only supporting my opinionated self, I have the luxury of choosing software that meets my approval. On 06/19/2024 10:09 PM, Luther Johnson wrote: > I just avoid tools that build with CMake altogether, I look for > alternative tools. The tool has already told me, what I can expect from > a continued relationship, by its use of CMake ... > > On 06/19/2024 10:01 PM, Scot Jenkins via TUHS wrote: >> "Greg A. Woods" <woods@robohack.ca> wrote: >> >>> I will not ever allow cmake to run, or even exist, on the machines I >>> control... >> I'm not a fan of cmake either. >> >> How do you deal with software that only builds with cmake (or meson, >> scons, ... whatever the developer decided to use as the build tool)? >> What alternatives exist short of reimplementing the build process in >> a standard makefile by hand, which is obviously very time consuming, >> error prone, and will probably break the next time you want to update >> a given package? >> >> If there is some great alternative, I would like to know about it. >> >> scot >> > > ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 5:01 ` Scot Jenkins via TUHS 2024-06-20 5:09 ` Luther Johnson @ 2024-06-20 18:34 ` Greg A. Woods 2024-06-20 18:41 ` Adam Thornton 2024-06-20 19:57 ` [TUHS] Version 256.1: Now slightly less likely to delete /home Jim Capp 1 sibling, 2 replies; 160+ messages in thread From: Greg A. Woods @ 2024-06-20 18:34 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 1376 bytes --] At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS <tuhs@tuhs.org> wrote: Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register > > "Greg A. Woods" <woods@robohack.ca> wrote: > > > I will not ever allow cmake to run, or even exist, on the machines I > > control... > > I'm not a fan of cmake either. > > How do you deal with software that only builds with cmake (or meson, > scons, ... whatever the developer decided to use as the build tool)? > What alternatives exist short of reimplementing the build process in > a standard makefile by hand, which is obviously very time consuming, > error prone, and will probably break the next time you want to update > a given package? The alternative _is_ to reimplement the build process. For example, see: https://github.com/robohack/yajl/ This example is a far more comprehensive rewrite than is usually necessary as I wanted a complete and portable example that could be used as the basis for further projects. An example of a much simpler reimplementation: http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN -- Greg A. Woods <gwoods@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> [-- Attachment #2: OpenPGP Digital Signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 18:34 ` Greg A. Woods @ 2024-06-20 18:41 ` Adam Thornton 2024-06-20 19:59 ` Warner Losh 2024-06-20 19:57 ` [TUHS] Version 256.1: Now slightly less likely to delete /home Jim Capp 1 sibling, 1 reply; 160+ messages in thread From: Adam Thornton @ 2024-06-20 18:41 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 1783 bytes --] Someone clearly never used imake... There's a reason that the xmkmf command ends in the two letters it does, and I'm never going to believe it's "make file". Adam On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods <woods@robohack.ca> wrote: > At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS <tuhs@tuhs.org> > wrote: > Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix > philosophy' The Register > > > > "Greg A. Woods" <woods@robohack.ca> wrote: > > > > > I will not ever allow cmake to run, or even exist, on the machines I > > > control... > > > > I'm not a fan of cmake either. > > > > How do you deal with software that only builds with cmake (or meson, > > scons, ... whatever the developer decided to use as the build tool)? > > What alternatives exist short of reimplementing the build process in > > a standard makefile by hand, which is obviously very time consuming, > > error prone, and will probably break the next time you want to update > > a given package? > > The alternative _is_ to reimplement the build process. > > For example, see: > > https://github.com/robohack/yajl/ > > This example is a far more comprehensive rewrite than is usually > necessary as I wanted a complete and portable example that could be used > as the basis for further projects. > > An example of a much simpler reimplementation: > > > http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN > > -- > Greg A. Woods <gwoods@acm.org> > > Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> > Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> > [-- Attachment #2: Type: text/html, Size: 3417 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 18:41 ` Adam Thornton @ 2024-06-20 19:59 ` Warner Losh 2024-06-20 20:12 ` ron minnich ` (2 more replies) 0 siblings, 3 replies; 160+ messages in thread From: Warner Losh @ 2024-06-20 19:59 UTC (permalink / raw) To: Adam Thornton; +Cc: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 3401 bytes --] For me, precomputing an environment is the same as a wysiwyg editor: what you see is all you get. If it works for you, and the environment that's inferred from predefined CPP symbols is correct, then it's an easy solution. When it's not, and for me it often wasn't, it's nothing but pain and suffering and saying MF all the time (also not Make File).... I was serious when I've said I've had more positive cmake experiences (which haven't been all that impressive: I'm more impressed with meson in this space, for example) than I ever had with IMakefiles, imake, xmkmf, etc... But It's also clear that different people have lived through different hassles, and I respect that... I've noticed too that we're relatively homogeneous these days: Everybody is a Linux box or Windows Box or MacOS, except for a few weird people on the fringes (like me). It's a lot easier to get things right enough w/o autotools, scons, meson, etc than it was in The Bad Old Days of the Unix Wars and the Innovation Famine that followed from the late 80s to the mid 2000s.... In that environment, there's one of two reactions: Test Everything or Least Common Denominator. And we've seen both represented in this thread. As well as the 'There's so few environments, can't you precompute them all?' sentiment from newbies that never bloodied their knuckles with some of the less like Research Unix machines out there like AIX and HP/UX... Or worse, Eunice... Warner On Thu, Jun 20, 2024 at 12:42 PM Adam Thornton <athornton@gmail.com> wrote: > > > Someone clearly never used imake... > > > There's a reason that the xmkmf command ends in the two letters it does, > and I'm never going to believe it's "make file". > > Adam > > On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods <woods@robohack.ca> wrote: > >> At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS <tuhs@tuhs.org> >> wrote: >> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix >> philosophy' The Register >> > >> > "Greg A. Woods" <woods@robohack.ca> wrote: >> > >> > > I will not ever allow cmake to run, or even exist, on the machines I >> > > control... >> > >> > I'm not a fan of cmake either. >> > >> > How do you deal with software that only builds with cmake (or meson, >> > scons, ... whatever the developer decided to use as the build tool)? >> > What alternatives exist short of reimplementing the build process in >> > a standard makefile by hand, which is obviously very time consuming, >> > error prone, and will probably break the next time you want to update >> > a given package? >> >> The alternative _is_ to reimplement the build process. >> >> For example, see: >> >> https://github.com/robohack/yajl/ >> >> This example is a far more comprehensive rewrite than is usually >> necessary as I wanted a complete and portable example that could be used >> as the basis for further projects. >> >> An example of a much simpler reimplementation: >> >> >> http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN >> >> -- >> Greg A. Woods <gwoods@acm.org> >> >> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> >> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> >> > [-- Attachment #2: Type: text/html, Size: 5383 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 19:59 ` Warner Losh @ 2024-06-20 20:12 ` ron minnich 2024-06-20 20:22 ` Adam Thornton ` (2 more replies) 2024-06-20 20:19 ` Clem Cole 2024-06-20 20:34 ` Luther Johnson 2 siblings, 3 replies; 160+ messages in thread From: ron minnich @ 2024-06-20 20:12 UTC (permalink / raw) To: Warner Losh; +Cc: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 4574 bytes --] The slurm configure, produced by the configure script, is 1 mbyte, 30,000 lines of impenetrable script. For each .c file in slurm, an 11960 line libtool script is invoked. autoconfig uses m4. When I told Eric Grosse, back in 2015, that *anything* still used m4, he would not believe it was "the m4 from the 70s" until I showed him. He was speechless. He had assumed m4 died in the 80s. Personally, the autoconfig process does not fill me with confidence, and it was recently responsible for a very serious security problem. And, autoconfig doesn't work: I've lost track of how many times autoconf has failed for me. In general, in my experience, autoconf makes for less portability, not more. For a good example of a very portable system with a very clean, human-readable make setup, I'd recommend a look at plan9ports. It includes 2 window managers, 2 graphical editors, and all the Plan 9 tools, and somehow manages to be at least as portable as the autoconf mechanism. On Thu, Jun 20, 2024 at 12:59 PM Warner Losh <imp@bsdimp.com> wrote: > For me, precomputing an environment is the same as a wysiwyg editor: what > you see is all you get. If it works for you, and the environment that's > inferred from predefined CPP symbols is correct, then it's an easy > solution. When it's not, and for me it often wasn't, it's nothing but pain > and suffering and saying MF all the time (also not Make File).... I was > serious when I've said I've had more positive cmake experiences (which > haven't been all that impressive: I'm more impressed with meson in this > space, for example) than I ever had with IMakefiles, imake, xmkmf, etc... > But It's also clear that different people have lived through different > hassles, and I respect that... > > I've noticed too that we're relatively homogeneous these days: Everybody > is a Linux box or Windows Box or MacOS, except for a few weird people on > the fringes (like me). It's a lot easier to get things right enough w/o > autotools, scons, meson, etc than it was in The Bad Old Days of the Unix > Wars and the Innovation Famine that followed from the late 80s to the mid > 2000s.... In that environment, there's one of two reactions: Test > Everything or Least Common Denominator. And we've seen both represented in > this thread. As well as the 'There's so few environments, can't you > precompute them all?' sentiment from newbies that never bloodied their > knuckles with some of the less like Research Unix machines out there like > AIX and HP/UX... Or worse, Eunice... > > Warner > > On Thu, Jun 20, 2024 at 12:42 PM Adam Thornton <athornton@gmail.com> > wrote: > >> >> >> Someone clearly never used imake... >> >> >> There's a reason that the xmkmf command ends in the two letters it does, >> and I'm never going to believe it's "make file". >> >> Adam >> >> On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods <woods@robohack.ca> wrote: >> >>> At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS <tuhs@tuhs.org> >>> wrote: >>> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix >>> philosophy' The Register >>> > >>> > "Greg A. Woods" <woods@robohack.ca> wrote: >>> > >>> > > I will not ever allow cmake to run, or even exist, on the machines I >>> > > control... >>> > >>> > I'm not a fan of cmake either. >>> > >>> > How do you deal with software that only builds with cmake (or meson, >>> > scons, ... whatever the developer decided to use as the build tool)? >>> > What alternatives exist short of reimplementing the build process in >>> > a standard makefile by hand, which is obviously very time consuming, >>> > error prone, and will probably break the next time you want to update >>> > a given package? >>> >>> The alternative _is_ to reimplement the build process. >>> >>> For example, see: >>> >>> https://github.com/robohack/yajl/ >>> >>> This example is a far more comprehensive rewrite than is usually >>> necessary as I wanted a complete and portable example that could be used >>> as the basis for further projects. >>> >>> An example of a much simpler reimplementation: >>> >>> >>> http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN >>> >>> -- >>> Greg A. Woods <gwoods@acm.org> >>> >>> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> >>> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> >>> >> [-- Attachment #2: Type: text/html, Size: 6794 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 20:12 ` ron minnich @ 2024-06-20 20:22 ` Adam Thornton 2024-06-20 20:29 ` ron minnich 2024-06-21 15:46 ` Chet Ramey via TUHS 2 siblings, 0 replies; 160+ messages in thread From: Adam Thornton @ 2024-06-20 20:22 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 5144 bytes --] > > In general, in my experience, autoconf makes for less portability, not > more. As an anecdotal data point, Jay Maynard has forked Hercules (S360/370/390/z Emulator) and, among other things, is ripping out 25 years of increasingly-baroque autoconf, which will probably make the build process (notoriously finicky) a whole lot clearer and easier. Adam On Thu, Jun 20, 2024 at 1:12 PM ron minnich <rminnich@gmail.com> wrote: > The slurm configure, produced by the configure script, is 1 mbyte, 30,000 > lines of impenetrable script. For each .c file in slurm, an 11960 line > libtool script is invoked. autoconfig uses m4. When I told Eric Grosse, > back in 2015, that *anything* still used m4, he would not believe it was > "the m4 from the 70s" until I showed him. He was speechless. He had assumed > m4 died in the 80s. > > Personally, the autoconfig process does not fill me with confidence, and > it was recently responsible for a very serious security problem. And, > autoconfig doesn't work: I've lost track of how many times autoconf has > failed for me. In general, in my experience, autoconf makes for less > portability, not more. > > For a good example of a very portable system with a very clean, > human-readable make setup, I'd recommend a look at plan9ports. It includes > 2 window managers, 2 graphical editors, and all the Plan 9 tools, and > somehow manages to be at least as portable as the autoconf mechanism. > > On Thu, Jun 20, 2024 at 12:59 PM Warner Losh <imp@bsdimp.com> wrote: > >> For me, precomputing an environment is the same as a wysiwyg editor: what >> you see is all you get. If it works for you, and the environment that's >> inferred from predefined CPP symbols is correct, then it's an easy >> solution. When it's not, and for me it often wasn't, it's nothing but pain >> and suffering and saying MF all the time (also not Make File).... I was >> serious when I've said I've had more positive cmake experiences (which >> haven't been all that impressive: I'm more impressed with meson in this >> space, for example) than I ever had with IMakefiles, imake, xmkmf, etc... >> But It's also clear that different people have lived through different >> hassles, and I respect that... >> >> I've noticed too that we're relatively homogeneous these days: Everybody >> is a Linux box or Windows Box or MacOS, except for a few weird people on >> the fringes (like me). It's a lot easier to get things right enough w/o >> autotools, scons, meson, etc than it was in The Bad Old Days of the Unix >> Wars and the Innovation Famine that followed from the late 80s to the mid >> 2000s.... In that environment, there's one of two reactions: Test >> Everything or Least Common Denominator. And we've seen both represented in >> this thread. As well as the 'There's so few environments, can't you >> precompute them all?' sentiment from newbies that never bloodied their >> knuckles with some of the less like Research Unix machines out there like >> AIX and HP/UX... Or worse, Eunice... >> >> Warner >> >> On Thu, Jun 20, 2024 at 12:42 PM Adam Thornton <athornton@gmail.com> >> wrote: >> >>> >>> >>> Someone clearly never used imake... >>> >>> >>> There's a reason that the xmkmf command ends in the two letters it >>> does, and I'm never going to believe it's "make file". >>> >>> Adam >>> >>> On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods <woods@robohack.ca> >>> wrote: >>> >>>> At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS < >>>> tuhs@tuhs.org> wrote: >>>> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix >>>> philosophy' The Register >>>> > >>>> > "Greg A. Woods" <woods@robohack.ca> wrote: >>>> > >>>> > > I will not ever allow cmake to run, or even exist, on the machines I >>>> > > control... >>>> > >>>> > I'm not a fan of cmake either. >>>> > >>>> > How do you deal with software that only builds with cmake (or meson, >>>> > scons, ... whatever the developer decided to use as the build tool)? >>>> > What alternatives exist short of reimplementing the build process in >>>> > a standard makefile by hand, which is obviously very time consuming, >>>> > error prone, and will probably break the next time you want to update >>>> > a given package? >>>> >>>> The alternative _is_ to reimplement the build process. >>>> >>>> For example, see: >>>> >>>> https://github.com/robohack/yajl/ >>>> >>>> This example is a far more comprehensive rewrite than is usually >>>> necessary as I wanted a complete and portable example that could be used >>>> as the basis for further projects. >>>> >>>> An example of a much simpler reimplementation: >>>> >>>> >>>> http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN >>>> >>>> -- >>>> Greg A. Woods <gwoods@acm.org> >>>> >>>> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> >>>> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> >>>> >>> [-- Attachment #2: Type: text/html, Size: 7702 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 20:12 ` ron minnich 2024-06-20 20:22 ` Adam Thornton @ 2024-06-20 20:29 ` ron minnich 2024-06-21 15:46 ` Chet Ramey via TUHS 2 siblings, 0 replies; 160+ messages in thread From: ron minnich @ 2024-06-20 20:29 UTC (permalink / raw) To: Warner Losh; +Cc: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 5138 bytes --] and, this just happened in slurm: autoreconf at top level of slurm fails with an m4 error complete with the usual incomprehensible error message. This gets old. As the saying goes, autoconf tools may be slow and buggy, but at least they're hard to use. one of the things I am grateful to Go for is that it does not suffer from this sort of nonsense. On Thu, Jun 20, 2024 at 1:12 PM ron minnich <rminnich@gmail.com> wrote: > The slurm configure, produced by the configure script, is 1 mbyte, 30,000 > lines of impenetrable script. For each .c file in slurm, an 11960 line > libtool script is invoked. autoconfig uses m4. When I told Eric Grosse, > back in 2015, that *anything* still used m4, he would not believe it was > "the m4 from the 70s" until I showed him. He was speechless. He had assumed > m4 died in the 80s. > > Personally, the autoconfig process does not fill me with confidence, and > it was recently responsible for a very serious security problem. And, > autoconfig doesn't work: I've lost track of how many times autoconf has > failed for me. In general, in my experience, autoconf makes for less > portability, not more. > > For a good example of a very portable system with a very clean, > human-readable make setup, I'd recommend a look at plan9ports. It includes > 2 window managers, 2 graphical editors, and all the Plan 9 tools, and > somehow manages to be at least as portable as the autoconf mechanism. > > On Thu, Jun 20, 2024 at 12:59 PM Warner Losh <imp@bsdimp.com> wrote: > >> For me, precomputing an environment is the same as a wysiwyg editor: what >> you see is all you get. If it works for you, and the environment that's >> inferred from predefined CPP symbols is correct, then it's an easy >> solution. When it's not, and for me it often wasn't, it's nothing but pain >> and suffering and saying MF all the time (also not Make File).... I was >> serious when I've said I've had more positive cmake experiences (which >> haven't been all that impressive: I'm more impressed with meson in this >> space, for example) than I ever had with IMakefiles, imake, xmkmf, etc... >> But It's also clear that different people have lived through different >> hassles, and I respect that... >> >> I've noticed too that we're relatively homogeneous these days: Everybody >> is a Linux box or Windows Box or MacOS, except for a few weird people on >> the fringes (like me). It's a lot easier to get things right enough w/o >> autotools, scons, meson, etc than it was in The Bad Old Days of the Unix >> Wars and the Innovation Famine that followed from the late 80s to the mid >> 2000s.... In that environment, there's one of two reactions: Test >> Everything or Least Common Denominator. And we've seen both represented in >> this thread. As well as the 'There's so few environments, can't you >> precompute them all?' sentiment from newbies that never bloodied their >> knuckles with some of the less like Research Unix machines out there like >> AIX and HP/UX... Or worse, Eunice... >> >> Warner >> >> On Thu, Jun 20, 2024 at 12:42 PM Adam Thornton <athornton@gmail.com> >> wrote: >> >>> >>> >>> Someone clearly never used imake... >>> >>> >>> There's a reason that the xmkmf command ends in the two letters it >>> does, and I'm never going to believe it's "make file". >>> >>> Adam >>> >>> On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods <woods@robohack.ca> >>> wrote: >>> >>>> At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS < >>>> tuhs@tuhs.org> wrote: >>>> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix >>>> philosophy' The Register >>>> > >>>> > "Greg A. Woods" <woods@robohack.ca> wrote: >>>> > >>>> > > I will not ever allow cmake to run, or even exist, on the machines I >>>> > > control... >>>> > >>>> > I'm not a fan of cmake either. >>>> > >>>> > How do you deal with software that only builds with cmake (or meson, >>>> > scons, ... whatever the developer decided to use as the build tool)? >>>> > What alternatives exist short of reimplementing the build process in >>>> > a standard makefile by hand, which is obviously very time consuming, >>>> > error prone, and will probably break the next time you want to update >>>> > a given package? >>>> >>>> The alternative _is_ to reimplement the build process. >>>> >>>> For example, see: >>>> >>>> https://github.com/robohack/yajl/ >>>> >>>> This example is a far more comprehensive rewrite than is usually >>>> necessary as I wanted a complete and portable example that could be used >>>> as the basis for further projects. >>>> >>>> An example of a much simpler reimplementation: >>>> >>>> >>>> http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN >>>> >>>> -- >>>> Greg A. Woods <gwoods@acm.org> >>>> >>>> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> >>>> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> >>>> >>> [-- Attachment #2: Type: text/html, Size: 7602 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 20:12 ` ron minnich 2024-06-20 20:22 ` Adam Thornton 2024-06-20 20:29 ` ron minnich @ 2024-06-21 15:46 ` Chet Ramey via TUHS 2024-06-21 16:06 ` Henry Bent 2 siblings, 1 reply; 160+ messages in thread From: Chet Ramey via TUHS @ 2024-06-21 15:46 UTC (permalink / raw) To: ron minnich, Warner Losh; +Cc: The Unix Heritage Society mailing list [-- Attachment #1.1: Type: text/plain, Size: 926 bytes --] On 6/20/24 4:12 PM, ron minnich wrote: > Personally, the autoconfig process does not fill me with confidence, and it > was recently responsible for a very serious security problem. And, > autoconfig doesn't work: I've lost track of how many times autoconf has > failed for me. In general, in my experience, autoconf makes for less > portability, not more. I'd be interested in some examples of this. I've had pretty decent success with autoconf-based portability. The one issue is cross-compiling between systems with different versions of libc (glibc vs. musl, for instance). Tools that run natively on the build platform have to be very portable, since they can't use config.h (which is for the target system). -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 203 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 15:46 ` Chet Ramey via TUHS @ 2024-06-21 16:06 ` Henry Bent 2024-06-21 16:24 ` Chet Ramey via TUHS 0 siblings, 1 reply; 160+ messages in thread From: Henry Bent @ 2024-06-21 16:06 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 1791 bytes --] On Fri, 21 Jun 2024 at 11:47, Chet Ramey via TUHS <tuhs@tuhs.org> wrote: > On 6/20/24 4:12 PM, ron minnich wrote: > > > Personally, the autoconfig process does not fill me with confidence, and > it > > was recently responsible for a very serious security problem. And, > > autoconfig doesn't work: I've lost track of how many times autoconf has > > failed for me. In general, in my experience, autoconf makes for less > > portability, not more. > > I'd be interested in some examples of this. I've had pretty decent success > with autoconf-based portability. > I think it's important to make a distinction between autotools not working and the actual software distribution not being buildable. For example, I've recently been working with Ultrix V4.5. Most configure scripts are able to complete successfully with ksh or sh5, so I don't absolutely need bash (even though I do have it and use it). The difficulties begin when trying to compile the actual code; for example, Ultrix doesn't have strdup(). Almost every autotools-based package I've used doesn't bother checking if I have strdup() and/or providing a replacement. This isn't the fault of autotools, this is the fault of the code author not considering whether a lack of strdup() is a possibility. The end result, however, is the same - I don't have a buildable release as-is. I know that Ultrix is incredibly out of date, but I use it to illustrate that while there are corner cases that autotools won't catch, that isn't the fault of autotools. It would be no different with cmake or imake or meson or handwritten makefiles or anything else - if the software author doesn't bother checking for and coding around the corner case that comes up on your particular system, you're stuck unless you can fix the code. -Henry [-- Attachment #2: Type: text/html, Size: 2265 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 16:06 ` Henry Bent @ 2024-06-21 16:24 ` Chet Ramey via TUHS 2024-06-21 16:40 ` Henry Bent 0 siblings, 1 reply; 160+ messages in thread From: Chet Ramey via TUHS @ 2024-06-21 16:24 UTC (permalink / raw) To: Henry Bent, The Unix Heritage Society mailing list [-- Attachment #1.1: Type: text/plain, Size: 2159 bytes --] On 6/21/24 12:06 PM, Henry Bent wrote: > On Fri, 21 Jun 2024 at 11:47, Chet Ramey via TUHS <tuhs@tuhs.org > <mailto:tuhs@tuhs.org>> wrote: > > On 6/20/24 4:12 PM, ron minnich wrote: > > > Personally, the autoconfig process does not fill me with confidence, > and it > > was recently responsible for a very serious security problem. And, > > autoconfig doesn't work: I've lost track of how many times autoconf has > > failed for me. In general, in my experience, autoconf makes for less > > portability, not more. > > I'd be interested in some examples of this. I've had pretty decent success > with autoconf-based portability. > > > I think it's important to make a distinction between autotools not working > and the actual software distribution not being buildable. > > For example, I've recently been working with Ultrix V4.5. Most configure > scripts are able to complete successfully with ksh or sh5, so I don't > absolutely need bash (even though I do have it and use it). The > difficulties begin when trying to compile the actual code; for example, > Ultrix doesn't have strdup(). For most projects, OS releases that ancient are not supported. It's the code author using some base minimum for assumptions -- OSs from the past 35 years or so should be safe (dating from the 4.4 BSD release, to use the strdup() example). Maybe that's the "code author not considering," but I'd say that's the result of the author simply not being interested in something that old. Bash ran on 4.3 BSD for a long time (and may still, I haven't checked with that project maintainer in a while), and I ran bash-5.0 on OPENSTEP 4.2 because I like it, but I'd say those are exceptions. I guess what I'm saying is that it's not the author's fault for not wanting to support OS versions released, for a significant percentage, before they were born. They have different priorities. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 203 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 16:24 ` Chet Ramey via TUHS @ 2024-06-21 16:40 ` Henry Bent 2024-06-21 16:52 ` Warner Losh ` (2 more replies) 0 siblings, 3 replies; 160+ messages in thread From: Henry Bent @ 2024-06-21 16:40 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 1501 bytes --] On Fri, 21 Jun 2024 at 12:24, Chet Ramey <chet.ramey@case.edu> wrote: > > For most projects, OS releases that ancient are not supported. It's the > code author using some base minimum for assumptions -- OSs from the past > 35 years or so should be safe (dating from the 4.4 BSD release, to use > the strdup() example). Maybe that's the "code author not considering," > but I'd say that's the result of the author simply not being interested > in something that old. > > Bash ran on 4.3 BSD for a long time (and may still, I haven't checked with > that project maintainer in a while), and I ran bash-5.0 on OPENSTEP 4.2 > because I like it, but I'd say those are exceptions. > > I guess what I'm saying is that it's not the author's fault for not wanting > to support OS versions released, for a significant percentage, before they > were born. They have different priorities. > > Sure, and I don't disagree. I was just using an old OS to make a point about corner cases; it would be just as applicable if I had a modern OS that for whatever reason lacked strdup(), or your personal favorite "but everyone has this!" function. You're not going to be able to cover all bases all the time, and I'm sure that there are plenty of code authors who aren't interested in formally supporting anything outside of the most common operating systems. If their autotools-based projects work on my other OS that's great, but it isn't the fault of autotools if the project isn't coded with my OS in mind. -Henry [-- Attachment #2: Type: text/html, Size: 1948 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 16:40 ` Henry Bent @ 2024-06-21 16:52 ` Warner Losh 2024-06-21 17:25 ` Chet Ramey via TUHS 2024-06-21 17:31 ` Phil Budne 2 siblings, 0 replies; 160+ messages in thread From: Warner Losh @ 2024-06-21 16:52 UTC (permalink / raw) To: Henry Bent; +Cc: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 1550 bytes --] On Fri, Jun 21, 2024 at 10:40 AM Henry Bent <henry.r.bent@gmail.com> wrote: > Sure, and I don't disagree. I was just using an old OS to make a point > about corner cases; it would be just as applicable if I had a modern OS > that for whatever reason lacked strdup(), or your personal favorite "but > everyone has this!" function. You're not going to be able to cover all > bases all the time, and I'm sure that there are plenty of code authors who > aren't interested in formally supporting anything outside of the most > common operating systems. If their autotools-based projects work on my > other OS that's great, but it isn't the fault of autotools if the project > isn't coded with my OS in mind. > Normally in modern software, "has it or not" is controlled by some pre-processor variable you can check. The problem comes in when you have under-conformant systems that claim conformance with POSiX 1-20xx, but that lack that one interface mandated by it (and one that's not controlled by some other thing... posix is super complex, for good and for ill). And you also have the edge case of "newly defined in C11" say, and the base compiler doesn't claim C11 conformance, but this function is none-the-less available. It's really really hard to know if it's there or not w/o testing for it. That even goes for "it's a linux box" since musl vs glibc has variations that you won't know about until you check. So it doesn't have to be something that should be as ubiquitous as strdup to run into issues. Warner [-- Attachment #2: Type: text/html, Size: 2048 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 16:40 ` Henry Bent 2024-06-21 16:52 ` Warner Losh @ 2024-06-21 17:25 ` Chet Ramey via TUHS 2024-06-21 17:31 ` Phil Budne 2 siblings, 0 replies; 160+ messages in thread From: Chet Ramey via TUHS @ 2024-06-21 17:25 UTC (permalink / raw) To: Henry Bent, The Unix Heritage Society mailing list [-- Attachment #1.1: Type: text/plain, Size: 420 bytes --] On 6/21/24 12:40 PM, Henry Bent wrote: > If their autotools-based projects work on my > other OS that's great, but it isn't the fault of autotools if the project > isn't coded with my OS in mind. Yep, we agree on that. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 203 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 16:40 ` Henry Bent 2024-06-21 16:52 ` Warner Losh 2024-06-21 17:25 ` Chet Ramey via TUHS @ 2024-06-21 17:31 ` Phil Budne 2024-06-21 17:55 ` Chet Ramey via TUHS 2 siblings, 1 reply; 160+ messages in thread From: Phil Budne @ 2024-06-21 17:31 UTC (permalink / raw) To: tuhs Henry Bent wrote: > On Fri, 21 Jun 2024 at 12:24, Chet Ramey <chet.ramey@case.edu> wrote: > > I guess what I'm saying is that it's not the author's fault for not wanting > > to support OS versions released, for a significant percentage, before they > > were born. They have different priorities. > If their autotools-based projects work on my > other OS that's great, but it isn't the fault of autotools if the project > isn't coded with my OS in mind. autotools isn't a magic wand for making portable apps, it's a toolkit for probing the environment to discover which alternatives are available. I'm sure it's a mysterious waste of time to those who didn't live through the Un*x wars, a time when there were multiple major things called Un*x, multiple major vendors, and available features changed frequently. Code can only be kept portable by building and testing and fixing it across all the platforms, which is time intensive, and given the closer alignment of systems nowadays doesn't get much effort. For a look at the effort I once invested in making/keeping a pet project portable look at the range of platforms I had to test on at http://ftp.regressive.org/finger/00README For a current project: https://www.regressive.org/snobol4/csnobol4/2.3/stats.html (I tested builds on Red Hat (not Enterprise!) 7.1 and FreeBSD 3.2) and https://www.regressive.org/snobol4/csnobol4/2.2/stats.html (includes OpenIndiana, a Solaris based distribution). I've never been an autotools fan; I've used it once, when I wanted to be able to build shared libraries across arbitrary platforms. I once used cpp for conditionalizing Makefiles, but that became unreliable once ANSI C hit the streets (ISTR throwing up my hands when I discovered "pee pee nums") The REAL evil of autotools is that it builds on the premise that all problems can be solved using #ifdef. I drank a different drink mix three decades ago: https://www.usenix.org/legacy/publications/library/proceedings/sa92/spencer.pdf But you're still stuck with having to discover what's available. Apache Portable Runtime or Boost are environments that try to smooth over some plaform differences (for varying values of some, depending on your needs), but that's a whole 'nuther belief system to buy into. Maybe this discussion needs to move to autoconf-haters? On the original topic, I keep imagining the systemd authors are are trying to build a monolithic system; an operating system inside an operating system that someday systemd will appear inside of. Then it will be "systemd all the way down". Followups to systemd-haters? P.S. Some earlier post complained about the complexity of writing rc.d scripts for FreeBSD; The current system only requires a script setting some variables. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 17:31 ` Phil Budne @ 2024-06-21 17:55 ` Chet Ramey via TUHS 0 siblings, 0 replies; 160+ messages in thread From: Chet Ramey via TUHS @ 2024-06-21 17:55 UTC (permalink / raw) To: Phil Budne, tuhs [-- Attachment #1.1: Type: text/plain, Size: 753 bytes --] On 6/21/24 1:31 PM, Phil Budne wrote: > The REAL evil of autotools is that it builds on the premise that > all problems can be solved using #ifdef. That's certainly the most common idiom, and one that most autotools users (including me) predominantly use, but it's not the only way. If you want to provide a larger distribution, you can use AC_REPLACE_FUNCS for things that a particular target doesn't provide and isolate the complexity there. gnulib is a big help here. Or you can provide a compatibility layer and push the complexity down to it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 203 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 19:59 ` Warner Losh 2024-06-20 20:12 ` ron minnich @ 2024-06-20 20:19 ` Clem Cole 2024-06-20 20:34 ` Luther Johnson 2 siblings, 0 replies; 160+ messages in thread From: Clem Cole @ 2024-06-20 20:19 UTC (permalink / raw) To: Warner Losh; +Cc: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 758 bytes --] On Thu, Jun 20, 2024 at 3:59 PM Warner Losh <imp@bsdimp.com> wrote: > As well as the 'There's so few environments, can't you precompute them > all?' sentiment from newbies that never bloodied their knuckles with some > of the less like Research Unix machines out there like AIX and HP/UX... Or > worse, Eunice... > Remember Henry's 10 commandments [maybe I can LA to post them in all their universities] the 10th beacons harsh here: - *Thou shalt forswear, renounce, and abjure the vile heresy which claimeth that All the world's a VAX, and have no commerce with the benighted heathens who cling to this barbarous belief, that the days of thy program may be long even though the days of thy current machine be short.* ᐧ [-- Attachment #2: Type: text/html, Size: 1685 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 19:59 ` Warner Losh 2024-06-20 20:12 ` ron minnich 2024-06-20 20:19 ` Clem Cole @ 2024-06-20 20:34 ` Luther Johnson 2024-06-20 21:00 ` ron minnich 2 siblings, 1 reply; 160+ messages in thread From: Luther Johnson @ 2024-06-20 20:34 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 6227 bytes --] I agree that there are certainly times when CMake's leverage has solved problems for people. My most visceral reactions were mostly based on cases where no tool like CMake was really required at all, but CMake had wormed its way into the consciousness of new programmers who never learned make, and thought CMake was doing them a great service. Bugged the hell out of me, this dumbing-down of the general programming population. My bad experiences were all as a consultant to teams that needed a lot of expert help, when they had thrown CMake along with a lot of other unnecessary complexity into their half-working solutions. So I guess it was all tarred by the same flavor of badly conceived work. But then as I tried to make my peace with the CMake build as it was, I got a deeper understanding of how intrinsically irrational CMake is (and again, behavior changing on the same builds depending on CMake release versions. So there certainly are times when something a little more comprehensive, outside of make, is required. ./configure && make is not so bad, it's not irrational, sometimes it's overkill, but it works ... but only if the system is kind of Unix-y. If not you may wind up doing a lot of work to pretend it's more Unix-y, so instead of porting your software, you're porting it to a common Unix-like subset, then emulating that Unix-like subset on your platform, both ends against the middle. That can be ultimately counter-productive too. I have an emotional reaction when I see the porting problem become transformed into adherence to the "one true way", be it Unix, or one build system or another. Because you're now just re-casting the problem into acceptance of that other tool or OS core as the way it should be. Instead of getting your thing to work on the other platform, by translating from what your application wants, into how to do it on whatever system, you're changing your application to be more like what the "one true system" wants to see. You've given up control of your idea of your app's core OS requirements, you've decided to "just give in and be UNiX (or Windows, or whatever)". To me, that's backwards. On 06/20/2024 12:59 PM, Warner Losh wrote: > For me, precomputing an environment is the same as a wysiwyg editor: > what you see is all you get. If it works for you, and the environment > that's inferred from predefined CPP symbols is correct, then it's an > easy solution. When it's not, and for me it often wasn't, it's nothing > but pain and suffering and saying MF all the time (also not Make > File).... I was serious when I've said I've had more positive cmake > experiences (which haven't been all that impressive: I'm more > impressed with meson in this space, for example) than I ever had with > IMakefiles, imake, xmkmf, etc... But It's also clear that different > people have lived through different hassles, and I respect that... > > I've noticed too that we're relatively homogeneous these days: > Everybody is a Linux box or Windows Box or MacOS, except for a few > weird people on the fringes (like me). It's a lot easier to get things > right enough w/o autotools, scons, meson, etc than it was in The Bad > Old Days of the Unix Wars and the Innovation Famine that followed from > the late 80s to the mid 2000s.... In that environment, there's one of > two reactions: Test Everything or Least Common Denominator. And we've > seen both represented in this thread. As well as the 'There's so few > environments, can't you precompute them all?' sentiment from newbies > that never bloodied their knuckles with some of the less like Research > Unix machines out there like AIX and HP/UX... Or worse, Eunice... > > Warner > > On Thu, Jun 20, 2024 at 12:42 PM Adam Thornton <athornton@gmail.com > <mailto:athornton@gmail.com>> wrote: > > > > Someone clearly never used imake... > > > There's a reason that the xmkmf command ends in the two letters it > does, and I'm never going to believe it's "make file". > > Adam > > On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods <woods@robohack.ca > <mailto:woods@robohack.ca>> wrote: > > At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS > <tuhs@tuhs.org <mailto:tuhs@tuhs.org>> wrote: > Subject: [TUHS] Re: Version 256 of systemd boasts '42% less > Unix philosophy' The Register > > > > "Greg A. Woods" <woods@robohack.ca > <mailto:woods@robohack.ca>> wrote: > > > > > I will not ever allow cmake to run, or even exist, on the > machines I > > > control... > > > > I'm not a fan of cmake either. > > > > How do you deal with software that only builds with cmake > (or meson, > > scons, ... whatever the developer decided to use as the > build tool)? > > What alternatives exist short of reimplementing the build > process in > > a standard makefile by hand, which is obviously very time > consuming, > > error prone, and will probably break the next time you want > to update > > a given package? > > The alternative _is_ to reimplement the build process. > > For example, see: > > https://github.com/robohack/yajl/ > > This example is a far more comprehensive rewrite than is usually > necessary as I wanted a complete and portable example that > could be used > as the basis for further projects. > > An example of a much simpler reimplementation: > > http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN > > -- > Greg A. Woods > <gwoods@acm.org <mailto:gwoods@acm.org>> > > Kelowna, BC +1 250 762-7675 RoboHack > <woods@robohack.ca <mailto:woods@robohack.ca>> > Planix, Inc. <woods@planix.com <mailto:woods@planix.com>> > Avoncote Farms <woods@avoncote.ca <mailto:woods@avoncote.ca>> > [-- Attachment #2: Type: text/html, Size: 10364 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 20:34 ` Luther Johnson @ 2024-06-20 21:00 ` ron minnich 2024-06-20 21:53 ` David Arnold ` (2 more replies) 0 siblings, 3 replies; 160+ messages in thread From: ron minnich @ 2024-06-20 21:00 UTC (permalink / raw) To: Luther Johnson; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 6594 bytes --] here's where I'd have to disagree: "./configure && make is not so bad, it's not irrational, sometimes it's overkill, but it works" because it doesn't. Work, that is. At least, for me. I'm amazed: the autoreconf step on slurm permanently broke the build, such that I am having to do a full git reset --hard and clean and start over. Even simple things fail with autoconf: see the sad story here, of how I pulled down a few simple programs, and they all fail to build. I replaced them ALL with a single Go program that was smaller, by far, than a single one of the configure scripts. https://docs.google.com/presentation/d/1d0yK7g-J6oITgE-B_odadSw3nlBWGbMK7clt_TmXo7c/edit?usp=sharing On Thu, Jun 20, 2024 at 1:35 PM Luther Johnson <luther.johnson@makerlisp.com> wrote: > I agree that there are certainly times when CMake's leverage has solved > problems for people. My most visceral reactions were mostly based on cases > where no tool like CMake was really required at all, but CMake had wormed > its way into the consciousness of new programmers who never learned make, > and thought CMake was doing them a great service. Bugged the hell out of > me, this dumbing-down of the general programming population. My bad > experiences were all as a consultant to teams that needed a lot of expert > help, when they had thrown CMake along with a lot of other unnecessary > complexity into their half-working solutions. So I guess it was all tarred > by the same flavor of badly conceived work. But then as I tried to make my > peace with the CMake build as it was, I got a deeper understanding of how > intrinsically irrational CMake is (and again, behavior changing on the same > builds depending on CMake release versions. > So there certainly are times when something a little more comprehensive, > outside of make, is required. ./configure && make is not so bad, it's not > irrational, sometimes it's overkill, but it works ... but only if the > system is kind of Unix-y. If not you may wind up doing a lot of work to > pretend it's more Unix-y, so instead of porting your software, you're > porting it to a common Unix-like subset, then emulating that Unix-like > subset on your platform, both ends against the middle. That can be > ultimately counter-productive too. > > I have an emotional reaction when I see the porting problem become > transformed into adherence to the "one true way", be it Unix, or one build > system or another. Because you're now just re-casting the problem into > acceptance of that other tool or OS core as the way it should be. Instead > of getting your thing to work on the other platform, by translating from > what your application wants, into how to do it on whatever system, you're > changing your application to be more like what the "one true system" wants > to see. You've given up control of your idea of your app's core OS > requirements, you've decided to "just give in and be UNiX (or Windows, or > whatever)". To me, that's backwards. > > On 06/20/2024 12:59 PM, Warner Losh wrote: > > For me, precomputing an environment is the same as a wysiwyg editor: what > you see is all you get. If it works for you, and the environment that's > inferred from predefined CPP symbols is correct, then it's an easy > solution. When it's not, and for me it often wasn't, it's nothing but pain > and suffering and saying MF all the time (also not Make File).... I was > serious when I've said I've had more positive cmake experiences (which > haven't been all that impressive: I'm more impressed with meson in this > space, for example) than I ever had with IMakefiles, imake, xmkmf, etc... > But It's also clear that different people have lived through different > hassles, and I respect that... > > I've noticed too that we're relatively homogeneous these days: Everybody > is a Linux box or Windows Box or MacOS, except for a few weird people on > the fringes (like me). It's a lot easier to get things right enough w/o > autotools, scons, meson, etc than it was in The Bad Old Days of the Unix > Wars and the Innovation Famine that followed from the late 80s to the mid > 2000s.... In that environment, there's one of two reactions: Test > Everything or Least Common Denominator. And we've seen both represented in > this thread. As well as the 'There's so few environments, can't you > precompute them all?' sentiment from newbies that never bloodied their > knuckles with some of the less like Research Unix machines out there like > AIX and HP/UX... Or worse, Eunice... > > Warner > > On Thu, Jun 20, 2024 at 12:42 PM Adam Thornton <athornton@gmail.com> > wrote: > >> >> >> Someone clearly never used imake... >> >> >> There's a reason that the xmkmf command ends in the two letters it does, >> and I'm never going to believe it's "make file". >> >> Adam >> >> On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods <woods@robohack.ca> wrote: >> >>> At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS <tuhs@tuhs.org> >>> wrote: >>> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix >>> philosophy' The Register >>> > >>> > "Greg A. Woods" <woods@robohack.ca> wrote: >>> > >>> > > I will not ever allow cmake to run, or even exist, on the machines I >>> > > control... >>> > >>> > I'm not a fan of cmake either. >>> > >>> > How do you deal with software that only builds with cmake (or meson, >>> > scons, ... whatever the developer decided to use as the build tool)? >>> > What alternatives exist short of reimplementing the build process in >>> > a standard makefile by hand, which is obviously very time consuming, >>> > error prone, and will probably break the next time you want to update >>> > a given package? >>> >>> The alternative _is_ to reimplement the build process. >>> >>> For example, see: >>> >>> https://github.com/robohack/yajl/ >>> >>> This example is a far more comprehensive rewrite than is usually >>> necessary as I wanted a complete and portable example that could be used >>> as the basis for further projects. >>> >>> An example of a much simpler reimplementation: >>> >>> >>> http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN >>> >>> -- >>> Greg A. Woods <gwoods@acm.org> >>> >>> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> >>> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> >>> >> > [-- Attachment #2: Type: text/html, Size: 11006 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 21:00 ` ron minnich @ 2024-06-20 21:53 ` David Arnold 2024-06-20 22:00 ` ron minnich 2024-06-20 22:35 ` Luther Johnson 2024-06-21 13:57 ` Stuff Received 2 siblings, 1 reply; 160+ messages in thread From: David Arnold @ 2024-06-20 21:53 UTC (permalink / raw) To: ron minnich; +Cc: Luther Johnson, tuhs > On 21 Jun 2024, at 07:00, ron minnich <rminnich@gmail.com> wrote: > > here's where I'd have to disagree: "./configure && make is not so bad, it's not irrational, sometimes it's overkill, but it works" > > because it doesn't. Work, that is. At least, for me. Never? Any tool can be misused (perhaps there’s an issue with slurm’s implementation here?) I think the quality of autoconf usage (by project authors) has declined, perhaps as building from source has been overtaken by the use of binary packages. I’d argue that autotools (incl automake and libtool) can be a decent solution in the hands of devs who care. At one time, I think it was the best compromise, although I’m open to argument that this time has passed. It was certainly never useful for general portability to Windows, for instance, and more recent tools manage that better. d ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 21:53 ` David Arnold @ 2024-06-20 22:00 ` ron minnich 2024-06-20 22:11 ` Larry McVoy 0 siblings, 1 reply; 160+ messages in thread From: ron minnich @ 2024-06-20 22:00 UTC (permalink / raw) To: David Arnold; +Cc: Luther Johnson, tuhs [-- Attachment #1: Type: text/plain, Size: 1378 bytes --] You're right. It's not that autoconf never works, it's that it fails so frequently that I can't trust it to work. Case in point, I just had a bunch of trouble this morning with it, with the most trivial command, and had to reset the repo to ground state to get it to build again. but compared to my experience with Go, autoconf does not compare well. On Thu, Jun 20, 2024 at 2:53 PM David Arnold <davida@pobox.com> wrote: > > > On 21 Jun 2024, at 07:00, ron minnich <rminnich@gmail.com> wrote: > > > > here's where I'd have to disagree: "./configure && make is not so bad, > it's not irrational, sometimes it's overkill, but it works" > > > > because it doesn't. Work, that is. At least, for me. > > Never? > > Any tool can be misused (perhaps there’s an issue with slurm’s > implementation here?) > > I think the quality of autoconf usage (by project authors) has declined, > perhaps as building from source has been overtaken by the use of binary > packages. > > I’d argue that autotools (incl automake and libtool) can be a decent > solution in the hands of devs who care. At one time, I think it was the > best compromise, although I’m open to argument that this time has passed. > > It was certainly never useful for general portability to Windows, for > instance, and more recent tools manage that better. > > > > > d > [-- Attachment #2: Type: text/html, Size: 1835 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 22:00 ` ron minnich @ 2024-06-20 22:11 ` Larry McVoy 0 siblings, 0 replies; 160+ messages in thread From: Larry McVoy @ 2024-06-20 22:11 UTC (permalink / raw) To: ron minnich; +Cc: Luther Johnson, tuhs On Thu, Jun 20, 2024 at 03:00:52PM -0700, ron minnich wrote: > You're right. It's not that autoconf never works, it's that it fails so > frequently that I can't trust it to work. Case in point, I just had a bunch > of trouble this morning with it, with the most trivial command, and had to > reset the repo to ground state to get it to build again. > > but compared to my experience with Go, autoconf does not compare well. This is BitKeeper's build shell. Not a lot to it. #!/bin/sh orig_args="$@" ms_env() { unset JOBS test "$MSYSBUILDENV" || { echo running in wrong environment, respawning... rm -f conf*.mk bk get -S ./update_buildenv BK_USEMSYS=1 bk sh ./update_buildenv export HOME=`bk pwd` test -d R:/build/buildenv/bin && exec R:/build/buildenv/bin/sh --login $0 $orig_args exec C:/build/buildenv/bin/sh --login $0 $orig_args } gcc --version | grep -q cyg && { echo No Mingw GCC found, I quit. exit 1 } } JOBS=-j4 while getopts j: opt do case "$opt" in j) JOBS=-j$OPTARG;; esac done shift `expr $OPTIND - 1` # ccache stuff CCLINKS=/build/cclinks CCACHEBIN=`which ccache 2>/dev/null` if [ $? = 0 -a "X$BK_NO_CCACHE" = X ] then test -d $CCLINKS || { mkdir -p $CCLINKS ln -s "$CCACHEBIN" $CCLINKS/cc ln -s "$CCACHEBIN" $CCLINKS/gcc } CCACHE_DIR=/build/.ccache # Seems like a good idea but if cache and # source are on different filesystems, setting # CCACHE_HARDLINK seems to have the same # effect as disabling the cache altogether #CCACHE_HARDLINK=1 CCACHE_UMASK=002 export CCACHE_DIR CCACHE_HARDLINK CCACHE_UMASK export PATH=$CCLINKS:$PATH else CCACHE_DISABLE=1 export CCACHE_DISABLE fi case "X`uname -s`" in XCYGWIN*|XMINGW*) ms_env; ;; esac test "$MAKE" || MAKE=`which gmake 2>/dev/null` test "$MAKE" || MAKE=make test "x$BK_VERBOSE_BUILD" != "x" && { V="V=1"; } "$MAKE" --no-print-directory $JOBS $V "$@" ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 21:00 ` ron minnich 2024-06-20 21:53 ` David Arnold @ 2024-06-20 22:35 ` Luther Johnson 2024-06-21 13:57 ` Stuff Received 2 siblings, 0 replies; 160+ messages in thread From: Luther Johnson @ 2024-06-20 22:35 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 8708 bytes --] I defer to your greater experience than mine. I guess I've run into ./configure && make in very vanilla situations, a few Gnu or Gnu-ish applications. If it has times when it doesn't work, or doesn't behave well, then I don't doubt your experience. I first entered this thread in pointing out some similarities in the style of opaque artificially pseudo intelligence behind systemd and CMake, namely, don't you decide what to do, tell about these qualities of these modules and we will decide what to do, don't worry your newbie little head. I think autoconf and configure are kind of halfway between user-decides-what to do (straight make) and user-decides-nothing, is-kept-in the-dark (CMake). So in that way, it's only half as bad. If it falls over sometimes when it shouldn't I think you know more about that then me. I will be wary. For my own code, I stick with straight make, and the occasional script. On 06/20/2024 02:00 PM, ron minnich wrote: > here's where I'd have to disagree: "./configure && make is not so bad, > it's not irrational, sometimes it's overkill, but it works" > > because it doesn't. Work, that is. At least, for me. > > I'm amazed: the autoreconf step on slurm permanently broke the build, > such that I am having to do a full git reset --hard and clean and > start over. > > Even simple things fail with autoconf: see the sad story here, of how > I pulled down a few simple programs, and they all fail to build. I > replaced them ALL with a single Go program that was smaller, by far, > than a single one of the configure scripts. > https://docs.google.com/presentation/d/1d0yK7g-J6oITgE-B_odadSw3nlBWGbMK7clt_TmXo7c/edit?usp=sharing > > On Thu, Jun 20, 2024 at 1:35 PM Luther Johnson > <luther.johnson@makerlisp.com <mailto:luther.johnson@makerlisp.com>> > wrote: > > I agree that there are certainly times when CMake's leverage has > solved problems for people. My most visceral reactions were mostly > based on cases where no tool like CMake was really required at > all, but CMake had wormed its way into the consciousness of new > programmers who never learned make, and thought CMake was doing > them a great service. Bugged the hell out of me, this dumbing-down > of the general programming population. My bad experiences were all > as a consultant to teams that needed a lot of expert help, when > they had thrown CMake along with a lot of other unnecessary > complexity into their half-working solutions. So I guess it was > all tarred by the same flavor of badly conceived work. But then as > I tried to make my peace with the CMake build as it was, I got a > deeper understanding of how intrinsically irrational CMake is (and > again, behavior changing on the same builds depending on CMake > release versions. > > So there certainly are times when something a little more > comprehensive, outside of make, is required. ./configure && make > is not so bad, it's not irrational, sometimes it's overkill, but > it works ... but only if the system is kind of Unix-y. If not you > may wind up doing a lot of work to pretend it's more Unix-y, so > instead of porting your software, you're porting it to a common > Unix-like subset, then emulating that Unix-like subset on your > platform, both ends against the middle. That can be ultimately > counter-productive too. > > I have an emotional reaction when I see the porting problem become > transformed into adherence to the "one true way", be it Unix, or > one build system or another. Because you're now just re-casting > the problem into acceptance of that other tool or OS core as the > way it should be. Instead of getting your thing to work on the > other platform, by translating from what your application wants, > into how to do it on whatever system, you're changing your > application to be more like what the "one true system" wants to > see. You've given up control of your idea of your app's core OS > requirements, you've decided to "just give in and be UNiX (or > Windows, or whatever)". To me, that's backwards. > > On 06/20/2024 12:59 PM, Warner Losh wrote: >> For me, precomputing an environment is the same as a wysiwyg >> editor: what you see is all you get. If it works for you, and the >> environment that's inferred from predefined CPP symbols is >> correct, then it's an easy solution. When it's not, and for me it >> often wasn't, it's nothing but pain and suffering and saying MF >> all the time (also not Make File).... I was serious when I've >> said I've had more positive cmake experiences (which haven't been >> all that impressive: I'm more impressed with meson in this space, >> for example) than I ever had with IMakefiles, imake, xmkmf, >> etc... But It's also clear that different people have lived >> through different hassles, and I respect that... >> >> I've noticed too that we're relatively homogeneous these days: >> Everybody is a Linux box or Windows Box or MacOS, except for a >> few weird people on the fringes (like me). It's a lot easier to >> get things right enough w/o autotools, scons, meson, etc than it >> was in The Bad Old Days of the Unix Wars and the Innovation >> Famine that followed from the late 80s to the mid 2000s.... In >> that environment, there's one of two reactions: Test Everything >> or Least Common Denominator. And we've seen both represented in >> this thread. As well as the 'There's so few environments, can't >> you precompute them all?' sentiment from newbies that never >> bloodied their knuckles with some of the less like Research Unix >> machines out there like AIX and HP/UX... Or worse, Eunice... >> >> Warner >> >> On Thu, Jun 20, 2024 at 12:42 PM Adam Thornton >> <athornton@gmail.com <mailto:athornton@gmail.com>> wrote: >> >> >> >> Someone clearly never used imake... >> >> >> There's a reason that the xmkmf command ends in the two >> letters it does, and I'm never going to believe it's "make file". >> >> Adam >> >> On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods >> <woods@robohack.ca <mailto:woods@robohack.ca>> wrote: >> >> At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS >> <tuhs@tuhs.org <mailto:tuhs@tuhs.org>> wrote: >> Subject: [TUHS] Re: Version 256 of systemd boasts '42% >> less Unix philosophy' The Register >> > >> > "Greg A. Woods" <woods@robohack.ca >> <mailto:woods@robohack.ca>> wrote: >> > >> > > I will not ever allow cmake to run, or even exist, on >> the machines I >> > > control... >> > >> > I'm not a fan of cmake either. >> > >> > How do you deal with software that only builds with >> cmake (or meson, >> > scons, ... whatever the developer decided to use as the >> build tool)? >> > What alternatives exist short of reimplementing the >> build process in >> > a standard makefile by hand, which is obviously very >> time consuming, >> > error prone, and will probably break the next time you >> want to update >> > a given package? >> >> The alternative _is_ to reimplement the build process. >> >> For example, see: >> >> https://github.com/robohack/yajl/ >> >> This example is a far more comprehensive rewrite than is >> usually >> necessary as I wanted a complete and portable example >> that could be used >> as the basis for further projects. >> >> An example of a much simpler reimplementation: >> >> http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN >> >> -- >> Greg A. Woods >> <gwoods@acm.org <mailto:gwoods@acm.org>> >> >> Kelowna, BC +1 250 762-7675 RoboHack >> <woods@robohack.ca <mailto:woods@robohack.ca>> >> Planix, Inc. <woods@planix.com <mailto:woods@planix.com>> >> Avoncote Farms <woods@avoncote.ca >> <mailto:woods@avoncote.ca>> >> > [-- Attachment #2: Type: text/html, Size: 15052 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 21:00 ` ron minnich 2024-06-20 21:53 ` David Arnold 2024-06-20 22:35 ` Luther Johnson @ 2024-06-21 13:57 ` Stuff Received 2 siblings, 0 replies; 160+ messages in thread From: Stuff Received @ 2024-06-21 13:57 UTC (permalink / raw) To: tuhs On 2024-06-20 17:00, ron minnich wrote (in part): > here's where I'd have to disagree: "./configure && make is not so bad, > it's not irrational, sometimes it's overkill, but it works" > > because it doesn't. Work, that is. At least, for me. And me. (Many configure+gmake scripts fail on Solaris 11.) S. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Version 256.1: Now slightly less likely to delete /home 2024-06-20 18:34 ` Greg A. Woods 2024-06-20 18:41 ` Adam Thornton @ 2024-06-20 19:57 ` Jim Capp 1 sibling, 0 replies; 160+ messages in thread From: Jim Capp @ 2024-06-20 19:57 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 303 bytes --] Enjoy. https://www.theregister.com/2024/06/20/systemd_2561_data_wipe_fix/ " Following closely after the release of version 256, version 256.1 fixes a handful of bugs. One of these is emphatically not systemd-tmpfiles recursively deleting your entire home directory. That's a feature." [-- Attachment #2: Type: text/html, Size: 769 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 23:28 ` Greg A. Woods 2024-06-20 5:01 ` Scot Jenkins via TUHS @ 2024-06-20 8:05 ` Steve Nickolas 1 sibling, 0 replies; 160+ messages in thread From: Steve Nickolas @ 2024-06-20 8:05 UTC (permalink / raw) To: The Unix Heritage Society mailing list So I have one program that relies on stuff that might vary from system to system. I just make use of functionality common to gmake and bmake, and expect the system to be in a reasonable state that the various detection scripts provided by the libraries work, and have "#ifdef" take care of the rest, so for most systems building the program is just "make". Works on Linux, OSX and a few other unices. I have a separate build script I use to build the Windows version. -uso. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-18 23:03 ` Warner Losh 2024-06-18 23:27 ` ron minnich 2024-06-19 1:38 ` Greg 'groggy' Lehey @ 2024-06-19 2:38 ` David Arnold 2024-06-19 22:52 ` Greg A. Woods 3 siblings, 0 replies; 160+ messages in thread From: David Arnold @ 2024-06-19 2:38 UTC (permalink / raw) To: Warner Losh; +Cc: The Unix Heritage Society mailing list > On 19 Jun 2024, at 09:03, Warner Losh <imp@bsdimp.com> wrote: > > Someone clearly never used imake... The authors of cmake? d ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-18 23:03 ` Warner Losh ` (2 preceding siblings ...) 2024-06-19 2:38 ` David Arnold @ 2024-06-19 22:52 ` Greg A. Woods 3 siblings, 0 replies; 160+ messages in thread From: Greg A. Woods @ 2024-06-19 22:52 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 1348 bytes --] At Tue, 18 Jun 2024 17:03:07 -0600, Warner Losh <imp@bsdimp.com> wrote: Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register > > [1 <text/plain; UTF-8 (quoted-printable)>] > On Tue, Jun 18, 2024, 4:50 PM Greg A. Woods <woods@robohack.ca> wrote: > > > At Tue, 18 Jun 2024 04:52:51 +0000, segaloco via TUHS <tuhs@tuhs.org> > > wrote: > > Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix > > philosophy' The Register > > > > > > That's not > > > to diminish the real help of things like autotools and CMake, > > > > Oh, that strikes a nerve. > > > > CMake is the very antithesis of a good tool. It doesn't help. I think > > it is perhaps the worst abomination EVER in the world of software tools, > > and especially amongst software construction tools. > > > > Someone clearly never used imake... Heh heh! I've grovelled deeply in the innards of X11's use of imake, but I assert that it's atrocities pale in comparison to those of cmake. At least there were real parsers and proper syntax for imake, and indeed it even built on and used other existing well known tools! -- Greg A. Woods <gwoods@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> [-- Attachment #2: OpenPGP Digital Signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-18 22:50 ` Greg A. Woods 2024-06-18 23:03 ` Warner Losh @ 2024-06-19 0:08 ` Luther Johnson 2024-06-19 0:46 ` Nevin Liber 1 sibling, 1 reply; 160+ messages in thread From: Luther Johnson @ 2024-06-19 0:08 UTC (permalink / raw) To: tuhs On 06/18/2024 03:50 PM, Greg A. Woods wrote: > At Tue, 18 Jun 2024 04:52:51 +0000, segaloco via TUHS <tuhs@tuhs.org> wrote: > Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register >> That's not >> to diminish the real help of things like autotools and CMake, > Oh, that strikes a nerve. > > CMake is the very antithesis of a good tool. It doesn't help. I think > it is perhaps the worst abomination EVER in the world of software tools, > and especially amongst software construction tools. > > -- > Greg A. Woods <gwoods@acm.org> > > Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> > Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> I agree with Greg here. In fact even if it was well done, it is declaring something that wasn't really a problem, to be a problem, to insert itself as the solution, but I think it's just extra stuff and steps that ultimately obfuscates and creates yet more dependencies. Self-serving complexity. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 0:08 ` Luther Johnson @ 2024-06-19 0:46 ` Nevin Liber 2024-06-19 1:00 ` segaloco via TUHS ` (2 more replies) 0 siblings, 3 replies; 160+ messages in thread From: Nevin Liber @ 2024-06-19 0:46 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1271 bytes --] On Tue, Jun 18, 2024 at 7:09 PM Luther Johnson <luther.johnson@makerlisp.com> wrote: > I agree with Greg here. In fact even if it was well done, it is > declaring something that wasn't really a problem, to be a problem, to > insert itself as the solution, but I think it's just extra stuff and > steps that ultimately obfuscates and creates yet more dependencies. > That's a really bold claim. You may not like the solution (I don't tend to comment on it because unlike some here, I recognize that build systems are a Hard Problem and I don't know how to make a better solution), but that doesn't mean it isn't solving real problems. But I'll bite. There was the claim by Larry McVoy that "Writing Makefiles isn't that hard". Please show these beautiful makefiles for a non-toy non-trivial product (say, something like gcc or llvm), which make it easy to change platforms, underlying compilers, works well with modern multicore processors, gets the dependencies right (one should never have to type "make clean" to get a build working correctly), etc. and doesn't require blindly running some 20K line shell script like "configure" to set it up. -- Nevin ":-)" Liber <mailto:nl <nevin@eviloverlord.com>iber@gmail.com> +1-847-691-1404 [-- Attachment #2: Type: text/html, Size: 1936 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 0:46 ` Nevin Liber @ 2024-06-19 1:00 ` segaloco via TUHS 2024-06-19 3:07 ` Luther Johnson 2024-06-19 13:28 ` Larry McVoy 2 siblings, 0 replies; 160+ messages in thread From: segaloco via TUHS @ 2024-06-19 1:00 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Tuesday, June 18th, 2024 at 5:46 PM, Nevin Liber <nliber@gmail.com> wrote: > On Tue, Jun 18, 2024 at 7:09 PM Luther Johnson <luther.johnson@makerlisp.com> wrote: > > > I agree with Greg here. In fact even if it was well done, it is > > declaring something that wasn't really a problem, to be a problem, to > > insert itself as the solution, but I think it's just extra stuff and > > steps that ultimately obfuscates and creates yet more dependencies. > > > That's a really bold claim. You may not like the solution (I don't tend to comment on it because unlike some here, I recognize that build systems are a Hard Problem and I don't know how to make a better solution), but that doesn't mean it isn't solving real problems. > > But I'll bite. There was the claim by Larry McVoy that "Writing Makefiles isn't that hard". > > Please show these beautiful makefiles for a non-toy non-trivial product (say, something like gcc or llvm), which make it easy to change platforms, underlying compilers, works well with modern multicore processors, gets the dependencies right (one should never have to type "make clean" to get a build working correctly), etc. and doesn't require blindly running some 20K line shell script like "configure" to set it up. > -- > Nevin ":-)" Liber <mailto:nliber@gmail.com> +1-847-691-1404 Not sure if this counts but technically the Linux kernel build itself is largely interfaced with via a makefile. The makefile itself may not necessarily be doing *all* the heavy lifting, but you don't start with a "./configure" this or "cmake ." that or "meson setup build" etc, you just run make to get at things like configuration, building, etc. Linux and it's various configurators do point to an alternate, albeit also more-than-a-makefile, way to do things. POSIX make's lack of conditionals for me is the main sticking point, but one solution is separate "parent" makefiles for certain conditions, with common definitions and rules being put in an include file. Then you, say, have one makefile per combination of ASFLAGS/LDFLAGS for a specific build scenario, then you can call your script that interprets conditions and calls the right makefile. You've still got a script involved, but one consisting of a handful of lines you wrote and understand well rather than oodles of generated code. Like systemd though, I think it comes down to the use-case. Most folks aren't thinking about POSIX through and through in their work probably, if they can cross-compile for various targets using one type of host machine, they only have to worry about their application, not their build system, playing by the POSIX rules. I say none of this to defend anything, especially CMake, I'm also not a fan, but it plays to the unfortunate norm out there where the build system just has to work for the author and/or high-profile contributors to a project, focusing on ensuring something will build anywhere probably isn't in most folks' immediate interest. Truth be told, the main thing that does have me focus on it is most of the stuff I work on these days is producing disassemblies of 80s/90s video games, something where the focus of the work *is* the quality of code representation, buildability, ease of modification, etc. so keeping such a thing from being tightly coupled to a specific platform does play heavily into my recent interactions with least common denominators. That and I'm nomadic with operating environments, so I don't want to paint myself into a corner where a project I'm working on is suddenly out in the rain because I bumped back to FreeBSD from Linux or out into some non-UNIX environment entirely. Sticking to POSIX make et. al. rules where possible minimizes that. - Matt G. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 0:46 ` Nevin Liber 2024-06-19 1:00 ` segaloco via TUHS @ 2024-06-19 3:07 ` Luther Johnson 2024-06-19 3:14 ` Luther Johnson 2024-06-19 9:00 ` Ralph Corderoy 2024-06-19 13:28 ` Larry McVoy 2 siblings, 2 replies; 160+ messages in thread From: Luther Johnson @ 2024-06-19 3:07 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 3464 bytes --] I don't think any makefiles I've written do all of that. I guess I don't expect all of that in one place. So i will have some makefiles that are really portable, because they are very compute-bound or their interface to the world is something else generic, like files. And then for more platform-specific parts I would have different makefiles for different platforms. One-button, one command-build (that seems) identical for all platforms, is not that important to me. And yes, sometimes I write scripts to do the parts of a build in sequence. And I don't consider any of this 'hard', but I'm not trying make the builds look like they are the same, even if they are really quite different. The GNU ./configure, make model is one model. CMake and other makefile generators are another. But I have used several compilers or other general purpose tools that have more than one makefile or build script, depending on the platform, and I just take the tool for what it is, and use it. And when I have to debug or change something about the build, it's MUCH easier to work with makefiles and build scripts than it is to extend configure scripts, or extend a build-specification in a build-tool-specific language. In my experience, so far. But some people will get into configure and/or CMake or any of the others and learn how to be productive that way. More power to them, but I don't enjoy doing that. When I have had to use CMake, it seemed to require more specification on my part to generate all sorts of crufty state, so every build was not necessarily the same, unless I used the right commands or deleted all these extra directories full of persistence from the last CMake or build, to write all these weird, generated, unreadablemakefiles calling makefiles, doing no more than I could easily do by hand in one makefile. No, my hand-written makefiles will not be absolutely universal, or appear to be, but they will work in a way I can predict, and that is of great value to me. On 06/18/2024 05:46 PM, Nevin Liber wrote: > On Tue, Jun 18, 2024 at 7:09 PM Luther Johnson > <luther.johnson@makerlisp.com <mailto:luther.johnson@makerlisp.com>> > wrote: > > I agree with Greg here. In fact even if it was well done, it is > declaring something that wasn't really a problem, to be a problem, to > insert itself as the solution, but I think it's just extra stuff and > steps that ultimately obfuscates and creates yet more dependencies. > > > That's a really bold claim. You may not like the solution (I don't > tend to comment on it because unlike some here, I recognize that build > systems are a Hard Problem and I don't know how to make a better > solution), but that doesn't mean it isn't solving real problems. > > But I'll bite. There was the claim by Larry McVoy that "Writing > Makefiles isn't that hard". > > Please show these beautiful makefiles for a non-toy non-trivial > product (say, something like gcc or llvm), which make it easy to > change platforms, underlying compilers, works well with modern > multicore processors, gets the dependencies right (one should never > have to type "make clean" to get a build working correctly), etc. and > doesn't require blindly running some 20K line shell script like > "configure" to set it up. > -- > Nevin ":-)" Liber <mailto:nl > <mailto:nevin@eviloverlord.com>iber@gmail.com > <mailto:iber@gmail.com>> +1-847-691-1404 [-- Attachment #2: Type: text/html, Size: 5128 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 3:07 ` Luther Johnson @ 2024-06-19 3:14 ` Luther Johnson 2024-06-19 3:36 ` Luther Johnson 2024-06-19 6:50 ` arnold 2024-06-19 9:00 ` Ralph Corderoy 1 sibling, 2 replies; 160+ messages in thread From: Luther Johnson @ 2024-06-19 3:14 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 3981 bytes --] To be fair, makefiles are specifications in a build-tool specific language. But it is one language I already know, and it is one that seems to be well-formed, translates to very definite actions on conditions, and I get to choose those actions. I guess it works for me if I do my part, and I can't really see what CMake does for me that I can't do for myself. On 06/18/2024 08:07 PM, Luther Johnson wrote: > > I don't think any makefiles I've written do all of that. I guess I > don't expect all of that in one place. So i will have some makefiles > that are really portable, because they are very compute-bound or their > interface to the world is something else generic, like files. And then > for more platform-specific parts I would have different makefiles for > different platforms. > > One-button, one command-build (that seems) identical for all > platforms, is not that important to me. And yes, sometimes I write > scripts to do the parts of a build in sequence. And I don't consider > any of this 'hard', but I'm not trying make the builds look like they > are the same, even if they are really quite different. The GNU > ./configure, make model is one model. CMake and other makefile > generators are another. But I have used several compilers or other > general purpose tools that have more than one makefile or build > script, depending on the platform, and I just take the tool for what > it is, and use it. And when I have to debug or change something about > the build, it's MUCH easier to work with makefiles and build scripts > than it is to extend configure scripts, or extend a > build-specification in a build-tool-specific language. In my > experience, so far. But some people will get into configure and/or > CMake or any of the others and learn how to be productive that way. > More power to them, but I don't enjoy doing that. When I have had to > use CMake, it seemed to require more specification on my part to > generate all sorts of crufty state, so every build was not necessarily > the same, unless I used the right commands or deleted all these extra > directories full of persistence from the last CMake or build, to write > all these weird, generated, unreadablemakefiles calling makefiles, > doing no more than I could easily do by hand in one makefile. No, my > hand-written makefiles will not be absolutely universal, or appear to > be, but they will work in a way I can predict, and that is of great > value to me. > > On 06/18/2024 05:46 PM, Nevin Liber wrote: >> On Tue, Jun 18, 2024 at 7:09 PM Luther Johnson >> <luther.johnson@makerlisp.com <mailto:luther.johnson@makerlisp.com>> >> wrote: >> >> I agree with Greg here. In fact even if it was well done, it is >> declaring something that wasn't really a problem, to be a problem, to >> insert itself as the solution, but I think it's just extra stuff and >> steps that ultimately obfuscates and creates yet more dependencies. >> >> >> That's a really bold claim. You may not like the solution (I don't >> tend to comment on it because unlike some here, I recognize that >> build systems are a Hard Problem and I don't know how to make a >> better solution), but that doesn't mean it isn't solving real problems. >> >> But I'll bite. There was the claim by Larry McVoy that "Writing >> Makefiles isn't that hard". >> >> Please show these beautiful makefiles for a non-toy non-trivial >> product (say, something like gcc or llvm), which make it easy to >> change platforms, underlying compilers, works well with modern >> multicore processors, gets the dependencies right (one should never >> have to type "make clean" to get a build working correctly), etc. and >> doesn't require blindly running some 20K line shell script like >> "configure" to set it up. >> -- >> Nevin ":-)" Liber <mailto:nl >> <mailto:nevin@eviloverlord.com>iber@gmail.com >> <mailto:iber@gmail.com>> +1-847-691-1404 > [-- Attachment #2: Type: text/html, Size: 6062 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 3:14 ` Luther Johnson @ 2024-06-19 3:36 ` Luther Johnson 2024-06-19 6:50 ` arnold 1 sibling, 0 replies; 160+ messages in thread From: Luther Johnson @ 2024-06-19 3:36 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 5829 bytes --] I think there is a parallel to the systemd discussion here, again. Both CMake and systemd ask you to declare properties or qualities to be ingested into the abstract model of the build or init problem, that is their worldview, and then, the 'engine' will consume that and decide what to do and how to do it. Whereas init scripts and makefiles say exactly what to do when, and the abstract model of what is to be done is in the mind of the author of the build or the init process. Makefiles and init scripts are prescriptive, Cmake and systemd input are descriptive. My problem with CMake has been that the abstract model that the CMake engine has in mind was not docmented, to my satisfaction, or I couldn't find the answers to questions I had. The 'algorithm' was not published, so to speak, or I couldn't find it. Unless I read the CMake code and can understand it well enough to predict what it will do. Maybe CMake aficionados do just that, I don't know. To me, both systemd and CMake seem much more opaque and mysterious. If I have to read the code for a tool to use it effectively, that seems wrong to me. Maybe I just haven't read the right books. Is there a 'nutshell' or similar book for CMake ? These tools seem to have more complexity, and a different mission, then /etc/rc or sysvinit scripts, or make. They are designed to solve a problem that isn't a problem to me. I expect a little bit of human attention to maintenance is required, for the actual problems I face, not all possible problems, so that I could theoretically not ever know how to solve those problems, because the tool would have done that for me. If I could only learn the dark art of that tool. On 06/18/2024 08:14 PM, Luther Johnson wrote: > > To be fair, makefiles are specifications in a build-tool specific > language. But it is one language I already know, and it is one that > seems to be well-formed, translates to very definite actions on > conditions, and I get to choose those actions. I guess it works for me > if I do my part, and I can't really see what CMake does for me that I > can't do for myself. > > On 06/18/2024 08:07 PM, Luther Johnson wrote: >> >> I don't think any makefiles I've written do all of that. I guess I >> don't expect all of that in one place. So i will have some makefiles >> that are really portable, because they are very compute-bound or >> their interface to the world is something else generic, like files. >> And then for more platform-specific parts I would have different >> makefiles for different platforms. >> >> One-button, one command-build (that seems) identical for all >> platforms, is not that important to me. And yes, sometimes I write >> scripts to do the parts of a build in sequence. And I don't consider >> any of this 'hard', but I'm not trying make the builds look like they >> are the same, even if they are really quite different. The GNU >> ./configure, make model is one model. CMake and other makefile >> generators are another. But I have used several compilers or other >> general purpose tools that have more than one makefile or build >> script, depending on the platform, and I just take the tool for what >> it is, and use it. And when I have to debug or change something about >> the build, it's MUCH easier to work with makefiles and build scripts >> than it is to extend configure scripts, or extend a >> build-specification in a build-tool-specific language. In my >> experience, so far. But some people will get into configure and/or >> CMake or any of the others and learn how to be productive that way. >> More power to them, but I don't enjoy doing that. When I have had to >> use CMake, it seemed to require more specification on my part to >> generate all sorts of crufty state, so every build was not >> necessarily the same, unless I used the right commands or deleted all >> these extra directories full of persistence from the last CMake or >> build, to write all these weird, generated, unreadablemakefiles >> calling makefiles, doing no more than I could easily do by hand in >> one makefile. No, my hand-written makefiles will not be absolutely >> universal, or appear to be, but they will work in a way I can >> predict, and that is of great value to me. >> >> On 06/18/2024 05:46 PM, Nevin Liber wrote: >>> On Tue, Jun 18, 2024 at 7:09 PM Luther Johnson >>> <luther.johnson@makerlisp.com <mailto:luther.johnson@makerlisp.com>> >>> wrote: >>> >>> I agree with Greg here. In fact even if it was well done, it is >>> declaring something that wasn't really a problem, to be a >>> problem, to >>> insert itself as the solution, but I think it's just extra stuff and >>> steps that ultimately obfuscates and creates yet more dependencies. >>> >>> >>> That's a really bold claim. You may not like the solution (I don't >>> tend to comment on it because unlike some here, I recognize that >>> build systems are a Hard Problem and I don't know how to make a >>> better solution), but that doesn't mean it isn't solving real problems. >>> >>> But I'll bite. There was the claim by Larry McVoy that "Writing >>> Makefiles isn't that hard". >>> >>> Please show these beautiful makefiles for a non-toy non-trivial >>> product (say, something like gcc or llvm), which make it easy to >>> change platforms, underlying compilers, works well with modern >>> multicore processors, gets the dependencies right (one should never >>> have to type "make clean" to get a build working correctly), etc. >>> and doesn't require blindly running some 20K line shell script like >>> "configure" to set it up. >>> -- >>> Nevin ":-)" Liber <mailto:nl >>> <mailto:nevin@eviloverlord.com>iber@gmail.com >>> <mailto:iber@gmail.com>> +1-847-691-1404 >> > [-- Attachment #2: Type: text/html, Size: 8480 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 3:14 ` Luther Johnson 2024-06-19 3:36 ` Luther Johnson @ 2024-06-19 6:50 ` arnold 2024-06-19 11:28 ` sjenkin 1 sibling, 1 reply; 160+ messages in thread From: arnold @ 2024-06-19 6:50 UTC (permalink / raw) To: tuhs, luther.johnson Luther Johnson <luther.johnson@makerlisp.com> wrote: > and I can't really see what CMake does for me that I > can't do for myself. I suspect that it's biggest advantage is that the same (set of) CMake input files can produce Makefiles, config files for Visual Studio, and also for Apple's IDE / build system. I also don't like it; it mixes system configuration with build dependencies and is ugly and hard to learn. But that's a separate issue. Arnold ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 6:50 ` arnold @ 2024-06-19 11:28 ` sjenkin 0 siblings, 0 replies; 160+ messages in thread From: sjenkin @ 2024-06-19 11:28 UTC (permalink / raw) To: TUHS [-- Attachment #1: Type: text/plain, Size: 1016 bytes --] Not responding to this email, apologies to Luther and Arnold. I’ve posted on COFF a related note on Unix Philosophy, Would appreciate comments & corrections. <https://www.tuhs.org/mailman3/hyperkitty/list/coff@tuhs.org/thread/KHQYFL6KMD3HZ73I2R6C653XWO23F72S/> > On 19 Jun 2024, at 16:50, arnold@skeeve.com wrote: > > Luther Johnson <luther.johnson@makerlisp.com> wrote: > >> and I can't really see what CMake does for me that I >> can't do for myself. > > I suspect that it's biggest advantage is that the same (set of) > CMake input files can produce Makefiles, config files for Visual > Studio, and also for Apple's IDE / build system. > > I also don't like it; it mixes system configuration with build > dependencies and is ugly and hard to learn. But that's a separate > issue. > > Arnold -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin [-- Attachment #2: Type: text/html, Size: 2315 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 3:07 ` Luther Johnson 2024-06-19 3:14 ` Luther Johnson @ 2024-06-19 9:00 ` Ralph Corderoy 1 sibling, 0 replies; 160+ messages in thread From: Ralph Corderoy @ 2024-06-19 9:00 UTC (permalink / raw) To: tuhs; +Cc: Eric S. Raymond Hi, Luther Johnson: > And when I have to debug or change something about the build, it's > MUCH easier to work with makefiles and build scripts than it is to > extend configure scripts, or extend a build-specification in > a build-tool-specific language. In my experience, so far. Eric Raymond recently started autodafe which chews over autotools' inputs and outputs to simplify its use or help move away from it to an editable makefile. https://gitlab.com/esr/autodafe/-/blob/master/README.adoc -- Cheers, Ralph. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 0:46 ` Nevin Liber 2024-06-19 1:00 ` segaloco via TUHS 2024-06-19 3:07 ` Luther Johnson @ 2024-06-19 13:28 ` Larry McVoy 2024-06-19 14:44 ` Warner Losh 2024-06-19 15:59 ` Theodore Ts'o 2 siblings, 2 replies; 160+ messages in thread From: Larry McVoy @ 2024-06-19 13:28 UTC (permalink / raw) To: Nevin Liber; +Cc: The Eunuchs Hysterical Society On Tue, Jun 18, 2024 at 07:46:15PM -0500, Nevin Liber wrote: > But I'll bite. There was the claim by Larry McVoy that "Writing Makefiles > isn't that hard". > > Please show these beautiful makefiles for a non-toy non-trivial product Works on *BSD, MacOS, Windows, Linux on a bunch of different architectures, Solaris, HPUX, AIX, IRIX, Tru64, etc. # Copyright 1999-2016 BitMover, Inc # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # http://www.apache.org/licenses/LICENSE-2.0 # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # Makefile for BitKeeper. # Bitmover makefiles try to provide the following targets: # # all build everything under the current directory # # clean remove all objects and programs # # clobber run clean plus 'bk -r. clean' # # srcs bk get all sources in current directory # # tags build ctags for all srcs (only needed in this (top) makefile) # # tags.local build ctags for srcs under current directory relative to top # #--- # Special make variables commonly used this makefile: # $@ target # $^ all sources # $< first source INSTALLED_BK ?= $(shell bash -c "cd / && command -v bk") INREPO ?= $(shell bash -c "test -d ../.bk && echo true || echo false") HERE := $(shell pwd) ROOT := $(shell dirname $(HERE)) REPO := $(notdir $(ROOT)) URL := $(shell echo bk://work/$(ROOT) | sed s,/home/bk/,,) LOG = $(shell echo LOG-`bk getuser`) OSTYPE := $(shell bash -c 'echo $$OSTYPE') include conf.mk ## Which hosts are used for producing nightly builds NIGHTLY_HOSTS := macos106 win7-vm debian40 debian40-64 ifeq "$(OSTYPE)" "msys" SYS=win32 EXE=.exe XTRA=win32 ifeq (,$(INSTALLED_BK)) # BINDIR should really be :C:/Program Files/BitKeeper # The shell can not handle space in pathname, so # we use the short name here BINDIR := "C:/PROGRA~1/BITKEE~1" else BINDIR := $(shell bk pwd -s "`bk _registry get 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion' ProgramFilesDir`/BitKeeper") endif INSTALL=installdir RESOURCE=bkres.o UWT_C=$(patsubst %,win32/uwtlib/%.c, wapi_intf wcrt_intf) BKGUI=bkg$(EXE) BKG_O=bkg.o else SYS=unix EXE= # You can set this to anywhere you like and do a # build production" and you'll have an installed BitKeeper. ifeq (,$(INSTALLED_BK)) BINDIR := /usr/local/bitkeeper else BINDIR := $(shell "$(INSTALLED_BK)" bin) endif INSTALL=install RESOURCE= endif # By default, we don't print verbose output. If you want to see # the full compiler command line, use 'make V=1' # The trick is to do "$(Q)$(CC)" instead of just "$(CC)" so that if # Q is not set, it's just "$(CC)" and if Q is set to @ it becomes # a quiet "@$(CC)". # For the verbose messages, gmake provides # $(if $(Q),<then>,<else>) # so we just conditionalize on Q. Empty is false. ifndef V Q=@ export Q endif BK=./bk$(EXE) G =-g TRIAL =0 IMGDIR =$(HERE)/tmp/bitkeeper # Handle warning arguments in GCC # # -Wall enables a bunch of warnings by default # -Wno-parentheses shuts up "suggest parentheses around assignment ...". # Unfortunately it also turns off dangling else warnings. # -Wno-char-subscripts shuts up "subscript has type char", which comes # up all the time with broken <ctype.h> implementations. # (renabled in GCC3 since it supresses warnings in system files by default) # -Wno-format-y2k supresses complains about '%y' in strftime formats # -Wstrict-prototypes Don't allow non-ansi function declarations WARNINGS=-Wall -Wno-parentheses -Wno-char-subscripts -Wno-format-y2k \ -Wstrict-prototypes # Warnings enabled with GCC newer than 3.0 # # -Wredundant-decls Declaring same function twice # -Wmissing-declarations Functions without a prototype WARNINGS_GCC3=-Wchar-subscripts -Wredundant-decls -Wmissing-declarations # Warnings enabled with GCC newer than 4.0 # # -Wextra enable a bunch of random things (called -Wextra in newer gccs) # -Wno-pointer-sign Suppress warnings about changing the signs of pointers # -Wno-sign-compare Suppress warnings about comparing signed and unsigned vars # -Wno-unsed-parameter Support warnings about function parameters that are # no used # -Wno-missing-field-initializers # -Wdeclaration-after-statement Warn if someone does a C++ thing of declaring # a variable in the middle of a block WARNINGS_GCC4=-Wextra -Wno-pointer-sign -Wno-sign-compare \ -Wno-unused-parameter -Wno-missing-field-initializers \ -Wdeclaration-after-statement -Wpointer-arith # Warnings enabled with GCC newer than 5.0 # # -Wno-unusedr-esult Do not warn if a caller ignores return value WARNINGS_GCC5=-Wno-unused-result WARNINGS_GCC6= -Wno-misleading-indentation # XXX could not get -Wimplicit-fallthrough=3 to work WARNINGS_GCC7= -Wno-implicit-fallthrough # Other options to consider enabling in the future: # # -Wnested-externs Prototypes declared in a function # -Wwrite-string warn in string constant is passed to a char * # -Wmissing-prototypes # -Wunused-parameter # -Wold-style-definition Would be nice, but zlib falls all over here GCC_MAJOR_REV=$(shell $(CC) -dumpversion | sed 's/\..*//') GCC_MINOR_REV=$(shell $(CC) -dumpversion | sed 's/.*\.//') ifeq ($(GCC_MAJOR_REV),3) WARNINGS += $(WARNINGS_GCC3) endif ifeq ($(GCC_MAJOR_REV),4) WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) ifeq ($(shell expr $(GCC_MINOR_REV) \> 5), 1) WARNINGS += -Wno-unused-result endif endif ifeq ($(GCC_MAJOR_REV),5) WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5) endif ifeq ($(GCC_MAJOR_REV),6) WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5) \ $(WARNINGS_GCC6) endif ifeq ($(GCC_MAJOR_REV),7) WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5) \ $(WARNINGS_GCC6) $(WARNINGS_GCC7) endif ifeq ($(GCC_MAJOR_REV),8) WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5) \ $(WARNINGS_GCC6) $(WARNINGS_GCC7) $(WARNINGS_GCC8) endif TRACE = -DUSE_TRACE ifeq ($(shell uname -s), Darwin) XLIBS += -lresolv G += -DNOPROC endif ifeq (clang, $(findstring clang, $(shell $(CC) --version))) WARNINGS += -Wno-unused-value -Wno-empty-body -Wno-self-assign endif GCCOPTS= CC_DEBUG=$(GCCOPTS) $G $(WARNINGS) $(TRACE) CC_FAST_DEBUG=$(GCCOPTS) $G -O2 $(WARNINGS) $(TRACE) CC_FAST =$(CC_FAST_DEBUG) CC_WALL=$(GCCOPTS) $G -DLINT $(WARNINGS) $(TRACE) BINS = $(BK) $(BKGUI) # List of all objects in bk other than bk.o. Keep it sorted. # But put bkver.o/cmd.o first, they generate headers. OBJ = bkver.o cmd.o \ abort.o adler32.o alias.o admin.o annotate.o attributes.o \ bam.o bisect.o bkd.o bkd_bam.o bkd_cd.o \ bkd_changes.o bkd_client.o bkd_clone.o bkd_cmdtab.o \ bkd_findkey.o bkd_http.o \ bkd_id.o bkd_kill.o bkd_level.o bkd_misc.o bkd_nested.o \ bkd_partition.o bkd_pull.o bkd_push.o bkd_pwd.o \ bkd_r2c.o \ bkd_rclone.o bkd_rootkey.o bkd_status.o bkd_synckeys.o bkd_version.o \ bkverinfo.o \ cat.o cfile.o changes.o config.o \ check.o checksum.o clean.o cleanpath.o clone.o \ cmdlog.o \ collapse.o comment.o comments.o commit.o comps.o compress.o \ contrib/cat.o \ contrib/test.o \ converge.o \ cp.o \ crypto.o \ cset.o cset_inex.o csetprune.o csets.o cweave.o \ dataheap.o dbfile.o delta.o diff.o dspec.o \ export.o \ fast-import.o fast-export.o features.o findmerge.o \ find.o findcset.o fixtool.o fsl.o fslayer.o \ g2bk.o gca.o get.o gethelp.o \ gethost.o gettemp.o getuser.o gfiles.o glob.o \ gnupatch.o graft.o grep.o \ hash_nokey.o \ heapdump.o help.o here.o here_check.o hostme.o http.o \ idcache.o isascii.o info.o \ key2rev.o key2path.o kill.o kv.o \ libcommit.o libdiff.o libgraph.o librange.o \ libsfiles.o lines.o \ localtm.o lock.o locking.o \ mail.o merge.o mklock.o \ mailslot.o \ mtime.o mv.o names.o ndiff.o nested.o newroot.o \ opark.o \ parent.o park.o partition.o \ patch.o \ pending.o preference.o proj.o \ poly.o \ populate.o \ port/bkd_server.o \ port/check_rsh.o \ port/gethomedir.o \ port/gethost.o port/getinput.o \ port/getrealname.o port/getrusage.o port/globalroot.o port/gui.o \ port/hostColonPath.o port/http_proxy.o \ port/mail.o port/mnext.o port/networkfs.o \ port/notifier.o port/ns_sock_host2ip.o port/platforminit.o \ port/sccs_getuser.o port/sccs_lockfile.o \ port/startmenu.o \ port/svcinfo.o \ port/uninstall.o \ progress.o \ prs.o pull.o push.o pwd.o \ randombits.o randseed.o range.o rcheck.o rclone.o \ rcs2bk.o rcsparse.o \ receive.o redblack.o regex.o registry.o renumber.o \ remap.o remote.o \ repo.o repos.o repogca.o repostats.o repotype.o \ resolve.o resolve_binaries.o resolve_contents.o \ resolve_create.o resolve_filetypes.o \ resolve_flags.o resolve_generic.o resolve_modes.o \ resolve_renames.o resolve_tags.o restore.o review.o \ rm.o rmdel.o rmgone.o \ root.o rset.o sane.o scat.o sccs.o sccs2bk.o \ sccslog.o sccs_mv.o search.o sec2hms.o send.o sendbug.o \ set.o setup.o sfio.o shrink.o sinfo.o \ slib.o smerge.o sort.o startmenu.o \ stat.o stattest.o status.o stripdel.o synckeys.o \ tagmerge.o testcode.o tclsh.o takepatch.o \ testdates.o time.o timestamp.o touch.o trigger.o \ unbk.o undo.o undos.o unedit.o \ unique.o uninstall.o unlink.o unlock.o unpull.o unrm.o unwrap.o upgrade.o \ urlinfo.o \ utils.o uu.o what.o which.o \ xfile.o xflags.o \ zone.o SCRIPTS = bk.script import \ uuwrap unuuwrap gzip_uuwrap ungzip_uuwrap \ b64wrap unb64wrap gzip_b64wrap ungzip_b64wrap PSCR = t/doit t/guitest PROGS = libc/mtst$(EXE) LIBS = libc/libc.a DATA = bkmsg.txt bkhelp.txt version \ ../doc/bk_refcard.ps ../doc/bk_refcard.pdf ../RELEASE-NOTES.md \ dspec-changes dspec-changes-3.2 dspec-changes-4.0 dspec-changes-h \ dspec-changes-hv dspec-changes-json dspec-changes-json-v \ dspec-changes-vv dspec-log dspec-prs CONTRIB = gui/ide/emacs/vc-bk.el contrib/git2bk.l ALL = PCRE $(LIBS) $(BINS) $(SCRIPTS) $(PSCR) $(XTRA) \ $(PROGS) L-clean GUI L-doc $(DATA) CFLAGS = $(CC_DEBUG) export CFLAGS CPPFLAGS= -Ilibc $(TOMCRYPT_CPPFLAGS) $(TOMMATH_CPPFLAGS) \ $(PCRE_CPPFLAGS) $(LZ4_CPPFLAGS) $(ZLIB_CPPFLAGS) # Override this if you don't have it. RANLIB = ranlib # list of C sources in bk SRCS = bk.c $(OBJ:.o=.c) # list of headers in bk HDRS = bam.h bkd.h bk-features.h config.h configvars.def diff.h fsfuncs.h \ graph.h nested.h \ progress.h range.h rcs.h resolve.h sccs.h \ cmd.h poly.h proj.h redblack.h libc/system.h xfile.h # list of non-C sources in bk SCRSRCS = bk.sh import.sh kwextract.pl uuwrap.sh unuuwrap.sh \ port/unix_platform.sh port/win32_platform.sh \ gzip_uuwrap.sh ungzip_uuwrap.sh \ substvars.sh b64wrap.sh gzip_b64wrap.sh \ unb64wrap.sh ungzip_b64wrap.sh MISC = bkmsg.doc t/doit.sh default: $(MAKE) p SUBDIRS = libc $(shell ls -d tomcrypt tommath 2>/dev/null) all: $(ALL) prof: $(MAKE) CFLAGS="$G -pg -O2" LDFLAGS=-pg all gprof: $(MAKE) CFLAGS="$G -DPROFILE -pg -O2" LDFLAGS=-pg all ggprof: $(MAKE) CFLAGS="$G -DPROFILE -pg" LDFLAGS=-pg all # Debugging... d: $(MAKE) CFLAGS="$G -DDEBUG" all debug: $(MAKE) CFLAGS="$G -DDEBUG" all debug2: $(MAKE) CFLAGS="$G -DDEBUG2" all gWall Wall: $(MAKE) CFLAGS="$(CC_WALL)" all # production builds p: ## Build a production version of BitKeeper (no -g) $(MAKE) CFLAGS="$(CC_FAST) $(CF)" all trial: $(MAKE) TRIAL="3*WEEK" CFLAGS="$(CC_FAST) $(CF)" all trial3M: $(MAKE) TRIAL="3*MONTH" CFLAGS="$(CC_FAST) $(CF)" all g: ## Build a debug version of BitKeeper (-g) $(MAKE) CFLAGS="$(CC_DEBUG)" all gO: $(MAKE) CFLAGS="$(CC_FAST_DEBUG)" all gcov: $(MAKE) CFLAGS="$(CC_DEBUG) -fprofile-arcs -ftest-coverage" all clean: L-clean FORCE ## Remove object files and executables $(if $(Q),@echo Cleaning up,) $(Q)for sub in $(SUBDIRS) ../doc ../man gui utils win32 t t/win32; \ do $(MAKE) -C$$sub "CFLAGS=$(CFLAGS)" $@; \ done $(Q)$(RM) $(OBJ) bk.o $(BKG_O) $(BINS) $(SCRIPTS) \ $(PSRC) $(PROGS) $(Q)$(RM) tags TAGS tags.local cscope.out substvars a.out cmd.c cmd.h \ core *.bb *.bbg *.da *.gcov \ bk.ico \ bkmsg.txt bkhelp.txt bkver.c version \ t/doit t/guitest kw2val_lookup.c bkres.o svcmgr.exe \ conf.mk $(Q)$(RM) -r tmp ifeq "$(OSTYPE)" "msys" $(Q)$(RM) -rf gnu/bin gnu/doc gnu/etc gnu/share $(Q)$(RM) -f gnu/m.ico gnu/msys.bat gnu/msys.ico $(Q)-rmdir gnu/tmp $(Q)-rmdir gnu endif ifeq (true,$(INREPO)) ifneq (,$(INSTALLED_BK)) $(Q)EXTRALIST=`"$(INSTALLED_BK)" -Aax | \ grep -v '~$$\|conf-.*\.mk$$'` ; \ if [ "$$EXTRALIST" ]; then \ echo "Clean left behind the following files:" ; \ for file in $$EXTRALIST; do \ echo " $$file" ; \ done ; \ else \ echo Clean complete ; \ fi endif endif clobber: clean FORCE ## Same as 'clean' but also bk clean files -@$(BK) -A clean # XXX subdirs? (see tags) wc: $(HDRS) $(SRCS) $(SCRSRCS) $(MISC) wc -l $(SRCS) $(HDRS) $(SCRSRCS) $(MISC) get-e: FORCE -@$(BK) edit -qT `echo $(HDRS) $(SRCS) $(SCRSRCS) $(MISC) | fmt -1|sort -u` $(Q)$(MAKE) tags srcs: $(SRCS) $(HDRS) FORCE $(Q)for sub in $(SUBDIRS); do $(BK) -r$$sub co -q; done tags: $(patsubst %,%/tags.local, $(SUBDIRS)) tags.local @if [ -x $(BK) ]; \ then $(BK) get -Sq tags.skippats; \ $(BK) _sort -u $^ | grep -v -ftags.skippats > $@; \ else \ bk get -Sq tags.skippats; \ bk _sort -u $^ | grep -v -ftags.skippats > $@; \ fi @echo ctags completed tags.local: $(SRCS) $(HDRS) @ctags -f $@ --file-tags=yes --c-types=d+f+s+t $^ %/tags.local: FORCE $(Q)$(MAKE) -C $(dir $@) tags.local ssh sshtest: $(MAKE) realtest rsh rshtest: PREFER_RSH=YES $(MAKE) realtest test tests: DO_REMOTE=NO $(MAKE) -C t nonet nonet_test localtest: BK_NONET=YES PREFER_RSH=YES $(MAKE) realtest realtest: $(ALL) t/doit -cd gui/tcltk && $(MAKE) clobber -$(BK) get -qS t/setup t/win32/win32_common $(BK) -rt get -qTS 't.*' cd t && ./doit -f 5 guitest: $(ALL) t/doit -$(BK) get -qS t/SCCS/s.g.* t/setup t/win32/win32_common t/guitest.tcl cd t && ./doit -g -i t/doit: t/doit.sh substvars ./substvars t/doit.sh > t/doit chmod +x t/doit t/guitest: t/guitest.tcl cat < t/guitest.tcl > t/guitest .PHONY: FORCE FORCE: win32: FORCE cd win32 && $(MAKE) BINDIR=$(BINDIR) cd t/win32 && $(MAKE) # build libraries in sub directories %.a: FORCE $(Q)$(MAKE) -C $(dir $@) $(notdir $@) libc/mtst$(EXE): libc/libc.a FORCE $(Q)$(MAKE) -C libc mtst$(EXE) bkres.o: win32/data/bk.rc bk.ico windres -i win32/data/bk.rc -o bkres.o bk.ico: win32/data/bk.ico @cp -f win32/data/bk.ico . ifneq ($(TOMCRYPT_SYSTEM),1) # add dependency on building libraries first $(BK): $(TOMCRYPT_LDFLAGS) endif ifneq ($(TOMMATH_SYSTEM),1) # add dependency on building libraries first $(BK): $(TOMMATH_LDFLAGS) endif $(BK): $(LIBS) bk.o $(RESOURCE) $(OBJ) $(if $(Q),@echo LINKING $(BK),) $(Q)$(LD) $(LDFLAGS) -o $@ bk.o $(OBJ) $(RESOURCE) $(LIBS) \ $(TOMCRYPT_LDFLAGS) $(TOMMATH_LDFLAGS) \ $(PCRE_LDFLAGS) $(LZ4_LDFLAGS) $(ZLIB_LDFLAGS) $(XLIBS) # Windows only rule, BKGUI should be blank on other platforms $(BKGUI): bkg.o $(RESOURCE) $(if $(Q),@echo LINKING $(BKGUI),) $(Q)$(LD) $(LDFLAGS) -o $@ bkg.o $(RESOURCE) -Llibc -lc -mwindows $(XLIBS) bk.script: bk.sh port/$(SYS)_platform.sh cat port/$(SYS)_platform.sh bk.sh > bk.script chmod +x bk.script bkmsg.txt: bkmsg.doc cp -f $< $@ L-clean: FORCE @rm -f gui/share/doc/L/little.man ../man/man1/bk-little.1 @rm -f ../man/man2help/bk-little-1.fmt # has to run before bkhelp.txt but after GUI L-doc L-docs: GUI FORCE @test -f gui/share/doc/L/little.man || { \ echo Failed to build gui/share/doc/L/little.man; \ exit 1; \ } @if [ -s gui/share/doc/L/little.man ]; \ then cp gui/share/doc/L/little.man ../man/man1/bk-little.1; \ else cp ../man/man1/bk-little.1.pfmt ../man/man1/bk-little.1; \ fi; \ chmod +w ../man/man1/bk-little.1 bkhelp.txt: $(BK) version L-docs FORCE @rm -f ../man/man2help/bk-little.fmt @cd ../man/man2help && $(MAKE) BK=$(HERE)/bk$(EXE) helptxt @cp ../man/man2help/helptxt bkhelp.txt @rm -f ../man/man1/bk-little.1 html-docs: bkhelp.txt @cd ../man/man2html && $(MAKE) ../doc/bk_refcard.ps: $(BK) FORCE $(Q)echo building $@ $(Q)-$(BK) -r../doc co -qS $(Q)$(MAKE) -C ../doc BK=$(HERE)/bk$(EXE) all ../doc/bk_refcard.pdf: ../doc/bk_refcard.ps # This must be rebuilt every time because it includes the build time bkver.c: utils/bk_version FORCE $(if $(Q),@echo Building $@,) $(Q)echo "#include \"sccs.h\"" > bk.v $(Q)echo "char *bk_platform = \""`./utils/bk_version`"\";" >> bk.v $(Q)echo "int test_release = "$(TRIAL)";" >> bk.v $(Q)echo "time_t bk_build_timet = "`perl -e "print time"`";" >> bk.v $(Q)echo "char *bk_build_dir = \""`pwd`"\";" >> bk.v $(Q)mv -f bk.v bkver.c version: version.sh $(BK) utils/bk_version GUI FORCE bash version.sh > $@ %: %.sh $(if $(Q),@echo Building $@,) $(Q)$(RM) $@ $(Q)cp $< $@ $(Q)chmod +x $@ %: %.l $(if $(Q),@echo Not lexing $@,) import: import.sh port/$(SYS)_platform.sh cat port/$(SYS)_platform.sh import.sh > import.T chmod +x import.T mv -f import.T import # Quick and dirty target so we can make all the gui tools without the rest .PHONY: GUI GUI: PCRE $(BK) @$(MAKE) -Cgui BK=$(HERE)/bk$(EXE) gui install: installdir tmp/bitkeeper/bk _install -d -f $(DESTDIR)$(BINDIR) @echo BitKeeper is installed in $(BINDIR) @echo We suggest you run: @echo @echo sudo $(BINDIR)/bk links /usr/local/bin @echo @echo to create the bk symlink. installdir: utils/registry.tcl rm -rf $(IMGDIR) || exit 1 mkdir -p $(IMGDIR)/contrib mkdir -p $(IMGDIR)/lscripts -$(BK) -rwww get -S -cp -f -r www $(IMGDIR) -$(BK) get -S $(CONTRIB) tar cf - $(BINS) $(SCRIPTS) lscripts gui/bin gui/lib gui/images \ | (cd $(IMGDIR) && tar xf -) cp -f $(DATA) $(IMGDIR) cp -f $(CONTRIB) $(IMGDIR)/contrib (cd ../doc/nested && $(MAKE) install HTML=$(IMGDIR)/html) if [ $(SYS) = unix ]; \ then $(BK) get -S ../man/Makefile; \ cd ../man && $(MAKE) install BINDIR=$(IMGDIR) ;\ else \ (cd win32 && $(MAKE) BINDIR=$(IMGDIR) install); \ cp utils/registry.tcl $(IMGDIR)/gui/lib; \ fi cd $(IMGDIR); \ find . -type l | \ perl -ne 'chomp; $$a = readlink; print "$$a|$$_\n";'>symlinks; \ test -s symlinks || rm -f symlinks @true image: ## Build the installer (left in src/utils/bk-*) $(MAKE) p $(MAKE) _image _image: $(MAKE) installdir ${MAKE} -Cutils BINDIR=$(IMGDIR) "CC=$(CC)" "BK=$(HERE)/bk$(EXE)" "CFLAGS=$(CFLAGS)" image crankturn: crank.sh remote.sh ## Run a clean-build + regressions in cluster REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh cranksave: crank.sh remote.sh ## Run a crankturn but save the built images REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh save crankstatus: crank.sh remote.sh ## See how the crank is going REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh status crankrelease nightly: $(BK) crank.sh remote.sh ## Do a BitKeeper release (or nightly build) @(TAG=$(shell $(BK) changes -r+ -d:TAG:) ; \ test x$$TAG = x && { \ echo Cannot crankrelease with a non-tagged tip ; \ exit 1 ; \ } ; \ case $@ in \ crankrelease ) \ TYPE=release; DIR=/home/bk/images/$$TAG; \ ;; \ nightly ) \ TYPE=nightly; DIR=/home/bk/images/nightly; \ HOSTS="$(NIGHTLY_HOSTS)" ; \ ;; \ esac ; \ test -d $$DIR || mkdir -p $$DIR ; \ REPO=$(REPO) URL=$(URL) HOSTS=$$HOSTS REMOTE=remote.sh \ LOG=$(LOG) bash crank.sh $$TYPE ; \ $(BK) -R get -qS ../RELEASE-NOTES.md ; \ cp ../RELEASE-NOTES.md $$DIR ; \ SAVED_WD=$(shell pwd) ; \ cd $$DIR && chmod +rx bk-* >/dev/null 2>&1 ; \ rm -f MD5SUMS ; \ md5sum bk-* >> MD5SUMS ; \ echo "Your images are in $$DIR" ; \ case $@ in \ crankrelease ) \ echo "Run './mkrelease $$TAG' to release this version of bk."; \ ;; \ nightly ) \ # cd $$SAVED_WD ; \ # ./mkupgrades --nightly $$TAG ; \ ;; \ esac) crankclean: crank.sh remote.sh REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh clean # This target assumes a bk repository .PHONY: src-tar src-tar: $(BK) version ## build tar.gz image for the current tree ifeq (false,$(INREPO)) $(error This target only works in a BK source repository) else ./bk here add default TCLTK $(Q)-mkdir -p tmp/src $(Q)(DIR=bk-$(shell $(BK) version -s) ; \ TAR="$$DIR".tar.gz ; \ echo "Creating $$TAR in tmp/src..." ; \ cd tmp/src ; \ rm -rf "$$DIR" ; \ ../../bk export -tplain -kwr+ -sdefault -sTCLTK "$$DIR" ; \ cat ../../version > "$$DIR/src/bkvers.txt" ; \ tar -czf "$$TAR" "$$DIR" ; \ rm -rf "$$DIR" ; \ echo Done ; \ ) endif # only depend on conf.mk.local if it exists conf.mk: mkconf.sh $(wildcard conf.mk.local) sh mkconf.sh > $@ || { $(RM) $@; false; } %.o: %.c $(if $(Q),@echo CC $<,) $(Q)$(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $@ port/startmenu.o: port/startmenu.c $(HDRS) $(if $(Q),@echo CC $<,) $(Q)$(CC) $(CFLAGS) -fno-strict-aliasing $(CPPFLAGS) -c $< -o $@ depend: $(SRCS) $(CC) -MM -MG -D_DEPEND $(SRCS) > depends # for system.h we need to actually run libc's makefile because it includes # calculated header files libc/system.h: FORCE $(MAKE) -C libc system.h libc/libc.a: libc/system.h sccs.h: PCRE .PHONY: PCRE PCRE: ifneq ($(PCRE_SYSTEM),1) $(MAKE) -Cgui/tcltk pcre endif $(OBJ) bk.o: $(HDRS) cmd.c cmd.h: cmd.pl bk.sh $(filter bkd_%,$(SRCS)) $(if $(Q),@echo Building $@,) $(Q)perl cmd.pl || (rm -f cmd.c cmd.h; exit 1) # This parses slib.c and extracts the meta-data keywords expanded # by kw2val() and passes them to gperf to generate hash lookup code. slib.o: kw2val_lookup.c kw2val_lookup.c: slib.c kw2val.pl $(if $(Q),@echo Building $@,) $(Q)perl kw2val.pl slib.c || (rm -f kw2val_lookup.c; exit 1) check-syntax: $(CC) $(CFLAGS) $(CPPFLAGS) -c -S ${CHK_SOURCES} -o /dev/null # print a make variable 'make print-REPO' # http://www.cmcrossroads.com/article/printing-value-makefile-variable print-%: @echo $* = \"$($*)\" .PHONY: help help: @grep -E -h '^[-a-zA-Z_\ ]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}' @echo Suggested: make -j12 image ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 13:28 ` Larry McVoy @ 2024-06-19 14:44 ` Warner Losh 2024-06-19 14:53 ` Larry McVoy 2024-06-19 15:59 ` Theodore Ts'o 1 sibling, 1 reply; 160+ messages in thread From: Warner Losh @ 2024-06-19 14:44 UTC (permalink / raw) To: Larry McVoy; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 27639 bytes --] On Wed, Jun 19, 2024, 7:28 AM Larry McVoy <lm@mcvoy.com> wrote: > On Tue, Jun 18, 2024 at 07:46:15PM -0500, Nevin Liber wrote: > > But I'll bite. There was the claim by Larry McVoy that "Writing > Makefiles > > isn't that hard". > > > > Please show these beautiful makefiles for a non-toy non-trivial product > > Works on *BSD, MacOS, Windows, Linux on a bunch of different architectures, > Solaris, HPUX, AIX, IRIX, Tru64, etc. > The posted Makefile is no a strictly conforming POSIX Makefile, but uses gmake extensions extensively... And eyes of the beholder may vary... Warner # Copyright 1999-2016 BitMover, Inc > > # Licensed under the Apache License, Version 2.0 (the "License"); > # you may not use this file except in compliance with the License. > # You may obtain a copy of the License at > > # http://www.apache.org/licenses/LICENSE-2.0 > > # Unless required by applicable law or agreed to in writing, software > # distributed under the License is distributed on an "AS IS" BASIS, > # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > # See the License for the specific language governing permissions and > # limitations under the License. > > # Makefile for BitKeeper. > > # Bitmover makefiles try to provide the following targets: > # > # all build everything under the current directory > # > # clean remove all objects and programs > # > # clobber run clean plus 'bk -r. clean' > # > # srcs bk get all sources in current directory > # > # tags build ctags for all srcs (only needed in this (top) > makefile) > # > # tags.local build ctags for srcs under current directory relative to > top > # > #--- > # Special make variables commonly used this makefile: > # $@ target > # $^ all sources > # $< first source > > INSTALLED_BK ?= $(shell bash -c "cd / && command -v bk") > INREPO ?= $(shell bash -c "test -d ../.bk && echo true || echo false") > HERE := $(shell pwd) > ROOT := $(shell dirname $(HERE)) > REPO := $(notdir $(ROOT)) > URL := $(shell echo bk://work/$(ROOT) | sed s,/home/bk/,,) > LOG = $(shell echo LOG-`bk getuser`) > OSTYPE := $(shell bash -c 'echo $$OSTYPE') > > include conf.mk > > ## Which hosts are used for producing nightly builds > NIGHTLY_HOSTS := macos106 win7-vm debian40 debian40-64 > > ifeq "$(OSTYPE)" "msys" > SYS=win32 > EXE=.exe > XTRA=win32 > ifeq (,$(INSTALLED_BK)) > # BINDIR should really be :C:/Program Files/BitKeeper > # The shell can not handle space in pathname, so > # we use the short name here > BINDIR := "C:/PROGRA~1/BITKEE~1" > else > BINDIR := $(shell bk pwd -s "`bk _registry get > 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion' > ProgramFilesDir`/BitKeeper") > endif > INSTALL=installdir > RESOURCE=bkres.o > UWT_C=$(patsubst %,win32/uwtlib/%.c, wapi_intf wcrt_intf) > BKGUI=bkg$(EXE) > BKG_O=bkg.o > else > SYS=unix > EXE= > # You can set this to anywhere you like and do a > # build production" and you'll have an installed BitKeeper. > ifeq (,$(INSTALLED_BK)) > BINDIR := /usr/local/bitkeeper > else > BINDIR := $(shell "$(INSTALLED_BK)" bin) > endif > INSTALL=install > RESOURCE= > endif > > # By default, we don't print verbose output. If you want to see > # the full compiler command line, use 'make V=1' > # The trick is to do "$(Q)$(CC)" instead of just "$(CC)" so that if > # Q is not set, it's just "$(CC)" and if Q is set to @ it becomes > # a quiet "@$(CC)". > # For the verbose messages, gmake provides > # $(if $(Q),<then>,<else>) > # so we just conditionalize on Q. Empty is false. > ifndef V > Q=@ > export Q > endif > > BK=./bk$(EXE) > G =-g > TRIAL =0 > IMGDIR =$(HERE)/tmp/bitkeeper > > # Handle warning arguments in GCC > # > # -Wall enables a bunch of warnings by default > # -Wno-parentheses shuts up "suggest parentheses around assignment ...". > # Unfortunately it also turns off dangling else warnings. > # -Wno-char-subscripts shuts up "subscript has type char", which comes > # up all the time with broken <ctype.h> implementations. > # (renabled in GCC3 since it supresses warnings in system files by > default) > # -Wno-format-y2k supresses complains about '%y' in strftime formats > # -Wstrict-prototypes Don't allow non-ansi function declarations > WARNINGS=-Wall -Wno-parentheses -Wno-char-subscripts -Wno-format-y2k \ > -Wstrict-prototypes > > # Warnings enabled with GCC newer than 3.0 > # > # -Wredundant-decls Declaring same function twice > # -Wmissing-declarations Functions without a prototype > WARNINGS_GCC3=-Wchar-subscripts -Wredundant-decls -Wmissing-declarations > > # Warnings enabled with GCC newer than 4.0 > # > # -Wextra enable a bunch of random things (called -Wextra in newer gccs) > # -Wno-pointer-sign Suppress warnings about changing the signs of pointers > # -Wno-sign-compare Suppress warnings about comparing signed and unsigned > vars > # -Wno-unsed-parameter Support warnings about function parameters that are > # no used > # -Wno-missing-field-initializers > # -Wdeclaration-after-statement Warn if someone does a C++ thing of > declaring > # a variable in the middle of a block > WARNINGS_GCC4=-Wextra -Wno-pointer-sign -Wno-sign-compare \ > -Wno-unused-parameter -Wno-missing-field-initializers \ > -Wdeclaration-after-statement -Wpointer-arith > > # Warnings enabled with GCC newer than 5.0 > # > # -Wno-unusedr-esult Do not warn if a caller ignores return value > WARNINGS_GCC5=-Wno-unused-result > > WARNINGS_GCC6= -Wno-misleading-indentation > > # XXX could not get -Wimplicit-fallthrough=3 to work > WARNINGS_GCC7= -Wno-implicit-fallthrough > > # Other options to consider enabling in the future: > # > # -Wnested-externs Prototypes declared in a function > # -Wwrite-string warn in string constant is passed to a char * > # -Wmissing-prototypes > # -Wunused-parameter > # -Wold-style-definition Would be nice, but zlib falls all over here > > GCC_MAJOR_REV=$(shell $(CC) -dumpversion | sed 's/\..*//') > GCC_MINOR_REV=$(shell $(CC) -dumpversion | sed 's/.*\.//') > ifeq ($(GCC_MAJOR_REV),3) > WARNINGS += $(WARNINGS_GCC3) > endif > ifeq ($(GCC_MAJOR_REV),4) > WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) > ifeq ($(shell expr $(GCC_MINOR_REV) \> 5), 1) > WARNINGS += -Wno-unused-result > endif > endif > ifeq ($(GCC_MAJOR_REV),5) > WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5) > endif > ifeq ($(GCC_MAJOR_REV),6) > WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5) \ > $(WARNINGS_GCC6) > endif > ifeq ($(GCC_MAJOR_REV),7) > WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5) \ > $(WARNINGS_GCC6) $(WARNINGS_GCC7) > endif > ifeq ($(GCC_MAJOR_REV),8) > WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5) \ > $(WARNINGS_GCC6) $(WARNINGS_GCC7) $(WARNINGS_GCC8) > endif > > TRACE = -DUSE_TRACE > > ifeq ($(shell uname -s), Darwin) > XLIBS += -lresolv > G += -DNOPROC > endif > > ifeq (clang, $(findstring clang, $(shell $(CC) --version))) > WARNINGS += -Wno-unused-value -Wno-empty-body -Wno-self-assign > endif > > GCCOPTS= > CC_DEBUG=$(GCCOPTS) $G $(WARNINGS) $(TRACE) > CC_FAST_DEBUG=$(GCCOPTS) $G -O2 $(WARNINGS) $(TRACE) > CC_FAST =$(CC_FAST_DEBUG) > CC_WALL=$(GCCOPTS) $G -DLINT $(WARNINGS) $(TRACE) > BINS = $(BK) $(BKGUI) > > # List of all objects in bk other than bk.o. Keep it sorted. > # But put bkver.o/cmd.o first, they generate headers. > OBJ = bkver.o cmd.o \ > abort.o adler32.o alias.o admin.o annotate.o attributes.o \ > bam.o bisect.o bkd.o bkd_bam.o bkd_cd.o \ > bkd_changes.o bkd_client.o bkd_clone.o bkd_cmdtab.o \ > bkd_findkey.o bkd_http.o \ > bkd_id.o bkd_kill.o bkd_level.o bkd_misc.o bkd_nested.o \ > bkd_partition.o bkd_pull.o bkd_push.o bkd_pwd.o \ > bkd_r2c.o \ > bkd_rclone.o bkd_rootkey.o bkd_status.o bkd_synckeys.o > bkd_version.o \ > bkverinfo.o \ > cat.o cfile.o changes.o config.o \ > check.o checksum.o clean.o cleanpath.o clone.o \ > cmdlog.o \ > collapse.o comment.o comments.o commit.o comps.o compress.o \ > contrib/cat.o \ > contrib/test.o \ > converge.o \ > cp.o \ > crypto.o \ > cset.o cset_inex.o csetprune.o csets.o cweave.o \ > dataheap.o dbfile.o delta.o diff.o dspec.o \ > export.o \ > fast-import.o fast-export.o features.o findmerge.o \ > find.o findcset.o fixtool.o fsl.o fslayer.o \ > g2bk.o gca.o get.o gethelp.o \ > gethost.o gettemp.o getuser.o gfiles.o glob.o \ > gnupatch.o graft.o grep.o \ > hash_nokey.o \ > heapdump.o help.o here.o here_check.o hostme.o http.o \ > idcache.o isascii.o info.o \ > key2rev.o key2path.o kill.o kv.o \ > libcommit.o libdiff.o libgraph.o librange.o \ > libsfiles.o lines.o \ > localtm.o lock.o locking.o \ > mail.o merge.o mklock.o \ > mailslot.o \ > mtime.o mv.o names.o ndiff.o nested.o newroot.o \ > opark.o \ > parent.o park.o partition.o \ > patch.o \ > pending.o preference.o proj.o \ > poly.o \ > populate.o \ > port/bkd_server.o \ > port/check_rsh.o \ > port/gethomedir.o \ > port/gethost.o port/getinput.o \ > port/getrealname.o port/getrusage.o port/globalroot.o port/gui.o \ > port/hostColonPath.o port/http_proxy.o \ > port/mail.o port/mnext.o port/networkfs.o \ > port/notifier.o port/ns_sock_host2ip.o port/platforminit.o \ > port/sccs_getuser.o port/sccs_lockfile.o \ > port/startmenu.o \ > port/svcinfo.o \ > port/uninstall.o \ > progress.o \ > prs.o pull.o push.o pwd.o \ > randombits.o randseed.o range.o rcheck.o rclone.o \ > rcs2bk.o rcsparse.o \ > receive.o redblack.o regex.o registry.o renumber.o \ > remap.o remote.o \ > repo.o repos.o repogca.o repostats.o repotype.o \ > resolve.o resolve_binaries.o resolve_contents.o \ > resolve_create.o resolve_filetypes.o \ > resolve_flags.o resolve_generic.o resolve_modes.o \ > resolve_renames.o resolve_tags.o restore.o review.o \ > rm.o rmdel.o rmgone.o \ > root.o rset.o sane.o scat.o sccs.o sccs2bk.o \ > sccslog.o sccs_mv.o search.o sec2hms.o send.o sendbug.o \ > set.o setup.o sfio.o shrink.o sinfo.o \ > slib.o smerge.o sort.o startmenu.o \ > stat.o stattest.o status.o stripdel.o synckeys.o \ > tagmerge.o testcode.o tclsh.o takepatch.o \ > testdates.o time.o timestamp.o touch.o trigger.o \ > unbk.o undo.o undos.o unedit.o \ > unique.o uninstall.o unlink.o unlock.o unpull.o unrm.o unwrap.o > upgrade.o \ > urlinfo.o \ > utils.o uu.o what.o which.o \ > xfile.o xflags.o \ > zone.o > SCRIPTS = bk.script import \ > uuwrap unuuwrap gzip_uuwrap ungzip_uuwrap \ > b64wrap unb64wrap gzip_b64wrap ungzip_b64wrap > PSCR = t/doit t/guitest > PROGS = libc/mtst$(EXE) > LIBS = libc/libc.a > DATA = bkmsg.txt bkhelp.txt version \ > ../doc/bk_refcard.ps ../doc/bk_refcard.pdf ../RELEASE-NOTES.md \ > dspec-changes dspec-changes-3.2 dspec-changes-4.0 dspec-changes-h \ > dspec-changes-hv dspec-changes-json dspec-changes-json-v \ > dspec-changes-vv dspec-log dspec-prs > > CONTRIB = gui/ide/emacs/vc-bk.el contrib/git2bk.l > ALL = PCRE $(LIBS) $(BINS) $(SCRIPTS) $(PSCR) $(XTRA) \ > $(PROGS) L-clean GUI L-doc $(DATA) > > CFLAGS = $(CC_DEBUG) > export CFLAGS > CPPFLAGS= -Ilibc $(TOMCRYPT_CPPFLAGS) $(TOMMATH_CPPFLAGS) \ > $(PCRE_CPPFLAGS) $(LZ4_CPPFLAGS) $(ZLIB_CPPFLAGS) > # Override this if you don't have it. > RANLIB = ranlib > > # list of C sources in bk > SRCS = bk.c $(OBJ:.o=.c) > # list of headers in bk > HDRS = bam.h bkd.h bk-features.h config.h configvars.def diff.h > fsfuncs.h \ > graph.h nested.h \ > progress.h range.h rcs.h resolve.h sccs.h \ > cmd.h poly.h proj.h redblack.h libc/system.h xfile.h > > # list of non-C sources in bk > SCRSRCS = bk.sh import.sh kwextract.pl uuwrap.sh unuuwrap.sh \ > port/unix_platform.sh port/win32_platform.sh \ > gzip_uuwrap.sh ungzip_uuwrap.sh \ > substvars.sh b64wrap.sh gzip_b64wrap.sh \ > unb64wrap.sh ungzip_b64wrap.sh > MISC = bkmsg.doc t/doit.sh > > default: > $(MAKE) p > > SUBDIRS = libc $(shell ls -d tomcrypt tommath 2>/dev/null) > > all: $(ALL) > > prof: > $(MAKE) CFLAGS="$G -pg -O2" LDFLAGS=-pg all > gprof: > $(MAKE) CFLAGS="$G -DPROFILE -pg -O2" LDFLAGS=-pg all > ggprof: > $(MAKE) CFLAGS="$G -DPROFILE -pg" LDFLAGS=-pg all > # Debugging... > d: > $(MAKE) CFLAGS="$G -DDEBUG" all > debug: > $(MAKE) CFLAGS="$G -DDEBUG" all > debug2: > $(MAKE) CFLAGS="$G -DDEBUG2" all > > gWall Wall: > $(MAKE) CFLAGS="$(CC_WALL)" all > > # production builds > p: ## Build a production version of BitKeeper (no -g) > $(MAKE) CFLAGS="$(CC_FAST) $(CF)" all > > trial: > $(MAKE) TRIAL="3*WEEK" CFLAGS="$(CC_FAST) $(CF)" all > > trial3M: > $(MAKE) TRIAL="3*MONTH" CFLAGS="$(CC_FAST) $(CF)" all > > g: ## Build a debug version of BitKeeper (-g) > $(MAKE) CFLAGS="$(CC_DEBUG)" all > gO: > $(MAKE) CFLAGS="$(CC_FAST_DEBUG)" all > gcov: > $(MAKE) CFLAGS="$(CC_DEBUG) -fprofile-arcs -ftest-coverage" all > > clean: L-clean FORCE ## Remove object files and executables > $(if $(Q),@echo Cleaning up,) > $(Q)for sub in $(SUBDIRS) ../doc ../man gui utils win32 t t/win32; > \ > do $(MAKE) -C$$sub "CFLAGS=$(CFLAGS)" $@; \ > done > $(Q)$(RM) $(OBJ) bk.o $(BKG_O) $(BINS) $(SCRIPTS) \ > $(PSRC) $(PROGS) > $(Q)$(RM) tags TAGS tags.local cscope.out substvars a.out cmd.c > cmd.h \ > core *.bb *.bbg *.da *.gcov \ > bk.ico \ > bkmsg.txt bkhelp.txt bkver.c version \ > t/doit t/guitest kw2val_lookup.c bkres.o svcmgr.exe \ > conf.mk > $(Q)$(RM) -r tmp > ifeq "$(OSTYPE)" "msys" > $(Q)$(RM) -rf gnu/bin gnu/doc gnu/etc gnu/share > $(Q)$(RM) -f gnu/m.ico gnu/msys.bat gnu/msys.ico > $(Q)-rmdir gnu/tmp > $(Q)-rmdir gnu > endif > ifeq (true,$(INREPO)) > ifneq (,$(INSTALLED_BK)) > $(Q)EXTRALIST=`"$(INSTALLED_BK)" -Aax | \ > grep -v '~$$\|conf-.*\.mk$$'` ; \ > if [ "$$EXTRALIST" ]; then \ > echo "Clean left behind the following files:" ; \ > for file in $$EXTRALIST; do \ > echo " $$file" ; \ > done ; \ > else \ > echo Clean complete ; \ > fi > endif > endif > > clobber: clean FORCE ## Same as 'clean' but also bk clean files > -@$(BK) -A clean > > # XXX subdirs? (see tags) > wc: $(HDRS) $(SRCS) $(SCRSRCS) $(MISC) > wc -l $(SRCS) $(HDRS) $(SCRSRCS) $(MISC) > > get-e: FORCE > -@$(BK) edit -qT `echo $(HDRS) $(SRCS) $(SCRSRCS) $(MISC) | fmt > -1|sort -u` > $(Q)$(MAKE) tags > > srcs: $(SRCS) $(HDRS) FORCE > $(Q)for sub in $(SUBDIRS); do $(BK) -r$$sub co -q; done > > tags: $(patsubst %,%/tags.local, $(SUBDIRS)) tags.local > @if [ -x $(BK) ]; \ > then $(BK) get -Sq tags.skippats; \ > $(BK) _sort -u $^ | grep -v -ftags.skippats > $@; \ > else \ > bk get -Sq tags.skippats; \ > bk _sort -u $^ | grep -v -ftags.skippats > $@; \ > fi > @echo ctags completed > > tags.local: $(SRCS) $(HDRS) > @ctags -f $@ --file-tags=yes --c-types=d+f+s+t $^ > > %/tags.local: FORCE > $(Q)$(MAKE) -C $(dir $@) tags.local > > ssh sshtest: > $(MAKE) realtest > > rsh rshtest: > PREFER_RSH=YES $(MAKE) realtest > > test tests: > DO_REMOTE=NO $(MAKE) -C t > > nonet nonet_test localtest: > BK_NONET=YES PREFER_RSH=YES $(MAKE) realtest > > realtest: $(ALL) t/doit > -cd gui/tcltk && $(MAKE) clobber > -$(BK) get -qS t/setup t/win32/win32_common > $(BK) -rt get -qTS 't.*' > cd t && ./doit -f 5 > > guitest: $(ALL) t/doit > -$(BK) get -qS t/SCCS/s.g.* t/setup t/win32/win32_common > t/guitest.tcl > cd t && ./doit -g -i > > t/doit: t/doit.sh substvars > ./substvars t/doit.sh > t/doit > chmod +x t/doit > > t/guitest: t/guitest.tcl > cat < t/guitest.tcl > t/guitest > > .PHONY: FORCE > FORCE: > > win32: FORCE > cd win32 && $(MAKE) BINDIR=$(BINDIR) > cd t/win32 && $(MAKE) > > # build libraries in sub directories > %.a: FORCE > $(Q)$(MAKE) -C $(dir $@) $(notdir $@) > > libc/mtst$(EXE): libc/libc.a FORCE > $(Q)$(MAKE) -C libc mtst$(EXE) > > bkres.o: win32/data/bk.rc bk.ico > windres -i win32/data/bk.rc -o bkres.o > > bk.ico: win32/data/bk.ico > @cp -f win32/data/bk.ico . > > ifneq ($(TOMCRYPT_SYSTEM),1) > # add dependency on building libraries first > $(BK): $(TOMCRYPT_LDFLAGS) > endif > ifneq ($(TOMMATH_SYSTEM),1) > # add dependency on building libraries first > $(BK): $(TOMMATH_LDFLAGS) > endif > > $(BK): $(LIBS) bk.o $(RESOURCE) $(OBJ) > $(if $(Q),@echo LINKING $(BK),) > $(Q)$(LD) $(LDFLAGS) -o $@ bk.o $(OBJ) $(RESOURCE) $(LIBS) \ > $(TOMCRYPT_LDFLAGS) $(TOMMATH_LDFLAGS) \ > $(PCRE_LDFLAGS) $(LZ4_LDFLAGS) $(ZLIB_LDFLAGS) $(XLIBS) > > # Windows only rule, BKGUI should be blank on other platforms > $(BKGUI): bkg.o $(RESOURCE) > $(if $(Q),@echo LINKING $(BKGUI),) > $(Q)$(LD) $(LDFLAGS) -o $@ bkg.o $(RESOURCE) -Llibc -lc -mwindows > $(XLIBS) > > bk.script: bk.sh port/$(SYS)_platform.sh > cat port/$(SYS)_platform.sh bk.sh > bk.script > chmod +x bk.script > > bkmsg.txt: bkmsg.doc > cp -f $< $@ > > L-clean: FORCE > @rm -f gui/share/doc/L/little.man ../man/man1/bk-little.1 > @rm -f ../man/man2help/bk-little-1.fmt > > # has to run before bkhelp.txt but after GUI > L-doc L-docs: GUI FORCE > @test -f gui/share/doc/L/little.man || { \ > echo Failed to build gui/share/doc/L/little.man; \ > exit 1; \ > } > @if [ -s gui/share/doc/L/little.man ]; \ > then cp gui/share/doc/L/little.man ../man/man1/bk-little.1; \ > else cp ../man/man1/bk-little.1.pfmt ../man/man1/bk-little.1; \ > fi; \ > chmod +w ../man/man1/bk-little.1 > > bkhelp.txt: $(BK) version L-docs FORCE > @rm -f ../man/man2help/bk-little.fmt > @cd ../man/man2help && $(MAKE) BK=$(HERE)/bk$(EXE) helptxt > @cp ../man/man2help/helptxt bkhelp.txt > @rm -f ../man/man1/bk-little.1 > > html-docs: bkhelp.txt > @cd ../man/man2html && $(MAKE) > > ../doc/bk_refcard.ps: $(BK) FORCE > $(Q)echo building $@ > $(Q)-$(BK) -r../doc co -qS > $(Q)$(MAKE) -C ../doc BK=$(HERE)/bk$(EXE) all > > ../doc/bk_refcard.pdf: ../doc/bk_refcard.ps > > # This must be rebuilt every time because it includes the build time > bkver.c: utils/bk_version FORCE > $(if $(Q),@echo Building $@,) > $(Q)echo "#include \"sccs.h\"" > bk.v > $(Q)echo "char *bk_platform = \""`./utils/bk_version`"\";" >> bk.v > $(Q)echo "int test_release = "$(TRIAL)";" >> bk.v > $(Q)echo "time_t bk_build_timet = "`perl -e "print time"`";" >> > bk.v > $(Q)echo "char *bk_build_dir = \""`pwd`"\";" >> bk.v > $(Q)mv -f bk.v bkver.c > > version: version.sh $(BK) utils/bk_version GUI FORCE > bash version.sh > $@ > > %: %.sh > $(if $(Q),@echo Building $@,) > $(Q)$(RM) $@ > $(Q)cp $< $@ > $(Q)chmod +x $@ > > %: %.l > $(if $(Q),@echo Not lexing $@,) > > import: import.sh port/$(SYS)_platform.sh > cat port/$(SYS)_platform.sh import.sh > import.T > chmod +x import.T > mv -f import.T import > > # Quick and dirty target so we can make all the gui tools without the rest > .PHONY: GUI > GUI: PCRE $(BK) > @$(MAKE) -Cgui BK=$(HERE)/bk$(EXE) gui > > install: installdir > tmp/bitkeeper/bk _install -d -f $(DESTDIR)$(BINDIR) > @echo BitKeeper is installed in $(BINDIR) > @echo We suggest you run: > @echo > @echo sudo $(BINDIR)/bk links /usr/local/bin > @echo > @echo to create the bk symlink. > > installdir: utils/registry.tcl > rm -rf $(IMGDIR) || exit 1 > mkdir -p $(IMGDIR)/contrib > mkdir -p $(IMGDIR)/lscripts > -$(BK) -rwww get -S > -cp -f -r www $(IMGDIR) > -$(BK) get -S $(CONTRIB) > tar cf - $(BINS) $(SCRIPTS) lscripts gui/bin gui/lib gui/images \ > | (cd $(IMGDIR) && tar xf -) > cp -f $(DATA) $(IMGDIR) > cp -f $(CONTRIB) $(IMGDIR)/contrib > (cd ../doc/nested && $(MAKE) install HTML=$(IMGDIR)/html) > if [ $(SYS) = unix ]; \ > then $(BK) get -S ../man/Makefile; \ > cd ../man && $(MAKE) install BINDIR=$(IMGDIR) ;\ > else \ > (cd win32 && $(MAKE) BINDIR=$(IMGDIR) install); \ > cp utils/registry.tcl $(IMGDIR)/gui/lib; \ > fi > cd $(IMGDIR); \ > find . -type l | \ > perl -ne 'chomp; $$a = readlink; print > "$$a|$$_\n";'>symlinks; \ > test -s symlinks || rm -f symlinks > @true > > image: ## Build the installer (left in src/utils/bk-*) > $(MAKE) p > $(MAKE) _image > > _image: > $(MAKE) installdir > ${MAKE} -Cutils BINDIR=$(IMGDIR) "CC=$(CC)" "BK=$(HERE)/bk$(EXE)" > "CFLAGS=$(CFLAGS)" image > > crankturn: crank.sh remote.sh ## Run a clean-build + regressions in > cluster > REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh > > cranksave: crank.sh remote.sh ## Run a crankturn but save the built images > REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh > save > > crankstatus: crank.sh remote.sh ## See how the crank is going > REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh > status > > crankrelease nightly: $(BK) crank.sh remote.sh ## Do a BitKeeper release > (or nightly build) > @(TAG=$(shell $(BK) changes -r+ -d:TAG:) ; \ > test x$$TAG = x && { \ > echo Cannot crankrelease with a non-tagged tip ; \ > exit 1 ; \ > } ; \ > case $@ in \ > crankrelease ) \ > TYPE=release; DIR=/home/bk/images/$$TAG; \ > ;; \ > nightly ) \ > TYPE=nightly; DIR=/home/bk/images/nightly; \ > HOSTS="$(NIGHTLY_HOSTS)" ; \ > ;; \ > esac ; \ > test -d $$DIR || mkdir -p $$DIR ; \ > REPO=$(REPO) URL=$(URL) HOSTS=$$HOSTS REMOTE=remote.sh \ > LOG=$(LOG) bash crank.sh $$TYPE ; \ > $(BK) -R get -qS ../RELEASE-NOTES.md ; \ > cp ../RELEASE-NOTES.md $$DIR ; \ > SAVED_WD=$(shell pwd) ; \ > cd $$DIR && chmod +rx bk-* >/dev/null 2>&1 ; \ > rm -f MD5SUMS ; \ > md5sum bk-* >> MD5SUMS ; \ > echo "Your images are in $$DIR" ; \ > case $@ in \ > crankrelease ) \ > echo "Run './mkrelease $$TAG' to release this version of > bk."; \ > ;; \ > nightly ) \ > # cd $$SAVED_WD ; \ > # ./mkupgrades --nightly $$TAG ; \ > ;; \ > esac) > > crankclean: crank.sh remote.sh > REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh > clean > > # This target assumes a bk repository > .PHONY: src-tar > src-tar: $(BK) version ## build tar.gz image for the current tree > ifeq (false,$(INREPO)) > $(error This target only works in a BK source repository) > else > ./bk here add default TCLTK > $(Q)-mkdir -p tmp/src > $(Q)(DIR=bk-$(shell $(BK) version -s) ; \ > TAR="$$DIR".tar.gz ; \ > echo "Creating $$TAR in tmp/src..." ; \ > cd tmp/src ; \ > rm -rf "$$DIR" ; \ > ../../bk export -tplain -kwr+ -sdefault -sTCLTK "$$DIR" ; \ > cat ../../version > "$$DIR/src/bkvers.txt" ; \ > tar -czf "$$TAR" "$$DIR" ; \ > rm -rf "$$DIR" ; \ > echo Done ; \ > ) > endif > > # only depend on conf.mk.local if it exists > conf.mk: mkconf.sh $(wildcard conf.mk.local) > sh mkconf.sh > $@ || { $(RM) $@; false; } > > %.o: %.c > $(if $(Q),@echo CC $<,) > $(Q)$(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $@ > > port/startmenu.o: port/startmenu.c $(HDRS) > $(if $(Q),@echo CC $<,) > $(Q)$(CC) $(CFLAGS) -fno-strict-aliasing $(CPPFLAGS) -c $< -o $@ > > depend: $(SRCS) > $(CC) -MM -MG -D_DEPEND $(SRCS) > depends > > # for system.h we need to actually run libc's makefile because it includes > # calculated header files > libc/system.h: FORCE > $(MAKE) -C libc system.h > > libc/libc.a: libc/system.h > > sccs.h: PCRE > .PHONY: PCRE > PCRE: > ifneq ($(PCRE_SYSTEM),1) > $(MAKE) -Cgui/tcltk pcre > endif > > $(OBJ) bk.o: $(HDRS) > > cmd.c cmd.h: cmd.pl bk.sh $(filter bkd_%,$(SRCS)) > $(if $(Q),@echo Building $@,) > $(Q)perl cmd.pl || (rm -f cmd.c cmd.h; exit 1) > > # This parses slib.c and extracts the meta-data keywords expanded > # by kw2val() and passes them to gperf to generate hash lookup code. > slib.o: kw2val_lookup.c > kw2val_lookup.c: slib.c kw2val.pl > $(if $(Q),@echo Building $@,) > $(Q)perl kw2val.pl slib.c || (rm -f kw2val_lookup.c; exit 1) > > check-syntax: > $(CC) $(CFLAGS) $(CPPFLAGS) -c -S ${CHK_SOURCES} -o /dev/null > > # print a make variable 'make print-REPO' > # http://www.cmcrossroads.com/article/printing-value-makefile-variable > print-%: > @echo $* = \"$($*)\" > > .PHONY: help > > help: > @grep -E -h '^[-a-zA-Z_\ ]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | > awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}' > @echo Suggested: make -j12 image > > [-- Attachment #2: Type: text/html, Size: 33662 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 14:44 ` Warner Losh @ 2024-06-19 14:53 ` Larry McVoy 2024-06-19 15:08 ` Warner Losh ` (2 more replies) 0 siblings, 3 replies; 160+ messages in thread From: Larry McVoy @ 2024-06-19 14:53 UTC (permalink / raw) To: Warner Losh; +Cc: The Eunuchs Hysterical Society On Wed, Jun 19, 2024 at 08:44:14AM -0600, Warner Losh wrote: > On Wed, Jun 19, 2024, 7:28???AM Larry McVoy <lm@mcvoy.com> wrote: > > > On Tue, Jun 18, 2024 at 07:46:15PM -0500, Nevin Liber wrote: > > > But I'll bite. There was the claim by Larry McVoy that "Writing > > Makefiles > > > isn't that hard". > > > > > > Please show these beautiful makefiles for a non-toy non-trivial product > > > > Works on *BSD, MacOS, Windows, Linux on a bunch of different architectures, > > Solaris, HPUX, AIX, IRIX, Tru64, etc. > > > > The posted Makefile is no a strictly conforming POSIX Makefile, but uses > gmake extensions extensively... And eyes of the beholder may vary... Yeah, I lost that battle. I prefer, and carry around the sources to, a make from Unix. It's simple and does what I need. But my guys convinced me there was enough value in gmake that we used it. I tried to keep the craziness to a minimum. And I think I succeeded, I can fix bugs in that Makefile. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 14:53 ` Larry McVoy @ 2024-06-19 15:08 ` Warner Losh 2024-06-19 15:11 ` G. Branden Robinson 2024-06-19 15:16 ` ron minnich 2 siblings, 0 replies; 160+ messages in thread From: Warner Losh @ 2024-06-19 15:08 UTC (permalink / raw) To: Larry McVoy; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 2177 bytes --] On Wed, Jun 19, 2024, 8:54 AM Larry McVoy <lm@mcvoy.com> wrote: > On Wed, Jun 19, 2024 at 08:44:14AM -0600, Warner Losh wrote: > > On Wed, Jun 19, 2024, 7:28???AM Larry McVoy <lm@mcvoy.com> wrote: > > > > > On Tue, Jun 18, 2024 at 07:46:15PM -0500, Nevin Liber wrote: > > > > But I'll bite. There was the claim by Larry McVoy that "Writing > > > Makefiles > > > > isn't that hard". > > > > > > > > Please show these beautiful makefiles for a non-toy non-trivial > product > > > > > > Works on *BSD, MacOS, Windows, Linux on a bunch of different > architectures, > > > Solaris, HPUX, AIX, IRIX, Tru64, etc. > > > > > > > The posted Makefile is no a strictly conforming POSIX Makefile, but uses > > gmake extensions extensively... And eyes of the beholder may vary... > > Yeah, I lost that battle. I prefer, and carry around the sources to, a > make from Unix. It's simple and does what I need. But my guys convinced > me there was enough value in gmake that we used it. I tried to keep > the craziness to a minimum. And I think I succeeded, I can fix bugs in > that Makefile. > I thought the ask was for a POSIX one that did that, hence my comment. I agree that is a fools errand for anything non-trivial. I can do way better using BSD's make since i can hide almost all the ugliness behind the scenes... Though what's hidden has rightfully been criticized already (I did diagree with some of it, but the main points still stand with my quibbles so I let it go). In many ways I really like cmake's declarative approach. I like bmake's include macros that try to do similar, but more constrained, things. I like that cmake figures things out, though I've done too much battle to control how it does things, but I digress. It's useful to have a tool that can do dependencies. However, you need a higher level tool to generate input to that tool, like meson with ninjamake or cmake. Combining them like gmake or bmake creates a nice macro assembler that can be made to work, but the pain winds up being in all the wrong places and the needs to constantly refactor is high to try to retain the simplicity. Warner > [-- Attachment #2: Type: text/html, Size: 3070 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 14:53 ` Larry McVoy 2024-06-19 15:08 ` Warner Losh @ 2024-06-19 15:11 ` G. Branden Robinson 2024-06-19 15:16 ` ron minnich 2 siblings, 0 replies; 160+ messages in thread From: G. Branden Robinson @ 2024-06-19 15:11 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 6542 bytes --] At 2024-06-19T07:53:59-0700, Larry McVoy wrote: > On Wed, Jun 19, 2024 at 08:44:14AM -0600, Warner Losh wrote: > > The posted Makefile is no a strictly conforming POSIX Makefile, but > > uses gmake extensions extensively... And eyes of the beholder may > > vary... > > Yeah, I lost that battle. I prefer, and carry around the sources to, > a make from Unix. It's simple and does what I need. But my guys > convinced me there was enough value in gmake that we used it. I tried > to keep the craziness to a minimum. And I think I succeeded, I can > fix bugs in that Makefile. As of POSIX 2024, that Makefile is less GNUish than its used to be. I excerpted the list of changes to POSIX make for Issue 8. Here it is. Changes in POSIX 2024 make Issue 8 Austin Group Defect 251 is applied, encouraging implementations to disallow the creation of filenames containing any bytes that have the encoded value of a <newline> character. Austin Group Defects 330, 1417, 1422, 1709, and 1710 are applied, adding new forms of macro assignment using the "::=", "?=", and "+=" operators. Austin Group Defect 333 is applied, adding support for “silent includes” using −include. Austin Group Defects 336 and 1711 are applied, specifying the behavior when string1 in a macro expansion contains a macro expansion. Austin Group Defect 337 is applied, adding a new form of macro assignment using the "!=" operator. Austin Group Defects 373 and 1417 are applied, changing the set of characters that portable applications can use in macro names to the entire portable filename character set (thus adding <hyphen-minus> to the set that could previously be used). Austin Group Defects 514 and 1520 are applied, adding the $+ and $^ internal macros. Austin Group Defect 518 is applied, allowing multiple files to be specified on an include line. Austin Group Defects 519, 1712, and 1715 are applied, adding support for pattern macro expansions. Austin Group Defects 523, 1708, and 1749 are applied, adding the .PHONY special target. Austin Group Defect 875 is applied, clarifying the requirements for inference rules. Austin Group Defect 1104 is applied, changing “s2.a” to “.s2.a”. Austin Group Defect 1122 is applied, changing the description of NLSPATH. Austin Group Defect 1141 is applied, changing “core files” to “a file named core”. Austin Group Defect 1155 is applied, clarifying the handling of the MAKE macro. Austin Group Defect 1325 is applied, adding requirements relating to the creation of include files. Austin Group Defect 1330 is applied, removing obsolescent interfaces. Austin Group Defect 1419 is applied, updating the .SCCS_GET default rule. Austin Group Defect 1420 is applied, clarifying where internal macros can be used. Austin Group Defect 1421 is applied, changing the APPLICATION USAGE section. Austin Group Defects 1424, 1658, 1690, 1701, 1702, 1703, 1704, 1707, 1719, 1720, 1721, 1722, and 1750 are applied, making various minor editorial wording changes. Austin Group Defects 1436, 1437, 1652, 1660, 1661, and 1733 are applied, adding the −j maxjobs option and the .NOTPARALLEL and .WAIT special targets, and changing the −n option. Austin Group Defects 1471 and 1513 are applied, adding a new form of macro assignment using the ":::=" operator. Austin Group Defect 1479 is applied, clarifying the requirements for default rules and macro values. Austin Group Defect 1492 is applied, changing the EXIT STATUS section. Austin Group Defect 1505 is applied, clarifying the requirements for expansion of macros that do not exist. Austin Group Defect 1510 is applied, correcting a typographic error in the RATIONALE section. Austin Group Defect 1549 is applied, clarifying the requirements for an escaped <newline> in a command line. Austin Group Defect 1615 is applied, allowing target names to contain slashes and hyphens. Austin Group Defect 1626 is applied, adding the CURDIR macro. Austin Group Defect 1631 is applied, adding information about use of the −j option with the .c.a default rule to the APPLICATION USAGE and EXAMPLES sections. Austin Group Defect 1650 is applied, changing the few occurrences of “dependencies” to use the more common “prerequisites”. Austin Group Defect 1653 is applied, clarifying the difference between how MAKEFLAGS is parsed compared to shell commands that use the make utility. Austin Group Defects 1654 and 1655 are applied, changing the APPLICATION USAGE section. Austin Group Defect 1656 is applied, changing the NAME section. Austin Group Defect 1657 is applied, moving some requirements unrelated to makefile syntax from the Makefile Syntax subsection to the beginning of the EXTENDED DESCRIPTION section. Austin Group Defect 1689 is applied, removing some redundant wording from the DESCRIPTION section. Austin Group Defect 1692 is applied, allowing make, when invoked with the −q or −t option, to execute command lines (without a <plus-sign> prefix) that expand the MAKE macro. Austin Group Defect 1693 is applied, changing “command lines” to “execution lines” in the description of the −s option. Austin Group Defect 1694 is applied, changing “in the order they appear” to “in the order specified” in the OPERANDS section. Austin Group Defect 1696 is applied, changing the STDOUT section. Austin Group Defect 1697 is applied, changing the RATIONALE and FUTURE DIRECTIONS sections. Austin Group Defect 1698 is applied, changing “of a target” to “of the target” in the EXTENDED DESCRIPTION section. Austin Group Defect 1699 is applied, addressing some inconsistencies in the use of the term “rules”. Austin Group Defect 1706 is applied, removing a line from the format specified for target rules. Austin Group Defect 1714 is applied, changing “beginning of the line” to “beginning of the value”. Austin Group Defect 1716 is applied, changing the typographic convention used for variable elements within target names, in particular the inference rule suffixes s1 and s2. Austin Group Defect 1723 is applied, adding historical context to a paragraph in the RATIONALE section. Austin Group Defect 1772 is applied, clarifying the ASYNCHRONOUS EVENTS section. "Well, I'm not even sure that's a crime anymore--there've been a lot of changes in the law." -- Irwin Fletcher Regards, Branden [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 14:53 ` Larry McVoy 2024-06-19 15:08 ` Warner Losh 2024-06-19 15:11 ` G. Branden Robinson @ 2024-06-19 15:16 ` ron minnich 2 siblings, 0 replies; 160+ messages in thread From: ron minnich @ 2024-06-19 15:16 UTC (permalink / raw) To: Larry McVoy; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1811 bytes --] somewhere in this zillion-thread discussion there was a comment about Plan 9 and its multi-headed community. While that comment was probably accurate a few years back, the last two years of Plan 9 workshops saw a lot of us, representing many different Plan 9 code bases, get together and converge on where we want to go. Once you meet someone in person, and go get a cheesesteak together, arguments seem to resolve. I would say, don't take too many impressions from 9fans, a famously argumentative list. The folks who write Plan 9 code are in broad agreement about moving forward and leaving hatchets buried. Progress is never as rapid as we all would like, but I'm optimistic. On Wed, Jun 19, 2024 at 7:54 AM Larry McVoy <lm@mcvoy.com> wrote: > On Wed, Jun 19, 2024 at 08:44:14AM -0600, Warner Losh wrote: > > On Wed, Jun 19, 2024, 7:28???AM Larry McVoy <lm@mcvoy.com> wrote: > > > > > On Tue, Jun 18, 2024 at 07:46:15PM -0500, Nevin Liber wrote: > > > > But I'll bite. There was the claim by Larry McVoy that "Writing > > > Makefiles > > > > isn't that hard". > > > > > > > > Please show these beautiful makefiles for a non-toy non-trivial > product > > > > > > Works on *BSD, MacOS, Windows, Linux on a bunch of different > architectures, > > > Solaris, HPUX, AIX, IRIX, Tru64, etc. > > > > > > > The posted Makefile is no a strictly conforming POSIX Makefile, but uses > > gmake extensions extensively... And eyes of the beholder may vary... > > Yeah, I lost that battle. I prefer, and carry around the sources to, a > make from Unix. It's simple and does what I need. But my guys convinced > me there was enough value in gmake that we used it. I tried to keep > the craziness to a minimum. And I think I succeeded, I can fix bugs in > that Makefile. > [-- Attachment #2: Type: text/html, Size: 2340 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 13:28 ` Larry McVoy 2024-06-19 14:44 ` Warner Losh @ 2024-06-19 15:59 ` Theodore Ts'o 2024-06-19 22:48 ` Kevin Bowling 1 sibling, 1 reply; 160+ messages in thread From: Theodore Ts'o @ 2024-06-19 15:59 UTC (permalink / raw) To: Larry McVoy; +Cc: The Eunuchs Hysterical Society On Wed, Jun 19, 2024 at 06:28:46AM -0700, Larry McVoy wrote: > On Tue, Jun 18, 2024 at 07:46:15PM -0500, Nevin Liber wrote: > > But I'll bite. There was the claim by Larry McVoy that "Writing Makefiles > > isn't that hard". > > > > Please show these beautiful makefiles for a non-toy non-trivial product > > Works on *BSD, MacOS, Windows, Linux on a bunch of different architectures, > Solaris, HPUX, AIX, IRIX, Tru64, etc. True, but it uses multiple GNU make features, include file inclusions, conditionals, pattern substitutions, etc. That probably worked for Bitkeeper because you controlled the build envirnment for the product, as you were primarily distributing binaries. From portability perspective for e2fsprogs, I wanted to make sure I could build it using the native build environment (e.g., suncc and later clang, not just gcc, and the default make distributed by Sun, AIX, Irix, HPUX, and later NetBSD/FreeBSD). I also wanted to support shared library support, and I didn't want to deal the horrific performance attributes of libtool and the inscrutibility of automake. Since my primary distribution channel was the source tarball (and later, a git checkout), and other high priority requirement for me is that I didn't want to require that people need to download some custom build infratrture. This rules out cmake, imake, gmake, and blaze (especially since blaze/bazel requires installing a Java <shudder> runtime). And since I did want to use various advanced features (optionally, if they exist on the system) such as Poix Threads (which back then I couldn't take for granted as existing on all of the OS's that I supported) and Thread Local Storage, as opposed to just restricting myself to the BSD v4.4 feature subset, I needed to use autoconf anyway, and from a runtime perspective, it only requires m4 / awk / sed which is available everywhere. So I did everything using (only) autoconf, including building and using shared libraries, with some optional build features that require GNU make, but the same makefiles will also work on FreeBSD's pmake. I do agree with your basic premise, though, which is there's realy no need to use fancy/complicated build infrastructure such as cmake or <shudder> imake. - Ted ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 15:59 ` Theodore Ts'o @ 2024-06-19 22:48 ` Kevin Bowling 2024-06-20 5:14 ` David Arnold 0 siblings, 1 reply; 160+ messages in thread From: Kevin Bowling @ 2024-06-19 22:48 UTC (permalink / raw) To: Theodore Ts'o; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 2788 bytes --] On Wed, Jun 19, 2024 at 11:59 PM Theodore Ts'o <tytso@mit.edu> wrote: > On Wed, Jun 19, 2024 at 06:28:46AM -0700, Larry McVoy wrote: > > On Tue, Jun 18, 2024 at 07:46:15PM -0500, Nevin Liber wrote: > > > But I'll bite. There was the claim by Larry McVoy that "Writing > Makefiles > > > isn't that hard". > > > > > > Please show these beautiful makefiles for a non-toy non-trivial product > > > > Works on *BSD, MacOS, Windows, Linux on a bunch of different > architectures, > > Solaris, HPUX, AIX, IRIX, Tru64, etc. > > True, but it uses multiple GNU make features, include file inclusions, > conditionals, pattern substitutions, etc. That probably worked for > Bitkeeper because you controlled the build envirnment for the product, > as you were primarily distributing binaries. > > From portability perspective for e2fsprogs, I wanted to make sure I > could build it using the native build environment (e.g., suncc and > later clang, not just gcc, and the default make distributed by Sun, > AIX, Irix, HPUX, and later NetBSD/FreeBSD). I also wanted to support > shared library support, and I didn't want to deal the horrific > performance attributes of libtool and the inscrutibility of automake. > > Since my primary distribution channel was the source tarball (and > later, a git checkout), and other high priority requirement for me is > that I didn't want to require that people need to download some custom > build infratrture. This rules out cmake, imake, gmake, and blaze > (especially since blaze/bazel requires installing a Java <shudder> > runtime). > > And since I did want to use various advanced features (optionally, if > they exist on the system) such as Poix Threads (which back then I > couldn't take for granted as existing on all of the OS's that I > supported) and Thread Local Storage, as opposed to just restricting > myself to the BSD v4.4 feature subset, I needed to use autoconf anyway, > and from a runtime perspective, it only requires m4 / awk / sed which > is available everywhere. > > So I did everything using (only) autoconf, including building and > using shared libraries, This is The Way if you really care about portability. Autoconf, once you get your head around what, why, and when it was created, makes for nice Makefiles and projects that are easy to include in the 100 Linux distributions with their own take on packaging the world. > with some optional build features that require > GNU make, but the same makefiles will also work on FreeBSD's pmake. I > do agree with your basic premise, though, which is there's realy no > need to use fancy/complicated build infrastructure such as cmake or > <shudder> imake. > > - Ted > [-- Attachment #2: Type: text/html, Size: 3706 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-19 22:48 ` Kevin Bowling @ 2024-06-20 5:14 ` David Arnold 2024-06-20 5:32 ` George Michaelson 0 siblings, 1 reply; 160+ messages in thread From: David Arnold @ 2024-06-20 5:14 UTC (permalink / raw) To: Kevin Bowling; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/html, Size: 2574 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 5:14 ` David Arnold @ 2024-06-20 5:32 ` George Michaelson 2024-06-20 6:37 ` Alexis 0 siblings, 1 reply; 160+ messages in thread From: George Michaelson @ 2024-06-20 5:32 UTC (permalink / raw) To: David Arnold; +Cc: The Eunuchs Hysterical Society we used to argue about that. I disliked autoconf because I felt 99% of the work could be precomputed, which is what MIT X11 Makefiles did: they had recipes for the common architectures. -G On Thu, Jun 20, 2024 at 3:15 PM David Arnold <davida@pobox.com> wrote: > > > On 20 Jun 2024, at 08:48, Kevin Bowling <kevin.bowling@kev009.com> wrote: > > > On Wed, Jun 19, 2024 at 11:59 PM Theodore Ts'o <tytso@mit.edu> wrote: > > > <…> > >> So I did everything using (only) autoconf, including building and >> using shared libraries, > > > This is The Way if you really care about portability. Autoconf, once you get your head around what, why, and when it was created, makes for nice Makefiles and projects that are easy to include in the 100 Linux distributions with their own take on packaging the world. > > > For those of a certain era, autoconf was both useful and relatively simple to use. > > In an era of many, divergent Unices, with different compilers, shared library implementations, and varying degrees of adherence to standards, it made using FOSS a matter of ‘./configure && make && make install’ which was massively easier than what had been required previously unless you happened to have exactly the same platform as the author. > > And to use it, you needed to understand shell, make, and m4, and learn a few dozen macros (at most). m4 was perhaps the least likely skill, but since it was used by sendmail(.mc), twmrc, X11 app defaults and various other stuff, most people already had a basic understanding of it. > > In my view the modern rejection of autoconf as “incomprehensible” mostly suggests that the speaker comes from a generation that never used the original Unix toolset. > > > > > d ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 5:32 ` George Michaelson @ 2024-06-20 6:37 ` Alexis 2024-06-20 7:07 ` David Arnold 2024-06-20 21:07 ` [TUHS] Building programs (Re: " Bakul Shah via TUHS 0 siblings, 2 replies; 160+ messages in thread From: Alexis @ 2024-06-20 6:37 UTC (permalink / raw) To: The Unix Heritage Society George Michaelson <ggm@algebras.org> writes: > we used to argue about that. I disliked autoconf because I felt > 99% of > the work could be precomputed, which is what MIT X11 Makefiles > did: > they had recipes for the common architectures. A point still being made: > So, okay, fine, at some point it made sense to run programs to > empirically determine what was supported on a given system. What > I don't understand is why we kept running those stupid little > shell snippets and little bits of C code over and over. It's > like, okay, we established that this particular system does > <library function foobar> with two args, not three. So why the > hell are we constantly testing for it over and over? > > Why didn't we end up with a situation where it was just a > standard thing that had a small number of possible values, and > it would just be set for you somewhere? Whoever was responsible > for building your system (OS company, distribution packagers, > whatever) could leave something in /etc that says "X = flavor 1, > Y = flavor 2" and so on down the line. > > And, okay, fine, I get that there would have been all kinds of > "real OS companies" that wouldn't have wanted to stoop to the > level of the dirty free software hippies. Whatever. Those same > hippies could have run the tests ONCE per platform/OS combo, put > the results into /etc themselves, and then been done with it. > > Then instead of testing all of that shit every time we built > something from source, we'd just drag in the pre-existing > results and go from there. It's not like the results were going > to change on us. They were a reflection of the way the kernel, C > libraries, APIs and userspace happened to work. Short of that > changing, the results wouldn't change either. --https://rachelbythebay.com/w/2024/04/02/autoconf/ Alexis. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 6:37 ` Alexis @ 2024-06-20 7:07 ` David Arnold 2024-06-20 21:07 ` [TUHS] Building programs (Re: " Bakul Shah via TUHS 1 sibling, 0 replies; 160+ messages in thread From: David Arnold @ 2024-06-20 7:07 UTC (permalink / raw) To: Alexis; +Cc: The Unix Heritage Society > On 20 Jun 2024, at 16:37, Alexis <flexibeast@gmail.com> wrote: > > George Michaelson <ggm@algebras.org> writes: > >> we used to argue about that. I disliked autoconf because I felt 99% of >> the work could be precomputed, which is what MIT X11 Makefiles did: >> they had recipes for the common architectures. > > A point still being made: > >> So, okay, fine, at some point it made sense to run programs to empirically determine what was supported on a given system. What I don't understand is why we kept running those stupid little shell snippets and little bits of C code over and over. It's like, okay, we established that this particular system does <library function foobar> with two args, not three. So why the hell are we constantly testing for it over and over? >> >> Why didn't we end up with a situation where it was just a standard thing that had a small number of possible values, and it would just be set for you somewhere? Whoever was responsible for building your system (OS company, distribution packagers, whatever) could leave something in /etc that says "X = flavor 1, Y = flavor 2" and so on down the line. >> >> And, okay, fine, I get that there would have been all kinds of "real OS companies" that wouldn't have wanted to stoop to the level of the dirty free software hippies. Whatever. Those same hippies could have run the tests ONCE per platform/OS combo, put the results into /etc themselves, and then been done with it. >> >> Then instead of testing all of that shit every time we built something from source, we'd just drag in the pre-existing results and go from there. It's not like the results were going to change on us. They were a reflection of the way the kernel, C libraries, APIs and userspace happened to work. Short of that changing, the results wouldn't change either. > > --https://rachelbythebay.com/w/2024/04/02/autoconf/ Which brings us back to imake (at least in xmkmf form), where if the pre-prepared settings matched your system, you were good and if not, you had a heap of work to set all the magic variables to have it build correctly. On classic MacOS, otoh, you’d compile against an SDK, but for each ROM/library symbol you wanted to use you were expected to check at runtime if it existed, and if not, switch to some alternative behaviour. Autoconf was somewhat of a middle path: check once for each installation. It also made more sense when there was less uniformity in the platforms in use. That said: autoconf never really worked outside of Unix. You could make other platforms Unix-like (eg. Cygwin, or even BeOS), but its claim to portability was always fairly narrow. U d ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 6:37 ` Alexis 2024-06-20 7:07 ` David Arnold @ 2024-06-20 21:07 ` Bakul Shah via TUHS 2024-06-20 23:35 ` [TUHS] " Alexis 1 sibling, 1 reply; 160+ messages in thread From: Bakul Shah via TUHS @ 2024-06-20 21:07 UTC (permalink / raw) To: The Unix Heritage Society mailing list >> Then instead of testing all of that shit every time we built something from source, we'd just drag in the pre-existing results and go from there. It's not like the results were going to change on us. They were a reflection of the way the kernel, C libraries, APIs and userspace happened to work. Short of that changing, the results wouldn't change either. To build a set of objects you need to worry about at least the following: - build recipes for each of them (which may also depend on other things) - configuration parameters - dealing with differences on each platform - third party libraries & alternatives - toolchains (& may be cross-platform builds) - supporting/navigating different versions of the last 3 above You can't really precompute all this as there are far too many combinations and they keep changing. Though you may be able to train a program porting AI model :-) ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 21:07 ` [TUHS] Building programs (Re: " Bakul Shah via TUHS @ 2024-06-20 23:35 ` Alexis 2024-06-21 0:05 ` Warner Losh ` (3 more replies) 0 siblings, 4 replies; 160+ messages in thread From: Alexis @ 2024-06-20 23:35 UTC (permalink / raw) To: The Unix Heritage Society; +Cc: Bakul Shah Bakul Shah via TUHS <tuhs@tuhs.org> writes: > To build a set of objects you need to worry about at least the > following: > - build recipes for each of them (which may also depend on other > things) > - configuration parameters > - dealing with differences on each platform > - third party libraries & alternatives > - toolchains (& may be cross-platform builds) > - supporting/navigating different versions of the last 3 above > > You can't really precompute all this as there are far too many > combinations and they keep changing. Both the blog author (who is a long-time sysadmin with many 'war stories') and myself understand all that. i believe the idea is not for precomputing to be done by _builds_, but to be done on and for a given machine and its configuration, independent of any specific piece of software, which is then _queried_ by builds. That precomputation would only need to be re-run when one of the things under its purview changes. If i compile something on one of my OpenBSD boxen in the morning, and then compile some other thing in the afternoon, without an OS upgrade in-between, autoconf isn't going to find that libc.so has changed in-between. If i did the same thing on my Gentoo box, it's theoretically possible that e.g. i've moved from glibc to musl in-between, but in that case, precomputation could be done in postinst (i.e. as part of the post-installation-of-musl process). Alexis. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 23:35 ` [TUHS] " Alexis @ 2024-06-21 0:05 ` Warner Losh 2024-06-21 0:34 ` Alexis 2024-06-21 0:35 ` Bakul Shah via TUHS ` (2 subsequent siblings) 3 siblings, 1 reply; 160+ messages in thread From: Warner Losh @ 2024-06-21 0:05 UTC (permalink / raw) To: Alexis; +Cc: The Unix Heritage Society, Bakul Shah [-- Attachment #1: Type: text/plain, Size: 1639 bytes --] On Thu, Jun 20, 2024, 5:35 PM Alexis <flexibeast@gmail.com> wrote: > Bakul Shah via TUHS <tuhs@tuhs.org> writes: > > > To build a set of objects you need to worry about at least the > > following: > > - build recipes for each of them (which may also depend on other > > things) > > - configuration parameters > > - dealing with differences on each platform > > - third party libraries & alternatives > > - toolchains (& may be cross-platform builds) > > - supporting/navigating different versions of the last 3 above > > > > You can't really precompute all this as there are far too many > > combinations and they keep changing. > > Both the blog author (who is a long-time sysadmin with many 'war > stories') and myself understand all that. > > i believe the idea is not for precomputing to be done by _builds_, > but to be done on and for a given machine and its configuration, > independent of any specific piece of software, which is then > _queried_ by builds. That precomputation would only need to be > re-run when one of the things under its purview changes. > > If i compile something on one of my OpenBSD boxen in the morning, > and then compile some other thing in the afternoon, without an OS > upgrade in-between, autoconf isn't going to find that libc.so has > changed in-between. If i did the same thing on my Gentoo box, it's > theoretically possible that e.g. i've moved from glibc to musl > in-between, but in that case, precomputation could be done in > postinst (i.e. as part of the post-installation-of-musl process). > Isn't that what thecautoconf cache is for? Warner > [-- Attachment #2: Type: text/html, Size: 2387 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 0:05 ` Warner Losh @ 2024-06-21 0:34 ` Alexis 2024-06-21 0:54 ` Greg A. Woods 2024-06-21 16:07 ` Chet Ramey via TUHS 0 siblings, 2 replies; 160+ messages in thread From: Alexis @ 2024-06-21 0:34 UTC (permalink / raw) To: The Unix Heritage Society Warner Losh <imp@bsdimp.com> writes: > Isn't that what thecautoconf cache is for? There's a cross-project cache? That is, a cache not just for the project for which autoconf was run, but for _all_ software built on that machine? (Over the decades i've regularly observed instances where autoconf doesn't seem to be making use of results of its previous runs for a particular project; i don't know if that's because the build maintainer didn't configure autoconf correctly. My own dev/doc work hasn't required me to wrestle with autoconf.) Alexis. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 0:34 ` Alexis @ 2024-06-21 0:54 ` Greg A. Woods 2024-06-21 1:06 ` G. Branden Robinson 2024-06-21 1:32 ` Alexis 2024-06-21 16:07 ` Chet Ramey via TUHS 1 sibling, 2 replies; 160+ messages in thread From: Greg A. Woods @ 2024-06-21 0:54 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 1766 bytes --] At Fri, 21 Jun 2024 10:34:46 +1000, Alexis <flexibeast@gmail.com> wrote: Subject: [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register > > Warner Losh <imp@bsdimp.com> writes: > > > Isn't that what thecautoconf cache is for? > > There's a cross-project cache? That is, a > cache not just for the project for which > autoconf was run, but for _all_ software > built on that machine? Indeed there is. Nothing new about it either. It's been around for two decades or more. From autoconf.info (with variants going back at least as far as 2002): 7.4.2 Cache Files .... The site initialization script can specify a site-wide cache file to use, instead of the usual per-program cache. In this case, the cache file gradually accumulates information whenever someone runs a new ‘configure’ script. There's a pkgsrc.org package, pkgtools/autoswc, that makes it all work cleanly for NetBSD and other platforms using pkgsrc, caching just the stuff that's known to be invariant (by pre-filling a static cache using a big monster "fake" configure script that covers most of the generic tests) and letting other stuff be handled at runtime. It can be a bit fragile, especially in the "gradually accumulates" way of using it (which is why pkgsrc avoids that), but usually the fault lies squarely on the shoulders of developers who either don't read the Autoconf documentation, or think that somehow they're smarter than Autoconf and the many decades of lore it encodes. -- Greg A. Woods <gwoods@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> [-- Attachment #2: OpenPGP Digital Signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 0:54 ` Greg A. Woods @ 2024-06-21 1:06 ` G. Branden Robinson 2024-06-21 1:32 ` Alexis 1 sibling, 0 replies; 160+ messages in thread From: G. Branden Robinson @ 2024-06-21 1:06 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 809 bytes --] At 2024-06-20T17:54:22-0700, Greg A. Woods wrote: > At Fri, 21 Jun 2024 10:34:46 +1000, Alexis <flexibeast@gmail.com> wrote: > > There's a cross-project [autoconf] cache? That is, a cache not just > > for the project for which autoconf was run, but for _all_ software > > built on that machine? > > Indeed there is. Nothing new about it either. It's been around for two > decades or more. [...] > It can be a bit fragile, especially in the "gradually accumulates" way > of using it (which is why pkgsrc avoids that), but usually the fault > lies squarely on the shoulders of developers who either don't read the > Autoconf documentation, or think that somehow they're smarter than > Autoconf and the many decades of lore it encodes. Hard to believe such people exist! Regards, Branden [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 0:54 ` Greg A. Woods 2024-06-21 1:06 ` G. Branden Robinson @ 2024-06-21 1:32 ` Alexis 2024-06-21 1:43 ` Warner Losh 1 sibling, 1 reply; 160+ messages in thread From: Alexis @ 2024-06-21 1:32 UTC (permalink / raw) To: The Unix Heritage Society mailing list "Greg A. Woods" <woods@robohack.ca> writes: > Indeed there is. Nothing new about it either. It's been around > for two > decades or more. TIL - thank you! i've never seen this mentioned before. (Perhaps because i only use autoconf as an end-user, rather than as a dev.) Looking at section 15.8 of that manual, it looks like i could specify that `-C` / `--config-cache` be passed to configure by default site-wide. So i might do so on my Gentoo system - given most things on that system are locally compiled, it might be an interesting stress-test data-point regarding configuration caching. Alexis. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 1:32 ` Alexis @ 2024-06-21 1:43 ` Warner Losh 0 siblings, 0 replies; 160+ messages in thread From: Warner Losh @ 2024-06-21 1:43 UTC (permalink / raw) To: Alexis; +Cc: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 1017 bytes --] On Thu, Jun 20, 2024, 7:32 PM Alexis <flexibeast@gmail.com> wrote: > "Greg A. Woods" <woods@robohack.ca> writes: > > > Indeed there is. Nothing new about it either. It's been around > > for two > > decades or more. > > TIL - thank you! i've never seen this mentioned before. (Perhaps > because i only use autoconf as an end-user, rather than as a dev.) > I used it on OpenBSD in the 90s to make ports builds go much faster in the days before pkgsrc was a going concern. It made a huge difference on my arc machine that was about P75 speed, the speed of a pentium clocked at 75MHz.... it was an R4000PC running at 100MHz iirc. Warner Looking at section 15.8 of that manual, it looks like i could > specify that `-C` / `--config-cache` be passed to configure by > default site-wide. So i might do so on my Gentoo system - given > most things on that system are locally compiled, it might be an > interesting stress-test data-point regarding configuration > caching. > > > Alexis. > [-- Attachment #2: Type: text/html, Size: 1719 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 0:34 ` Alexis 2024-06-21 0:54 ` Greg A. Woods @ 2024-06-21 16:07 ` Chet Ramey via TUHS 1 sibling, 0 replies; 160+ messages in thread From: Chet Ramey via TUHS @ 2024-06-21 16:07 UTC (permalink / raw) To: Alexis, The Unix Heritage Society [-- Attachment #1.1: Type: text/plain, Size: 1183 bytes --] On 6/20/24 8:34 PM, Alexis wrote: > Warner Losh <imp@bsdimp.com> writes: > >> Isn't that what thecautoconf cache is for? > > There's a cross-project cache? That is, a cache not just for the project > for which autoconf was run, but for _all_ software built on that machine? Well, `all' is pretty broad. You can set some site-specific defaults: https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Site-Defaults.html and use a site-specific cache file: https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Cache-Files.html This cache file can be written by every `configure' run, if you like. It's just a shell script. > (Over the decades i've regularly observed instances where autoconf doesn't > seem to be making use of results of its previous runs for a particular > project; i don't know if that's because the build maintainer didn't > configure autoconf correctly. You have to tell configure to use the cache file. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 203 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 23:35 ` [TUHS] " Alexis 2024-06-21 0:05 ` Warner Losh @ 2024-06-21 0:35 ` Bakul Shah via TUHS 2024-06-21 1:15 ` Alexis 2024-06-21 0:35 ` Larry McVoy 2024-06-21 15:57 ` Chet Ramey via TUHS 3 siblings, 1 reply; 160+ messages in thread From: Bakul Shah via TUHS @ 2024-06-21 0:35 UTC (permalink / raw) To: Alexis; +Cc: The Unix Heritage Society mailing list > On Jun 20, 2024, at 4:35 PM, Alexis <flexibeast@gmail.com> wrote: > > If i compile something on one of my OpenBSD boxen in the morning, and then compile some other thing in the afternoon, without an OS upgrade in-between, autoconf isn't going to find that libc.so has changed in-between. If i did the same thing on my Gentoo box, it's theoretically possible that e.g. i've moved from glibc to musl in-between, but in that case, precomputation could be done in postinst (i.e. as part of the post-installation-of-musl process). But the overlap between two different programs or their assumptions will be only partial (except for some very basic things) which likely means the cache won't quite work. For example, you may find that program A and B depend on different versions of some library C. And how does the configure or whatever tool find out that no dependency has changed? I don't think you can factor out a cache of such data to a global place that will work for every ported program. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 0:35 ` Bakul Shah via TUHS @ 2024-06-21 1:15 ` Alexis 2024-06-21 1:43 ` segaloco via TUHS 0 siblings, 1 reply; 160+ messages in thread From: Alexis @ 2024-06-21 1:15 UTC (permalink / raw) To: The Unix Heritage Society; +Cc: Bakul Shah Bakul Shah <bakul@iitbombay.org> writes: > But the overlap between two different programs or their > assumptions > will be > only partial (except for some very basic things) which likely > means > the cache > won't quite work. For example, you may find that program A and B > depend on different versions of some library C. The basic things are, in fact, a significant part of what autoconf is being used to check for. "Does this platform provide this function?" And that doesn't significantly change between versions of the specific libc used by the system (glibc, musl, the *BSD libcs, etc.); due to their nature as a fundamental part of the system, they're relatively conservative (compared to higher-level libraries and applications) as to the rate at which they change, and what they add and remove. i've only rarely encountered libc version issues when compiling many pieces of software for my use over the years. For higher-level libraries, there's pkg-config and its reimplementations, such as pkgconf: > pkgconf is a program which helps to configure compiler and > linker flags for development libraries. This allows build > systems to detect other dependencies and use them with the > system toolchain. -- pkgconf(1), https://www.mankier.com/1/pkgconf which can (and does) get _used_ by autoconf, but is a standalone project. (Which is not to say i'm endorsing the system, just that it exists, and is independent of the autoconf system.) > And how does the > configure or whatever > tool find out that no dependency has changed? I don't think you > can > factor > out a cache of such data to a global place that will work for > every > ported > program. You're right: not for _every_ ported program. But even if the cache worked for _most_, and simplified the build processes of _most_ programs, thus reducing the complexity needing to be understood by build maintainers, and reducing the complexity available for malfeasants to hide backdoors, that would still be a significant win, in my opinion. Don't let the perfect be the enemy of the good, etc. Alexis. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 1:15 ` Alexis @ 2024-06-21 1:43 ` segaloco via TUHS 2024-06-21 13:58 ` Alan D. Salewski 0 siblings, 1 reply; 160+ messages in thread From: segaloco via TUHS @ 2024-06-21 1:43 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Thursday, June 20th, 2024 at 6:15 PM, Alexis <flexibeast@gmail.com> wrote: > Bakul Shah bakul@iitbombay.org writes: > > > But the overlap between two different programs or their > > assumptions > > will be > > only partial (except for some very basic things) which likely > > means > > the cache > > won't quite work. For example, you may find that program A and B > > depend on different versions of some library C. > > > The basic things are, in fact, a significant part of what autoconf > is being used to check for. "Does this platform provide this > function?" > > ... > > > Alexis. This aspect of things I have found a bit perplexing. On one hand, sure, it's nice to have some scripted system spit out a: "Dependency xyz not found" But where it falls apart in my head is what that tells me that, for instance, cpp's error diagnostic about a missing include or ld saying a symbol or library wasn't found does. It's in my mind a minor convenience but one that doesn't justify all the machinery between one's self and make just to provide. Granted that's not all autotools does, so a poor example in practice, but in theory gets at one of my irks, packaging something that you are already going to discover some other way. That and "does my target platform list support xyz" isn't necessarily a matter I'd wait until I've created a whole build package around my software to settle... Just a small part of the puzzle but one of the parts that gives me more headaches than not. Now I don't get to respond to a compiler or linker asking for something by putting it where it asked for it, now I also have to figure out how to do the extra work to ensure that it's put somewhere and in a way that all this machinery between myself and the compiler can also verify in its own magical way component <xyz> is present. I'd be willing to wager that half the time autotools, cmake, etc has made me want to put my head through a wall is not that some needed thing isn't there, it's just that it's not there according to whatever extra expectations or formulas come into play just to satisfy the build machinery. These tools can be helpful in the face of extreme complexity, but I feel silly when most of the work I put into compiling some package that's like 6 source files is making sure the environment on my system can satisfy the expectations of the build tools. It has been said already that part of the problem too with the uptake of these tools and their growing ubiquity is new folks who don't know any better think that's just "how it is" and then wind up spinning an autotools or cmake build for a <1000 line tool written in ANSI C. I've done the same in less experienced times, one of my first attempts at a game engine uses an autotools build. I quickly grew frustrated with it and everything since has used a flat makefile and has been just fine. Granted I'm not building a triple A game, but that gets at the root of one of my gripes, I think these sorts of frameworks are overused. They have their areas that they shine, or they wouldn't have reached the critical mass they have, but as consequence folks will use them haphazardly regardless of the need. Long story short, maybe gcc needs a configure script, but does GNU ed? Maybe KDE Plasma needs CMake files, but does libtiff? I make no claims regarding the complexity of these actual codebases...but one does have to wonder... - Matt G. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 1:43 ` segaloco via TUHS @ 2024-06-21 13:58 ` Alan D. Salewski 0 siblings, 0 replies; 160+ messages in thread From: Alan D. Salewski @ 2024-06-21 13:58 UTC (permalink / raw) To: TUHS (The Unix Heritage Society) On Thu, Jun 20, 2024, at 21:43, segaloco via TUHS wrote: > On Thursday, June 20th, 2024 at 6:15 PM, Alexis <flexibeast@gmail.com> wrote: > [...] >> The basic things are, in fact, a significant part of what autoconf >> is being used to check for. "Does this platform provide this >> function?" >> >> ... >> >> >> Alexis. > > This aspect of things I have found a bit perplexing. On one hand, > sure, it's nice to have some scripted system spit out a: > > "Dependency xyz not found" > > But where it falls apart in my head is what that tells me that, for > instance, cpp's error diagnostic about a missing include or ld saying a > symbol or library wasn't found does. It's in my mind a minor > convenience but one that doesn't justify all the machinery between > one's self and make just to provide. Granted that's not all autotools > does, so a poor example in practice, but in theory gets at one of my > irks, packaging something that you are already going to discover some > other way. That and "does my target platform list support xyz" isn't > necessarily a matter I'd wait until I've created a whole build package > around my software to settle... > > Just a small part of the puzzle but one of the parts that gives me more > headaches than not. Now I don't get to respond to a compiler or linker > asking for something by putting it where it asked for it, now I also > have to figure out how to do the extra work to ensure that it's put > somewhere and in a way that all this machinery between myself and the > compiler can also verify in its own magical way component <xyz> is > present. [...] The thing about the autotools is that there are two different audiences for different aspects of the system: consumers of the package (sysadmins, porters, distro packagers...) and developers. In general, the developers need to work a little harder to make life of the consumers easier. While some consumers might be fine with (to use the example above) a cpp error diagnostic about a missing include, I imagine most would prefer a "configure time" diagnostic explaining that dependency package foo needs to be installed before they try to build it. Those who are not C or C++ developers wouldn't necessarily know what cpp is, or how to control it.[0] I, for one, appreciate that pretty much any build tool can be integrated into the autotools framework, in part because it acts as a barrier between the consumers and the underlying language-specific build tooling, etc. The same could be (and has been) said of portable Makefiles, but the level of effort would be quite high to achieve what the autotools-generated Makefiles produce out of the box. E.g., the 'make distcheck' target not only drives a full configure and build in a temporary directory, but also verifies that a VPATH build (building separately from the source tree) works. Language-specific build mechanisms are fine as far as it goes. But the more of them you encounter and need to interact with directly, the more friction there is. The audience for such tools is primarily the developer. Python's pip, JavaScript's npm (or yarn, or ...), golang, Rust's cargo, Java's mvn (or ant, or ivy, or ...), Clojure's lein, Perl's ExtUtils::MakeMaker (or Module::Build, or ...), Ruby's gem, ... And tooling to produce documentation is even worse: DocBook, AsciiDoc, reStructuredText. Even driving LaTeX has become complicated (PDFLaTeX, XeTeX, LuaTeX, ...). The developer who necessarily understands such things can, with some effort, integrate them into an autotools build, making life much easier for the consumers of the package (assuming the integration has been done well). When the audience or consumer of the package is sysadmins (including end-users acting as their own sysadmin), porters, and distro packagers, I think "the usual dance" of "./configure && make" is nice because it is consistent across underlying languages, compilers, and whatever auxiliary tools are needed to produce documentation, etc. And I happen to like m4 :-) *ducks* -Al [0] Sadly, the days when C was the lingua franca amongst programmers seem to be behind us. -- a l a n d. s a l e w s k i ads@salewski.email salewski@att.net https://github.com/salewski ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 23:35 ` [TUHS] " Alexis 2024-06-21 0:05 ` Warner Losh 2024-06-21 0:35 ` Bakul Shah via TUHS @ 2024-06-21 0:35 ` Larry McVoy 2024-06-21 0:49 ` Alexis 2024-06-21 15:57 ` Chet Ramey via TUHS 3 siblings, 1 reply; 160+ messages in thread From: Larry McVoy @ 2024-06-21 0:35 UTC (permalink / raw) To: Alexis; +Cc: The Unix Heritage Society, Bakul Shah Are we into bike shed territory? It seems like cmake and autoconf are hated but then they have their fans. I posted a makefile that was pretty portable but that was not OK because it was GNU make? Huh? I've been up since 12:22am (psyched for fishing, couldn't sleep) so maybe I'm not on point, but what is the problem that this discussion is trying to solve? On Fri, Jun 21, 2024 at 09:35:18AM +1000, Alexis wrote: > Bakul Shah via TUHS <tuhs@tuhs.org> writes: > > >To build a set of objects you need to worry about at least the > >following: > >- build recipes for each of them (which may also depend on other > >things) > >- configuration parameters > >- dealing with differences on each platform > >- third party libraries & alternatives > >- toolchains (& may be cross-platform builds) > >- supporting/navigating different versions of the last 3 above > > > >You can't really precompute all this as there are far too many > >combinations and they keep changing. > > Both the blog author (who is a long-time sysadmin with many 'war stories') > and myself understand all that. > > i believe the idea is not for precomputing to be done by _builds_, but to be > done on and for a given machine and its configuration, independent of any > specific piece of software, which is then _queried_ by builds. That > precomputation would only need to be re-run when one of the things under its > purview changes. > > If i compile something on one of my OpenBSD boxen in the morning, and then > compile some other thing in the afternoon, without an OS upgrade in-between, > autoconf isn't going to find that libc.so has changed in-between. If i did > the same thing on my Gentoo box, it's theoretically possible that e.g. i've > moved from glibc to musl in-between, but in that case, precomputation could > be done in postinst (i.e. as part of the post-installation-of-musl process). > > > Alexis. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 0:35 ` Larry McVoy @ 2024-06-21 0:49 ` Alexis 2024-06-21 1:22 ` Greg A. Woods 0 siblings, 1 reply; 160+ messages in thread From: Alexis @ 2024-06-21 0:49 UTC (permalink / raw) To: The Unix Heritage Society Larry McVoy <lm@mcvoy.com> writes: > I've been up since 12:22am (psyched for fishing, couldn't sleep) > so > maybe I'm not on point, but what is the problem that this > discussion > is trying to solve? The complexity of the autoconf-based build process contributed to the xz-utils backdoor attempt. (Here's Russ Cox's writeup: https://research.swtch.com/xz-script) So, to what extent is the complexity of autoconf _needed_ nowadays? For some cases, it's not needed (and might never have been needed). For others, it seems like it might still be needed. What about the in-between cases? Can we do something different that gets us 90% of what autoconf provides in those cases, but with only 10% of the complexity (to use those commonly-provided figures)? Alexis. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 0:49 ` Alexis @ 2024-06-21 1:22 ` Greg A. Woods 2024-06-21 1:44 ` Kevin Bowling 0 siblings, 1 reply; 160+ messages in thread From: Greg A. Woods @ 2024-06-21 1:22 UTC (permalink / raw) To: The Unix Heritage Society mailing list; +Cc: The Unix Heritage Society [-- Attachment #1: Type: text/plain, Size: 1692 bytes --] At Fri, 21 Jun 2024 10:49:34 +1000, Alexis <flexibeast@gmail.com> wrote: Subject: [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register > > So, > to what extent is the complexity of > autoconf _needed_ nowadays? For xz in particular Autoconf is _probably_ not necessary, but I haven't examined it in detail. For a vast amount of application C code and libraries no build-time configuration beyond what's provided by the system headers and the C compiler is necessary. This is especially true if the code is designed to require a slightly "modern" version of C, such as iso9899:1999 (perhaps with GNU CC extensions). There are however some things in more systems level programs and libraries that are more difficult to handle even with well written code, but compared to the number of tests offered by the likes of Autoconf, well those things are actually very few. One thing that Autoconf gets used for, but for which it is not really necessary, is for choosing build-time options. Indeed its feature set for doing so is complex and error-prone to use! Too much weird mixing of shell scripts and M4 macros, with all the quoting nightmare this brings. Just try to read XZ's configure.ac! A simple declarative configuration file, such as a Makefile fragment, is sufficient. When you wander into the realm of non-C code things might also be a bit more complex, unless of course it's Go code, where this problem simply doesn't exist in the first place. -- Greg A. Woods <gwoods@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> [-- Attachment #2: OpenPGP Digital Signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 1:22 ` Greg A. Woods @ 2024-06-21 1:44 ` Kevin Bowling 0 siblings, 0 replies; 160+ messages in thread From: Kevin Bowling @ 2024-06-21 1:44 UTC (permalink / raw) To: The Unix Heritage Society mailing list On Thu, Jun 20, 2024 at 6:22 PM Greg A. Woods <woods@robohack.ca> wrote: > > At Fri, 21 Jun 2024 10:49:34 +1000, Alexis <flexibeast@gmail.com> wrote: > Subject: [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register > > > > So, > > to what extent is the complexity of > > autoconf _needed_ nowadays? > > For xz in particular Autoconf is _probably_ not necessary, but I haven't > examined it in detail. > > For a vast amount of application C code and libraries no build-time > configuration beyond what's provided by the system headers and the C > compiler is necessary. This is especially true if the code is designed > to require a slightly "modern" version of C, such as iso9899:1999 > (perhaps with GNU CC extensions). > > There are however some things in more systems level programs and > libraries that are more difficult to handle even with well written code, > but compared to the number of tests offered by the likes of Autoconf, > well those things are actually very few. Warner sufficiently summed up the philosophical reason for the probe-the-world-after-slumber approach. It seems foolish at first; a waste of time/cycles; but the deeper you dig into the problem space the less foolish it becomes. As an example, autoconf builds easily handle cross toolchains or shimmed toolchains where a mix of native and emulated tools are used to speed up cross builds. I agree with the chorus that the implementation of autoconf is awful. But the audience that assume that autoconf is also bad, and the bits and bobs of shell and make are somehow equivalent, is living in a state of willful ignorance. > One thing that Autoconf gets used for, but for which it is not really > necessary, is for choosing build-time options. Indeed its feature set > for doing so is complex and error-prone to use! Too much weird mixing > of shell scripts and M4 macros, with all the quoting nightmare this > brings. Just try to read XZ's configure.ac! A simple declarative > configuration file, such as a Makefile fragment, is sufficient. > > When you wander into the realm of non-C code things might also be a bit > more complex, unless of course it's Go code, where this problem simply > doesn't exist in the first place. Go's approach was the same as Java, if you control the level of abstraction sufficiently you eliminate much of the complexity. > > -- > Greg A. Woods <gwoods@acm.org> > > Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> > Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-20 23:35 ` [TUHS] " Alexis ` (2 preceding siblings ...) 2024-06-21 0:35 ` Larry McVoy @ 2024-06-21 15:57 ` Chet Ramey via TUHS 2024-06-22 0:04 ` Alexis 3 siblings, 1 reply; 160+ messages in thread From: Chet Ramey via TUHS @ 2024-06-21 15:57 UTC (permalink / raw) To: tuhs [-- Attachment #1.1: Type: text/plain, Size: 1289 bytes --] On 6/20/24 7:35 PM, Alexis wrote: > i believe the idea is not for precomputing to be done by _builds_, but to > be done on and for a given machine and its configuration, independent of > any specific piece of software, which is then _queried_ by builds. That > precomputation would only need to be re-run when one of the things under > its purview changes. This is the rationale behind local (package-specific) and global (site- specific) versions of config.cache and `configure -C'. I use them all the time; they reduce configuration time considerably. (But then, I am probably building more often than someone who just downloads a source tarball, builds it, and installs the result.) > If i compile something on one of my OpenBSD boxen in the morning, and then > compile some other thing in the afternoon, without an OS upgrade > in-between, autoconf isn't going to find that libc.so has changed > in-between. configure and config.cache compute the results for a given build environment. If you change that, whose responsibility is it to update the dependencies? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 203 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-21 15:57 ` Chet Ramey via TUHS @ 2024-06-22 0:04 ` Alexis 2024-06-22 17:53 ` Chet Ramey via TUHS 0 siblings, 1 reply; 160+ messages in thread From: Alexis @ 2024-06-22 0:04 UTC (permalink / raw) To: The Unix Heritage Society Chet Ramey via TUHS <tuhs@tuhs.org> writes: > On 6/20/24 7:35 PM, Alexis wrote: >> If i compile something on one of my OpenBSD boxen in the >> morning, >> and then compile some other thing in the afternoon, without an >> OS >> upgrade in-between, autoconf isn't going to find that libc.so >> has >> changed in-between. > > configure and config.cache compute the results for a given build > environment. If you change that, whose responsibility is it to > update > the > dependencies? Sorry, i'm not sure i understand your question, particularly given that i was writing about the situation where a fundamental part of the build environment _hasn't_ changed .... Could you please elaborate or rephrase? Alexis. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-22 0:04 ` Alexis @ 2024-06-22 17:53 ` Chet Ramey via TUHS 2024-06-22 18:15 ` Luther Johnson 0 siblings, 1 reply; 160+ messages in thread From: Chet Ramey via TUHS @ 2024-06-22 17:53 UTC (permalink / raw) To: Alexis, The Unix Heritage Society [-- Attachment #1.1: Type: text/plain, Size: 1212 bytes --] On 6/21/24 5:04 PM, Alexis wrote: > Chet Ramey via TUHS <tuhs@tuhs.org> writes: > >> On 6/20/24 7:35 PM, Alexis wrote: > >>> If i compile something on one of my OpenBSD boxen in the morning, >>> and then compile some other thing in the afternoon, without an OS >>> upgrade in-between, autoconf isn't going to find that libc.so has >>> changed in-between. >> >> configure and config.cache compute the results for a given build >> environment. If you change that, whose responsibility is it to update >> the >> dependencies? > > Sorry, i'm not sure i understand your question, particularly given that i > was writing about the situation where a fundamental part of the build > environment _hasn't_ changed .... Could you please elaborate or rephrase? I think we're kind of saying the same thing. The autotools can't update dependencies if something in the environment changes, regardless of whether an OS update has occurred or not. That responsibility has to fall on the admin or other tools. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 203 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-22 17:53 ` Chet Ramey via TUHS @ 2024-06-22 18:15 ` Luther Johnson 2024-06-22 21:16 ` David Arnold 2024-06-23 18:56 ` Chet Ramey via TUHS 0 siblings, 2 replies; 160+ messages in thread From: Luther Johnson @ 2024-06-22 18:15 UTC (permalink / raw) To: tuhs If I could say something a little more meta, and echoing an earlier comment - autotools, configure, etc, don't do the port for you - it's up to the author to decide and test what OS features are required, and if something hasn't been too implicitly assumed, if a "needs this" hasn't been left out, then the "configure && make" process will give you the right build for a system that is indeed, already supported. If it doesn't build, we can interpret that as "not supported", or that the author did not sufficiently adjust input to the build process, or test similar-enough configurations, to get the right build for that system. But that is not an indictment of this whole way of doing things, or the tools themselves, necessarily. It may just mean that someone made some fairly ordinary mistake along the way in setting up the build. Or that the system on which we are trying to build is different in a way that the author did not imagine. On 06/22/2024 10:53 AM, Chet Ramey via TUHS wrote: > On 6/21/24 5:04 PM, Alexis wrote: >> Chet Ramey via TUHS <tuhs@tuhs.org> writes: >> >>> On 6/20/24 7:35 PM, Alexis wrote: >> >>>> If i compile something on one of my OpenBSD boxen in the morning, >>>> and then compile some other thing in the afternoon, without an OS >>>> upgrade in-between, autoconf isn't going to find that libc.so has >>>> changed in-between. >>> >>> configure and config.cache compute the results for a given build >>> environment. If you change that, whose responsibility is it to update >>> the >>> dependencies? >> >> Sorry, i'm not sure i understand your question, particularly given >> that i was writing about the situation where a fundamental part of >> the build environment _hasn't_ changed .... Could you please >> elaborate or rephrase? > > I think we're kind of saying the same thing. The autotools can't update > dependencies if something in the environment changes, regardless of > whether > an OS update has occurred or not. That responsibility has to fall on the > admin or other tools. > ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-22 18:15 ` Luther Johnson @ 2024-06-22 21:16 ` David Arnold 2024-06-23 0:29 ` segaloco via TUHS 2024-06-23 18:50 ` Theodore Ts'o 2024-06-23 18:56 ` Chet Ramey via TUHS 1 sibling, 2 replies; 160+ messages in thread From: David Arnold @ 2024-06-22 21:16 UTC (permalink / raw) To: Luther Johnson; +Cc: tuhs > On 23 Jun 2024, at 04:16, Luther Johnson <luther.johnson@makerlisp.com> wrote: > > If I could say something a little more meta, and echoing an earlier > comment - autotools, configure, etc, don't do the port for you - it's up > to the author to decide and test what OS features are required, and if > something hasn't been too implicitly assumed, if a "needs this" hasn't > been left out, then the "configure && make" process will give you the > right build for a system that is indeed, already supported. If it > doesn't build, we can interpret that as "not supported", or that the > author did not sufficiently adjust input to the build process, or test > similar-enough configurations, to get the right build for that system. The author thus ends up searching for a sweet spot: test too many things, and people complain that you’re wasting time checking something that is always true; test too few, and it will break on relatively common platforms. As an example, mentioned up-thread, building on Ultrix in 2024: you need to test and work around a bunch of things that have been fixed on anything updated since the mid-90’s to get a clean build on Ultrix, SunOS-4.x, etc. Your average Linux or macOS user sees this as pointless time wasting. There’s no right answer here: someone is always annoyed at you. d ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-22 21:16 ` David Arnold @ 2024-06-23 0:29 ` segaloco via TUHS 2024-06-23 18:50 ` Theodore Ts'o 1 sibling, 0 replies; 160+ messages in thread From: segaloco via TUHS @ 2024-06-23 0:29 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Saturday, June 22nd, 2024 at 2:16 PM, David Arnold <davida@pobox.com> wrote: > > On 23 Jun 2024, at 04:16, Luther Johnson luther.johnson@makerlisp.com wrote: > > > > If I could say something a little more meta, and echoing an earlier > > comment - autotools, configure, etc, don't do the port for you - it's up > > to the author to decide and test what OS features are required, and if > > something hasn't been too implicitly assumed, if a "needs this" hasn't > > been left out, then the "configure && make" process will give you the > > right build for a system that is indeed, already supported. If it > > doesn't build, we can interpret that as "not supported", or that the > > author did not sufficiently adjust input to the build process, or test > > similar-enough configurations, to get the right build for that system. > > > The author thus ends up searching for a sweet spot: test too many things, and people complain that you’re wasting time checking something that is always true; test too few, and it will break on relatively common platforms. > > As an example, mentioned up-thread, building on Ultrix in 2024: you need to test and work around a bunch of things that have been fixed on anything updated since the mid-90’s to get a clean build on Ultrix, SunOS-4.x, etc. Your average Linux or macOS user sees this as pointless time wasting. > > There’s no right answer here: someone is always annoyed at you. > > > > > d Well and part of that is indeed being intentional about platform support, fancy toolkit or not. If you're specifically intending to support just a particular vendor's platform, you make programming choices, not build machinery choices, towards that end. Similarly, if you truly expect something you write to work everywhere with minimal modification, no amount of build machinery is a substitute for pulling up and adhering as closely to POSIX as possible, same with non-UNIX platforms and being intentional about ANSI C. Now, if you're trying to use things these least common denominators don't include, like for instance ANSI C+thread support, build machinery still isn't going to be what makes your program work, you have to write or otherwise incorporate an abstraction layer over the available system services, be it pthreads, Win32 threads, etc. That all said, one excellent point I must agree with up thread is that a build system will be used by a small handful of devs but then countless consumers who aren't experts in programming and that expect things to "just work". We as programmers may be fine with an "alias cc=<insert cross-compiler here>" to avoid some lengthy cross-compiler detection mechanism in our own development process, but tell every consumer they have to set a bunch of environment variables and/or aliases to get a makefile to work and they'll throw their hands up and look for something with a configure script *even if* the former really is an easier and more dependable way to get exactly what you want. I say this because the former is how I've handled personal projects for a bit now, if I do need any environmental difference from the flat makefile in my project, I setup that environment just-in-time by hand, which usually just amounts to aliasing a command or too, maybe adding to LD_LIBRARY_PATH, that sort of thing, or if it's frequent enough, just do this with a teeny tiny script. I like the control and terseness of the setup, but throw that at someone who is used to using a package manager or at most using a configure script or CMake, and yeah, they'd probably balk at the lack of "sophistication" in your distributable. Looking at it as an accessibility matter rather than a developmental necessity certainly gives me different feelings about all this stuff. I may not need it and indeed would likely be mildly inconvenienced in some situations, but for someone else, it's a crucial piece of their experience. These words may ring true about the original subject of systemd as well... - Matt G. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-22 21:16 ` David Arnold 2024-06-23 0:29 ` segaloco via TUHS @ 2024-06-23 18:50 ` Theodore Ts'o 1 sibling, 0 replies; 160+ messages in thread From: Theodore Ts'o @ 2024-06-23 18:50 UTC (permalink / raw) To: David Arnold; +Cc: Luther Johnson, tuhs On Sun, Jun 23, 2024 at 07:16:35AM +1000, David Arnold wrote: > > As an example, mentioned up-thread, building on Ultrix in 2024: you > need to test and work around a bunch of things that have been fixed > on anything updated since the mid-90’s to get a clean build on > Ultrix, SunOS-4.x, etc. Your average Linux or macOS user sees this > as pointless time wasting. In practice, the set of OS's which a particular software package using autotools will change over time. For me and e2fsprogs, just to give a concrete example, there is the set of packages for which I personally have access to. Many years ago this included Ultrix, OSF/1, AIX, Irix, and Solaris; and when I did have easy access to those machines, it wasn't hard for me to do a test compile, and when things broke, it was easy enough to add (or write) an autoconf test, and fix that particular build or test breakage. There would also be OS's for which I did not have direct access --- for example HPUX, where (a) sometimes the portability work that I did for AIX or Solaris would address eome portability issue on HPUX, or (b) someone building the package on HPUX would send me a bug report, and in general, it would be really easy to fix up the sources so that things worked on HPUX. So surprise, Autotools is not magic. It will not magically make your code portable. However, for someone who *wants* to make portable code, I've found autotools to be the most developer friendly way of supporting portable code. Certainly, it's ***way*** more user-friendly than imake, for which I have had the misfortune of having to have used, and because autotools is test features, and not OS's, it's much easier to support than needing to have a manually curated set of #define's for each OS that you want to support. (I can't beieve people think that's a good idea; I would find that incredibly painful and would involve much more work.) What does happen over time, though, is that when the maintainer, or the development commuity at large, loses access to an hardware and/or OS combination, support for that that platform will start to rot, and things will gradully start breaking as new feature development will accidentally add some dependency which can't be guaranteed everywhere. Yes, you can have someone strictly trying to require that no advanced feature beyond that which was available in BSD 4.3 be used, in the name of portability, but sometimes there are real functional and performance sacrifices that might get made if you do that. > There’s no right answer here: someone is always annoyed at you. Indeed, and there will always be people who want to backseat drive and tell you that you should do things their way. I find there's a lot of religion wrapped up here, much like the choice of ed, vi or emacs.... - Ted ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-22 18:15 ` Luther Johnson 2024-06-22 21:16 ` David Arnold @ 2024-06-23 18:56 ` Chet Ramey via TUHS 2024-06-23 20:15 ` Stuff Received 1 sibling, 1 reply; 160+ messages in thread From: Chet Ramey via TUHS @ 2024-06-23 18:56 UTC (permalink / raw) To: Luther Johnson, tuhs [-- Attachment #1.1: Type: text/plain, Size: 648 bytes --] On 6/22/24 2:15 PM, Luther Johnson wrote: > It may just mean that someone made some > fairly ordinary mistake along the way in setting up the build. Or that > the system on which we are trying to build is different in a way that > the author did not imagine. A third possibility is that the author or authors decided not to test for and support a set of (in this case) older systems. Not a lack of imagination, but a development priority decision. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 203 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-23 18:56 ` Chet Ramey via TUHS @ 2024-06-23 20:15 ` Stuff Received 2024-06-24 14:03 ` Theodore Ts'o 2024-06-24 15:23 ` Chet Ramey via TUHS 0 siblings, 2 replies; 160+ messages in thread From: Stuff Received @ 2024-06-23 20:15 UTC (permalink / raw) To: tuhs On 2024-06-23 14:56, Chet Ramey via TUHS wrote: > On 6/22/24 2:15 PM, Luther Johnson wrote: >> It may just mean that someone made some >> fairly ordinary mistake along the way in setting up the build. Or that >> the system on which we are trying to build is different in a way that >> the author did not imagine. > > A third possibility is that the author or authors decided not to test for > and support a set of (in this case) older systems. Not a lack of > imagination, but a development priority decision. My opinion is that the authors simply did not have access to other systems or were not interested. Sometimes, one finds a disclaimer to that effect. I understand that but I am irked when they claim POSIX compliance. S. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-23 20:15 ` Stuff Received @ 2024-06-24 14:03 ` Theodore Ts'o 2024-06-24 14:33 ` Dan Cross 2024-06-24 15:23 ` Chet Ramey via TUHS 1 sibling, 1 reply; 160+ messages in thread From: Theodore Ts'o @ 2024-06-24 14:03 UTC (permalink / raw) To: Stuff Received; +Cc: tuhs On Sun, Jun 23, 2024 at 04:15:40PM -0400, Stuff Received wrote: > My opinion is that the authors simply did not have access to other > systems or were not interested. Sometimes, one finds a disclaimer to > that effect. I understand that but I am irked when they claim POSIX > compliance. I get irked because Posix compliance applies to OS's (a specific binary release of the kernel plus userspace runtime environment), and not to applications. Also, compliance implies that it has passed a specific test process, after paying $$$$ to a Posix Test Compliance Lab, and said compliance certificate gets revoked the moment you fix a security bug, until you go and you pay additional $$$ to the Posix compliance lab. Basically, it's racket that generally only companies who need to sell into the US or European government market were willing to play. (e.g., at one point there were Red Hat and SuSE distributions which were POSIX certified, but Fedora or Debian never were.) A project or vendor could claim that there product was a "strictly conforming POSIX application[1], but that's hard to actually prove (which is why there is no compliance testing for it), since not only do you have to limit yourself to only those interface guaranted to be present by POSIX, but you must also not depend on any behavior which specified to be "implementation defined" (and very often many traditional Unix behaviors are technically "implementation defined", so that VMS and Windows could claim to be be "POSIX compliant implementation".) So a strictly POSIX conforming application was likely only relevant for very simple "toy" applications that didn't need to do anything fancy, like say, networking. (Berkeley sockets couldn't be required because AT&T Streams. Oh, joy.) [1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#tag_02_02_01 Can you tell I'm a bit jaded and cynical about the whole Posix compliance/conformance thing? :-) Cheers, - Ted ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-24 14:03 ` Theodore Ts'o @ 2024-06-24 14:33 ` Dan Cross 2024-06-24 15:17 ` Warner Losh 0 siblings, 1 reply; 160+ messages in thread From: Dan Cross @ 2024-06-24 14:33 UTC (permalink / raw) To: Theodore Ts'o; +Cc: Stuff Received, tuhs On Mon, Jun 24, 2024 at 10:12 AM Theodore Ts'o <tytso@mit.edu> wrote: > On Sun, Jun 23, 2024 at 04:15:40PM -0400, Stuff Received wrote: > > My opinion is that the authors simply did not have access to other > > systems or were not interested. Sometimes, one finds a disclaimer to > > that effect. I understand that but I am irked when they claim POSIX > > compliance. > > I get irked because Posix compliance applies to OS's (a specific > binary release of the kernel plus userspace runtime environment), and > not to applications. > > Also, compliance implies that it has passed a specific test process, > after paying $$$$ to a Posix Test Compliance Lab, and said compliance > certificate gets revoked the moment you fix a security bug, until you > go and you pay additional $$$ to the Posix compliance lab. Basically, > it's racket that generally only companies who need to sell into the US > or European government market were willing to play. (e.g., at one > point there were Red Hat and SuSE distributions which were POSIX > certified, but Fedora or Debian never were.) > > A project or vendor could claim that there product was a "strictly > conforming POSIX application[1], but that's hard to actually prove > (which is why there is no compliance testing for it), since not only > do you have to limit yourself to only those interface guaranted to be > present by POSIX, but you must also not depend on any behavior which > specified to be "implementation defined" (and very often many > traditional Unix behaviors are technically "implementation defined", > so that VMS and Windows could claim to be be "POSIX compliant > implementation".) So a strictly POSIX conforming application was > likely only relevant for very simple "toy" applications that didn't > need to do anything fancy, like say, networking. Also, what is "POSIX" changes over time: new things are added, and occasionally something is removed. Indeed, a new version was just released a couple of weeks ago. So what does it mean to say that some OS conforms to POSIX? Which version? For some very old systems, particularly those that are no longer being substantially updated but that may have conformed to an older version of the standard, they may have credibly claimed "POSIX compliant" at some point in the past, but time has left them behind. It is unreasonable to constrain program authors to ancient versions of standards just because some tiny fraction of people want to use an old system. Consider 4.3BSD, for example: it shipped with a compiler that predated the ANSI C standard, and doesn't understand the ANSI-style function declaration syntax. Should one restrict oneself to the traditional C dialect forever? If so, one loses out on the substantial benefits of stronger type checking. Or consider better string handling functions that came later (`snprintf` is an obvious example, but I would argue `strlcpy` and `strlcat` as well). Should we restrict ourselves to laborious and error-prone shenanigans with `strlen` and `strcpy` just to keep code running on a Sun4c machine under SunOS 4? I really don't think so. - Dan C. > (Berkeley sockets couldn't be required because AT&T Streams. Oh, > joy.) > > [1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#tag_02_02_01 > > Can you tell I'm a bit jaded and cynical about the whole Posix > compliance/conformance thing? :-) > > Cheers, > > - Ted ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-24 14:33 ` Dan Cross @ 2024-06-24 15:17 ` Warner Losh 0 siblings, 0 replies; 160+ messages in thread From: Warner Losh @ 2024-06-24 15:17 UTC (permalink / raw) To: Dan Cross; +Cc: Stuff Received, tuhs [-- Attachment #1: Type: text/plain, Size: 5607 bytes --] On Mon, Jun 24, 2024 at 8:33 AM Dan Cross <crossd@gmail.com> wrote: > On Mon, Jun 24, 2024 at 10:12 AM Theodore Ts'o <tytso@mit.edu> wrote: > > On Sun, Jun 23, 2024 at 04:15:40PM -0400, Stuff Received wrote: > > > My opinion is that the authors simply did not have access to other > > > systems or were not interested. Sometimes, one finds a disclaimer to > > > that effect. I understand that but I am irked when they claim POSIX > > > compliance. > > > > I get irked because Posix compliance applies to OS's (a specific > > binary release of the kernel plus userspace runtime environment), and > > not to applications. > > > > Also, compliance implies that it has passed a specific test process, > > after paying $$$$ to a Posix Test Compliance Lab, and said compliance > > certificate gets revoked the moment you fix a security bug, until you > > go and you pay additional $$$ to the Posix compliance lab. Basically, > > it's racket that generally only companies who need to sell into the US > > or European government market were willing to play. (e.g., at one > > point there were Red Hat and SuSE distributions which were POSIX > > certified, but Fedora or Debian never were.) > > > > A project or vendor could claim that there product was a "strictly > > conforming POSIX application[1], but that's hard to actually prove > > (which is why there is no compliance testing for it), since not only > > do you have to limit yourself to only those interface guaranted to be > > present by POSIX, but you must also not depend on any behavior which > > specified to be "implementation defined" (and very often many > > traditional Unix behaviors are technically "implementation defined", > > so that VMS and Windows could claim to be be "POSIX compliant > > implementation".) So a strictly POSIX conforming application was > > likely only relevant for very simple "toy" applications that didn't > > need to do anything fancy, like say, networking. > > Also, what is "POSIX" changes over time: new things are added, and > occasionally something is removed. Indeed, a new version was just > released a couple of weeks ago. So what does it mean to say that some > OS conforms to POSIX? Which version? For some very old systems, > particularly those that are no longer being substantially updated but > that may have conformed to an older version of the standard, they may > have credibly claimed "POSIX compliant" at some point in the past, but > time has left them behind. > Certification only lasts a certain amount of time... And the compliance isn't with POSIX, but POSIX.1-2008 or POSIX.1-2024. The advantage of POSIX, though, is that it tries to keep up with the changes in interfaces, tastes, etc. So aiming for it is a useful "fuzzy cloud" of what's currently most likely to be portable to most modern (read: released in the last decade or less) systems. > It is unreasonable to constrain program authors to ancient versions of > standards just because some tiny fraction of people want to use an old > system. > Indeed. Ancient systems in general are best dealt with by some common sense build hacks. libposix can handle the missing functionality for people that care about these ancient systems, and "layered" include systems work for systems that are at least new enough to have #include_next (and #include "/usr/include/stdio.h" for those that don't). Pushing that job to a thousand package writers is a loser. I've done this for various older systems that I've dabbled with and it becomes a question of how much is enough... I do similar things to build a few Linux applications on FreeBSD w/o bothering the authors too much (I fix bugs that don't matter on Linux, but make my shim layer smaller though). But that's mostly a modern -> modern so C dialect is identical (enough), and the only troublesome interfaces are the Linux Specific ones which I map to FreeBSD functionality. I've never formalized this since I only have a few I care about that are a bit resistant to accepting FreeBSD patches... > Consider 4.3BSD, for example: it shipped with a compiler that predated > the ANSI C standard, and doesn't understand the ANSI-style function > declaration syntax. Should one restrict oneself to the traditional C > dialect forever? If so, one loses out on the substantial benefits of > stronger type checking. Or consider better string handling functions > that came later (`snprintf` is an obvious example, but I would argue > `strlcpy` and `strlcat` as well). Should we restrict ourselves to > laborious and error-prone shenanigans with `strlen` and `strcpy` just > to keep code running on a Sun4c machine under SunOS 4? I really don't > think so. > Yea. > - Dan C. > > > > (Berkeley sockets couldn't be required because AT&T Streams. Oh, > > joy.) > Sockets are standardized these days in POSIX, though. IPv6 is optional, though if you support it, you have to support it with the interfaces defined. Same with Raw Sockets. But most of that's there (and been there since 2008 or earlier) > > [1] > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#tag_02_02_01 > > > > Can you tell I'm a bit jaded and cynical about the whole Posix > > compliance/conformance thing? :-) > Yea, Just because POSIX says so has been a terrible excuse for doing something silly. FreeBSD has long recognized it. However, in moderation, POSIX is a very good thing. Exact, pedantic, 100% conformance with no flexibility... isn't. Warner [-- Attachment #2: Type: text/html, Size: 7457 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-23 20:15 ` Stuff Received 2024-06-24 14:03 ` Theodore Ts'o @ 2024-06-24 15:23 ` Chet Ramey via TUHS 1 sibling, 0 replies; 160+ messages in thread From: Chet Ramey via TUHS @ 2024-06-24 15:23 UTC (permalink / raw) To: Stuff Received, tuhs [-- Attachment #1.1: Type: text/plain, Size: 793 bytes --] On 6/23/24 4:15 PM, Stuff Received wrote: > My opinion is that the authors simply did not have access to other systems > or were not interested. Sometimes, one finds a disclaimer to that effect. > I understand that but I am irked when they claim POSIX compliance. These are not at all the same. "POSIX compliance," from an application's perspective, means that the application behaves the way POSIX says it should for the behaviors POSIX standardizes. That doesn't have much to do with the author's implementation choices or whether or not the application runs on arbitrary systems. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 203 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-18 1:52 ` Steve Nickolas 2024-06-18 4:52 ` segaloco via TUHS @ 2024-06-21 15:41 ` Chet Ramey via TUHS 1 sibling, 0 replies; 160+ messages in thread From: Chet Ramey via TUHS @ 2024-06-21 15:41 UTC (permalink / raw) To: Steve Nickolas, The Unix Heritage Society mailing list [-- Attachment #1.1: Type: text/plain, Size: 622 bytes --] On 6/17/24 9:52 PM, Steve Nickolas wrote: > It's still possible to port NetBSD's /bin/sh to Debian (I've done it, > called it "nash", but don't have any official release because I don't > really see a point). I ported it to macOS to use as a testing variant. You might contact kre and see if he's interested in your work; he and I talked a year or two ago about his possible future plans to release a portable version. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 203 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-17 22:34 ` Steve Nickolas 2024-06-16 7:57 ` Greg A. Woods @ 2024-06-21 15:38 ` Chet Ramey via TUHS 1 sibling, 0 replies; 160+ messages in thread From: Chet Ramey via TUHS @ 2024-06-21 15:38 UTC (permalink / raw) To: Steve Nickolas, tuhs [-- Attachment #1.1: Type: text/plain, Size: 1052 bytes --] On 6/17/24 6:34 PM, Steve Nickolas wrote: > On Mon, 17 Jun 2024, Stuff Received wrote: > >> On 2024-06-16 21:25, Larry McVoy wrote (in part): >> [...] >>> *Every* time they used some bash-ism, it bit us in the ass. >> >> This is so true for a lot of OS projects (on Github, for example). Most >> -- sometimes all -- the scripts that start with /bin/sh but are full of >> bashisms because the authors run systems where /bin/sh is really bash. > > Which is why I'm glad Debian's /bin/sh is dash (fork of ash) instead. Like everything else, it depends on your goals. If portability across different OSs is a goal, and you can't be guaranteed that bash will be available, it's best to stick with POSIX features. If you want to run places where you can be guaranteed that bash exists, use whatever `bashisms' you like and use `#! /bin/bash'. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 203 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-17 1:25 ` Larry McVoy 2024-06-17 1:32 ` Warner Losh 2024-06-17 19:21 ` Stuff Received @ 2024-06-20 20:14 ` Alexander Schreiber 2 siblings, 0 replies; 160+ messages in thread From: Alexander Schreiber @ 2024-06-20 20:14 UTC (permalink / raw) To: Larry McVoy; +Cc: Alexis, The Unix Heritage Society mailing list On Sun, Jun 16, 2024 at 06:25:31PM -0700, Larry McVoy wrote: > On Mon, Jun 17, 2024 at 11:01:40AM +1000, Alexis wrote: > > > > The issue isn't about learning shell scripting _per se_. It's about the > > extent to which _volunteers_ have to go beyond the _basics_ of shell > > scripting to learn about the _complexities_ and _subtle issues_ involved in > > using it to provide _robust_ service management. Including learning, for > > example, that certain functionality one takes for granted in a given shell > > isn't actually POSIX, and can't be assumed to be present in the shell one is > > working with (not to mention that POSIX-compatibility might need to be > > actively enabled, as in the case of e.g. ksh, via POSIXLY_CORRECT). > > This is sort of off topic but maybe relevant. > > When I was running my company, my engineers joked that if it were invented > after 1980 I wouldn't let them use it. Which wasn't true, we used mmap(). > > But the underlying sentiment sort of was true. Even though they were > all used to bash, I tried very hard to not use bash specific stuff. > And it paid off, in our hey day, we supported SCO, AIX, HPUX, SunOS, > Solaris, Tru64, Linux on every architecture from tin to IBM mainframes, > Windows, Macos on PPC and x86, etc. And probably a bunch of other > platforms I've forgotten. > > *Every* time they used some bash-ism, it bit us in the ass. I kept > telling them "our build environment is not our deployment environment". > We had a bunch of /bin/sh stuff that we shipped so we had to go for > the common denominator. My latest brush with someone using bash in the wrong place was when I saw the configure scripts for GlusterFS break on NetBSD. Because someone had used bash 4 syntax in the configure scripts ... presumably on a Linux variant where /bin/sh == /bin/bash. While that was easy to fix (and the PR accepted and patched in) I shouldn't have had to fix that in the first place ... Kind regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-16 5:48 ` Alexis 2024-06-15 8:48 ` Greg A. Woods @ 2024-06-16 6:43 ` Wesley Parish 1 sibling, 0 replies; 160+ messages in thread From: Wesley Parish @ 2024-06-16 6:43 UTC (permalink / raw) To: tuhs On 16/06/24 17:48, Alexis wrote: > Grant Taylor via TUHS <tuhs@tuhs.org> writes: > >> I'm anti-systemd *cough*Master Control Program*cough* and it's >> associated suite of utilities for many reasons. But I've come to >> accept that systemd is not just an init system. It's role of a >> service life cycle manager is a superset of what an init system does. >> It's a relatively new world (at least comparatively). > > Indeed: it doesn't just do init, but also _service supervision_ > (making sure that a service that _should_ be up, _is_ up) and _service > management_ (enabling, disabling, starting, stopping, dependencies, > etc.). Hence why phrases like "the init wars" are such a misnomer. > > As described in the potted history outlined in the "known problems > with System 5 rc" article i linked to upthread, Sys V rc's issues with > service supervision and service management have been known for decades: > >> In 1999, Luke Mewburn worked on replacing the /etc/rc system in >> NetBSD. netbsd.tech.userlevel mailing list discussions from the time >> show several criticisms of the System 5 rc and System 5 init systems, >> and encouragement not to repeat their mistakes in the BSD world. The >> resultant rc.d system was roughly contemporary with Daniel Robbins >> producing OpenRC, another System 5 rc replacement that replaced the >> (Bourne/Bourne Again) shell with a different script interpreter, >> nowadays named /sbin/openrc, that provided a whole lot of standard >> service management functionality as pre-supplied functions. The >> NetBSD rc.d system likewise reduced rc.d scripts to a few variable >> assignments and function calls (in about two thirds of cases). > > The initial release of OpenRC - still Gentoo's 'native' system for > service management - was in April 2007; the initial release of systemd > was in March 2010. But although both OpenRC and systemd address > various pain points of Sys V rc on Linux, systemd has _also_ had the > backing of an 800-pound gorilla in the Linux world - Red Hat - which > has _implicitly_ forced its adoption over alternatives by distros that > don't have the same level of resources behind them. > > Here's an excerpt from something i wrote on the Gentoo forum back in > April: > >> There's been so much anger and vitriol expressed about systemd. Has >> that significantly slowed the systemd juggernaut? Not really. Not >> least because, as in the case of D-Bus, and as in the case of >> Wayland, it addresses very real issues for significant numbers of >> people. >> >> For example: unlike on, say, OpenBSD, which has developed a pretty >> clean shell-script-based service management system, with a 'standard >> library' in the form of rc.subr(8), the situation on Linux was a >> mess. Many of the (usually volunteers) who maintain packages for >> Linux don't want to have to learn the complexities of shell scripting >> and the subtle issues that can arise, or develop and maintain >> workarounds for race conditions, and so on. systemd comes along and >> says: "Hey, with systemd, you'll be able to write service definitions >> declaratively; you won't need to wrangle shell scripts." That's a >> pretty attractive proposition to a number of package maintainers, and >> in the absence of systemd alternatives explicitly providing such an >> interface - not just saying "oh that could be done on our >> alternative" - those maintainers are going to be inclined towards >> systemd, regardless of what design and implementation issues are >> involved in systemd's approach. >> >> So in wanting to try to ensure that myself and others have choices >> and alternatives available, i feel that ranting against the incoming >> tide, like a tech King Cnut, is typically far less effective than >> actually putting in the work to develop and support those choices and >> alternatives. > > > Alexis. Might also be worth pointing out that Red Hat's an IBM *nix daemon, and IBM's mainframe business is built in no small part on service managers in the OS management layer. I expect their "Phone Home" ability was part-and-parcel of the IBM mainframe service contracts. If systemd phones home without an explicit (ie, sign-on-the-dotted-line type) contract between me and Red Hat, I'll raise a stink about - but so far it hasn't. (I'm running Fedora.) Wesley Parish ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-14 14:17 ` Grant Taylor via TUHS 2024-06-16 5:48 ` Alexis @ 2024-06-16 21:56 ` David Arnold 2024-06-16 23:34 ` Luther Johnson ` (2 more replies) 1 sibling, 3 replies; 160+ messages in thread From: David Arnold @ 2024-06-16 21:56 UTC (permalink / raw) To: Grant Taylor; +Cc: tuhs > On 15 Jun 2024, at 00:18, Grant Taylor via TUHS <tuhs@tuhs.org> wrote: > > It's my understanding that systemd as a service lifecycle manager is starting to take on some aspects of what cluster service managers used to do. I think it goes beyond this, and that systemd is just a convenient focus point for folks to push back against a wider set of changes. My usual example here is PolKit and polkitd. In this latest systemd release, for example, it seems the new systemd-run0 command (replacing sudo or su), starts a privileged process by checking permissions with polkitd over DBus, and then uses systemd to actually fork and setup the “child”. This is a fairly distinctive departure from how Unix works: over the last decade, Linux has increasingly moved away from being Unix, and I think this is why people find systemd so confronting. And there’s more to come, eg. varlink. I’m sure systemd, polkitd and their ilk address real needs. But the solution isn’t (in my view) Unix-like, and those for whom Linux is a convenient Unix are disappointed (to put it mildly). The world is no longer a PDP-11 or a Vax or a SPARCstation. USB in particular introduced a lot more dynamism to the Unix device model, and started us down this path of devfs, DBus, systemd, etc. Users reasonably want things to work, and Red Hat wants to satisfy those users, and they’ve chosen this way to do it. Unfortunately, there’s been no real competition: this goes well beyond system startup, and well beyond service management, and citing s6 or launchd or whatever misses the war by focusing on the battle. d ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-16 21:56 ` David Arnold @ 2024-06-16 23:34 ` Luther Johnson 2024-06-16 23:46 ` Larry McVoy 2024-06-17 0:54 ` Åke Nordin 2024-06-18 5:55 ` Alexis 2 siblings, 1 reply; 160+ messages in thread From: Luther Johnson @ 2024-06-16 23:34 UTC (permalink / raw) To: tuhs I think there's a parallel from the Unix/Linux systems that we think of as more Unix-like, to the cars and airplanes and other machines of that and earlier eras. It used to be that part of the design of a system, alongside its operation, was the idea of normal, regular maintenance. The system could be pretty simple, but there was some maintenance and wearable parts replacement required. It was expected that there was an administrator or mechanic checking in once in a while to keep things tuned and in "good repair". This worked well, as long as people accepted this responsibility as part of the deal. Now it seems like people want everything done for them automatically, and not to have to know anything about the systems they are using. They want the systems to be smarter so they don't have to know as much. It's sort of like when the private airplane industry tried to engineer any skill required on the part of the pilot, out of the airplane. The results were not good. Planes became more complex, with more points of failure, and pilots did not know how to react to unexpected situations. I see this happening with our computer systems, and the people using them now, too. Of course there's a reasonable middle ground, but I think we've gone a little too far making things "easy", and in fact it's not easier at all, we're just fiddling in a different way, often through random trial and error, it all seems horribly indirect, opaque, and irrational, to support some programmer's idea somewhere, of some perfect abstraction. For example: CMake vs. just learning how to write makefiles properly. You fiddle with CMake and you never really know why it does what it does, especially from one version to the next, "but you don't have to write makefiles". On 06/16/2024 02:56 PM, David Arnold wrote: >> On 15 Jun 2024, at 00:18, Grant Taylor via TUHS <tuhs@tuhs.org> wrote: >> >> It's my understanding that systemd as a service lifecycle manager is starting to take on some aspects of what cluster service managers used to do. > I think it goes beyond this, and that systemd is just a convenient focus point for folks to push back against a wider set of changes. > > My usual example here is PolKit and polkitd. In this latest systemd release, for example, it seems the new systemd-run0 command (replacing sudo or su), starts a privileged process by checking permissions with polkitd over DBus, and then uses systemd to actually fork and setup the “child”. > > This is a fairly distinctive departure from how Unix works: over the last decade, Linux has increasingly moved away from being Unix, and I think this is why people find systemd so confronting. And there’s more to come, eg. varlink. > > I’m sure systemd, polkitd and their ilk address real needs. But the solution isn’t (in my view) Unix-like, and those for whom Linux is a convenient Unix are disappointed (to put it mildly). > > The world is no longer a PDP-11 or a Vax or a SPARCstation. USB in particular introduced a lot more dynamism to the Unix device model, and started us down this path of devfs, DBus, systemd, etc. Users reasonably want things to work, and Red Hat wants to satisfy those users, and they’ve chosen this way to do it. Unfortunately, there’s been no real competition: this goes well beyond system startup, and well beyond service management, and citing s6 or launchd or whatever misses the war by focusing on the battle. > > > > d > ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-16 23:34 ` Luther Johnson @ 2024-06-16 23:46 ` Larry McVoy 2024-06-17 21:40 ` Steffen Nurpmeso 0 siblings, 1 reply; 160+ messages in thread From: Larry McVoy @ 2024-06-16 23:46 UTC (permalink / raw) To: Luther Johnson; +Cc: tuhs On Sun, Jun 16, 2024 at 04:34:34PM -0700, Luther Johnson wrote: > I think there's a parallel from the Unix/Linux systems that we think of > as more Unix-like, to the cars and airplanes and other machines of that > and earlier eras. It used to be that part of the design of a system, > alongside its operation, was the idea of normal, regular maintenance. > The system could be pretty simple, but there was some maintenance and > wearable parts replacement required. It was expected that there was an > administrator or mechanic checking in once in a while to keep things > tuned and in "good repair". This worked well, as long as people accepted > this responsibility as part of the deal. > > Now it seems like people want everything done for them automatically, > and not to have to know anything about the systems they are using. They > want the systems to be smarter so they don't have to know as much. It's > sort of like when the private airplane industry tried to engineer any > skill required on the part of the pilot, out of the airplane. The > results were not good. Planes became more complex, with more points of > failure, and pilots did not know how to react to unexpected situations. > I see this happening with our computer systems, and the people using > them now, too. Of course there's a reasonable middle ground, but I think > we've gone a little too far making things "easy", and in fact it's not > easier at all, we're just fiddling in a different way, often through > random trial and error, it all seems horribly indirect, opaque, and > irrational, to support some programmer's idea somewhere, of some perfect > abstraction. > > For example: CMake vs. just learning how to write makefiles properly. > You fiddle with CMake and you never really know why it does what it > does, especially from one version to the next, "but you don't have to > write makefiles". I could not agree more with this post, all of it, but especially the Cmake stuff. Writing Makefiles isn't that hard, if you are a programmer and can't do that, how good of a programmer are you? And is it really easier to learn shiny-new-make-replacement-du-jour every year? ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-16 23:46 ` Larry McVoy @ 2024-06-17 21:40 ` Steffen Nurpmeso 0 siblings, 0 replies; 160+ messages in thread From: Steffen Nurpmeso @ 2024-06-17 21:40 UTC (permalink / raw) To: Larry McVoy; +Cc: Luther Johnson, tuhs Larry McVoy wrote in <20240616234654.GB12821@mcvoy.com>: |On Sun, Jun 16, 2024 at 04:34:34PM -0700, Luther Johnson wrote: |> I think there's a parallel from the Unix/Linux systems that we think of ... |> For example: CMake vs. just learning how to write makefiles properly. |> You fiddle with CMake and you never really know why it does what it |> does, especially from one version to the next, "but you don't have to |> write makefiles". | |I could not agree more with this post, all of it, but especially the |Cmake stuff. Writing Makefiles isn't that hard, if you are a programmer |and can't do that, how good of a programmer are you? And is it really |easier to learn shiny-new-make-replacement-du-jour every year? It must be said that "thrillingly fast" is a key item all those (maybe ninja cmake ant) throw in. And that it takes quite a bit of (non-portability and) thought to empower "normal" makefiles to achieve full parallelism etc. I think you watch the FreeBSD hacker community, and there is "war" around the "meta-mode" (against cmake) to avoid recompilations etc. Multiple people are working on BSD make and the BSD makefile system. (In fact on NetBSD the last years even saw a tremendous run on overhauling BSD make, which then only got imported to FreeBSD.) The files are very dense after decades of engineering, and due to "clean namespace" paradigm there are long variable names that sometimes fill half of an eighty column screen alone; for (stupid first-see-and-take) things like INSTALL_DDIR= ${_INSTALL_DDIR:S://:/:g:C:/$::} you need a clear head. This is not self-descriptive. (Not to talk about the fact that lines (may) become expanded by the shell after they have become expanded by make, ie, all the quoting, and the delayed or immediate macro expansion mechanism(s).) Original make did not have conditionals, or file inclusions, or dedicated control of parallelism (on file, on target level) via .NOTPARALLEL: and .WAIT:, so things like tangerine: config .WAIT build .WAIT test .WAIT install are not portable. (In fact portability and parallelism is not possible unless you use a recursive approach, with all the pitfalls that then brings.) And then all the bugs everywhere, with quoting pitfalls, and this applies to helper tools like awk too (ie xpg4/bin/awk even documents "Notice that backslash escapes are interpreted twice"). I also remember (from the time i still gave money to journalists) terms like "the usual triad" for "./configure && make && make install" with that implied "grazy times, but that is how you do it" undertone maybe even. Now i see for example "cmake -D VAR1 .. && cmake --build build && cmake --install build" which is possibly easier to grasp when compiling a C compiler that is 1.2 GiB when installed. --End of <20240616234654.GB12821@mcvoy.com> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-16 21:56 ` David Arnold 2024-06-16 23:34 ` Luther Johnson @ 2024-06-17 0:54 ` Åke Nordin 2024-06-18 5:55 ` Alexis 2 siblings, 0 replies; 160+ messages in thread From: Åke Nordin @ 2024-06-17 0:54 UTC (permalink / raw) To: tuhs On 2024-06-16 23:56, David Arnold wrote: >> On 15 Jun 2024, at 00:18, Grant Taylor via TUHS <tuhs@tuhs.org> wrote: >> >> It's my understanding that systemd as a service lifecycle manager is starting to take on some aspects of what cluster service managers used to do. > I think it goes beyond this, and that systemd is just a convenient focus point for folks to push back against a wider set of changes. As an example of where I believe evolution is headed, I'd like to talk about the Elephant in the Room. Android. It has a Linux, and thus Unix, heritage. The parts of it that still depends on libc enjoys the quality of OpenBSD code, so it is blessed by some unixy simplicity. Yet regular users are so far removed from anything unix-like that it might as well be Multivac or the Mima. That it still has a file manager of sorts that knows the typical locations of downloads or photos is one of the last concessions to us "I know it's a computer, let me use it as one" types. By default, its apps are sandboxed and isolated in their own hives with their code (main(), library dependencies, media resources) and data presumably sealed off from the rest of the file system. Every code component is of course duplicated in every app. Each new version of Android seems to remove yet another aspect of its Unix roots. It didn't start there, though. Once upon a time, chroot() was a popular way to reduce attack surface area in Linux as well as elsewhere. You had to carefully populate it with just the dependencies that were needed. Containers followed, automating dependency provisioning. Android and its app ecosystem is just a logical continuation of that evolution. Ubuntu has promoted "snaps," a kind of containerized applications that pretty much walks and quacks just like an Android app. Maybe it'sjust me being stupid trying to make things work with e.g. a snap-based version of synergy for keyboard and mouse sharing, but to me it seems that they typically don't see much of your file system, not to talk about any comprehensive view of your /dev. Quite a few distros seems to be headed that way. I'm probably both deluded as well as occluded in my reasoning, but I strongly suspect that the last generation of actively interested computer users where a majority understood processor memory models, I/O and interrupts is now largely promoted out of harms way. "Add another layer of abstractions so we don't need to care about such bullshit" seems to be the new call to arms. That dbus, systemd and Wayland isn't worse than they are is frankly an amazing success given the circumstances they were born under. -- Åke Nordin <ake.nordin@netia.se>, resident Net/Lunix/telecom geek. Netia Data AB, Stockholm SWEDEN *46#7O466OI99# ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-16 21:56 ` David Arnold 2024-06-16 23:34 ` Luther Johnson 2024-06-17 0:54 ` Åke Nordin @ 2024-06-18 5:55 ` Alexis 2024-06-18 6:39 ` Michael Kjörling 2 siblings, 1 reply; 160+ messages in thread From: Alexis @ 2024-06-18 5:55 UTC (permalink / raw) To: The Unix Heritage Society David Arnold <davida@pobox.com> writes: > Users reasonably want things to work, and Red Hat wants to > satisfy > those users, and they’ve chosen this way to do > it. Unfortunately, > there’s been no real competition: this goes well beyond system > startup, and well beyond service management, and citing s6 or > launchd > or whatever misses the war by focusing on the battle. Good point. The problem that D-Bus attempts to solve is communication between components and applications designed for different desktop environments. i wasn't paying particular attention at the time, so i don't know what more Unix-y alternatives were proposed, if any. Laurent Bercot, the developer of s6[a], has created a bare-bones proof-of-concept alternative: https://skarnet.org/software/skabus/ but this hasn't been taken further, as his priorities have been elsewhere. Wayland is an attempt to solve various issues and limitations of X. It's not a project by people who don't understand X; as an example, Matthieu Herbb, an Xorg dev and a primary OpenBSD dev in this area, did a presentation last year in which he said "X11 is fading away" and "Wayland is the way to go for graphical desktop": https://2023.eurobsdcon.org/slides/eurobsdcon2023-matthieu_herrb-wayland-openbsd.pdf The problem is, people who aren't facing the issues and limitations faced by others are unlikely to have any motivation to work on, or support, the development of alternatives. This leaves the field of proposed solutions open to those with a different approach and/or a desire for résumé-driven development, regardless of the quality of the design and/or implementation. But even when the people working on alternatives are people who understand the problem space, those for whom the existing solution is perfectly adequate are unlikely to provide input regarding the development of those alternatives - so when a particular alternative gains sufficient momentum that those people are forced to start dealing with it, they might find it unusable for their use-case(s). In other words, the war is pretty much lost at the outset, and people are left fighting battles that, in the medium-to-long term, are likely to turn out to be quixotic. Alexis. [a] i would say s6 is very much in the spirit of "the Unix philosophy": a suite small focused programs that can be combined in various ways, "mechanism not policy", and utilising fundamental Unix features. As Laurent writes at the end of the page about the s6 approach to 'socket activation', to which i linked upthread: > You don't have to use specific libraries or write complex unit > files, you just need to understand how a command line > works. This is Unix. -- https://skarnet.org/software/s6/socket-activation.html Nevertheless, he's also noted, back in 2020, the real-world issues that have been an obstacle to s6's uptake: > The fact is that a full-featured init system *is* a complex > beast, and the s6 stack does nothing more than is strictly > needed, but it exposes all the tools, all the entrails, all the > workings of the system, and that is a lot for non-specialists to > handle. Integrated init systems, such as systemd, are > significantly *more* complex than the s6 stack, but they do a > better job of *hiding* the complexity, and presenting a > relatively simple interface. That is why, despite being > technically inferior (on numerous metrics: bugs, length of code > paths, resource consumption, actual modularity, flexibility, > portability, etc.), they are more easily accepted: they are just > less intimidating. > > As a friend told me, and it was an enlightening moment: you are > keeping the individual parts simple, but in doing so, you are > moving the complexity to the *interactions* between the parts, > and are burdening the user with that complexity. You are keeping > the code simple, which has undeniable maintainability benefits, > but you are making the administration more difficult, and the > trade-off is not good enough for a lot of users. -- https://skarnet.org/lists/supervision/2586.html ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register 2024-06-18 5:55 ` Alexis @ 2024-06-18 6:39 ` Michael Kjörling 0 siblings, 0 replies; 160+ messages in thread From: Michael Kjörling @ 2024-06-18 6:39 UTC (permalink / raw) To: tuhs On 18 Jun 2024 15:55 +1000, from flexibeast@gmail.com (Alexis): >> As a friend told me, and it was an enlightening moment: you are keeping >> the individual parts simple, but in doing so, you are moving the >> complexity to the *interactions* between the parts, and are burdening >> the user with that complexity. You are keeping the code simple, which >> has undeniable maintainability benefits, but you are making the >> administration more difficult, and the trade-off is not good enough for >> a lot of users. > > -- https://skarnet.org/lists/supervision/2586.html It used to be the case, not least before the widespread advent of microcomputers (let's say between the late 1970s and mid-1980s), that computing time was fairly expensive, and programmer time was fairly cheap (both grossly relatively speaking). So it made sense to shift the burden from the computer to the programmer where reasonable, especially where the operation being automated would be performed many times: the computer would need to do the work every time, whereas the programmer only needed to do the corresponding work once. Now computing time (as in the cost of completing a given operation; say, adding two 64-bit integers, or storing a given number of bytes, or even determining whether a given line of text appears in the output of a command) is for all intents and purposes dirt cheap, while programmer time is relatively expensive. Hence programming-level abstractions which save programmer time, even when those come at a performance cost. The same argument can be made for memory cost. It probably can also be made for system administrator time versus the computing cost of making the sysadmin's job easier. It's also pretty undeniably the case that there are many, many more sysadmins working on many, many, many more systems than there are programmers working on init systems and system state management services. (Which is not to say that it those abstractions are only a good thing. Hiding the complexity of what is actually going on opens up _its own_ set of pitfalls, both because it hides what's going on and because the abstractions can only go so far; and all that performance cost does eventually add up. If we wrote software for today's computers like we wrote it for an early-1980s computer, it could probably be blazingly fast; but could we reasonably write software at the level of today's software complexity that way? The jury might not have arrived yet.) -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-13 18:39 ` segaloco via TUHS 2024-06-13 18:45 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Mychaela Falconia 2024-06-13 18:54 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Dan Cross @ 2024-06-13 19:37 ` Alan D. Salewski 2024-06-13 20:05 ` Clem Cole ` (2 more replies) 2 siblings, 3 replies; 160+ messages in thread From: Alan D. Salewski @ 2024-06-13 19:37 UTC (permalink / raw) To: TUHS (The Unix Heritage Society) On Thu, Jun 13, 2024, at 14:39, segaloco via TUHS wrote: [...] > Are there any known attempts in the modern age to roll Linux with > something resembling research/BSD init? That would be a nice counter > to the proliferation of systemd. Even if it doesn't make a dent in the > actual uptake, at least it'd feel cathartic to have an alternative in > the opposite direction. > > - Matt G. I'm interested in hearing about other options in this space, too. The ones that I'm aware of include: 1. Slackware http://www.slackware.com/ 2. Debian, with sysvinit-core or some other init https://www.debian.org/doc/manuals/debian-faq/customizing.en.html#sysvinit https://wiki.debian.org/Init 3. Devuan (for a Debian derived system w/o systemd) https://www.devuan.org/ The most no-fuss, just-works-out-of-the-box-without-systemd approach would probably be to use Slackware. Debian can be easily customized to run without systemd, once you know the formulas[0]. I did not include Alpine Linux[1] in the above list because it includes lots of tools in a single executable (possibly "init").[2] It does not use systemd by default, though. I mention Devuan only because I'm aware of it -- I've never used it in anger. -Al [0] Even on a systemd-infected host, it isn't much more complicated than: * install the 'sysvinit-core' package (and friends) * pin the 'systemd-sysv' package to '-1' (never install) * reboot * purge most (or all) packages with 'systemd' in their name [1] https://www.alpinelinux.org/about/ [2] It's great in certain circumstances, though -- it's my go-to distro base for most of my small-footprint-scenarios work with Linux containers. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-13 19:37 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Alan D. Salewski @ 2024-06-13 20:05 ` Clem Cole 2024-06-13 20:31 ` Bakul Shah via TUHS 2024-06-13 20:06 ` A. P. Garcia 2024-06-14 0:27 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Alexis 2 siblings, 1 reply; 160+ messages in thread From: Clem Cole @ 2024-06-13 20:05 UTC (permalink / raw) To: Alan D. Salewski; +Cc: TUHS (The Unix Heritage Society) [-- Attachment #1: Type: text/plain, Size: 1590 bytes --] Except ... My primary Linux instances are on my growing family of Raspberry PIs or equiv (I have a couple of BananaPIs and Libre boards). It's based enough on Raspian which like Henry's line WRT 4.2, is just like Debian only different. Frankly, dealing with those issues when you leave the fold is a huge PITA. The problem for me, I really don't have a choice as I can not run a *BSD on them easily to do what I want to do - which is typically to control HW (like my PiDP's or a some "homecontrol" stuff I have). As I have said, it all about economics (well and ego in this case). You have to make something better to make it valuable. Replacing how the system init worked always struck me as throwing out the baby with the bathwater. SysV init was not at all bad, moving from Research/BSD init to it was not a huge life. That said, I agree with Dan, adding a resource system is a good idea and probably was a "hole." Years ago, the CMU Mach team created their nanny system, but it ran in cooperation with init - it did not try to replace init (remember Mach was trying to be a superset of BSD -- they had learned the lessons with Accent of being completely different). When Apple picked up Mach, their engineers eventually combined them to create launchd - which is what I think opened up the world to "getting rid of init" and thus systemd being considered possible by some Linux folks. Of course, the Linux developers could not settle for using launched (NIH) .... so, sadly, https://xkcd.com/927/ applies here - that's the ego part. ᐧ ᐧ ᐧ [-- Attachment #2: Type: text/html, Size: 3154 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-13 20:05 ` Clem Cole @ 2024-06-13 20:31 ` Bakul Shah via TUHS 0 siblings, 0 replies; 160+ messages in thread From: Bakul Shah via TUHS @ 2024-06-13 20:31 UTC (permalink / raw) To: Clem Cole; +Cc: Alan D. Salewski, The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 834 bytes --] On Jun 13, 2024, at 1:05 PM, Clem Cole <clemc@ccc.com> wrote: > > My primary Linux instances are on my growing family of Raspberry PIs or equiv (I have a couple of BananaPIs and Libre boards). It's based enough on Raspian which like Henry's line WRT 4.2, is just like Debian only different. Frankly, dealing with those issues when you leave the fold is a huge PITA. The problem for me, I really don't have a choice as I can not run a *BSD on them easily to do what I want to do - which is typically to control HW (like my PiDP's or a some "homecontrol" stuff I have). (at least) FreeBSD works on Pis (though support will usually lag or be non-existent for various "HATs"). And plan9 has worked for much longer, not to mention it's more flexible. Both have gpio drivers. Writing drivers for plan9 should be far easier. [-- Attachment #2: Type: text/html, Size: 1589 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-13 19:37 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Alan D. Salewski 2024-06-13 20:05 ` Clem Cole @ 2024-06-13 20:06 ` A. P. Garcia 2024-06-13 20:26 ` Jim Capp 2024-06-13 21:35 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy 2024-06-14 0:27 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Alexis 2 siblings, 2 replies; 160+ messages in thread From: A. P. Garcia @ 2024-06-13 20:06 UTC (permalink / raw) To: Alan D. Salewski; +Cc: TUHS (The Unix Heritage Society) [-- Attachment #1: Type: text/plain, Size: 377 bytes --] On Thu, Jun 13, 2024, 3:38 PM Alan D. Salewski <ads@salewski.email> wrote: > On Thu, Jun 13, 2024, at 14:39, segaloco via TUHS wrote: > [...] > > Are there any known attempts in the modern age to roll Linux with > > something resembling research/BSD init? > > I'm interested in hearing about other options in this space, > too. > https://nosysyemd.org > [-- Attachment #2: Type: text/html, Size: 1072 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-13 20:06 ` A. P. Garcia @ 2024-06-13 20:26 ` Jim Capp 2024-06-13 21:35 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy 1 sibling, 0 replies; 160+ messages in thread From: Jim Capp @ 2024-06-13 20:26 UTC (permalink / raw) To: A. P. Garcia; +Cc: TUHS (The Unix Heritage Society), Alan D. Salewski [-- Attachment #1: Type: text/plain, Size: 719 bytes --] https://nosystemd.org/ From: "A. P. Garcia" <a.phillip.garcia@gmail.com> To: "Alan D. Salewski" <ads@salewski.email> Cc: "TUHS (The Unix Heritage Society)" <tuhs@tuhs.org> Sent: Thursday, June 13, 2024 4:06:39 PM Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register On Thu, Jun 13, 2024, 3:38 PM Alan D. Salewski <ads@salewski.email> wrote: On Thu, Jun 13, 2024, at 14:39, segaloco via TUHS wrote: [...] > Are there any known attempts in the modern age to roll Linux with > something resembling research/BSD init? I'm interested in hearing about other options in this space, too. https://nosysyemd.org [-- Attachment #2: Type: text/html, Size: 2466 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register 2024-06-13 20:06 ` A. P. Garcia 2024-06-13 20:26 ` Jim Capp @ 2024-06-13 21:35 ` Larry McVoy 1 sibling, 0 replies; 160+ messages in thread From: Larry McVoy @ 2024-06-13 21:35 UTC (permalink / raw) To: A. P. Garcia; +Cc: Alan D. Salewski, TUHS (The Unix Heritage Society) On Thu, Jun 13, 2024 at 04:06:39PM -0400, A. P. Garcia wrote: > On Thu, Jun 13, 2024, 3:38???PM Alan D. Salewski <ads@salewski.email> wrote: > > > On Thu, Jun 13, 2024, at 14:39, segaloco via TUHS wrote: > > [...] > > > Are there any known attempts in the modern age to roll Linux with > > > something resembling research/BSD init? > > > > > > I'm interested in hearing about other options in this space, > > too. > > > > https://nosysyemd.org Doesn't resolve for me? -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-13 19:37 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Alan D. Salewski 2024-06-13 20:05 ` Clem Cole 2024-06-13 20:06 ` A. P. Garcia @ 2024-06-14 0:27 ` Alexis 2024-06-14 0:59 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy 2 siblings, 1 reply; 160+ messages in thread From: Alexis @ 2024-06-14 0:27 UTC (permalink / raw) To: The Unix Heritage Society; +Cc: Alan D. Salewski "Alan D. Salewski" <ads@salewski.email> writes: > I'm interested in hearing about other options in this space, > too. i'm currently running Gentoo+OpenRC as my daily driver, with OpenRC an 'official' Gentoo option. https://www.gentoo.org/ Previously i was running Void+s6/66, after having been running Void+runit, with runit being Void's default system (at least at the time). https://voidlinux.org/ Artix is an Arch-based non-systemd distro, with support for OpenRC, runit, s6 and dinit. https://artixlinux.org/ Obarun is an Arch-based distro using 66, which is roughly a 'wrapper' for s6, providing declarative syntax for service definition. https://wiki.obarun.org/ Not a distro, but the s6-overlay project allows using s6 as PID 1 in Docker containers: https://github.com/just-containers/s6-overlay The developer of nosh has a page outlining the know problems with Sys V rc: https://jdebp.uk/FGA/system-5-rc-problems.html The developer of dinit has written a nice comparison of various non-systemd systems providing init / service supervision / service management: https://github.com/davmac314/dinit/blob/master/doc/COMPARISON The developer of s6 has pages: * explaining his perspective on various non-systemd systems: https://skarnet.org/software/s6/why.html * providing a general overview of s6 itself: https://skarnet.org/software/s6/overview.html * discussing s6's approach to 'socket activation', which uses file descriptors: https://skarnet.org/software/s6/socket-activation.html (s6 is the system i'm most familiar with in this space, not least because i'm the porter and maintainer of mdoc(7) versions of the documentation for various parts of the s6/skaware ecosystem.) Alexis. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register 2024-06-14 0:27 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Alexis @ 2024-06-14 0:59 ` Larry McVoy 2024-06-14 1:11 ` Luther Johnson ` (5 more replies) 0 siblings, 6 replies; 160+ messages in thread From: Larry McVoy @ 2024-06-14 0:59 UTC (permalink / raw) To: The Unix Heritage Society This is all well and good but what I, and I suspect other boomers like me, are looking for, is something like Ubuntu without systemd. I'm a xubuntu guy (Ubuntu with a lighter weight desktop), but whatever. Ubuntu is fine, everything works there. So is there an "Everything just works" distro without systemd? A guy can hope but I suspect not. I'm not trying to be a pain in the ass but I'm 62, I prefer to spend my effort on fishing on the ocean, I'm not some young guy that wants to put in a ton of hours on my Linux install, I like Linux because it is Unix and it is trivial to install. Windows? Hours and hours of finding drivers after you find some USB network connector that Windows knows? No thanks. *BSD - have you installed one of those? It's a trip back to the 1980s, those installers are fine for BSD developers but just suck compared to Linux. Mainstream Linux just works. On Fri, Jun 14, 2024 at 10:27:29AM +1000, Alexis wrote: > "Alan D. Salewski" <ads@salewski.email> writes: > > >I'm interested in hearing about other options in this space, > >too. > > i'm currently running Gentoo+OpenRC as my daily driver, with OpenRC an > 'official' Gentoo option. > > https://www.gentoo.org/ > > Previously i was running Void+s6/66, after having been running Void+runit, > with runit being Void's default system (at least at the time). > > https://voidlinux.org/ > > Artix is an Arch-based non-systemd distro, with support for OpenRC, runit, > s6 and dinit. > > https://artixlinux.org/ > > Obarun is an Arch-based distro using 66, which is roughly a 'wrapper' for > s6, providing declarative syntax for service definition. > > https://wiki.obarun.org/ > > Not a distro, but the s6-overlay project allows using s6 as PID 1 in Docker > containers: > > https://github.com/just-containers/s6-overlay > > The developer of nosh has a page outlining the know problems with Sys V rc: > > https://jdebp.uk/FGA/system-5-rc-problems.html > > The developer of dinit has written a nice comparison of various non-systemd > systems providing init / service supervision / service management: > > https://github.com/davmac314/dinit/blob/master/doc/COMPARISON > > The developer of s6 has pages: > > * explaining his perspective on various non-systemd systems: > > https://skarnet.org/software/s6/why.html > > * providing a general overview of s6 itself: > > https://skarnet.org/software/s6/overview.html > > * discussing s6's approach to 'socket activation', which uses file > descriptors: > > https://skarnet.org/software/s6/socket-activation.html > > (s6 is the system i'm most familiar with in this space, not least because > i'm the porter and maintainer of mdoc(7) versions of the documentation for > various parts of the s6/skaware ecosystem.) > > > Alexis. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register 2024-06-14 0:59 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy @ 2024-06-14 1:11 ` Luther Johnson 2024-06-14 1:42 ` Alexis ` (4 subsequent siblings) 5 siblings, 0 replies; 160+ messages in thread From: Luther Johnson @ 2024-06-14 1:11 UTC (permalink / raw) To: tuhs I believe there is a Debian package you can install after installing Debian that reverts to sysvinit, removes systemd. There is also a configuration that leaves systemd in place but lets you use the sysvinit scripts and forget (well for most people, most uses) that systemd is there. I have the latter style of installation on my server, but I was thinking of going the full no-systemd route sometime. On 06/13/2024 05:59 PM, Larry McVoy wrote: > This is all well and good but what I, and I suspect other boomers like me, > are looking for, is something like Ubuntu without systemd. I'm a xubuntu > guy (Ubuntu with a lighter weight desktop), but whatever. Ubuntu is fine, > everything works there. > > So is there an "Everything just works" distro without systemd? A guy can > hope but I suspect not. > > I'm not trying to be a pain in the ass but I'm 62, I prefer to spend my > effort on fishing on the ocean, I'm not some young guy that wants to > put in a ton of hours on my Linux install, I like Linux because it is > Unix and it is trivial to install. Windows? Hours and hours of finding > drivers after you find some USB network connector that Windows knows? > No thanks. *BSD - have you installed one of those? It's a trip back > to the 1980s, those installers are fine for BSD developers but just suck > compared to Linux. Mainstream Linux just works. > > On Fri, Jun 14, 2024 at 10:27:29AM +1000, Alexis wrote: >> "Alan D. Salewski" <ads@salewski.email> writes: >> >>> I'm interested in hearing about other options in this space, >>> too. >> i'm currently running Gentoo+OpenRC as my daily driver, with OpenRC an >> 'official' Gentoo option. >> >> https://www.gentoo.org/ >> >> Previously i was running Void+s6/66, after having been running Void+runit, >> with runit being Void's default system (at least at the time). >> >> https://voidlinux.org/ >> >> Artix is an Arch-based non-systemd distro, with support for OpenRC, runit, >> s6 and dinit. >> >> https://artixlinux.org/ >> >> Obarun is an Arch-based distro using 66, which is roughly a 'wrapper' for >> s6, providing declarative syntax for service definition. >> >> https://wiki.obarun.org/ >> >> Not a distro, but the s6-overlay project allows using s6 as PID 1 in Docker >> containers: >> >> https://github.com/just-containers/s6-overlay >> >> The developer of nosh has a page outlining the know problems with Sys V rc: >> >> https://jdebp.uk/FGA/system-5-rc-problems.html >> >> The developer of dinit has written a nice comparison of various non-systemd >> systems providing init / service supervision / service management: >> >> https://github.com/davmac314/dinit/blob/master/doc/COMPARISON >> >> The developer of s6 has pages: >> >> * explaining his perspective on various non-systemd systems: >> >> https://skarnet.org/software/s6/why.html >> >> * providing a general overview of s6 itself: >> >> https://skarnet.org/software/s6/overview.html >> >> * discussing s6's approach to 'socket activation', which uses file >> descriptors: >> >> https://skarnet.org/software/s6/socket-activation.html >> >> (s6 is the system i'm most familiar with in this space, not least because >> i'm the porter and maintainer of mdoc(7) versions of the documentation for >> various parts of the s6/skaware ecosystem.) >> >> >> Alexis. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register 2024-06-14 0:59 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy 2024-06-14 1:11 ` Luther Johnson @ 2024-06-14 1:42 ` Alexis 2024-06-14 4:22 ` ron minnich 2024-06-14 6:54 ` Angel M Alganza 2024-06-14 7:04 ` Dave Horsfall ` (3 subsequent siblings) 5 siblings, 2 replies; 160+ messages in thread From: Alexis @ 2024-06-14 1:42 UTC (permalink / raw) To: The Unix Heritage Society Larry McVoy <lm@mcvoy.com> writes: > This is all well and good but what I, and I suspect other > boomers like me, > are looking for, is something like Ubuntu without systemd. I'm > a xubuntu > guy (Ubuntu with a lighter weight desktop), but whatever. > Ubuntu is fine, > everything works there. > > So is there an "Everything just works" distro without systemd? > A guy can > hope but I suspect not. Mm, well, i guess that depends on what one's "everything" is. i used Ubuntu years ago - having moved from Mandriva - and was pleased by how everything "just worked". But over time i started experiencing various issues where things _didn't_ just work (i can't remember what now; i think printing might have been one thing), which became increasingly frustrating. So i moved to Debian, and had a much more "just works" experience. But then Debian moved to systemd, and i started getting frustrated again in various ways, and so i moved to Void. Void's a binary distro, and i don't recall having any more issues with it than i ended up having with Ubuntu. And for experienced *n*x users, the installation process is trivial (even if the installer is text-based, rather than involving snazzy graphics). > I'm not trying to be a pain in the ass but I'm 62, I prefer to > spend my > effort on fishing on the ocean, I'm not some young guy that > wants to > put in a ton of hours on my Linux install Fwiw, i'm a 50-year-old woman. :-) My first distro was RedHat 5.2, around the end of '97. To me, this is a "bubbles in wallpaper" thing. i've spent the time setting up Gentoo because i'm now at the point where i'm clear on what i do and don't need/want (in general), and i'm trying to minimise the extent to which i'm beholden to having to deal with breaking changes to subsystems / libraries / software that i don't need/want, or with breakages i don't know how to immediately fix or workaround. Because i have _many_ other life commitments myself, and i've never distro-hopped just for the fun of it; i've always been driven to do so, for various reasons. My distro is merely a means to an end, not the end in itself. (i've taken on s6 documentation stuff because although there's no shortage of people wanting alternatives to systemd, there are far fewer people volunteering to do even small amounts of the work necessary for that.) Alexis. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register 2024-06-14 1:42 ` Alexis @ 2024-06-14 4:22 ` ron minnich 2024-06-14 6:54 ` Angel M Alganza 1 sibling, 0 replies; 160+ messages in thread From: ron minnich @ 2024-06-14 4:22 UTC (permalink / raw) To: Alexis; +Cc: The Unix Heritage Society [-- Attachment #1: Type: text/plain, Size: 2688 bytes --] well, it depends on what you want, but tinycorelinux has worked well for me, and it fits in about 24M On Thu, Jun 13, 2024 at 6:42 PM Alexis <flexibeast@gmail.com> wrote: > Larry McVoy <lm@mcvoy.com> writes: > > > This is all well and good but what I, and I suspect other > > boomers like me, > > are looking for, is something like Ubuntu without systemd. I'm > > a xubuntu > > guy (Ubuntu with a lighter weight desktop), but whatever. > > Ubuntu is fine, > > everything works there. > > > > So is there an "Everything just works" distro without systemd? > > A guy can > > hope but I suspect not. > > Mm, well, i guess that depends on what one's "everything" is. i > used Ubuntu years ago - having moved from Mandriva - and was > pleased by how everything "just worked". But over time i started > experiencing various issues where things _didn't_ just work (i > can't remember what now; i think printing might have been one > thing), which became increasingly frustrating. So i moved to > Debian, and had a much more "just works" experience. But then > Debian moved to systemd, and i started getting frustrated again in > various ways, and so i moved to Void. > > Void's a binary distro, and i don't recall having any more issues > with it than i ended up having with Ubuntu. And for experienced > *n*x users, the installation process is trivial (even if the > installer is text-based, rather than involving snazzy graphics). > > > I'm not trying to be a pain in the ass but I'm 62, I prefer to > > spend my > > effort on fishing on the ocean, I'm not some young guy that > > wants to > > put in a ton of hours on my Linux install > > Fwiw, i'm a 50-year-old woman. :-) My first distro was RedHat 5.2, > around the end of '97. > > To me, this is a "bubbles in wallpaper" thing. i've spent the time > setting up Gentoo because i'm now at the point where i'm clear on > what i do and don't need/want (in general), and i'm trying to > minimise the extent to which i'm beholden to having to deal with > breaking changes to subsystems / libraries / software that i don't > need/want, or with breakages i don't know how to immediately fix > or workaround. Because i have _many_ other life commitments > myself, and i've never distro-hopped just for the fun of it; i've > always been driven to do so, for various reasons. My distro is > merely a means to an end, not the end in itself. > > (i've taken on s6 documentation stuff because although there's no > shortage of people wanting alternatives to systemd, there are far > fewer people volunteering to do even small amounts of the work > necessary for that.) > > > Alexis. > [-- Attachment #2: Type: text/html, Size: 3358 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register 2024-06-14 1:42 ` Alexis 2024-06-14 4:22 ` ron minnich @ 2024-06-14 6:54 ` Angel M Alganza 1 sibling, 0 replies; 160+ messages in thread From: Angel M Alganza @ 2024-06-14 6:54 UTC (permalink / raw) To: tuhs On 2024-06-14 03:42, Alexis wrote: > Mm, well, i guess that depends on what one's "everything" is. i used > Ubuntu years ago - having moved from Mandriva - and was pleased by how > everything "just worked". But over time i started experiencing various > issues where things _didn't_ just work (i can't remember what now; i > think printing might have been one thing), which became increasingly > frustrating. So i moved to Debian, and had a much more "just works" > experience. But then Debian moved to systemd, and i started getting > frustrated again in various ways, and so i moved to Void. I used Debian for 27 years, until ascii (the last release without the nasty systemd), which I upgraded to Devuan ascii. The upgrade process was flawless with everything working without problems for me (I don't use disgusting DEs like Gnome or KDE, of course). In several systems, I've kept upgrading release after release of Devuan, changing every part of the hardware in the way, and it keeps working great. In the BSDs, I much prefer the more classic text installers, where I'm in control, but NomadBSD and GhostBSD have graphical installers which seem to be much simpler and easier to use than the Ubuntu one. Cheers, Ángel ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register 2024-06-14 0:59 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy 2024-06-14 1:11 ` Luther Johnson 2024-06-14 1:42 ` Alexis @ 2024-06-14 7:04 ` Dave Horsfall 2024-06-14 7:33 ` arnold ` (2 subsequent siblings) 5 siblings, 0 replies; 160+ messages in thread From: Dave Horsfall @ 2024-06-14 7:04 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Thu, 13 Jun 2024, Larry McVoy wrote: > This is all well and good but what I, and I suspect other boomers like > me, are looking for, is something like Ubuntu without systemd. I'm a > xubuntu guy (Ubuntu with a lighter weight desktop), but whatever. > Ubuntu is fine, everything works there. I'm looking for something like Debian for its Amateur radio ("ham") stuff for a laptop, but without the "systemd" monstrosity; I've seen a reference to "Devuan" (?) which might suit me. > So is there an "Everything just works" distro without systemd? A guy > can hope but I suspect not. Hopefully... > I'm not trying to be a pain in the ass but I'm 62, I prefer to spend my > effort on fishing on the ocean, I'm not some young guy that wants to put > in a ton of hours on my Linux install, I like Linux because it is Unix > and it is trivial to install. Windows? Hours and hours of finding > drivers after you find some USB network connector that Windows knows? No > thanks. *BSD - have you installed one of those? It's a trip back to > the 1980s, those installers are fine for BSD developers but just suck > compared to Linux. Mainstream Linux just works. Only 62? I turn 72 in a few months :-) And I *don't* like Linux precisely because it is *not* Unix (too many irritating differences), but I need something for the aforesaid lapdog (with some proprietary hardware, but 3rd-party drivers exist). As for *BSD, yes, many times; I started with SunOS, used OpenBSD/NetBSD/FreeBSD (the latter is my current server), and I really don't see any problem. Heck, even my Mac runs FreeBSD (albeit on steroids)... I have to say though that the SunOS graphical installer was beautiful :-) -- Dave ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register 2024-06-14 0:59 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy ` (2 preceding siblings ...) 2024-06-14 7:04 ` Dave Horsfall @ 2024-06-14 7:33 ` arnold 2024-06-14 7:34 ` Andy Kosela 2024-06-14 11:31 ` Vincenzo Nicosia 5 siblings, 0 replies; 160+ messages in thread From: arnold @ 2024-06-14 7:33 UTC (permalink / raw) To: tuhs, lm I'm with Larry on this one. I'm 64, I been running Ubuntu Mate for ~8 years or so, and even though it's systemd, and yeah, systemd IS an abomination, I don't care enough to go looking for something else. I still have $DAYJOB, kids living at home, Free Software to maintain, books to write, etc., etc., etc. https://wiki.ubuntu.com/SystemdForUpstartUsers#Permanent_switch_back_to_upstart looks like it might do the trick, but it also looks like it's a little old, and I don't want to brick my production systems. I may try to spin up a VM and see if the instructions work before doing it for real. Arnold Larry McVoy <lm@mcvoy.com> wrote: > This is all well and good but what I, and I suspect other boomers like me, > are looking for, is something like Ubuntu without systemd. I'm a xubuntu > guy (Ubuntu with a lighter weight desktop), but whatever. Ubuntu is fine, > everything works there. > > So is there an "Everything just works" distro without systemd? A guy can > hope but I suspect not. > > I'm not trying to be a pain in the ass but I'm 62, I prefer to spend my > effort on fishing on the ocean, I'm not some young guy that wants to > put in a ton of hours on my Linux install, I like Linux because it is > Unix and it is trivial to install. Windows? Hours and hours of finding > drivers after you find some USB network connector that Windows knows? > No thanks. *BSD - have you installed one of those? It's a trip back > to the 1980s, those installers are fine for BSD developers but just suck > compared to Linux. Mainstream Linux just works. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register 2024-06-14 0:59 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy ` (3 preceding siblings ...) 2024-06-14 7:33 ` arnold @ 2024-06-14 7:34 ` Andy Kosela 2024-06-14 7:44 ` Dave Horsfall 2024-06-14 11:31 ` Vincenzo Nicosia 5 siblings, 1 reply; 160+ messages in thread From: Andy Kosela @ 2024-06-14 7:34 UTC (permalink / raw) To: Larry McVoy; +Cc: The Unix Heritage Society [-- Attachment #1: Type: text/plain, Size: 2299 bytes --] On Friday, June 14, 2024, Larry McVoy <lm@mcvoy.com> wrote: > This is all well and good but what I, and I suspect other boomers like me, > are looking for, is something like Ubuntu without systemd. I'm a xubuntu > guy (Ubuntu with a lighter weight desktop), but whatever. Ubuntu is fine, > everything works there. > > So is there an "Everything just works" distro without systemd? A guy can > hope but I suspect not. > > I'm not trying to be a pain in the ass but I'm 62, I prefer to spend my > effort on fishing on the ocean, I'm not some young guy that wants to > put in a ton of hours on my Linux install, I like Linux because it is > Unix and it is trivial to install. Windows? Hours and hours of finding > drivers after you find some USB network connector that Windows knows? > No thanks. *BSD - have you installed one of those? It's a trip back > to the 1980s, those installers are fine for BSD developers but just suck > compared to Linux. Mainstream Linux just works. > Larry, in that case I think you will be best with sticking to Xubuntu or Debian. These distros just work. And although I am also from anti-systemd camp after years of using systemd in production environments -- pretty much it has been a standard since rhel 7 -- I conclude that systemd is not the end of the world like some purported back in the days. Mostly it just works too. Switching to some esoteric distro maintained by a couple of university students that will most likely disappear in three years is probably not the best option. Debian is stable and been there from the beginning. All the packages are also there just one simple command away. These days I am also not that interested in kernel development anymore or debugging low level stuff. It was fun when Linux or FreeBSD kernels were much smaller and less complex. I am mostly into retro computing and retro games these days; still playing and enjoying old classics like "The Secret of Monkey Island" from LucasArts on period correct hardware. For daily tasks I am using Macbook which also just works and have a terminal, so I can run my stuff from there. I can control my k8s clusters from the terminal. I am still mostly CLI oriented. Command line will always remain the most elegant and beautiful interface to speak with machines. --Andy [-- Attachment #2: Type: text/html, Size: 2728 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register 2024-06-14 7:34 ` Andy Kosela @ 2024-06-14 7:44 ` Dave Horsfall 0 siblings, 0 replies; 160+ messages in thread From: Dave Horsfall @ 2024-06-14 7:44 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Fri, 14 Jun 2024, Andy Kosela wrote: > For daily tasks I am using Macbook which also just works and have a > terminal, so I can run my stuff from there. I can control my k8s > clusters from the terminal. I am still mostly CLI oriented. Command line > will always remain the most elegant and beautiful interface to speak > with machines. What he said... -- Dave ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? The Register 2024-06-14 0:59 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy ` (4 preceding siblings ...) 2024-06-14 7:34 ` Andy Kosela @ 2024-06-14 11:31 ` Vincenzo Nicosia 5 siblings, 0 replies; 160+ messages in thread From: Vincenzo Nicosia @ 2024-06-14 11:31 UTC (permalink / raw) To: The Unix Heritage Society On Thu, Jun 13, 2024 at 05:59:02PM -0700, Larry McVoy wrote: > This is all well and good but what I, and I suspect other boomers like me, > are looking for, is something like Ubuntu without systemd. I'm a xubuntu > guy (Ubuntu with a lighter weight desktop), but whatever. Ubuntu is fine, > everything works there. > > So is there an "Everything just works" distro without systemd? A guy can > hope but I suspect not. TL;DR: Devuan (https://devuan.org) works more or less fine as a daily drive, both as a desktop and on servers, and it gives choice of sysvinit, runit, openrc, and lately also s6 I believe (but I haven't tried it). If you need something that "kinda works" without systemd, well, Devuan is still "kinda usable", and possibly one of the best options around. Personal rant follows. You are not expected to read this ;P Linux is probably broken beyond repair now, and I am saying that with a heavy heart, having used exlusively Linux and all the other *BSD in the last 26 years, and having advocated its adoption strongly, in different environments. In many ways, Linux is not unix, not any more, to any sensible measure, and since a good while ago. These days Linux can only provide a somehow-lightly-unixy-flavoured system that "kinda works", provided that you do things as the distro decided, and do not look under the hood, ever. I personally believe Linux was at its top around 10-12 years ago, even in terms of how well everything worked in it and how easy it still was to do things your own way, if you wanted to do so. It was still simple enough, yet it provided a full-featured computing experience, from desktops to high-end servers. Nowadays if you decide to use Linux you must accept that far too many things "do happen" to your computer, and neither you nor anybody else knows why they do, or why they shouldn't, or how to alter their behavious or avoid them altogether. There is so much complexity everywhere that there is almost no space left for KISS, anywhere. Linux has eaten itself alive plus a whole bunch of additional bloat, many times, recursively. I have already moved all the servers away of Linux in the last 6-7 years, and I am currently in the last phase of moving my desktops away from it as well. It's a sad farewell, but a necessary one. You can't be totally fed up and keep carrying on for long, can you? :) My2Cents Enzo -- ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-13 16:47 ` Arrigo Triulzi via TUHS 2024-06-13 18:39 ` segaloco via TUHS @ 2024-06-13 20:26 ` Dave Horsfall 2024-06-14 11:32 ` Michael Kjörling 1 sibling, 1 reply; 160+ messages in thread From: Dave Horsfall @ 2024-06-13 20:26 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 523 bytes --] On Thu, 13 Jun 2024, Arrigo Triulzi via TUHS wrote: > Binary logs, ’nuff said. Ugh... > Good sysadmins live & die by grep and being able to visually detect > departures from the norm by just looking at the “shape” of logs > scrolling down a screen (before), terminal window now. Which is exactly what I do: one window with "tail -F /var/log/maillog" and another with "tail -F /var/log/httpd-access.log"; I've spotted lots of attacks that way (followed by a quick update to my firewall). -- Dave ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-13 20:26 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Dave Horsfall @ 2024-06-14 11:32 ` Michael Kjörling 2024-06-14 12:21 ` A. P. Garcia 2024-06-23 0:13 ` Dave Horsfall 0 siblings, 2 replies; 160+ messages in thread From: Michael Kjörling @ 2024-06-14 11:32 UTC (permalink / raw) To: tuhs On 14 Jun 2024 06:26 +1000, from dave@horsfall.org (Dave Horsfall): >> Good sysadmins live & die by grep and being able to visually detect >> departures from the norm by just looking at the “shape” of logs >> scrolling down a screen (before), terminal window now. > > Which is exactly what I do: one window with "tail -F /var/log/maillog" and > another with "tail -F /var/log/httpd-access.log"; I've spotted lots of > attacks that way (followed by a quick update to my firewall). journalctl -f -u 'postfix*' or journalctl -f -u 'exim*' or journalctl -f -u 'smtpd' or whatever else might map to the SMTP server software you're running. (Sure, it gets slightly more complicated if you don't know what SMTP server software is in use, but in that case I think a case can be made for why do you even care about its logs?) To filter, one can either add -g 'pcre-expression'; or pipe the output through grep -P for the same effect. Or you can use something like --output=json (or -o json) and pipe the output of that through, say, jq. And I'm pretty sure most web servers still log to text files in typical configurations, so that plain "tail -F" should still work there. Is systemd perfect? Of course not. I have my gripes with it myself, but not enough to actively fight it. And nobody is _forcing_ anyone to use systemd; plenty of examples have already been posted in this thread, from specially-made Linux distribution derivatives to ones that have opted to not include systemd to *BSDs to links to instructions for how to get rid of systemd from more mainstream Linux distributions that have opted to use it as a default. Also, the subjectular headline from The Register seems like something someone has dreamed up; I certainly don't see anything like that in the actual release announcement at <https://github.com/systemd/systemd/releases/tag/v256>. Also using multiple different search engines to try to find it only brought up the _The Register_ article and a handful of places regurgitating that quote as a real representation of a statement from the systemd maintainers. I don't see anything resembling it anywhere on either systemd.io or github.com. Until I see someone posting a link to something like that quote posted by a systemd maintainer in representation of _any_ systemd release, let alone v256, I'm going to treat that one as hearsay at best, and actively malicious at worst. As much as I can appreciate the architectural simplicity of early UNIX, how about not ignoring the fact that today's systems are quite a bit more complex both at the hardware and the software level than they were in the late 1960s, and that to some extent, this complexity _itself_ (unfortunately) drives complexity in other areas. Also that much of that simplicity was also out of necessity. There's a reason why most software these days isn't written directly in assembler or even C. None of which negates the accomplishments of either UNIX or C. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-14 11:32 ` Michael Kjörling @ 2024-06-14 12:21 ` A. P. Garcia 2024-06-18 12:02 ` Arrigo Triulzi via TUHS 2024-06-23 0:13 ` Dave Horsfall 1 sibling, 1 reply; 160+ messages in thread From: A. P. Garcia @ 2024-06-14 12:21 UTC (permalink / raw) To: e5655f30a07f; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 943 bytes --] On Fri, Jun 14, 2024, 7:42 AM Michael Kjörling <e5655f30a07f@ewoof.net> wrote Also, the subjectular headline from The Register seems like something > someone has dreamed up; I certainly don't see anything like that in > the actual release announcement at > <https://github.com/systemd/systemd/releases/tag/v256>. Also using > multiple different search engines to try to find it only brought up > the _The Register_ article and a handful of places regurgitating that > quote as a real representation of a statement from the systemd > maintainers. I don't see anything resembling it anywhere on either > systemd.io or github.com. Until I see someone posting a link to > something like that quote posted by a systemd maintainer in > representation of _any_ systemd release, let alone v256, I'm going to > treat that one as hearsay at best, and actively malicious at worst. > https://fosstodon.org/@bluca/112600235561688561 [-- Attachment #2: Type: text/html, Size: 1692 bytes --] ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-14 12:21 ` A. P. Garcia @ 2024-06-18 12:02 ` Arrigo Triulzi via TUHS 0 siblings, 0 replies; 160+ messages in thread From: Arrigo Triulzi via TUHS @ 2024-06-18 12:02 UTC (permalink / raw) To: The Eunuchs Hysterical Society From Mastodon (https://mastodon.social/@nixCraft/112637213238431183): >FYI, there is a bug in systemd. So, running: "systemd-tmpfiles --purge" will delete your /home/ in systemd version 256. and Twitter (https://x.com/DevuanOrg/status/1802997574695080067). Could be Debian-specific but… Arrigo ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-14 11:32 ` Michael Kjörling 2024-06-14 12:21 ` A. P. Garcia @ 2024-06-23 0:13 ` Dave Horsfall 2024-06-23 1:47 ` Alexis 1 sibling, 1 reply; 160+ messages in thread From: Dave Horsfall @ 2024-06-23 0:13 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 555 bytes --] On Fri, 14 Jun 2024, Michael Kjörling wrote: [...] > journalctl -f -u 'smtpd' > > or whatever else might map to the SMTP server software you're running. > (Sure, it gets slightly more complicated if you don't know what SMTP > server software is in use, but in that case I think a case can be made > for why do you even care about its logs?) My server runs Sendmail, and I have no idea what "journalctl" is (it sounds Penguin-ish, which I definitely don't run). And I care so that I can firewall the buggers on the spot... -- Dave ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-23 0:13 ` Dave Horsfall @ 2024-06-23 1:47 ` Alexis 2024-06-23 19:00 ` Theodore Ts'o 0 siblings, 1 reply; 160+ messages in thread From: Alexis @ 2024-06-23 1:47 UTC (permalink / raw) To: The Unix Heritage Society Dave Horsfall <dave@horsfall.org> writes: > My server runs Sendmail, and I have no idea what "journalctl" is > (it > sounds Penguin-ish, which I definitely don't run). It's systemd's program for accessing the binary logs it generates. So, yes, it's Penguin, in the sense that systemd is explicitly not supported on anything other than Linux. Alexis. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-23 1:47 ` Alexis @ 2024-06-23 19:00 ` Theodore Ts'o 2024-06-23 20:04 ` Alexander Schreiber 0 siblings, 1 reply; 160+ messages in thread From: Theodore Ts'o @ 2024-06-23 19:00 UTC (permalink / raw) To: Alexis; +Cc: The Unix Heritage Society On Sun, Jun 23, 2024 at 11:47:52AM +1000, Alexis wrote: > Dave Horsfall <dave@horsfall.org> writes: > > > My server runs Sendmail, and I have no idea what "journalctl" is (it > > sounds Penguin-ish, which I definitely don't run). > > It's systemd's program for accessing the binary logs it generates. So, yes, > it's Penguin, in the sense that systemd is explicitly not supported on > anything other than Linux. Systemd certainly isn't a pioneer in terms of binary log files. The first such "innovation" that I can think of is Ultrix's (and later OSF/1 and Tru64)'s uerf (Ultrix error report formatter). AIX also had binary error logs that needed to be decoded using the errpt command. And Solaris's audit logs are also stored in a binary format. All of these "innovations" consider it a Feature that it becomes easier to store and filter on structured data, instead of trying to write complex regex's to pull out events that match some particular query. - Ted ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-23 19:00 ` Theodore Ts'o @ 2024-06-23 20:04 ` Alexander Schreiber 2024-06-24 13:50 ` Theodore Ts'o 0 siblings, 1 reply; 160+ messages in thread From: Alexander Schreiber @ 2024-06-23 20:04 UTC (permalink / raw) To: Theodore Ts'o; +Cc: Alexis, The Unix Heritage Society On Sun, Jun 23, 2024 at 03:00:02PM -0400, Theodore Ts'o wrote: > On Sun, Jun 23, 2024 at 11:47:52AM +1000, Alexis wrote: > > Dave Horsfall <dave@horsfall.org> writes: > > > > > My server runs Sendmail, and I have no idea what "journalctl" is (it > > > sounds Penguin-ish, which I definitely don't run). > > > > It's systemd's program for accessing the binary logs it generates. So, yes, > > it's Penguin, in the sense that systemd is explicitly not supported on > > anything other than Linux. > > Systemd certainly isn't a pioneer in terms of binary log files. The > first such "innovation" that I can think of is Ultrix's (and later > OSF/1 and Tru64)'s uerf (Ultrix error report formatter). AIX also had > binary error logs that needed to be decoded using the errpt command. > And Solaris's audit logs are also stored in a binary format. AIX sort of gets a pass here on account of being on the weird side to begin with and bonus points for not using DB/2 for primary log storage ;-) > All of these "innovations" consider it a Feature that it becomes > easier to store and filter on structured data, instead of trying to > write complex regex's to pull out events that match some particular > query. Except you now have to do the additional step of extracting the data from the binary logs and _then_ apply the regex filter you were going to use in the first place, which makes the logs less accessible. All of my systemd running machines still get rsyslog plugged into it so it can deliver the logs to my central log host (which then dumps them into PostgreSQL) - and to enable a quick rummage in the local logs via less & grep. Kind regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-23 20:04 ` Alexander Schreiber @ 2024-06-24 13:50 ` Theodore Ts'o 2024-06-24 14:21 ` Dan Cross 2024-06-24 15:03 ` Steffen Nurpmeso 0 siblings, 2 replies; 160+ messages in thread From: Theodore Ts'o @ 2024-06-24 13:50 UTC (permalink / raw) To: Alexander Schreiber; +Cc: Alexis, The Unix Heritage Society On Sun, Jun 23, 2024 at 10:04:22PM +0200, Alexander Schreiber wrote: > Except you now have to do the additional step of extracting the > data from the binary logs and _then_ apply the regex filter you > were going to use in the first place, which makes the logs less > accessible. All of my systemd running machines still get rsyslog > plugged into it so it can deliver the logs to my central log host > (which then dumps them into PostgreSQL) - and to enable a quick > rummage in the local logs via less & grep. Well, no, not necessarily. You *could* just query the structured data directly, which avoids needing to do complex, and error-prone parsing of the data using complex (and potentially easy to fool regex's). If this is being done to trigger automation to handle certain exception conditions, this could potentially be a security vulnerability if the attacker could use /usr/ucb/logger to insert arbitrary text into the system logs which could then potentially fool the regex parser (in the worst case, if there things aren't properly escaped when handling the parsed text, there might be a Bobby Tables style attack[1]). [1] https://xkcd.com/327/ Now, you could say that there could be two separate events notification; one which is sent via the old-fashioned text-based syslog system, and a different one which is structured which is better suited for large-scale automation. So for example, at $WORK we *used* to grovel through the system logs looking for file system corruption reports which were sent to the console logs. But we've since added an fsnotify schema to the upstream Linux kernel which sends a structured event notification which isn't nearly as error-prone, and which doens't require parsing to fetch the device name, etc. We didn't remove the old-style "print to the console log" for backwards compatibility reasons, however, so this didn't break people who were used to parse the console log by hand. Linux kernel developers are a lot more about backwards compatibility than some userspace projects (including, unfortunately, systemd). However, this dysfunction isn't limited to Linux userspace. Unfortunately, in the case of (I think, but I'll Digital folks correct me if I'm wrong) Digital's uerf and AIX's unspeakable horror ("AIX --- it *reminds* you of Unix"), backwards compatibility wasn't considered as important by the Product Managers who make these sorts of decisions. Back in the Linux-land, for a while, a number of distributions had rsyslog installed in parallel to the systemd logging system precisely to provide that backwards compatibility. A stable release later, because this meant logging data was being written twice to stable storage, rsyslog has been made no longer the default for some distributions, but of course, you can just install rsyslog by hand if you still want to use it. The bottom line is that while people seem to be ranting and raving about systemd --- and there are a lot of things that are terrible about systemd, don't get me wrong --- I find it interesting that legacy Unix systems get viewed with kind of a rosy-eyed set of glasses in the past, when in fact, the "good old days" weren't necessary all that good --- and there *are* reasons why some engineers have considered plain text ala the 1970's Unix philosophy to not necessarily be the final word in systems design. Cheers, - Ted ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-24 13:50 ` Theodore Ts'o @ 2024-06-24 14:21 ` Dan Cross 2024-06-26 7:39 ` Kevin Bowling 2024-06-24 15:03 ` Steffen Nurpmeso 1 sibling, 1 reply; 160+ messages in thread From: Dan Cross @ 2024-06-24 14:21 UTC (permalink / raw) To: Theodore Ts'o; +Cc: Alexander Schreiber, Alexis, The Unix Heritage Society On Mon, Jun 24, 2024 at 9:51 AM Theodore Ts'o <tytso@mit.edu> wrote: >[snip] > > The bottom line is that while people seem to be ranting and raving > about systemd --- and there are a lot of things that are terrible > about systemd, don't get me wrong --- I find it interesting that > legacy Unix systems get viewed with kind of a rosy-eyed set of glasses > in the past, when in fact, the "good old days" weren't necessary all > that good --- and there *are* reasons why some engineers have > considered plain text ala the 1970's Unix philosophy to not > necessarily be the final word in systems design. I must concur here. To bring this back to history, I think it's useful to consider the context in which, "use text, as it's a universal interchange format" arose. We _are_ talking about the 1970s here, where there was a lot more variation between computers than nowadays; back in that era, you still had a lot of word-oriented machines with non-power-of-2 word sizes, one's complement machines, and the world had not yet coalesced around the 8-bit byte (much of networking is _still_ defined in terms of "octets" because of this). In that era, yeah, it was just easier to move text between programs: transporting a program from a 16-bit machine to a 32-bit machine didn't mean changing parsing routines, for example. Contrast this to today, where things are much more homogenized, even between different ISAs. Most ISAs are little endian, and for general purpose machines 8 bit bytes, power-of-two integer widths, and 2's complement are pretty much universal (I'm aware that there are some embedded and special purpose processors --- like some types of DSPs --- for which this is not true. But I'm not trying to run Unix on those). Furthermore, we have robust serialization formats that allow us to move binary data between dissimilar machines in a well-defined manner; things like XDR -- dating back almost 40 years now -- paved the way for Protobuf and all the rest of them. In this environment, the argument for "text first!" isn't as strong as it was in the 70s. Something that I think also gets lost here is that we also have well-defined, text-based serialization formats for structured data. Things like sexprs, JSON, have all been employed to good effect here. You can have your textual cake and eat your structured data, too! I think what irks people more is that the traditional, line-oriented tools we all know and love are no longer prioritized. But to me that's an invitation to ask "why?" The default assumption seems to be that the people who don't are just ignorant, or worse, stupid. But could it be that they have actual, real-world problems that are not well served by those tools? So it is with systemd. I don't like it, and the recent, "deletes your homedir lol you're holding it wrong lmao" thing solidifies that opinion, but in some ways it's actually _more_ Unix-y than some of the alternatives. Take smf, where nothing screams "UNIX!!!" at me more than XML-based config files consumed by giant libraries. Systemd, at least, is broken into a bunch of little programs that each do one thing (sorta...) well, and it uses somewhat-readable text-based configuration files and symlinks. Indeed, we look at what we consider "real Unix" with some very rosy glasses. Perhaps that's why we overlook un-Unix-like functionality like Solaris's "profile" facilities, where the kernel does an upcall to a userspace daemon to determine what privileges a program should have? Or how about the IP management daemon, in.ndpd, or the rest of the libipadm.so stuff? Unix hasn't been Unix for a very long time now. - Dan C. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-24 14:21 ` Dan Cross @ 2024-06-26 7:39 ` Kevin Bowling 0 siblings, 0 replies; 160+ messages in thread From: Kevin Bowling @ 2024-06-26 7:39 UTC (permalink / raw) To: Dan Cross; +Cc: Alexander Schreiber, Alexis, The Unix Heritage Society On Mon, Jun 24, 2024 at 7:22 AM Dan Cross <crossd@gmail.com> wrote: > > On Mon, Jun 24, 2024 at 9:51 AM Theodore Ts'o <tytso@mit.edu> wrote: > >[snip] > > > > The bottom line is that while people seem to be ranting and raving > > about systemd --- and there are a lot of things that are terrible > > about systemd, don't get me wrong --- I find it interesting that > > legacy Unix systems get viewed with kind of a rosy-eyed set of glasses > > in the past, when in fact, the "good old days" weren't necessary all > > that good --- and there *are* reasons why some engineers have > > considered plain text ala the 1970's Unix philosophy to not > > necessarily be the final word in systems design. > > I must concur here. To bring this back to history, I think it's useful > to consider the context in which, "use text, as it's a universal > interchange format" arose. We _are_ talking about the 1970s here, > where there was a lot more variation between computers than nowadays; > back in that era, you still had a lot of word-oriented machines with > non-power-of-2 word sizes, one's complement machines, and the world > had not yet coalesced around the 8-bit byte (much of networking is > _still_ defined in terms of "octets" because of this). In that era, > yeah, it was just easier to move text between programs: transporting a > program from a 16-bit machine to a 32-bit machine didn't mean changing > parsing routines, for example. > > Contrast this to today, where things are much more homogenized, even > between different ISAs. Most ISAs are little endian, and for general > purpose machines 8 bit bytes, power-of-two integer widths, and 2's > complement are pretty much universal (I'm aware that there are some > embedded and special purpose processors --- like some types of DSPs > --- for which this is not true. But I'm not trying to run Unix on > those). Furthermore, we have robust serialization formats that allow > us to move binary data between dissimilar machines in a well-defined > manner; things like XDR -- dating back almost 40 years now -- paved > the way for Protobuf and all the rest of them. In this environment, > the argument for "text first!" isn't as strong as it was in the 70s. > > Something that I think also gets lost here is that we also have > well-defined, text-based serialization formats for structured data. > Things like sexprs, JSON, have all been employed to good effect here. > You can have your textual cake and eat your structured data, too! > > I think what irks people more is that the traditional, line-oriented > tools we all know and love are no longer prioritized. But to me that's > an invitation to ask "why?" The default assumption seems to be that > the people who don't are just ignorant, or worse, stupid. But could it > be that they have actual, real-world problems that are not well served > by those tools? > > So it is with systemd. I don't like it, and the recent, "deletes your > homedir lol you're holding it wrong lmao" thing solidifies that > opinion, but in some ways it's actually _more_ Unix-y than some of the > alternatives. Take smf, where nothing screams "UNIX!!!" at me more > than XML-based config files consumed by giant libraries. Systemd, at > least, is broken into a bunch of little programs that each do one > thing (sorta...) well, and it uses somewhat-readable text-based > configuration files and symlinks. > > Indeed, we look at what we consider "real Unix" with some very rosy > glasses. Perhaps that's why we overlook un-Unix-like functionality > like Solaris's "profile" facilities, where the kernel does an upcall > to a userspace daemon to determine what privileges a program should > have? Or how about the IP management daemon, in.ndpd, or the rest of > the libipadm.so stuff? > > Unix hasn't been Unix for a very long time now. Apologies if that is too much into the personal taste direction but using Solaris as an exemplar of anything UNIX is not far removed from the common opinions of AIX on this list.. It is an awkward culmination of a lot of money, great multi-faceted marketing spanning several megacorporations, and from the time of enthusiastic overuse of the word "enterprise". Larry and others have described the financial situation that led to Solaris. It was a launch salvo of SVR4.. and SVRn had a lot of expansion(®ression?) in ideology as well as some unfortunate technicalities that have some relevance to the success of NT (especially) and Linux than most historians recount. Knowing that, I find it understandable when people fondly remember Solaris because it was cool, had a nice complement of hardware, software, and training but a little stretched if put on a pedestal. The thing that put Sun on the map was SunOS, and that exemplified UNIX. It is always fun to "what if" Larry's SourceWare. > > - Dan C. ^ permalink raw reply [flat|nested] 160+ messages in thread
* [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 2024-06-24 13:50 ` Theodore Ts'o 2024-06-24 14:21 ` Dan Cross @ 2024-06-24 15:03 ` Steffen Nurpmeso 1 sibling, 0 replies; 160+ messages in thread From: Steffen Nurpmeso @ 2024-06-24 15:03 UTC (permalink / raw) To: Theodore Ts'o; +Cc: Alexander Schreiber, Alexis, The Unix Heritage Society Theodore Ts'o wrote in <20240624135049.GA280025@mit.edu>: |On Sun, Jun 23, 2024 at 10:04:22PM +0200, Alexander Schreiber wrote: |> Except you now have to do the additional step of extracting the |> data from the binary logs and _then_ apply the regex filter you |> were going to use in the first place, which makes the logs less |> accessible. All of my systemd running machines still get rsyslog |> plugged into it so it can deliver the logs to my central log host |> (which then dumps them into PostgreSQL) - and to enable a quick |> rummage in the local logs via less & grep. | |Well, no, not necessarily. You *could* just query the structured data |directly, which avoids needing to do complex, and error-prone parsing |of the data using complex (and potentially easy to fool regex's). If ... |console logs. But we've since added an fsnotify schema to the |upstream Linux kernel which sends a structured event notification |which isn't nearly as error-prone, and which doens't require parsing |to fetch the device name, etc. We didn't remove the old-style "print ... |The bottom line is that while people seem to be ranting and raving |about systemd --- and there are a lot of things that are terrible |about systemd, don't get me wrong --- I find it interesting that |legacy Unix systems get viewed with kind of a rosy-eyed set of glasses |in the past, when in fact, the "good old days" weren't necessary all |that good --- and there *are* reasons why some engineers have |considered plain text ala the 1970's Unix philosophy to not |necessarily be the final word in systems design. But that is the thing, and it has nothing to do with systemd vs a normal syslog. I always wondered why things like fail2ban are used to make active system decisions, including active firewall setup, where daemons which *know* (to their extend) a state transform it to string data, send it to syslog (or files), which then gets parsed again. Christos Zoulas of NetBSD then came over with blacklistd about a decade ago, with patches for OpenSSH and postfix and some more, where at least authentication (failure) events are collected at the core where they happen, and then sent to the blacklistd, which has backends for certain firewalls. The newest OpenSSH has something internal built-in that does not report the event, as far as i know. All those do not help against nonsense connections, like premature forced breaks, or ditto with hanging on the port until the server (or OS even) closes the connection, TLS setup failures, downloading the same file a thousand times, etc etc. A pity it is. The server knows, the firewall or a controller needs to know. All that deep inspection shit of the past, and all the guessing on connection count, interpolating connectivity bandwidth, and what not, "done in the firewall", blind flight. Noone jumped on that train that blacklistd started, even when asked for such possibilities. Sorry, i do not see why a binary "journal" log is any better than a plain text file except that possibly programs can be addressed more easily ... by their name. Btw i hope for that new capability-for-namespaces thing that lwn reported, that would be cool! (Btw with 6.1.93 i could not "cryptsetup close" unmounted mediums that were mounted before kvm driven virtual machines moved to inside cgroup namespaces were started. Off-topic, of course.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 160+ messages in thread
end of thread, other threads:[~2024-06-26 7:39 UTC | newest] Thread overview: 160+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-06-13 14:56 [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' • The Register Charles H Sauer (he/him) 2024-06-13 15:33 ` [TUHS] " Dan Cross 2024-06-13 15:35 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy 2024-06-13 15:41 ` Alan D. Salewski 2024-06-13 15:55 ` Steve Nickolas 2024-06-13 15:39 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Clem Cole 2024-06-13 16:47 ` Arrigo Triulzi via TUHS 2024-06-13 18:39 ` segaloco via TUHS 2024-06-13 18:45 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Mychaela Falconia 2024-06-14 8:59 ` Ralph Corderoy 2024-06-13 18:54 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Dan Cross 2024-06-12 19:29 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' " Greg A. Woods 2024-06-13 20:03 ` Dan Cross 2024-06-13 17:07 ` Greg A. Woods 2024-06-14 14:17 ` Grant Taylor via TUHS 2024-06-16 5:48 ` Alexis 2024-06-15 8:48 ` Greg A. Woods 2024-06-16 19:44 ` Clem Cole 2024-06-17 0:10 ` Peter Yardley 2024-06-17 0:29 ` Clem Cole 2024-06-17 1:01 ` Alexis 2024-06-17 1:21 ` Warner Losh 2024-06-17 1:25 ` Larry McVoy 2024-06-17 1:32 ` Warner Losh 2024-06-17 19:21 ` Stuff Received 2024-06-17 19:28 ` Larry McVoy 2024-06-17 22:34 ` Steve Nickolas 2024-06-16 7:57 ` Greg A. Woods 2024-06-17 23:44 ` Warner Losh 2024-06-18 0:06 ` Larry McVoy 2024-06-18 22:44 ` Greg A. Woods 2024-06-19 2:33 ` David Arnold 2024-06-18 1:52 ` Steve Nickolas 2024-06-18 4:52 ` segaloco via TUHS 2024-06-18 22:50 ` Greg A. Woods 2024-06-18 23:03 ` Warner Losh 2024-06-18 23:27 ` ron minnich 2024-06-19 1:38 ` Greg 'groggy' Lehey 2024-06-19 1:42 ` Warner Losh 2024-06-19 23:28 ` Greg A. Woods 2024-06-20 5:01 ` Scot Jenkins via TUHS 2024-06-20 5:09 ` Luther Johnson 2024-06-20 5:18 ` Luther Johnson 2024-06-20 18:34 ` Greg A. Woods 2024-06-20 18:41 ` Adam Thornton 2024-06-20 19:59 ` Warner Losh 2024-06-20 20:12 ` ron minnich 2024-06-20 20:22 ` Adam Thornton 2024-06-20 20:29 ` ron minnich 2024-06-21 15:46 ` Chet Ramey via TUHS 2024-06-21 16:06 ` Henry Bent 2024-06-21 16:24 ` Chet Ramey via TUHS 2024-06-21 16:40 ` Henry Bent 2024-06-21 16:52 ` Warner Losh 2024-06-21 17:25 ` Chet Ramey via TUHS 2024-06-21 17:31 ` Phil Budne 2024-06-21 17:55 ` Chet Ramey via TUHS 2024-06-20 20:19 ` Clem Cole 2024-06-20 20:34 ` Luther Johnson 2024-06-20 21:00 ` ron minnich 2024-06-20 21:53 ` David Arnold 2024-06-20 22:00 ` ron minnich 2024-06-20 22:11 ` Larry McVoy 2024-06-20 22:35 ` Luther Johnson 2024-06-21 13:57 ` Stuff Received 2024-06-20 19:57 ` [TUHS] Version 256.1: Now slightly less likely to delete /home Jim Capp 2024-06-20 8:05 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register Steve Nickolas 2024-06-19 2:38 ` David Arnold 2024-06-19 22:52 ` Greg A. Woods 2024-06-19 0:08 ` Luther Johnson 2024-06-19 0:46 ` Nevin Liber 2024-06-19 1:00 ` segaloco via TUHS 2024-06-19 3:07 ` Luther Johnson 2024-06-19 3:14 ` Luther Johnson 2024-06-19 3:36 ` Luther Johnson 2024-06-19 6:50 ` arnold 2024-06-19 11:28 ` sjenkin 2024-06-19 9:00 ` Ralph Corderoy 2024-06-19 13:28 ` Larry McVoy 2024-06-19 14:44 ` Warner Losh 2024-06-19 14:53 ` Larry McVoy 2024-06-19 15:08 ` Warner Losh 2024-06-19 15:11 ` G. Branden Robinson 2024-06-19 15:16 ` ron minnich 2024-06-19 15:59 ` Theodore Ts'o 2024-06-19 22:48 ` Kevin Bowling 2024-06-20 5:14 ` David Arnold 2024-06-20 5:32 ` George Michaelson 2024-06-20 6:37 ` Alexis 2024-06-20 7:07 ` David Arnold 2024-06-20 21:07 ` [TUHS] Building programs (Re: " Bakul Shah via TUHS 2024-06-20 23:35 ` [TUHS] " Alexis 2024-06-21 0:05 ` Warner Losh 2024-06-21 0:34 ` Alexis 2024-06-21 0:54 ` Greg A. Woods 2024-06-21 1:06 ` G. Branden Robinson 2024-06-21 1:32 ` Alexis 2024-06-21 1:43 ` Warner Losh 2024-06-21 16:07 ` Chet Ramey via TUHS 2024-06-21 0:35 ` Bakul Shah via TUHS 2024-06-21 1:15 ` Alexis 2024-06-21 1:43 ` segaloco via TUHS 2024-06-21 13:58 ` Alan D. Salewski 2024-06-21 0:35 ` Larry McVoy 2024-06-21 0:49 ` Alexis 2024-06-21 1:22 ` Greg A. Woods 2024-06-21 1:44 ` Kevin Bowling 2024-06-21 15:57 ` Chet Ramey via TUHS 2024-06-22 0:04 ` Alexis 2024-06-22 17:53 ` Chet Ramey via TUHS 2024-06-22 18:15 ` Luther Johnson 2024-06-22 21:16 ` David Arnold 2024-06-23 0:29 ` segaloco via TUHS 2024-06-23 18:50 ` Theodore Ts'o 2024-06-23 18:56 ` Chet Ramey via TUHS 2024-06-23 20:15 ` Stuff Received 2024-06-24 14:03 ` Theodore Ts'o 2024-06-24 14:33 ` Dan Cross 2024-06-24 15:17 ` Warner Losh 2024-06-24 15:23 ` Chet Ramey via TUHS 2024-06-21 15:41 ` [TUHS] " Chet Ramey via TUHS 2024-06-21 15:38 ` Chet Ramey via TUHS 2024-06-20 20:14 ` Alexander Schreiber 2024-06-16 6:43 ` Wesley Parish 2024-06-16 21:56 ` David Arnold 2024-06-16 23:34 ` Luther Johnson 2024-06-16 23:46 ` Larry McVoy 2024-06-17 21:40 ` Steffen Nurpmeso 2024-06-17 0:54 ` Åke Nordin 2024-06-18 5:55 ` Alexis 2024-06-18 6:39 ` Michael Kjörling 2024-06-13 19:37 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Alan D. Salewski 2024-06-13 20:05 ` Clem Cole 2024-06-13 20:31 ` Bakul Shah via TUHS 2024-06-13 20:06 ` A. P. Garcia 2024-06-13 20:26 ` Jim Capp 2024-06-13 21:35 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy 2024-06-14 0:27 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Alexis 2024-06-14 0:59 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy 2024-06-14 1:11 ` Luther Johnson 2024-06-14 1:42 ` Alexis 2024-06-14 4:22 ` ron minnich 2024-06-14 6:54 ` Angel M Alganza 2024-06-14 7:04 ` Dave Horsfall 2024-06-14 7:33 ` arnold 2024-06-14 7:34 ` Andy Kosela 2024-06-14 7:44 ` Dave Horsfall 2024-06-14 11:31 ` Vincenzo Nicosia 2024-06-13 20:26 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Dave Horsfall 2024-06-14 11:32 ` Michael Kjörling 2024-06-14 12:21 ` A. P. Garcia 2024-06-18 12:02 ` Arrigo Triulzi via TUHS 2024-06-23 0:13 ` Dave Horsfall 2024-06-23 1:47 ` Alexis 2024-06-23 19:00 ` Theodore Ts'o 2024-06-23 20:04 ` Alexander Schreiber 2024-06-24 13:50 ` Theodore Ts'o 2024-06-24 14:21 ` Dan Cross 2024-06-26 7:39 ` Kevin Bowling 2024-06-24 15:03 ` Steffen Nurpmeso
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).