After rattling around in the back of a train car with nothing but my thoughts, I emerged and said: "systemd is a pox on our way of life" and then promptly rolled over and went back to sleep. -Henry On Fri, 2 Jul 2021 at 17:38, Larry McVoy <lm(a)mcvoy.com> wrote:

Steve Nickolas wrote in <alpine.DEB.2.21.2107021910240.15013(a)sd-119843.dedibox.fr>: |On Fri, 2 Jul 2021, Henry Bent wrote: |> On Fri, 2 Jul 2021 at 17:38, Larry McVoy <lm(a)mcvoy.com> wrote: |> |>> As I started reading it I found plenty to disagree with in the first few |>> paragraphs but they completely lost me at "After all, moving from System |>> V init scripts to systemd has arguably improvedthe Linux boot sequence." |>> |>> Um, no, just, no. |> |> After rattling around in the back of a train car with nothing but my |> thoughts, I emerged and said: |> |> "systemd is a pox on our way of life" |> |> and then promptly rolled over and went back to sleep. |> |> -Henry |> | |The Linux distro I use does use systemd but I can ignore it and go on with |my life as if it were still running sysvinit. So it's not that big a deal |to me. | |I'd prefer that they kept sysvinit, but eh. What's that saying? "Those |who fail to understand Unix are condemned to recreate it, poorly" ? Well iwd(8) for example that i happen to have installed as a replacement for wpa_supplicant just today (because .. i installed my beloved sysvinit/BSD rc based CRUX-Linux on a new spare laptop, a 18 month old but totally new IdeaPad S145, and since i do not have initrd kernels but compile an all-builtin one i use a generic kernel in order to lsmod(8) in order to be able to create a custom kernel with a modified "make localyesmod" that Linux supports, here ArchLinux 2020.12, because AlpineLinux did not do it, somehow, and whereas i hate that ArchLinux now that all old developers fled does not even ship install instructions it actually does come with iwd/iwctl, and it happened that iwctl looked so much better to me than wpa_cli of wpa_supplicant, that i took the time and replaced there here, iwctl has at least one bug though, iwd ditto, and i must say that whereas iwd is much smaller is has a larger memory footprint than wpa_supplicant, and .. whatever), and note that iwd neither supports a normal syslog nor command line parameters to configure paths etc., the latter have to come in via environment if they shall, and the manual says these are "normally provided by systemd" (which is not true .. for me). And no syslog at all! No PID file handling. And bugs even though Intel.com paid for it. I mean "get up, stand up", they do a thousand things and not seldom i wonder. @Tony Finch: wonderful reading of the first two pages, thanks for this link! It seems Knuth always had "a touch" for writing good, and for good writing. P.S.: not that do-one-thing's like sysklogd are bug free, for example the sysklogd CRUX now uses/offers introduced a new bug that causes /var/log/kernel to print monotonic clock times or what, mind you, just now it is "Jun 30 13:13:16" (for "kent"). --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)

I remember at some Usenix panel, Steve Johnson said "what happens to the Unix model when the primary mode of interaction isn't a set of bytes" This was 20+ years ago, IIRC. I think Rob Pike's ACME and Squeak tried to provide an answer to a half-way situation.

On Sat, Jul 3, 2021 at 8:36 AM Thomas Paulsen <thomas.paulsen(a)firemail.de> wrote: Systemd is both good and bad. The good part is that it allows for parallel service startup, which means that your system gets up and running (and serving useful work) faster. It understands the service dependency graph and thus the service start order and what can be done simultaneously. It also, in theory anyway, makes life a little easier for the authors of what I'll call "service software" (read: daemons and servers): need a privileged resource? Describe it to systemd, that will then acquire it for you and hand it to your unprivileged service software. That's nifty, aids privilege separation, namespace sandboxing a la containers, etc. But systemd is also terrible. In an extremely un-Unix-like manner, it consolidates an enormous number of disparate functions into a single monolithic piece of software. It uses ersatz data formats that are abjectly horrible. It uses binary logging, which means that one cannot use the full complement of Unix text filters to inspect logs. It does all sorts of stuff behind the scenes (manipulating filesystems, for example) in ways that are obscured and opaque to system administrators, let alone programmers; this can have surprising results (ask Ron Minnich about systemd-related data loss). It has complete disregard, and indeed, contempt for the Unix philosophy. What's interesting (to me, anyway), is how few people care about the deficiencies. This suggests a pretty fundamental shift in how people use Unix-like systems, and Linux in particular: for _most_ users, it has become a commoditized vessel for running other interesting software, but not what we historically think of as "Unix". Sure, a lot of people still live at the command line, but that's no longer the primary focus of interaction. Our machines are now either all-singing, all-dancing multimedia workstations where the sole user is in a web browser most of the time, in which case the underlying system is just a detail, they're server-class machines that are running some workload, but not something that's interactive, or embedded devices that are black boxes. Much of Unix's early evolution and thus architecture and philosophy, came from addressing a set of problems that people had in a historical context that, one could argue, aren't that relevant anymore. A hierarchical filesystem in a global namespace, pipelines facilitating chaining of filters for interactive use, a simple but weak permissions model, unstructured text as a universal interchange format, terminal-oriented text editors.... All of these were fine on shared multiuser interactive machines, but do they matter as much now? If the nexus of interaction is a web browser, who cares whether I can grep a log file? If I just want my bluetooth headphones and USB camera to work for an online meeting, how that stuff is put together under the hood isn't that interesting to me. In short, the Unix philosophy is becoming less and less relevant as a new generation of users and programmers put different demands on systems. Linux is _probably_ the most prevalent kernel in the world, but most places its used it's hidden from view. In that context, something like systemd actually makes some amount of sense. Perhaps I've mentioned this story before: a former colleague at Google was writing a shell script to figure something out. It wasn't working. Really, what he wanted was basically a `grep -q` and an `if` statement, but he'd written a complicated mess with shell functions that tried to "return" the exit status of the processes they ran: his shell script was written more like a Python program. I rewrote it for him in half-a-dozen or so lines (down from 30 or 40) and talked about Unix for a minute, the philosophy, etc. At the end of my monologue extolling the virtues of our style of computing, he looked at me blankly and said something along the lines of, "yeah. I think that time has passed and people just don't conceptualize problems that way anymore." I was sad, but is it any wonder that the kids reach for Python before a shell script these days? We aren't teaching, yes, but moreover they don't want to learn because the problems they're trying to solve are different. We need to accept and internalize that and think hard about how the tools we use can be brought to bear on the problems that are relevant _now_, not 30 years ago. It does beg the question: is a Unix-style kernel still the appropriate foundation for this style of computing? Why are we still using this system: is it because of its intrinsic power and versatility, or because of inertia? Systemd, containers, etc, all suggest that our models are inadequate. - Dan C.

On Sat, Jul 3, 2021 at 11:45 AM Theodore Ts'o <tytso(a)mit.edu> wrote: You mean System V's sar program? BSD has never had a sar program. It's not in any of the CSRG releases, nor in any of {Free,Net,Open}BSD systems that are around today. It first appeared in System Vr1, and was in each of the following releases if the listings of files on the net are any indication. Sounds awful... Warner

On Sat, Jul 3, 2021 at 2:10 PM Theodore Ts'o <tytso(a)mit.edu> wrote: Huh. I guess 'sa' wasn't good enough, though that also uses a format that suffers from many of the same deficiencies you point out for 'sar'. My larger point remains, though; is System V considered "Unix" by Dan Well, with the caveat that I'm pretty sure Dan Cross's definition of Unix is of interest to an extremely small set of people (possibly the empty set...), and that any answer is a bit of a meditation on the existential philosophy of, "really, what _is_ Unix, anyway?" I'll go out on a limb and say yes. I don't think that the pervasive use of text formats for logs in much of the system was ever meant to be to the exclusion of binary formats for specific applications where that was warranted (usually for efficiency), which have existed since the near the beginning. Off the top of my head, representative examples of logging or logging-adjacent binary formats common on Unix systems and extending into antiquity include utmp/wtmp, lastlog, the quota database and acct; perhaps even crash dumps and core files might fall under this overarching umbrella. Not to mention all of the other ubiquitous binary file formats that've been floating around seemingly forever: tar/tp/ar/UFS dump, dbm/ndbm, any number of compressed file formats, and so on. Not to mention the on-disk data structures describing filesystems and so on. But historically speaking, logs, whether generated by explicit print statements in programs or by something like calling `syslog()`, have been text. I suppose the point being that, while individual use cases might use some binary format, by and large most systems opted to use text and for many years that was just the accepted and anticipated course of action. It was the default. Systemd turns this on it's head. Text isn't just no longer the default, it's just not an option. Sure, the aforementioned things are similar, but this is a step beyond. And note that I didn't say that Linux wasn't Unix because of systemd (or perhaps more properly, that the Linux distributions that use systemd weren't Unix), but rather, that systemd itself wasn't very Unixy. I think that's accurate. Of course with respect for the other binary things you mentioned (databases and so on) people write all kinds of whacky things for systems, but those don't define the system. Systemd is much closer to the "system" than, say Ingres of Oracle or PostgreSQL. I do think this shift probably started with System V, but it still largely follows the model of "Unix". And even AIX has syslog. It's funny...I have no recollection of the mechanism you describe for Ultrix, and a DECstation 5000/240 was my main machine for a good while. - Dan C.

On Sun, Jul 04, 2021 at 02:47:57AM +0200, Tomasz Rola wrote: This is a response to Cross. You are sort of right in that we are not on uniprocessors where we disable interrupts to manage things. Unix still matters. It has mattered for a very long time, I could argue it is the most important operating system in the world. Yeah, windows won, but it didn't win on merits. In my opinion you couldn't be more wrong. We still have the same problems, we are still trying to grep an answer out of a bunch of info that has just gotten bigger. We still want to do the same things and we are doing them better with faster CPUs, memory, disks, etc. I maybe think the reason you think that things aren't relevant anymore are because young people don't get Unix, they just pile on to this framework and that framework, NONE OF WHICH THEY UNDERSTAND, they just push more stuff onto the stack. If you actually have a clue, if you can do stuff, all of that other stuff becomes fluff. Yep, some of it is useful but most of it is just there because it wants to feel important. Unix matters, the way that you can compose stuff still matters, people who can do that run circles around the people who say Unix doesn't work. My first job, they said 6 months, I did it 3 weeks by using what Unix gave me.

On Sat, Jul 03, 2021 at 09:36:15PM -0700, Larry McVoy wrote: I'm not sure I agree with you. The same problems still exist, to be sure. But there are new problems that have also arisen, for which Unix might not be the best match. For example, Unix didn't have to deal with devices appearing after the system has booted; or those devices disappearing afterwards. And of course, with services that might need to be started or reconfigured or stopped as devices get attached and detached. The original Unix systems didn't have the requirement of automatically detecting failed hardware or software, and taking action to mitigate those faults without depending on operators in data centers. If we consider some of the structured logging systems, whether it's Ultrix/OSF's uerf, or Solaris's SMF, or Tuttle (an internal system I designed for $WORK), it's at least in part because scraping /var/log/messages and having cluster management systems parse textual log entries using an unholy mess of regex's is error prone and not necessarily reliable or maintainable. There are also new problems, such as Machine Learning, which has led to the introduction of coprocessors, which is a great example of something which is *not* doing the "same things" but with better CPUs, memory, disks, etc. You can of course define away some of these new problems as "not interesting", or "not the true spirit of Unix", but the reality is there are a good reason why systems have been changing --- it's in response the pressures of new requirements and new problems being added, even if the old problems haven't gone away. This is perhaps an unavoidable response to increasing complexity. When I was an undergraduate we started by building a computer using TTL chips on a breadboard, and then we went on to learn Scheme and the Lambda calculus, and then built up from there. But a few years ago, MIT decided this wasn't sufficiently relevant to how most software engineers work today, so the intro to computing class was redone to use Python, and it was a stated goal to give students experience in how to build on top of a framework which is not sufficiently documented, and where they need to figure out what the #?$!@? was going on via experimentation, supplemented with whatever documentation and sources that students could find/read/understand. (And if you look at the depth of a stack trace after a typical Java application crashes due to an unhandled exception, MIT has probably gotten it right in terms of what most CS students will experience after they graduate. I remember looking 80-90 Java function names in a Lotus Notes stack dump after a crash, involving the Eclipse *and* the Standard Java library frameworks, with awe and horror...) As a result, I've found that most new college grads don't have much in the way of Systems training or experience, and for those groups that need that kind of Systems thinking at $WORK, it's something we need to train, and not something I can assume new hires will have. (This is also true for many candidates with significant industry experience which I've interviewed, alas.) - Ted

On Sun, Jul 04, 2021 at 01:10:14PM -0700, David Barto wrote: I know that is tongue in cheek, but because I want a real kernel that has sane semantics. The windows kernel is pretty nuts.

On Sat, Jul 3, 2021 at 8:57 PM Tomasz Rola <rtomek(a)ceti.pl> wrote: I didn't say that Unix is no longer relevant. I said that the problems that were prominent when Unix was built, and that thus shaped its architecture, are much _less_ relevant now than they were at the time. They still have some relevance, but are no longer primary for the vast majority of use cases Unix is used for. Further, the way people approach problems now has changed, even if they still generically assume "Unix" as the base they build on. - Dan C.

On Mon, Jul 5, 2021 at 3:15 AM Tomasz Rola &lt;rtomek(a)ceti.pl&gt; wrote: I think there is more to it than that. See < http://www.catb.org/~esr/writings/unix-koans/zealot.html>. I am not sure. I tried to find some time and install old OS on ITS, yes. But the debugger was not just a debugger, it was also a general command-line interpreter, a shell in modern terms. So while it is possible to debug an empty memory into doing whatever you want, it is also possible to run "advent", aka Colossal Cave Adventure. I switched from Teco to ex at some point, and never went either forward or back. (Occasionally I drop into vi mode for things like parenthesis checking.) By the way, did anyone else start out on Unix-alikes before using actual Unix? I read the BSTJ issue and became an instant convert, but only when $EMPLOYER got a MicroVAX was I able to work like that. Next came the MKS Toolkit on DOS, and then Cygwin for many years. I suppose it's only my last two $EMPLOYERs standardizing on the Mac that has left me running, like, actual Unix. If I still stick to Unix, it is because I still need something "Computers are the greatest set of electric trains in the world." True. But then, many of us geeks make our choices not on technical criteria but on tribal loyalty. Which is *technically* superior, vi or emacs? (Please don't answer that.) Note that Emacs is probably the oldest import into the Unix ecosystem from outside, and it bears the marks of its origin: monolithic (but programmable), one tool does it all. Without doubt. I am not loyal to a kernel or a set of utilities, I simply follow the Way of Unix: <http://vrici.lojban.org/~cowan/upc/> (sadly incomplete) John Cowan http://vrici.lojban.org/~cowan cowan(a)ccil.org "Hacking is the true football." --F.W. Campbell (1863) in response to a successful attempt to ban shin-kicking from soccer. Today, it's biting.

On Wed, 7 Jul 2021, Tomasz Rola wrote: I don't think that's anything new. "Great OS, where's the editor?" is a really old joke about EMACS. -uso.

On Tue, Jul 6, 2021 at 7:17 PM Tomasz Rola &lt;rtomek(a)ceti.pl&gt; wrote: Well, yes. But to achieve that state of effortlessness requires so much effort!

The emacs manual *printed, one-sided, bound to the desk with rods of steel* which I read in the 1980s in leeds was one of the best explanations of Virtual Memory I saw. I really struggled with the idea of address segments, maps, the idea of address space being bigger than physical memory (I think I drove a PhD student doing tutoring close to tears on this in '79) but the Emacs manual said really clearly up-front: "look, you can't address 32 bits of memory in "me" I only do 24, but this is how I do them, if you're interested" The Vax VMS manual along side it (another 2 feet of single-sided print) was probably as good, but more aimed at real engineers who could think in RPN and had pocket protectors. This was in a context where it was probably the go-to basis to try and play with LISP because nobody really told you about any other REPL to run in. I think even then I realised I wasn't going to ever want to code a towers-of-hanoi, nor even really explore 24 bits of (virtual) address space. I hate the cult. I decided to re-learn the finger muscle memory, now I can do bare-minimum in emacs for ORG and I think I'll go back to vi where I belong. vi suffered from insufficient love. I had to stop hating vim when it became the only real choice. (hate.. culty word, that) VScode was interesting, as was Atom, and I suspect more than a few people who code for a way of life here think this editor-wars stuff is tedious. I actually "think" in ed. I can't escape line-based semantic intent. I carry my own personal koan which basically says "any algorithm which needs more than 2 sentences or 1 screen of code to implement is probably beyond you". Its a bit of a flaw. On Wed, Jul 7, 2021 at 10:47 AM Theodore Ts'o &lt;tytso(a)mit.edu&gt; wrote:

On Tue, Jul 06, 2021 at 08:46:34PM -0400, Theodore Ts'o wrote: [...] [...] Yeah, during my 486 days it was indeed doing stuff with disk. But I was too happy to have this "workstation lookalike" running "Unix lookalike" installed from dozens of floppies so I did not complained about some minor problems. An excerpt from my ps: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND xxxek 576 0.0 0.2 283392 34172 pts/122 SNl Jun29 0:06 emacs xxxek 23684 0.3 1.7 379624 211872 pts/21 SN Jul03 22:06 emacs /ho xxxon 12331 12.5 20.4 5898360 2519640 ? TNsl Mar29 18278:11 firefox-esr xxxon 3553 0.0 1.2 218028 150656 pts/67 TN Jun30 0:24 dillo xxxek 12588 0.0 0.0 38108 752 pts/183 T 2020 0:00 lynx -nocolor -force-html /ho xxxek 6785 0.0 0.0 310580 10052 pts/22 Sl 2020 41:51 roxterm xxxek 5321 0.0 0.0 102712 1456 tty2 S 2020 1:56 rxvt -bg Black xxxek 5322 0.0 0.0 66784 1988 tty2 S 2020 165:48 xterm -bg xxxek 5596 0.0 0.0 21608 536 pts/121 S+ 2020 1:35 /usr/bin/screen Emacs ver.23, firefox ver. "very old". I do not trust my browsers too much, so when I go to sleep they go to STOP freeze. The second emacs is editing my pathetic########glorious######## wiki with org-mode, file length about 55 megabytes, with unicodes, so the rss is multiple of file size. I have long ago replaced konsole with roxterm. As you can see, it eats nowhere near a gigabyte. And it does not read a whole disk when starting. It usually goes with three tabs opened, so maybe in your case memsize would have been bigger. I make a lot of use with virtual desktops offered by fvwm, and when I need terminal on one of those desktops (I usually do), I open some rxvt variation; position, resize and keep it there for further use. As I have only 12gigs of ram and more than half goes to ramdisk (always doing something there, including compiling huge piles of code from the net), so I have to keep an eye on firefox. When it goes above 2.9g of rss I usually start to fret and kill unneeded tabs. I set it up to use only two or three fonts and completely disregard author-provided fonts. So far, so good. Ah, and I use noscript, too. Yet despite of all those precautions, I have to kill -STOP it, because the mere thought that it will keep eating 50-90% of cpu while doing nothing, well, this drives me up the wall. Likewise, back in the past, when I saw how *idle* program (firefox) constantly wrote *gigs* of bytes to my disk, I simply went mad. Long story short, now it only can write to temporary place in ramdisk. It still does not stop it from opening multiple files on disk in /tmp, deleting them and keeping opened/deleted forever, using up my precious ram. It sometimes closes those files, but not very often. I usually open new pages in dillo, w3m or lynx (or curl) and use firefox when nothing else would do. Not perfect solution - dillo has some memory problem, so I usually have many of them opened and slash those who grow too much. Like, 300megs for dillo is enough. Read up all the tabs in it and kill. And it seems I have (pidof lynx|wc -w) 170 lynx processes, all kill-stopped and awaiting my attention. Craps. Chances are I did not stopped being mad. At least Unix command line tools allow me to measure it. Now I am happy that I do not use systemd. Now I want to find more time and migrate to OpenBSD. I really do (I know there are some Linux distros which evaded systemd - for a while, but I consider a whole Linux land to be lost already, just a matter of time, and I foresee that OpenBSD will fall as the very last, if ever). I will sleep less and program more. I will rewrite all my old python2x scripts in r7rs scheme. Not really so many. Fruits of hard work shall be sweet and plentiful. 12g for a browser. I am not criticising you, but I could say a bit about people who made programs and websites contributing to such sizes. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola@bigfoot.com **

On Wed, Jul 07, 2021 at 08:50:51PM +0000, Michael Kjörling wrote: This is quite strange for me. Without looking at your system I can only suspect it has something to do with multithreading. If I do two different commands as root, with firefox pid here .eq. 12331, as above: => (500 15): lsof -p 12331 | wc -l 402 => (500 17): lsof | awk '$2==12331' | wc -l 22055 The first column gives a name, and in second case it not always is 'firefox'. I am yet to study manpage for lsof and play with it, but it surely shows interesting things. On my system, when firefox gets killed, 'free' shows a difference - if I recall, free mem increases by the size of rss plus all the stuff which was opened and released from buffers. I did not pay much attention, I assumed numbers would match and this is what they probably did :-). OS on my box used to report to me as Debian, and still does, but some years ago I have decided to skip the usual system upgrade, and after some more time I started to upgrade various elements by hand. So it is more like a tattered patchwork right now. But it does what I expect, hopefully. [...] Yeah, strange. [...] Hard to tell - first I would like to learn where the hundred-giga rss came from... -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola@bigfoot.com **

Derek Fawcus wrote in &lt;YOcE3fre5cUTt6Br(a)clarinet.employees.org&gt;: |On Thu, Jul 08, 2021 at 08:46:53AM +0200, Tomasz Rola wrote: |> On Wed, Jul 07, 2021 at 08:50:51PM +0000, Michael Kjörling wrote: |>> On 7 Jul 2021 20:32 +0200, from rtomek(a)ceti.pl (Tomasz Rola): |>>> An excerpt from my ps: |>>> |>>> xxxon 12331 12.5 20.4 5898360 2519640 ? TNsl Mar29 18278:11 \ |>>> firefox-esr |>> |>> I'm going to stick my neck out here by saying that the VSZ and RSS |>> values reported by ps, at least for Firefox, are largely meaningless. | |Or does it depend upon the OS? From a mac instance: ... |So there are defintitly issues in mapping the current use of various types |of memory to a simple display format. Another thing is that, when i used it, Mac command line tools did not take care about exit status (as in "succeed though they should not") or know about job signals. But it is not only Mac, take iwd again, iwctl('s display handling) definetely is buggy in respect to handling of SIGCONT after a TSTP. (Ie the screen starts scrolling line-wise but no display is ever refreshed.) Regarding the thing, here this seems pretty much fine for RSS. root 1454 0.0 0.0 7912 2480 ? S 21:03 0:00 /bin/bash /x/pub/box-web.sh browse firefox root 1456 0.0 0.0 3012 2032 ? S 21:03 0:00 /usr/bin/doas -u steffen /box.firefox steffen 1457 0.0 0.0 2384 700 ? S 21:03 0:00 /bin/sh - /box.firefox steffen 1458 31.2 3.7 3029004 299700 ? Sl 21:03 0:04 firefox --no-remote steffen 1545 4.0 1.3 2421200 108196 ? Sl 21:03 0:00 /usr/lib/firefox/firefox-bin -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 244806 -parentBuildID 20210614221319 -appdir /usr/lib/f steffen 1583 2.2 1.1 2412124 89636 ? Sl 21:03 0:00 /usr/lib/firefox/firefox-bin -contentproc -childID 2 -isForBrowser -prefsLen 4909 -prefMapSize 244806 -parentBuildID 20210614221319 -appdir /usr/li steffen 1636 0.6 0.7 2382844 59560 ? Sl 21:03 0:00 /usr/lib/firefox/firefox-bin -contentproc -childID 3 -isForBrowser -prefsLen 5602 -prefMapSize 244806 -parentBuildID 20210614221319 -appdir /usr/li Yeah i use --no-remote because otherwise firefox will find its other-box instances via X cookies (i do not have Wayland here). I deem it a critical error that firefox then starts up even though the ~/.mozilla/XXX profile is a totally different one, but on the IRC we just ended like this. Btw i use setup_cgroup() { #return [ -e /sys/fs/cgroup/cgroup.procs ] || return [ -d /sys/fs/cgroup/_box_web ] && return ( umask 0022 mkdir /sys/fs/cgroup/_box_web || return ) echo 1-3 > /sys/fs/cgroup/_box_web/cpuset.cpus echo 1 > /sys/fs/cgroup/_box_web/cpu.weight echo 300 > /sys/fs/cgroup/_box_web/pids.max echo 1000000000 > /sys/fs/cgroup/_box_web/memory.high } on this box for box-web.sh, and i can read all my newspapers and browse the web, even youtube. If i open to many tabs, they start crashing. This mostly seems due to the pids.max, however, i already increased this from 250. What _i_ find interesting is that for the first time i really get impressive scheduling feedback. This cpu.weight=1 can indeed cause the browser to be delayed entirely for minutes, dependent on the other tasks on the system. I mean really, totally, entirely. I was impressed by reading the sched manual once i came back to Linux two years ago, but seeing cpu.weight=1 in action _like that_, really impressive. Btw .. happy to be on the other side of the spectrum steffen 1251 0.0 0.0 11240 6184 tty1 S Jul05 0:06 cwm steffen 1261 0.0 0.1 19284 9096 ? Ss Jul05 1:11 st -n stgrey steffen 1262 0.0 0.0 8588 3896 pts/0 Ss+ Jul05 0:00 tmux a steffen 1334 0.0 1.1 94088 88680 ? Ss Jul05 1:25 tmux a steffen 5058 0.0 0.1 14672 8712 pts/1 S+ Jul05 0:11 s-nail -Aich steffen 30448 0.0 0.2 100800 19052 pts/7 Sl+ 20:50 0:00 irssi steffen 1340 0.0 0.0 11848 6840 pts/6 Ss+ Jul05 0:00 vim -u /home/steffen/.vimrc It all fits a single Terminal.app (if not taking into account tmux history), even if online. (Granted st does not have the history patch, and firefox not running.) --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)

Steffen Nurpmeso wrote in &lt;20210708192538.jpOvc%steffen(a)sdaoden.eu&gt;: ... | steffen 1458 31.2 3.7 3029004 299700 ? Sl 21:03 0:04 \ | firefox --no-remote ... |Yeah i use --no-remote because otherwise firefox will find its |other-box instances via X cookies (i do not have Wayland here). |I deem it a critical error that firefox then starts up even though |the ~/.mozilla/XXX profile is a totally different one, but on the |IRC we just ended like this. Not to mention that firefox-bin 89.0.1 as compiled mozilla.com themselves no longer does that right, it will exit the other instance in another box with another profile directory even if both instances start with --no-remote. Heck, software is a complicated beast. Has to be said, humans produce so many bugs, i am happy that it is software that controls american warships, nuclear power plants, the chemical industry, and so many other important things! --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)

On Wed, Jul 07, 2021 at 08:50:51PM +0000, Michael Kjörling wrote: No, VSZ is correct, but it's confusing since it includes things that you might not expect. VSZ includes *all* virtual memory space consumed by a process. For example, consider this simple program: main(int argc, char **argv) { printf("Hello, world\n"); sleep(10); return 0; } It uses shared libraries: % ldd /tmp/hello linux-vdso.so.1 (0x00007fff20bff000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd8caad9000) /lib64/ld-linux-x86-64.so.2 (0x00007fd8cacca000) If you run the program the ps listing looks like this: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND tytso 4060239 0.0 0.0 2300 512 pts/2 T 17:01 0:00 /tmp/hello If you look at /proc/4060239/maps, you'll memory map for the process. 5559e8e7d000-5559e8e7e000 r--p 00000000 00:25 260006 /tmp/hello 5559e8e7e000-5559e8e7f000 r-xp 00001000 00:25 260006 /tmp/hello 5559e8e7f000-5559e8e80000 r--p 00002000 00:25 260006 /tmp/hello 5559e8e80000-5559e8e81000 r--p 00002000 00:25 260006 /tmp/hello 5559e8e81000-5559e8e82000 rw-p 00003000 00:25 260006 /tmp/hello 5559ea383000-5559ea3a4000 rw-p 00000000 00:00 0 [heap] 7f8419a44000-7f8419a69000 r--p 00000000 fc:00 10763398 /usr/lib/x86_64-linux-gnu/libc-2.31.so 7f8419a69000-7f8419bb4000 r-xp 00025000 fc:00 10763398 /usr/lib/x86_64-linux-gnu/libc-2.31.so ... If you add the sum total of all of the VM regions, i.e.: (0x5559e8e7e000 - 0x5559e8e7d000) + (0x5559e8e7f000 - 0x5559e8e7e000) + (0x5559e8e80000 - 0x5559e8e7f000) + ... (ignore the last vsyscall region, since that's a kernel page mapped into all processes) You'll get the 2300k of the VSZ. If the process mmap's in a large 2GB file, the VSZ will go up by 2GB, even if none of the file is paged in. Or if you mmap in 2MB of anonymous memory backed by the zero page for the heap, the VSZ will go up by 2MB. I don't think that's right. Are you sure it's not 374MB? I started firefox-esr on my Debian machine, and the PS output is: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND tytso 4063201 5.8 1.0 3027868 357248 pts/2 Sl 17:38 0:07 firefox-esr tytso 4063274 0.5 0.3 2446608 105620 pts/2 Sl 17:38 0:00 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 1 -isF tytso 4063317 0.8 0.3 2457032 124200 pts/2 Sl 17:38 0:01 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 2 -isF tytso 4063341 2.9 0.8 2623896 282420 pts/2 Sl 17:38 0:03 /usr/lib/firefox-esr/firefox-esr -contentproc -childID 3 -isF 357248k is 343MB. Maybe you were adding up the RSS's for all of the processes? That's misleading because if a physical 4k page is shared across multiple process, that 4k page will be accounted in each of the processes's RSS --- even if that process hasn't actually *used* that particular page. So for example, the hello world program had a 512k RSS: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND tytso 4060239 0.0 0.0 2300 512 pts/2 T 17:01 0:00 /tmp/hello That's not because the hello world program actually used half a megabyte worth of the C library; but rather, almost half a megabyte of the C library has been paged in to support all of the processes currently running in the system. It also follows that every process using shared library is going to have an RSS which is at least 512k. Cheers, - Ted

Tomasz Rola &lt;rtomek(a)ceti.pl&gt; wrote: The more unixy parts of AmigaDOS came from TRIPOS https://www.pagetable.com/?p=193 https://en.wikipedia.org/wiki/TRIPOS TRIPOS was originally developed by a team led by Martin Richards, who had previously developed BCPL. Also true for the Acorn / Norcroft ARM C Compiler on the Archimedes, which was my first contact with unix-like tools :-) Tony. -- f.anthony.n.finch &lt;dot(a)dotat.at&gt; https://dotat.at/ Northwest Fitzroy, Sole: Northwesterly 4 or 5, occasionally 6 at first, backing westerly or southwesterly 3 or 4 later. Moderate, occasionally rough at first. Showers. Good, occasionally moderate.

On Tue, Jul 06, 2021 at 12:05:04PM -0400, Clem Cole wrote: [...] [...] Clem, thanks a lot for writing this. I think I have connected few dots now. Like, I was long aware that there were various groups of computer users, but never before I had the thought about how this "divide" contributed so much to creation and adoption of Unix. I suppose I like Unix even more now. [...] Ahem. I do not see myself selling or buying during golf course... Especially if it has to do with computers... [...] I will see if I can have my hand on it. I definitely like this attitude. Yikes. Five kilodollars, what a deal. When I learned C, in middle/late 80-ties, it was my third language after Basic and Pascal. I did not have computer at that time and I wrote short programs in a notebook. I wonder if I could locate the notebook and if any of this code would run. But, compared to the first two, C had something fresh in it. Nowadays, however, this freshness is a little bit trapped under a ton of supporting libraries. Back at the time, the fact there was a C compiler on every computer I heard about, and standard library gave it a bit of unified look, and I could write C oneliners on less paper, more idiomatic (saves time! all those begin/end words replaced by mere curly braces, very nice) - all of this made C very interesting to me. [...] I hope C would have been invented even without Unix. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola@bigfoot.com **

On Sun, Jul 04, 2021 at 09:10:49PM +0100, Tony Finch wrote: This is also a really good talk, by Benno Rice. Benno is a FreeBSD developer, and has served on the FreeBSD Core Team. He gave this talk at Linux.Conf.au 2019, and it was a repeat of a talk he gave at BSDCan 2018, entitled "The Tragedy of Systemd" ("Tragedy" in the title was used in the Greek drama context): https://www.youtube.com/watch?v=o_AIw9bGogo It's a pretty fair talk about the why systemd came up, and what we might be able to learn from systemd. His closing line was, which I think is quite good was: "What I would challenge every one here is to look at systemd, and try find one thing you like --- and then go try to implement it." - Ted

Independent of systemd, the idea of regularizing service management is quite useful. A single function in a way, & fits the Unix Philosophy [which is really about factoring out common components and making them easily reusable. The fact that the shell allows that sort of composition with minimal syntax is, to me, one of its greatest contributions] Similarly there are other such new functions where this philosophy can be applied. Containers, and many other tech. solutions have evolved in response to changing needs. The question that interests me is can we apply the Unix philosophy in this changing environment and if so how. One thing I like about Apple is their continuous focus & s/w evolution on helping the end-user (we may disagree on specific changes but I bet many people on this list are using Apple devices as their "terminal"). It is a real joy to use some of these programs. And yet it is a real shame to not see open standards for such things.

Hmm ... do I want to get in the middle of a fight with my friends and get them all mad at me… but I guess I cann’t just keep quiet on this debate. Basically I think Larry and Dan are having the Dan Akroyd/Gilda Radner “Shimmer” Dessert Topping / Floor Wax <https://www.youtube.com/watch?v=wPO8PqHGWFU> debate. That said, I do think systemd is a giant step backward for most of the same reasons others have already said, so I’ll not pile on and stick to the basic what does it mean to be Unix or not/what is an improvement or not, discussion. Larry observes: “I maybe think the reason you think that things aren't relevant anymore are because young people don't get Unix, they just pile on to this framework and that framework, NONE OF WHICH THEY UNDERSTAND, they just push more stuff onto the stack.” Simply, I could not have said that better. But that is a symptom of the problem. Frankly, with frameworks and the like, we have added so many levels of abstraction, we have completely lost sight of the real issues and many folks really don’t “think like a programmer” any more. Remember, UNIX was a system *by programmers for programmers.* Much work since has been hiding a lot of what made it great IMO - which I think has caused the most damage. What makes a system a flavor UNIX or not is almost personal, based on what you value (or not). But the fact is no matter what you call it, “UNIX” is the core kernel with a small and simple set of operations, plus a set of programs that are all based on the simple ideas, basic concepts and mostly solid mathematics/computer science that a small group of people in NJ came up with at the time, when they suggested there might be a better way to put things together than had been otherwise popular at the time. Their concepts and ideas collectively were different enough that they were encouraged to write a paper about it. That paper was accepted and published in CACM, it got a lot of people in the community interested in those ideas and the rest is history as we say. But a huge difference between then and now is the *economics* and thus the matching equipment they used to explore those new ideas. So some solutions, we take for granted today, would not be practical, much less even possible in those times. Just like some people trying to claim that ‘Linux’ is not UNIX, falls away deftly as well as it did years ago when other ‘progressive’ features were added to 'Research UNIX' and we got systems like BSD 4.1 much less 4.2. Remember smart people from Rob’s “cat -v” paper to Henry Spencer (“BSD is just like UNIX, only different” net.noise comment) in those days railed on the new BSD system as not being ‘UNIX’ either. For good or for bad, many of the things we take for granted today as being required in a UNIX system, go back to UCB features (or features from AUUG, MIT, CMU or similar). I’ve also stated many times, I do so miss the simplicity and cleanliness of V6 and V7, but I would not want to use it for my daily work today. So many of those very features that Henry and Rob pointed out back in the day, have somehow proven in fact to be ‘helpful’ or at least comfortable. While a few of us probably could live with something like ed(1), particularly with a front-end/feature more like Plan9’s sam(1), than absolutely having to have VI/EMACS. Let me offer an example as a thought exercise. I was recently helping a young hacker trying to get V5/V6/V7 going on a PDP-11 simulator so he could play with it to learn more about the 11 and UNIX itself. I gave him some help and without thinking about it in my email I mentioned that he try something, but I had forgotten that the program head(1) was a Bill Joy program wrote in 1977. What UNIX box would not have it today? As it is screwed into the ROM in my fingers when I type (actually the sources to head (1) is less than 200 lines with ¼ that being the BSD copyright, I sent him them and suggested he recompile it - partly as an exercise to see how C changed). But note that when wnj wrote head(1), Joy followed the famous ‘Unix Philosophy’ of doing one (small) job well. Which means he did not add a feature *i.e. *abusing, an old program, like cat(1), and add some new switch to it that that told the program stop outputting after n lines. Instead Joy wrote a simple new tool. This is the problem with what Larry was pointing out, I think frameworks and like are just adding features on features on features to current subsystems. Yeech!!! To me what made Unix ‘great’ was that this small (16-bit) system, with 48k-256K of memory can could practically owned by a department at $150-250K would allow you to do the same sorts of things that took a $1-4M type of system (be it a PDP-10 or IBM or the like). Mashey did his ACM lectures called “Small Is Beautiful”, sometime after they completed PWB 1.0 and this was one of his points. Unix was a small SW system on a small HW system platform, but was clean and did what you (the programmer) needed without a lot of extra cruft. IIRC for PWB 1.0, that was an 11/45 as the recommended system to run it. Not the smallest (11/40), but hardly the 11/70 either. But as the 32-bit systems became available, many of the different constraints of the PDP-11 were removed – first data size and then text size. When the VAX came and 32-bits was infinite (probably still is for text space), performance got better (and cheaper), disks got bigger, *etc*. And because it was less and less of a problem, quickly programmers got a tad lazy or at least stopped paying attention to things they were required to consider in the past. Ex (or for that matter EMACS) in thinking was the first the UCB “explosions” and maybe where UNIX began to be a tad different and look less and less like what had come from the NJ avengers. The resources of the new systems were such that you did not need a new set of small programs, you added features (extensions) to the old – and that was (is) a trap which we seem to follow today. I think other folks like to point out all the new wonder new functionality in the Linux kernel (or FreeBSd or macOS etc...) have brought to the UNIX world besides BSD’s sockets networking (loadable drivers, dynamic devices are super and I would not want to be without either). I like shared libraries, and better memory systems. Although of course on my supercomputer what are two things we turn off (shared libraries and much of the fancy memory stuff - cause they get in the way of real programs ;-). BTW: I also think sockets were (are) a terrible addition to UNIX and we did not really need them. We are stuck with them now, but I would rather have had something more like what ChaosNet and the original UofI Arpanet code, or what UNET did, where much of the network stack was in user space [which in fact was what the Interface BBN originally used]. In other places, over time, we have added window managers GUI’s *et al*. Hey the core C compiler’s code generator is remarkable compared to what it was for the PDP-11, plus we have new languages be they Rust, Go or even C++ and Java. The key point is few people are really asking the question, *if I add this new feature what does it cost, and what do we really get for it?* The truth is many of these features are all comforts and *I do like many of them* and I use them and want many of them. I like kernel support for MxN threading, but that took kernel support – what did we get beyond fork/exec that we really did not have (the answer is probably better performance due to tighter control, but I wonder if we bought much more than that). I’m typing on a Mac, while most of why ‘work’ these days is targeted Linux. But what is common is mostly I can work in the manner I want. I have something that does make some things nice (easier)… Both are ‘UNIX’ in some manner – that core of both are the same core ideas I see in V5/V6/V7 – that’s good. *i.e.* they both work as a floor wax…. But all of those new features have come at a cost, the biggest is complexity/bloat. We have lost a lot in the design because today’s programmers just don’t have to deal with the kind of constraints that some of had to deal with years ago and I think you hear a number of us groaning that when papers like this one come out, they have completely missed the point and really don’t understand what it means to be UNIX. I suspect if VM/TSO or VMS had become the core technology of the future, the papers being written today would be just as damning. If you never lived in the old world, I’m not sure you understand the improvement. I’m going to toss the gauntlet with a slightly even more political statement. When I read that paper, it reminded me of the current round of anti-vaxxers. Those of us that remember polio and other ‘childhood diseases’ have no desire to go back in time and relive it. I really don't want to run VMS/RSX or for that matter TSS/360 which was the first system I really ever knew how to use well. So in the same way, UNIX is the core technology we have today and I’m damned glad it ‘won’ be it called Linux, FreeBSD or macOS. It was not perfect then and it is hardly perfect today. But it was different from what we had at that time, and so much better - *that today we now use those ideas* from UNIX as our core ideas when we build systems. I just wish people would understand what they have and see it for the positive instead of trying to knock it down - ‘standing on the shoulders of the giants’ and showing what they did as a help, but based on solid ideas, instead of stepping on the toes trying to make their new thing/feature more valuable and claim it’s not made from the origin story. Hey Chevy… can I have some “shimmer” for my pudding. ᐧ

Noel. Pls check the TUHS archives and I think you will see sed does yet exist in 6th edition when Joy wrote head in 1977. Certainly not yet at UCB. On Sun, Jul 4, 2021 at 9:34 PM Noel Hunt &lt;noel.hunt(a)gmail.com&gt; wrote: Sent from a handheld expect more typos than usual

Right. A dyslexic typo sorry doesn’t That was my point. He needed a tool and didn’t have one so he wrote a singular tool to solve the problem. We now consider that tool pretty much standard equipment On Sun, Jul 4, 2021 at 10:51 PM Warner Losh &lt;imp(a)bsdimp.com&gt; wrote: Sent from a handheld expect more typos than usual

Thank you for the correction. Having only used Unix from Seventh Edition on, research-editions only, I have never used head(1) and didn't realize it was written so early. On Mon, Jul 5, 2021 at 12:38 PM Clem Cole &lt;clemc(a)ccc.com&gt; wrote:

On Tue, Jul 6, 2021 at 1:13 AM Nevin Liber &lt;nevin(a)eviloverlord.com&gt; wrote: was written. So you missed the point of my example. FWIW: if you want to pick nits, in this case, the solution with the former is redundant with the latter. IMO, That's ok as it follows in the basic tradition. UNIX has a number of ways to do similar things/solve the same problem, because it offers tools, the system designers do not try to dictate a singular solution. As I fear by the reaction, many of you have missed the point of what I was trying to say. I guess I did not do that clearly. Let me try in a shorter form. The basic idea of the original Unix was that was small and simple and in Dennis' words, 'ran on modest hardware.' The designers of UNIX also did not try to solve any one particular problem but offered a set of tools for a >>programmer<< take upon her/himself to do so. The issue is that the target >>user<< of UNIX had devolved from that of a 'programmer' but rather the elusive 'end user' and her/his view/requirements tend to be "solve my problem now -- I don't care how - just do it I don't want to think about it - make it go away." So over time, we hid a lot of the simplicity in features that were built on features (often warts) that were built on other features (often other warts). Mashey had a great visual in his "small is beautiful" talk using a 'build slide' in PPT terms that demonstrated the problem. I was commenting on the OPs post of the paper picking on UNIX, the UNIX Shell, and where we are today *vs.* 50+ years ago. My other point is the authors need to get over themselves and recognize that* they are not making a really new argument*. Folks were not too happy with many of the BSD 'features' either, but now those same features (like head(1) or BSD sockets(3)) are considered SOP for nay new UNIX and you have to have them - even if there are other if not 'better' ways of doing the same thing. ᐧ

On Tue, Jul 6, 2021 at 12:25 PM Theodore Ts'o &lt;tytso(a)mit.edu&gt; wrote: Interestingly, much of this is kind of the point I was trying to make earlier: many of the problems are different now. Trying to force them into a metaphor that made sense for the problems that were primary 40 years ago can lead to awkward and inefficient solutions. It doesn't always have to, but sometimes it does. "Everything is a file" and "files are streams of bytes" was great for approaching so many of the sorts of problems that were interesting in the 1970s and 80s. Now days, there are whole new types of problems that don't fit into that model easily; is that the fault of the problem, or a suggestion that we need to expand our model and reexamine the basic structure of our systems? Even, to some extent, the notion of a global hierarchical file namespace has broken down. Now, I want to be able to partition and organize datasets across multiple dimensions and across multiple machines and group things on an ad hoc basis; it's all very dynamic, and by comparison the model of a 7th Edition filesystem is static and downright limited. Fork is another great example: it went in because a) Ken knew about it, and b) it was easy to implement (22 instructions of PDP-7 assembler or something) and c) it got the job done. After the fact, it turned out to have all kinds of neat properties that let it compose with pipelines, redirection, background jobs, etc. That model for process management served well for a long time. But then people wanted to have multithreaded processes, because it turns out that independent threads of execution inside of a shared address space are an excellent mechanism for representing concurrency. But they discovered that fork composes poorly with threads: the problem space changed and the model broke down. Btw, Benno Rice is entertaining to watch, and I enjoy his presentations. His talk on COBOL is also interesting, and I would argue somewhat relevant: https://www.youtube.com/watch?v=BCqGjGzWI48 I don't know that the "Unix Patriarchs" ever suggested or intended that "head" was "verboten" or that programs be forced into their smallest, simplest expression. To continue your sectarian metaphor, that's an extreme interpretation of the early church's teachings regarding its scripture. I tend to think of these things as schools of art, rather than religious orders. Much of what we think of as "Unix" carries with it an implicit allegiance to a class of aesthetics: file namespaces and byte streams are great examples. We claim our way is better, but if you sort of squint at it right, you can kinda-sorta imagine a Unix system as an image based language environment, where the "image" is the filesystem and running kernel instance, and the REPL is the shell. Is it so different, then, than Smalltalk or a Lisp? In some sense, no, it's not. Instead of CONS cells making lists, I have streams of bytes, but in some regard that's just an aesthetic thing: it's my fundamental building block, but it's just a building block and all systems have building blocks. But like the art world, is it any wonder that the big arguments are over minutia? The question you asked me earlier, about whether System V is "really Unix" isn't so dissimilar from the questions over whether Common Lisp was "really Lisp". Similarly, discarding "head" for the generality of "seq 10q" is an aesthetic statement, not a matter of engineering principle. Rob Pike in a black turtleneck espousing the benefits of simplistic minimalism as an end unto itself is an exponent of that school, but there are other schools, as Benno reminds us. The challenge for the new generation of artists is to absorb what's come before and create something new. If they draw from many schools, that's fine. What perhaps irks so many of us is that the school is changing, and without full appreciation of the aesthetics of existing canon. "It is sad, this state of affairs. Look how ugly is the systemd!" "But Dan...your /etc/rc is so 1970s." "Yes! See the beauty! Perceive it!" "You are old." "I weep for you." The question I'm asking is if the kids are reaching far enough. - Dan C.

On 06/07/2021, Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: I've never been a fan of clone(). It always strikes me as something that seems like an elegant simplification at first, but the practical realization (on Linux that is) requires several rather ugly library-level hacks to make it work right for typical use cases. UX/RT will use the "processes are containers for threads" model rather than rfork()/clone() since that's the model the seL4 kernel basically uses (in a very generalized form with address spaces , capability spaces, and threads being separate objects and each thread being associated with a capability space and address space), and it would also be slightly easier to create the helper threads that will be required in certain parts of the IPC transport layer. The base process creation primitive (efork(), for "empty/eviscerated fork") will create a completely blank non-runnable child process with no memory mappings or file descriptors, and return a context FD that the parent can use to manipulate the state of the child with normal APIs, including copying FDs and memory mappings. To actually start the child the parent will perform an exec*() within the child context (either a regular exec*() to make the child run a different program, or a new eexec() function that takes an entry point rather than a command line to run the process with whatever memory mappings were set up), after which point the parent will no longer be able to manipulate the child's state. This will eliminate the overhead of fork() for spawning processes running other programs, but will still allow for a library-level fork() implementation that has comparable overhead to traditional implementations. Also, it will do what Plan 9 never did and make the process/memory APIs file-oriented (I still don't get why Plan 9 went with a rather limited anonymous memory API rather than using memory-mapped files for everything). Also, we're straying a bit from historical Unix here and should have probably moved to COFF several messages ago.

Hi, Jon Steinhart wrote: If buggy code rather than a single bug counts then the software model written over fifteen years by Neil Ferguson of Imperial College, London, which has been instrumental in poor UK Government policy decisions on COVID-19 has easily topped more than a thousand deaths in the net tally. It was a single 15,000-line file of C, written by a non-programmer. Eventually, ic.ac.uk released a C++ version which had been worked on by Microsoft and other volunteers for a month so it could face the public. ‘For me the code is not a mess, but it’s all in my head, completely undocumented. Nobody would be able to use it... and I don’t have the bandwidth to support individual users.’ ― Neil Ferguson. Politician Steve Baker MP, a former senior programmer, has been critical of the public version and commissioned a review by Mike Hearn. A path to Hearn's paper starts at https://threadreaderapp.com/thread/1323897771510943745.html And another coder critique is at https://lockdownsceptics.org/code-review-of-fergusons-model/ The numbers from Ferguson's original pre-release C program were presented by him to Number 10 and were instrumental in setting the UK on the path of lockdowns. ‘...lockdowns are the single worst public health mistake in the last 100 years’ ― Jay Bhattacharya, professor of medicine at Stanford University. -- Cheers, Ralph.

Hi Henry, Death-by-bug is OT enough for TUHS to begin with, though ‘entertaining’. Can we try and keep the thread to that together with any argument for why a bug caused net deaths. -- Cheers, Ralph.

Hi Jon, True. I don't know of any but if I had to pick an area where they might be occurring it would be medical devices. I've been an external reviewer of a company's embedded C code for a medical device in the past, bare-metal, simple pre-emptive round-robin task-switcher, etc., though my suggestion is nothing to do with their quality of work or products, just that the level of detail they went to shows how slacker companies could err. The Therac-25 gave fatal radiation doses in a few cases. These were obvious when they occurred. https://en.wikipedia.org/wiki/Therac-25 What if a medical device which sits in the background quietly doing its continuous, but sometimes vital, thing had the occasional hiccough from which it recovered? If the blip is only fatal in patients which were already touch and go and device fault left no obvious sign to suggest death wasn't caused by the initial ailment then the cause of death would be, quite reasonably, assumed. Given some devices are present in large numbers for many years in hospitals, and there's a lot of hospitals, an unnoticed bug could be steadily chipping away at its human overlords. -- Cheers, Ralph.

On Sun, Jul 11, 2021 at 03:04:53AM -0600, arnold(a)skeeve.com wrote: We should never be depending on a human being able to write "perfect code". Instead, we need to come up with processes so that imperfect code doesn't escape into production *despite* the fact that humans are fallible. Such processes might include requiring unit tests, integration tests, stress tests, etc., requiring code reivews by a second pair of eyes, perhaps using formal proofs, having multiple implementations of critical algorithms, cross-checking the results from those independent implementations, and so on. The space shuttle used a number of these techniques. It did *not* depend on super-human, Über-programmers. - Ted

"Theodore Y. Ts'o" &lt;tytso(a)mit.edu&gt; wrote: I strongly agree with all that. But given that many places don't use such practices (especially startups), I prefer not to put myself into situations where safety of the product depends entirely on the skills of the programming team. Arnold

Ralph Corderoy writes: Well, we agree once again. I have done a lot of work on medical devices, and was surprised at the lack of diligence on the part of some of the people with whom I worked. But your example is similar to the way that people have trouble with COVID - there's too much of a lag between exposure and symptoms for many folks to make the connection. So I'm kind of wondering what sort of bug may blow up a refinery or chemical plant and cause enough loss of life and damage to make people take notice. Jon

On Tue, Jul 6, 2021 at 1:12 AM Nevin Liber &lt;nevin(a)eviloverlord.com&gt; wrote in summary: Hmm, it seems like I must write my own Master Foo koan (this is a first draft only, improvements welcome): After Master Foo completed his discourse on the Unix nature < http://www.catb.org/~esr/writings/unix-koans/unix-nature.html>, a tall, thin, gray-haired, balding, bespectacled man entered the room. Master Foo looked up from his lectern. "Greetings," said Master Foo. "Who are you?" "I am the Master Planner," said the Master Planner. "Ninth of my dharma line," he added modestly. "I am Master Foo," said Master Foo. "What do you plan for?" "To reach enlightenment by concentration on a single focus," said the Master Planner. "Therefore I remove all that is unnecessary from my life." Master Foo said nothing, but began to type fiercely. Those students who could see what he was doing were astonished that he appeared to be typing complete gibberish. When he stopped typing, Master Foo pushed the device to the Master Planner. "Read me, if you would, the last maxim of the Zen of Python." The Master Planner appeared as astonished as the students. "But all men know that the twenty-one maxims of the Zen of Python have been unchanged since the Master Sorter wrote them down long ago!" he protested. "Nevertheless," said Master Foo softly. The Master Planner gave the words of command and then spoke very softly. "It says -- it says, 'Inclusion is better than exclusion.'" On hearing these words, all present were enlightened.

On Tue, Jul 6, 2021 at 9:12 AM Chet Ramey &lt;chet.ramey(a)case.edu&gt; wrote: While I may be mis-remembering, IIRC that wasn't true in System V Unix from AT&T (which is where I was first exposed to it). -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404

According to http://bitsavers.trailing-edge.com/pdf/att/3b1/999-801-312IS_ATT_UNIX_PC_Sy… and https://archive.org/details/bitsavers_attunixSystemVRelease4ProgrammersRefe… there is no 'head' command. So Nevin's experience is accurate.

On 7/2/21, Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: They come from the same "modern" camp of cloud fanatics that claim "there was no automation before Ansible and no containerization before Docker". They also think that C is obsolete and your software stack is useless if you don't include a dozen or so flashy bleeding edge technologies and programming languages. This is the kind of techno-cult fashion that Nikolai Bezroukov warned about. In the last few years we have seen more and more "papers" that debunk and mock older stable Unix technologies because they want to forcefully push their agenda and their new marketing terms. We have seen this with systemd which was forcefully pushed down on us; we have seen this with Ansible, etc. This vandalization of Unix already took place and I do not see a clear way out of this situation. --Andy

On 2021-07-04 19:24, Derek Fawcus wrote (in part): This would be very much domain specific.  I work with embedded systems, where one's choice of language is limited. N.

On Mon, Jul 05, 2021 at 12:24:18AM +0100, Derek Fawcus wrote: I had a systems people get together at my place maybe a year ago. Kirk McKusick and Eric Allman came (as well as a bunch of others, perhaps most notable was Pugs). I had a very pleasant chat with Eric about programming styles. I came to the conclusion that I'd love working with Eric, I think I could work for him and it's even possible he could work for me. We both love C, we are both disciplined enough to write maintainable/extendable code in C, it works for us. We really clicked over our love of C. I've tried to like other languages, Java is a huge tangled mess, C++ is, well C++, every company that uses C++ has a list of things you are not supposed to use, I tried to like Go, maybe I haven't given it enough of a chance but it didn't grab me, lots of people I know have gone to Rust, I tried to like that but, man, all the reinventing of syntax drove me nuts, D seemed like it sort of was close but it changed the syntax too much. If I had infinite energy and money, I would fund a dialect of C that made it more useful. The thing I hate about new programming languages is they all feel the need to invent a new syntax. There are really two syntaxes, C and Lisp (and that's a tip of a hat to Lisp, I'm not a fan). Pick one of those and evolve it. My whole career I've felt that when you add to the set of code that is in the world, you should build on what people already know. Everyone knows C syntax, yeah there are some areas that could do with a cleanup (looking at you function pointer declarations) but for the most part, most people can look at C code and know what it does. So why invent a new syntax and invalidate all of that knowledge that everyone has? For all its faults, C++ is the closest to a modern language that sort of fits with what I want but it is a kitchen sink language. It really wanted the Go trio to say "no" to a lot of stuff, it didn't have that so it has every language feature you can imagine and it's hard to onboard people to that. Harder yet to write maintainable code. So, yeah, I like C. A lot. I wish it would evolve in a sensible way but as a buddy says, we live in an imperfect world. --lm

Bogus argument. The Linux kernel is free to rely on specific compiler behavior.

On Sun, Jul 4, 2021 at 8:49 PM Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: Actually, haven't there been many security holes discovered in sendmail?

On Mon, Jul 5, 2021 at 6:45 AM Steffen Nurpmeso &lt;steffen(a)sdaoden.eu&gt; wrote: A null-terminated array of char is a petri dish. A proper string type is more like a disinfectant.

On Mon, Jul 5, 2021 at 4:16 PM Dan Stromberg &lt;drsalists(a)gmail.com&gt; wrote: Hrrmpt.... maybe (in theory), but I can say that never seen it really work in practice -- bwk in Why Pascal is Not My Favorite Programming Language <http://www.lysator.liu.se/c/bwk-on-pascal.html> describes much of the practical realities of this sort of choice: 2.1. The size of an array is part of its typeIf one declares var arr10 : array [1..10] of integer; arr20 : array [1..20] of integer; then arr10 and arr20 are arrays of 10 and 20 integers respectively. Suppose we want to write a procedure 'sort' to sort an integer array. Because arr10 and arr20 have different types, it is not possible to write a single procedure that will sort them both. The place where this affects Software Tools particularly, and I think programs in general, is that it makes it difficult indeed to create a library of routines for doing common, general-purpose operations like sorting. The particular data type most often affected is 'array of char', for in Pascal a string is an array of characters. Consider writing a function 'index(s,c)' that will return the position in the string s where the character c first occurs, or zero if it does not. The problem is how to handle the string argument of 'index'. The calls 'index('hello',c)' and ' index('goodbye',c)' cannot both be legal, since the strings have different lengths. (I pass over the question of how the end of a constant string like 'hello' can be detected, because it can't.) The next try is var temp : array [1..10] of char; temp := 'hello'; n := index(temp,c); but the assignment to 'temp' is illegal because 'hello' and 'temp' are of different lengths. The only escape from this infinite regress is to define a family of routines with a member for each possible string size, or to make all strings (including constant strings like 'define' ) of the same length. The latter approach is the lesser of two great evils. In 'Tools', a type called 'string' is declared as type string = array [1..MAXSTR] of char; where the constant 'MAXSTR' is ``big enough,'' and all strings in all programs are exactly this size. This is far from ideal, although it made it possible to get the programs running. It does not solve the problem of creating true libraries of useful routines. There are some situations where it is simply not acceptable to use the fixed-size array representation. For example, the 'Tools' program to sort lines of text operates by filling up memory with as many lines as will fit; its running time depends strongly on how full the memory can be packed. Thus for 'sort', another representation is used, a long array of characters and a set of indices into this array: type charbuf = array [1..MAXBUF] of char; charindex = array [1..MAXINDEX] of 0..MAXBUF; But the procedures and functions written to process the fixed-length representation cannot be used with the variable-length form; an entirely new set of routines is needed to copy and compare strings in this representation. In Fortran or C the same functions could be used for both. As suggested above, a constant string is written as 'this is a string' and has the type 'packed array [1..n] of char', where n is the length. Thus each string literal of different length has a different type. The only way to write a routine that will print a message and clean up is to pad all messages out to the same maximum length: error('short message '); error('this is a somewhat longer message'); Many commercial Pascal compilers provide a 'string' data type that explicitly avoids the problem; 'string's are all taken to be the same type regardless of size. This solves the problem for this single data type, but no other. It also fails to solve secondary problems like computing the length of a constant string; another built-in function is the usual solution. Pascal enthusiasts often claim that to cope with the array-size problem one merely has to copy some library routine and fill in the parameters for the program at hand, but the defense sounds weak at best:(12 <http://www.lysator.liu.se/c/bwk-on-pascal.html#lit-12>) ``Since the bounds of an array are part of its type (or, more exactly, of the type of its indexes), it is impossible to define a procedure or function which applies to arrays with differing bounds. Although this restriction may appear to be a severe one, the experiences we have had with Pascal tend to show that it tends to occur very infrequently. [...] However, the need to bind the size of parametric arrays is a serious defect in connection with the use of program libraries.'' This botch is the biggest single problem with Pascal. I believe that if it could be fixed, the language would be an order of magnitude more usable. The proposed ISO standard for Pascal(13 <http://www.lysator.liu.se/c/bwk-on-pascal.html#lit-13>) provides such a fix (``conformant array schemas''), but the acceptance of this part of the standard is apparently still in doubt. ᐧ

On Mon, Jul 5, 2021 at 2:29 PM Clem Cole &lt;clemc(a)ccc.com&gt; wrote: I think language designers since Pascal have learned from Pascal's mistake there. Supposedly even Borland's TurboPascal had better strings than vanilla Pascal.

On Mon, Jul 5, 2021 at 9:37 PM Dan Stromberg &lt;drsalists(a)gmail.com&gt; wrote: and then they used only 1 byte for the string length, limiting the max length to 255, which made it completely pointless, because the moment you had some real world data, you were back in manage-my-own-pointers-to-arrays-of-chars-land. (I loved Turbo Pascal, it's the first language I used for "serious" programming. They got a lot of things right, but strings were emphatically not among those things). My other gripe was that Turbo Pascal programs spend half their time on pointer normalization (every pointer access has a preamble that makes sure that the offset is < 16). I'd really love to understand why on earth they decided to do it that way (I'm sure there's a reason, I just fail to see it). It's not like anyone could do pointer arithmetic behind the compiler's back... it slows things down, and it's probably the reason why an equivalent Turbo C program is only half the code size. And it makes it impossible to do clever things with segment registers (18 year old me didn't like that).

I subscribe 100% to your statement! Well I think it's enough to add new concepts like modules/packages/classes to C, and a jdk a-like all purposes library, as libc isn't enough for the 21ths century. I still love C because I'm able of writing small and very fast programs. go is cool to, but a memory hunk compared to C. The rust hype is declining since 2 years and java is the new cobol, ie. it's good for business oriented applications, whereas C and go are (beside ASM) the only choices for system oriented people. Has C a future? Yes, it already has just begun.

Forgive me a side note, but has it not been shown for some time that apart from a very gifted few people, hand-crafted machine-code is usually slower than the best optimising compilers these days? With out of order instruction stuff, side effects (inter-core locking) cache coherency &c it isn't hard to wind up using "simpler" machine code which performs worserer. Doesn't really alter the language debate, but it does go to "compilers are pretty smart these days"

Larry McVoy wrote in &lt;20210705144314.GV817(a)mcvoy.com&gt;: |On Mon, Jul 05, 2021 at 02:23:36PM +1000, George Michaelson wrote: |> Forgive me a side note, but has it not been shown for some time that |> apart from a very gifted few people, hand-crafted machine-code is |> usually slower than the best optimising compilers these days? With out Some *BSDs moved from such to plain C code for strlen() for example, a couple of years back, yes. |> of order instruction stuff, side effects (inter-core locking) cache |> coherency &c it isn't hard to wind up using "simpler" machine code |> which performs worserer. | |I dunno where my team sat on the "gifted" scale, I like to think they |were pretty good. We ran our code through Intel's fancy C compiler and |it made less than a 1% difference vs GCC. We cared about performance |and had already done the by hand work to make the critical paths go fast. Funnily just a couple of months ago at least FreeBSD (but i think also DragonFly BSD, a tad different) moved back, on at least x86_64. (I personally no longer look nor care that much, as (a) i cannot help it anyway, (b) there are so many CPU etc. models out there. Why try to go backward because Cyrix is so good there, use code alignment of X for processor A and Y for processor B? That is just a tremendous maintenance mess, and that for free and with so few time. No. Fun fact is that my one NVME disc can read/write 1.3 gigabytes per second doing "btrfs scrub", that is i think at least four times the speed of the main memory the mentioned Cyrix had available.) --End of &lt;20210705144314.GV817(a)mcvoy.com&gt; --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)

On 7/4/21 7:24 PM, Derek Fawcus wrote: Hoping to correctly recall computability theory, a language needs only statements S := 0 S := S + 1 if S == 0 goto Label to be Turing complete. It doesn't mean the language is always pleasant to use, but is enough - just as an editor with only char ins/del is technically enough. C has its place, and so do tools for other classes of problems. I enjoy python for signal processing work. Matrices, complex numbers, many libraries are all there. Libraries even parcel out calcs to cpu cores behind the scenes, letting the DSP guy worry (mostly) only about math. And then C is speedy for the end product. As comp sci evolves, we get more blades in our Swiss Army knife. Mike Markowski

On Mon, Jul 5, 2021 at 12:40 PM Warner Losh &lt;imp(a)bsdimp.com&gt; wrote: Amen... FWIW: I wrote this a few years ago: https://www.quora.com/Is-Fortran-obsolete/answer/Clem-Cole ᐧ