From jnc at mercury.lcs.mit.edu Thu Feb 1 23:03:11 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 1 Feb 2018 08:03:11 -0500 (EST) Subject: [TUHS] Odd behaviour on V6 startup, etc Message-ID: <20180201130311.4BAB118C0B2@mercury.lcs.mit.edu> As I mentioned recently, Dave Bridgham and I are doing an RK11 emulator (and soon an RP11, which just will take editing the Verilog a tiny bit) using an SD card for storage, for heritage computer collectors who want to run their PDP-11's but don't want to risk a head crash (since replacement heads are now un-obtainium) - and also for people who have an -11, but no mass storage. So the last stage was bringing up V6 on a hardware PDP-11/23, using the emulated RK11, and we were having an issue (which turned out to be partial block reads/writes not working properly; this has since been fixed, and we have successfullly booted V6 on the -11/23 with only an SD card). In the process of debugging that issue, I added logging to the RK driver, and noticed that in the process of attempting to boot single-user, the system was trying to do some swapping - two writes, and two reads - before it even tried doing the fork() to create the shell process, followed by opening /dev/tty8 and doing the exec() of /bin/sh. This confused me, since both newproc() and expand() have code which uses a memory-memory copy if there is enough free memory - and on first booting, there definitely was. Why was it swapping? So I added some more logging, and the cause turned out that at one point, I had re-compiled /etc/init - and without thinking about it too hard, had made it a pure-text program. And that's what did it: in exec() (called when process 1 tries to exec() /etc/init), it calls xalloc(), which i) if the text was not already available, gets together the pure text, and puts a copy on the swap device, and ii) if the text is not already in core, swaps the rest of the process out, because, as the code explains: * if the calling process * is misplaced in core the text image might not fit. * Quite possibly the code after "out:" could check to * see if the text does fit and simply swap it in. If you're looking at the code, the process doesn't have a data segment at that point, just the U area; the data will be set up later in the exec() code, after the call to xalloc() returns, after the process is swapped back in. In fact, the process will _never_ have anything other than a U area when in this code; the only call to xalloc() in the system is immediately preceeded by an "expand(USIZE)" which throws away everything except the U area. So I'm contemplating doing what the comment suggests - adding code to check to see if there's enough memory available to hold the pure text, and if so, avoiding the swap-out/in of the process' U-only data segment. If done 'right', it should also be possible to allow avoiding the reading-in of the text from the swap device, when first exec'ing a pure text... Probably not as interesting a project as doing the splice() system call was, but no doubt it will teach me about a corner of the system I don't know very well (back in the day, doing networking stuff, I was mostly looking at I/O code). Although there is potentially a certain amount of amusement in an additional enhancement, which is trying to make sure there's enough room for both the text and the data; immediately upon the return from xalloc(), the process is expanded to have room for the data. Which might involve _another_ swap-out/in sequence... So perhaps the U area should simply be moved out of the way via a direct memory-memory copy, rather than swapping it out/in, just before doing it again! You are not expected to understand this... :-) I guess I should first take a look at the PWB1 pure text code, which is heavily modified from the stock V6, to see what it does - this all may have already been done there. Noel From spedraja at gmail.com Thu Feb 1 23:10:29 2018 From: spedraja at gmail.com (SPC) Date: Thu, 1 Feb 2018 14:10:29 +0100 Subject: [TUHS] Odd behaviour on V6 startup, etc In-Reply-To: <20180201130311.4BAB118C0B2@mercury.lcs.mit.edu> References: <20180201130311.4BAB118C0B2@mercury.lcs.mit.edu> Message-ID: This sounds Great, Noel. ​ 2018-02-01 14:03 GMT+01:00 Noel Chiappa : > As I mentioned recently, Dave Bridgham and I are doing an RK11 emulator > (and > soon an RP11, which just will take editing the Verilog a tiny bit) using an > SD card for storage, for heritage computer collectors who want to run their > PDP-11's but don't want to risk a head crash (since replacement heads are > now > un-obtainium) - and also for people who have an -11, but no mass storage. > ​I am very interested in your work exactly for the reasons you explain in your email message. The only difference is that my PDP-11 is one 23/PLUS. There are some differences between this one and the PDP-11/23 and perhaps your emulator woudln't work in this PDP-11 model. I will test the working state of my PDP. If all is fine perhaps I could help doing with some tests on it.​ ​ ​ Gracias | Regards - Saludos | Greetings | Freundliche Grüße | Salutations ​ -- *Sergio Pedraja* -- twitter: @sergio_pedraja | skype: Sergio Pedraja -- http://plus.google.com/u/0/101292256663392735405 http://www.linkedin.com/in/sergiopedraja http://spedraja.wordpress.com ----- No crea todo lo que ve, ni crea que está viéndolo todo ----- "El estado de una Copia de Seguridad es desconocido hasta que intentas restaurarla" (- nixCraft) ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri Feb 2 00:12:05 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 1 Feb 2018 09:12:05 -0500 (EST) Subject: [TUHS] Odd behaviour on V6 startup, etc Message-ID: <20180201141205.CACD318C0B2@mercury.lcs.mit.edu> > From: Sergio Pedraja > I am very interested in your work exactly for the reasons you explain We will generally be sending messages about it to the CCTalk list (for collectors of 'classic' computers), so if you want to be notified about it, sign up there. We currently have only wire-wrap prototypes (the FPGA is on an off-the-shelf daughter-card); we're hoping to produce PCB production versions 'soon'. We do have the technology for getting PCB's, which we have used for doing 'indicator panels': http://ana-3.lcs.mit.edu/~jnc/tech/DECIndicatorPanels.html We have those working (they've been a big help in debugging, actually :-), and they'll be available too. I don't personally have one of them yet, I'm _really_ looking forward to watching the lights blink as UNIX boots... :-) > The only difference is that my PDP-11 is one 23/PLUS. There are some > differences between this one and the PDP-11/23 and perhaps your emulator > woudln't work in this PDP-11 model. No, AFAIK the /23 and /23-PLUS are effectively identical, as far as the QBUS goes. (Obviously the -PLUS has devices, etc, the plain /23 doesn't, but they don't enter into whether our board will work with one.) We also plan at UNIBUS version; the two busses are similar enough that we'll probably start with a PCB version for that one. > I will test the working state of my PDP. If all is fine perhaps I could > help doing with some tests on it. Sure; use CCTalk. Noel From cym224 at gmail.com Fri Feb 2 10:04:43 2018 From: cym224 at gmail.com (Nemo) Date: Thu, 1 Feb 2018 19:04:43 -0500 Subject: [TUHS] Happy birthday, John von Neumann! In-Reply-To: References: Message-ID: On 27/12/2017, Dave Horsfall wrote (in part): > We gained John von Neumann on this day in 1903, and if you haven't heard > of him then you are barely human... As computer science goes, he's right > up there with Alan Turing. There is speculation that he knew of Babbage's > work; > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > suffer." This does not answer the potential Babbage connection but I ran across the following paragraph by Dyson ("A Walk through Johnny von Neumann's Garden" from here http://www.ams.org/notices/201302/index.html): "I got to know Johnny personally when I came to the Institute for Advanced Study in 1948. He was then actively engaged in building the institute computer and learning how to use it. He under- stood from the beginning that two of the most important uses of the machine would be to predict weather and to model climate. He hired engineers to build the machine and meteorologists to use it. The chief engineer was Julian Bigelow, and the chief meteorologist was Jules Charney. Each of them had a gang of young people to do the heavy work, persuading a totally new kind of machine to produce some real science. I enjoyed very much the young people, with their rowdy conversation and irreverent behavior. There was an amusing clash of cultures between these young hooligans and the older members of the institute. As Einstein wrote to his friend the queen of the Belgians when he arrived at the institute in 1933, Princeton was a quaint and ceremonious village populated by demi- gods on stilts. The culture of the older members was based on formal politeness and respect for the academic hierarchy. Johnny and I were on the side of the hooligans." N. From lm at mcvoy.com Fri Feb 2 13:44:48 2018 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 1 Feb 2018 19:44:48 -0800 Subject: [TUHS] Dynamics between BSD and Linux In-Reply-To: References: Message-ID: <20180202034448.GA2796@mcvoy.com> I think it's a culture thing. My experience is formed somewhat from recent interactions with Netflix but it goes all the way back to 386BSD and the {Free,Net,Open}BSD after that. Dragonfly might be an exception but I haven't engaged with them enough to know. I've engaged with all the other BSDs. Or tried to. There is an east coast culture and there is a west coast culture when it comes to society (not talking about computers here). The east coast is the ivy league, and it is about who you know. Who your family is. Look at the Bush family, as much as George wanted to be a Texan, he's east coast ivy league. If you are in that club, you are in, doesn't matter if you have talent or not, you are in. The west coast doesn't have the prestige of all the east coast elites, it's the new kid. So on the west coast, all that anyone cares about is can you get shit done? You can be a nobody but if you make shit happen, you are in. Linux is like the west coast. Maybe not so much today, but certainly back at the start and for a long time, all that anyone cared about was "is your code good". And I think they still have that attitude though it's somewhat harder to break in. BSD is like the east coast, and still is to this day. It's a club. In order to be in that club you have to be somebody that somebody knows. I have to say that I think the BSD culture is pretty toxic. It's an old boy's club and that limits the success it can have. Because, as we all know, the people that move things forward are mostly the young unknown kids that we send out to solve a problem that we think can't be solved. And yet, once in a while they do solve one. The BSD community seems to only want proven people in their group, which is fine at one level, but rules out the new people that solve the unsolvable. Given the differences, and believe me, Linus and crew are aware of the differences, the Linux guys aren't that interested in the BSD stuff. Why should they be? What does BSD bring to the table for Linux? It's a bummer because BSD brings minimalism to the table. You can run a BSD machine in 128MB and it works. Hell, it used to work great in 4MB. Nanobsd and the other firewall distributions work well in low memory machines. Here's a personal example of the differences. When I was looking at working with Netflix I emailed McKuisik to ask him about some UFS stuff. And this was me, I know Kirk, I've been to his house, had wine with him and Eric. No reply. Ok, I'm old and washed up, I get it. I emailed Linus about the Spectre/Meltdown stuff, asking him if I should release some before/after LMbench results. Got a reply in about 20 minutes where he outlined where things where, where they were going, talked about his stuff getting to the intel CEO, etc, etc. Linus and I could be enemies because of Git/BK but Linus doesn't care about that, he responded because I had a valid question. I've tried to have the same conversation with BSD people and I was ignored. +1 Linux. The BSD stuff isn't being taken seriously because the BSD people aren't interested in taking new people seriously. Which is a shame because the work that Netflix and other BSD people have done is really cool. I'd love to hear Ted's take, it might be very different. --lm From bakul at bitblocks.com Fri Feb 2 16:11:20 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 01 Feb 2018 22:11:20 -0800 Subject: [TUHS] Dynamics between BSD and Linux In-Reply-To: Your message of "Thu, 01 Feb 2018 19:44:48 -0800." <20180202034448.GA2796@mcvoy.com> References: <20180202034448.GA2796@mcvoy.com> Message-ID: <20180202061135.CAEAF156E811@mail.bitblocks.com> On Thu, 01 Feb 2018 19:44:48 -0800 Larry McVoy wrote: Larry McVoy writes: > > It's a bummer because BSD brings minimalism to the table. You can run > a BSD machine in 128MB and it works. Hell, it used to work great in 4MB. I think this is the crux of the issue. As a group gets bigger, minimalism is hard to maintain. To have a fighting chance you have inculcate new people in the same minimalism culture and that takes time. This puts a higher bar to entry. > The BSD stuff isn't being taken seriously because the BSD people aren't > interested in taking new people seriously. Which is a shame because the > work that Netflix and other BSD people have done is really cool. If you think what BSD folks have done is cool, just join in. Why not ignore the personalities and the popularity contest. Regardless of how we got here, the reality is that BSD at this point has a tiny footprint in the market. Even Linux has a small footprint in the desktop + laptop market, compared to Windows and Mac. BSD isn't even counted separately any more there. In the server market Linux is basically it. In the cloud market it is mostly Linux (almost all of it, if you don't count Azure). In the Mobile+desktop+laptop market, other than Android, Linux is under 1%. BSD numbers are just in the noise. The reality is that BSD just doesn't matter to most folks. The same with minimalism. So it goes. [And neither fact matters to me for my non-pay work.] From imp at bsdimp.com Fri Feb 2 16:29:55 2018 From: imp at bsdimp.com (Warner Losh) Date: Thu, 1 Feb 2018 23:29:55 -0700 Subject: [TUHS] Dynamics between BSD and Linux In-Reply-To: <20180202061135.CAEAF156E811@mail.bitblocks.com> References: <20180202034448.GA2796@mcvoy.com> <20180202061135.CAEAF156E811@mail.bitblocks.com> Message-ID: On Thu, Feb 1, 2018 at 11:11 PM, Bakul Shah wrote: > On Thu, 01 Feb 2018 19:44:48 -0800 Larry McVoy wrote: > Larry McVoy writes: > > > > It's a bummer because BSD brings minimalism to the table. You can run > > a BSD machine in 128MB and it works. Hell, it used to work great in 4MB. > > I think this is the crux of the issue. As a group gets bigger, > minimalism is hard to maintain. To have a fighting chance you > have inculcate new people in the same minimalism culture and > that takes time. This puts a higher bar to entry. Though even in the early days of Linux, it could run in a slightly smaller footprint. It just grew more quickly than BSD, though retained a better way to subset that let it retain much of the lower end that BSD had grown too large for for many years. > The BSD stuff isn't being taken seriously because the BSD people aren't > > interested in taking new people seriously. Which is a shame because the > > work that Netflix and other BSD people have done is really cool. > > If you think what BSD folks have done is cool, just join in. > Why not ignore the personalities and the popularity contest. > Honestly, most of the heavy BSD contributors do just that. There's drama here and there, but it's mostly away from larger contributors... And so it goes... > Regardless of how we got here, the reality is that BSD at this > point has a tiny footprint in the market. Even Linux has a > small footprint in the desktop + laptop market, compared to > Windows and Mac. BSD isn't even counted separately any more > there. In the server market Linux is basically it. In the > cloud market it is mostly Linux (almost all of it, if you > don't count Azure). In the Mobile+desktop+laptop market, other > than Android, Linux is under 1%. BSD numbers are just in the > noise. > Yet, according to Sandvine, Netflix serves 35% of peak internet traffic, all from FreeBSD. Go figure :) > The reality is that BSD just doesn't matter to most folks. The > same with minimalism. So it goes. [And neither fact matters to > me for my non-pay work.] > Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Fri Feb 2 16:36:48 2018 From: ggm at algebras.org (George Michaelson) Date: Fri, 2 Feb 2018 16:36:48 +1000 Subject: [TUHS] Dynamics between BSD and Linux In-Reply-To: References: <20180202034448.GA2796@mcvoy.com> <20180202061135.CAEAF156E811@mail.bitblocks.com> Message-ID: Van Jacobsen did most of his ?ESNET? funded work on TCP/IP on BSD. He was associated with Berkeley. When BSD fragmented and there were 3, getting traction for rapid adoption of IP stack changes became hard. He worked on his suite of Mbone tools for a while, then gave up. He popped up again around the time codel was beginning, with random early drop (RED) changes, and they made BSD. But, things began to be released in linux kernels faster. BBR was a killer moment: its out in all modern Linux. Its barely adopted in FreeBSD, and the issues around BBR, Codel, models are being chained into the floor by interminable discussions (I am possibly wrong here, but this is the sense I get) Three or four smart guys at Swinburne were working on a really nice agile stack for IP changes in BSD. THey lost funds and traction and the team is now at Netflix. FQ-Codel aimed to home routers. Home routers for some reason are linux down the line. I also don't understand this: NetBSD would have been a fine model for tiny memory footprint SoC but somehow, it just didn't work out that way. Likewise the PI. I know NetBSD works, but somehow, its not on the main release cycle of the PI people. Its sideline. NAS people still like BSD. I think a lot of Open Source NAS projects wanted better underlying Disk IO models than Linux had, and ZFS, but now ZFS is in Linux.. I think the writing might be on the wall there. Juniper was (I believe) very BSD friendly. I don't know now. Was. On Fri, Feb 2, 2018 at 4:29 PM, Warner Losh wrote: > > > On Thu, Feb 1, 2018 at 11:11 PM, Bakul Shah wrote: >> >> On Thu, 01 Feb 2018 19:44:48 -0800 Larry McVoy wrote: >> Larry McVoy writes: >> > >> > It's a bummer because BSD brings minimalism to the table. You can run >> > a BSD machine in 128MB and it works. Hell, it used to work great in >> > 4MB. >> >> I think this is the crux of the issue. As a group gets bigger, >> minimalism is hard to maintain. To have a fighting chance you >> have inculcate new people in the same minimalism culture and >> that takes time. This puts a higher bar to entry. > > > Though even in the early days of Linux, it could run in a slightly smaller > footprint. It just grew more quickly than BSD, though retained a better way > to subset that let it retain much of the lower end that BSD had grown too > large for for many years. > >> > The BSD stuff isn't being taken seriously because the BSD people aren't >> > interested in taking new people seriously. Which is a shame because the >> > work that Netflix and other BSD people have done is really cool. >> >> If you think what BSD folks have done is cool, just join in. >> Why not ignore the personalities and the popularity contest. > > > Honestly, most of the heavy BSD contributors do just that. There's drama > here and there, but it's mostly away from larger contributors... And so it > goes... > >> >> Regardless of how we got here, the reality is that BSD at this >> point has a tiny footprint in the market. Even Linux has a >> small footprint in the desktop + laptop market, compared to >> Windows and Mac. BSD isn't even counted separately any more >> there. In the server market Linux is basically it. In the >> cloud market it is mostly Linux (almost all of it, if you >> don't count Azure). In the Mobile+desktop+laptop market, other >> than Android, Linux is under 1%. BSD numbers are just in the >> noise. > > > Yet, according to Sandvine, Netflix serves 35% of peak internet traffic, all > from FreeBSD. Go figure :) > >> >> The reality is that BSD just doesn't matter to most folks. The >> same with minimalism. So it goes. [And neither fact matters to >> me for my non-pay work.] > > > Warner From ggm at algebras.org Fri Feb 2 16:43:13 2018 From: ggm at algebras.org (George Michaelson) Date: Fri, 2 Feb 2018 16:43:13 +1000 Subject: [TUHS] Dynamics between BSD and Linux In-Reply-To: References: <20180202034448.GA2796@mcvoy.com> <20180202061135.CAEAF156E811@mail.bitblocks.com> Message-ID: the other odd thing here is that Kirk McKusick used to pop up at lots of places teaching. He is enormously engaging and a good presenter and people love to hear about Filesystem design and models of virtual filesystem.. but at the end of the day if they don't run the BSD kernel, or code, then its .. kind of off-beam. I bet he could still fill a room of people, but I doubt the room would equate to the volume of linux nodes run inside DC. Bhyve is a really nice virtualization model. It has zero traction. Docker is it. Docker on Bhyve was mooted and died. CePH is barely on BSD, 3-5 years down the track. So thats almost the entire world of Docker -> Kubernetes you can't run, and the data/science world of giant distributed filestores you can't run. Sucks to be a BSD nerd at this point, because nobody wants you. I'm running iSCSI backed from NetAPP for ZFS via FreeBSD. The ZFS is rock solid. the iSCSI sucks, and can't do sensible dual channel bonding, and a bunch of things in my life might be easier if I moved it to Linux. I run another 10-15 nodes as FreeBSD and I have to run one as Debian to get BBR to get data from intractably slow ssh/rsync feeds, on BSD or.. use this one Linux node and get a 10x speedup. Its very hard to ignore this as a real-world signal of failure. (rsync over ssh is hell, and there are much better models but this one is bankable with other people) right now, as a BSD bigot in a technology company, I'm in a group of one. Its lonely, its cold, and its going to be a long slow winter (to quote bill murray from groundhog day, kinda) On Fri, Feb 2, 2018 at 4:36 PM, George Michaelson wrote: > Van Jacobsen did most of his ?ESNET? funded work on TCP/IP on BSD. He > was associated with Berkeley. When BSD fragmented and there were 3, > getting traction for rapid adoption of IP stack changes became hard. > He worked on his suite of Mbone tools for a while, then gave up. > > He popped up again around the time codel was beginning, with random > early drop (RED) changes, and they made BSD. But, things began to be > released in linux kernels faster. BBR was a killer moment: its out in > all modern Linux. Its barely adopted in FreeBSD, and the issues around > BBR, Codel, models are being chained into the floor by interminable > discussions (I am possibly wrong here, but this is the sense I get) > > Three or four smart guys at Swinburne were working on a really nice > agile stack for IP changes in BSD. THey lost funds and traction and > the team is now at Netflix. > > FQ-Codel aimed to home routers. Home routers for some reason are linux > down the line. I also don't understand this: NetBSD would have been a > fine model for tiny memory footprint SoC but somehow, it just didn't > work out that way. Likewise the PI. I know NetBSD works, but somehow, > its not on the main release cycle of the PI people. Its sideline. > > NAS people still like BSD. I think a lot of Open Source NAS projects > wanted better underlying Disk IO models than Linux had, and ZFS, but > now ZFS is in Linux.. I think the writing might be on the wall there. > > Juniper was (I believe) very BSD friendly. I don't know now. Was. > > > > > On Fri, Feb 2, 2018 at 4:29 PM, Warner Losh wrote: >> >> >> On Thu, Feb 1, 2018 at 11:11 PM, Bakul Shah wrote: >>> >>> On Thu, 01 Feb 2018 19:44:48 -0800 Larry McVoy wrote: >>> Larry McVoy writes: >>> > >>> > It's a bummer because BSD brings minimalism to the table. You can run >>> > a BSD machine in 128MB and it works. Hell, it used to work great in >>> > 4MB. >>> >>> I think this is the crux of the issue. As a group gets bigger, >>> minimalism is hard to maintain. To have a fighting chance you >>> have inculcate new people in the same minimalism culture and >>> that takes time. This puts a higher bar to entry. >> >> >> Though even in the early days of Linux, it could run in a slightly smaller >> footprint. It just grew more quickly than BSD, though retained a better way >> to subset that let it retain much of the lower end that BSD had grown too >> large for for many years. >> >>> > The BSD stuff isn't being taken seriously because the BSD people aren't >>> > interested in taking new people seriously. Which is a shame because the >>> > work that Netflix and other BSD people have done is really cool. >>> >>> If you think what BSD folks have done is cool, just join in. >>> Why not ignore the personalities and the popularity contest. >> >> >> Honestly, most of the heavy BSD contributors do just that. There's drama >> here and there, but it's mostly away from larger contributors... And so it >> goes... >> >>> >>> Regardless of how we got here, the reality is that BSD at this >>> point has a tiny footprint in the market. Even Linux has a >>> small footprint in the desktop + laptop market, compared to >>> Windows and Mac. BSD isn't even counted separately any more >>> there. In the server market Linux is basically it. In the >>> cloud market it is mostly Linux (almost all of it, if you >>> don't count Azure). In the Mobile+desktop+laptop market, other >>> than Android, Linux is under 1%. BSD numbers are just in the >>> noise. >> >> >> Yet, according to Sandvine, Netflix serves 35% of peak internet traffic, all >> from FreeBSD. Go figure :) >> >>> >>> The reality is that BSD just doesn't matter to most folks. The >>> same with minimalism. So it goes. [And neither fact matters to >>> me for my non-pay work.] >> >> >> Warner From steffen at sdaoden.eu Sat Feb 3 01:07:06 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 02 Feb 2018 16:07:06 +0100 Subject: [TUHS] Dynamics between BSD and Linux In-Reply-To: <20180202034448.GA2796@mcvoy.com> References: <20180202034448.GA2796@mcvoy.com> Message-ID: <20180202150706.26FII%steffen@sdaoden.eu> Larry McVoy wrote: ... |Here's a personal example of the differences. When I was looking at |working with Netflix I emailed McKuisik to ask him about some UFS stuff. |And this was me, I know Kirk, I've been to his house, had wine with him |and Eric. No reply. Ok, I'm old and washed up, I get it. Even though i have read your message as a maybe even ironic sharpening, i feel i have to step in and find this hard to believe. Maybe there have been technical reasons. To me micro micro always an overwhelming experience to receive answers or mails in general from people of this league, with such names, etc. This is truly academical spirit. And you can even make errors, as long as you can explain why you thought what turned out to be an error was the way to go. McKusick? No... |I emailed Linus about the Spectre/Meltdown stuff, asking him if I should |release some before/after LMbench results. Got a reply in about 20 |minutes where he outlined where things where, where they were going, |talked about his stuff getting to the intel CEO, etc, etc. Linus and |I could be enemies because of Git/BK but Linus doesn't care about that, |he responded because I had a valid question. | |I've tried to have the same conversation with BSD people and I was |ignored. +1 Linux. Well, Matthew Dillon of DragonFly BSD had an initial Meltdown mitigation in no later but January 5th (and finished on 01-11), and also posted long explanatory and benchmarking etc. mails. Later Maxime Villard of NetBSD also posted, a bit cryptic. Also on one of the BSD lists, i forgot which, there i saw the link to the ARM document which was the very best read on this topic in all that terrible mess of noise surrounding these issues. So no real need for conversation if the work is done. |The BSD stuff isn't being taken seriously because the BSD people aren't |interested in taking new people seriously. Which is a shame because the I would agree, but i guess it depends on the people whether that is true or not. ^.^ |work that Netflix and other BSD people have done is really cool. I disagree for the non-software related part. I am damn happy that we in Germany have TV under public law. Where programs of quality can be made, programs which will never make any money, and maybe even do not get a price. Non-trivial programs. --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) From lm at mcvoy.com Sat Feb 3 01:29:04 2018 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 2 Feb 2018 07:29:04 -0800 Subject: [TUHS] Dynamics between BSD and Linux In-Reply-To: <20180202150706.26FII%steffen@sdaoden.eu> References: <20180202034448.GA2796@mcvoy.com> <20180202150706.26FII%steffen@sdaoden.eu> Message-ID: <20180202152904.GG2632@mcvoy.com> On Fri, Feb 02, 2018 at 04:07:06PM +0100, Steffen Nurpmeso wrote: > Larry McVoy wrote: > ... > |Here's a personal example of the differences. When I was looking at > |working with Netflix I emailed McKuisik to ask him about some UFS stuff. > |And this was me, I know Kirk, I've been to his house, had wine with him > |and Eric. No reply. Ok, I'm old and washed up, I get it. > > Even though i have read your message as a maybe even ironic > sharpening, i feel i have to step in and find this hard to > believe. Maybe there have been technical reasons. I didn't really mean to shine a light on Kirk, I like Kirk, I'm one of the few people besides Kirk to work on UFS. That said, I stand by what I said, it's what happened. And it seems to be reflective of the BSD "culture", it appears to be the opposite of inclusive. Disappointing. Linux has a very different culture. Everyone is welcome and they maintain sanity largely via Linus willing to call a spade a spade. He doesn't suffer fools but he's willing to engage with anyone until they prove themselves to be a fool and nothing more. From imp at bsdimp.com Sat Feb 3 01:46:15 2018 From: imp at bsdimp.com (Warner Losh) Date: Fri, 2 Feb 2018 08:46:15 -0700 Subject: [TUHS] Dynamics between BSD and Linux In-Reply-To: <20180202152904.GG2632@mcvoy.com> References: <20180202034448.GA2796@mcvoy.com> <20180202150706.26FII%steffen@sdaoden.eu> <20180202152904.GG2632@mcvoy.com> Message-ID: On Fri, Feb 2, 2018 at 8:29 AM, Larry McVoy wrote: > On Fri, Feb 02, 2018 at 04:07:06PM +0100, Steffen Nurpmeso wrote: > > Larry McVoy wrote: > > ... > > |Here's a personal example of the differences. When I was looking at > > |working with Netflix I emailed McKuisik to ask him about some UFS > stuff. > > |And this was me, I know Kirk, I've been to his house, had wine with him > > |and Eric. No reply. Ok, I'm old and washed up, I get it. > > > > Even though i have read your message as a maybe even ironic > > sharpening, i feel i have to step in and find this hard to > > believe. Maybe there have been technical reasons. > > I didn't really mean to shine a light on Kirk, I like Kirk, I'm one of > the few people besides Kirk to work on UFS. > There's about a dozen. They talk. Even Kirk. But you can't expect people whose time is their own to reply to you on a short timeline. It's not a reasonable expectation. That said, I stand by what I said, it's what happened. And it seems to > be reflective of the BSD "culture", it appears to be the opposite of > inclusive. Disappointing. > I've had a completely different experience. But when people don't answer, I ask again. I just just go off and sulk that they were mean to me. > Linux has a very different culture. Everyone is welcome and they > maintain sanity largely via Linus willing to call a spade a spade. > He doesn't suffer fools but he's willing to engage with anyone until > they prove themselves to be a fool and nothing more. > Sure, if you love a toxic culture that's hard to break through the machismo when the anointed ones are wrong.... Needless to say, I have a completely different perspective and two-decades-long experience with BSD and its collaboration. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Sat Feb 3 03:00:28 2018 From: tytso at mit.edu (Theodore Ts'o) Date: Fri, 2 Feb 2018 12:00:28 -0500 Subject: [TUHS] Dynamics between BSD and Linux In-Reply-To: References: Message-ID: <20180202170028.GA2268@thunk.org> On Wed, Jan 31, 2018 at 01:39:25AM -0700, Kevin Bowling wrote: > Linux has been described as influenced by Minix and System V. The Minix > connection is well discussed. The SysV connection something something > Linus had access to a spec manual. For many of us it was POSIX.1 1990. I implemented Job Control from the POSIX.1 spec, and then recompiled bash, and it worked the first time out of the box. The Berkeley man pages are not bad, but the POSIX spec was much more of a formal POSIX spec. > But I’d guess reality would be more gradual — new contributors that > liked CSRG BSD would have mostly gravitated to the continuations in > 386/BSDi/Net/Free that were concurrent to early and formative Linux > development.. so there’d be an implicit vacuum of BSD people for > Linux development. I'll note that my first experiencing hacking kernels was the BSD 4.3+Reno; but it was mostly what I perceived as the toxicity of a certain core team member (way worse than the caricature of Linus as portrayed by the press) that caused me to decide to stick with Linux than with *BSD. > The kinds of BSD things I am talking about are ufs, kqueue, jails, pf, > Capsicum. Linux has grown alternatives, but with sometimes willful > ignorance of other technology. It seems clear epoll was not a good design > from the start. In some cases, the ideas were carefully considered, and they were rejected. For example, Soft Updates was one that we looked and we decided that it was too complicated, and would restrict who could add new features to the file system afterwards. This LWN article, "Soft Updates, Hard Problems"[1] was written much later, but it's a good summary of our reasons. [1] https://lwn.net/Articles/339337/ In other cases, it was a case of parallel evolution. Work done on epoll, was at least partially funded by IBM as part of the Linux Scalability Effort, and the basic design had been fixed in advance. I wasn't working on that myself, but I vaguely recall that there were potential Microsoft patent concerns that constrained the epoll design. > Despite jails not being taken to the logical conclusion of > modern containers like zones, the architecture is fundamentally closer > aligned to how people want to securely use containers versus namespaces and > cgroups. The original goal of cgroups and namespace was not for security/isolation. Cgroups in particular was something Google had implemented for to allow a large number of jobs on a single shared system. The jobs all belonged to different Google teams/product groups, so mutually distrustful job owners weren't part of the design requirements; efficiency to decrease compute TCO was the overarching goal. Using cgroups for containers is something that a startups like Docker drove, and "time to market" and "keep the VC's happy" were far more happy than to "delay product launch for years while we burn VC money to reimplement BSD jails". > This seems strange to me as BSD people are generally open to other /ideas/, > we have to be careful with Linux code due to license incompatibility, but > the converse is does not seem true either in interest in other ideas or > license hampering code flow. I'll note that I implemnted e2fsck using a lot of ideas about how to speed up fsck for the BSD FFS from a paper published in the 1989 Usenix conference in Baltimore. The core idea was to cache data and cleverly reorder how various consistency checks were done by fsck so that metadata blocks would not need read more than once in most cases. These techniques sped up fsck by a factor of 2-3 I contacted the author and was told those ideas were never picked up by BSD. Oh well, BSD's loss, Linux ext3's gain. :-) > The history of UNIX is spectacularly successful because different groups > got together at the table and agreeed on the ideas. Is there room for that > in the modern era where Linux is the monopoly OS? The Austin Group is > still a thing but it’s not clear people in any of the Freenix communities > really care about evolving the standards. I get that, but not so much > completely burrying ones head in the sand to what other OSes are doing. Is > there any future for UNIX as an “open system” in this climate or are people > going to go there separate ways? I don't think it's really about "wilful ignorance". It's more about economic considerations and what you can get your employer to pay for. I can think of a lot of times were my design was driven by the amount of headcount I could get authorized, and how much time I had before code freeze for this year's Android release. Some of these considerations don't apply if the work is done by starving hobbiest, or by academics who can use cheap grad student labor. But I suspect here have also be cases where "minimal publishable unit" has also driven the way certain work has landed into, for example the Coda File System, which I was told "contained the remanants of a dozen Ph.D. theses", and was the code was too ugly and debt-ridden to be salvaged. (Which is why Intermezzo was started; alas, that never went anywhere.) - Ted From beebe at math.utah.edu Sat Feb 3 03:01:12 2018 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Fri, 2 Feb 2018 10:01:12 -0700 Subject: [TUHS] Happy birthday, John von Neumann! In-Reply-To: Message-ID: Dave Horsfall wrote on Thu, 28 Dec 2017 09:10:56 +1100 (EST): >> We gained John von Neumann on this day in 1903, and if you haven't heard >> of him then you are barely human... John (Johnny to his English-speaking friends) von Neumann was a colossal figure in 20th Century mathematics and physics with a photographic memory, an ability to work on several jobs at once, a passion for partying, and a broad range of research publication in computer science, economics, game theory, mathematics, probability, and physics. There are several books about him that I've found enjoyable reading. He is included with all of the other major quantum pioneers in the BibNet Project bibliography archive at http://www.math.utah.edu/pub/bibnet/authors/v/von-neumann-john.bib [change .bib to .html for a similar view in a Web browser, but with live hyperlinks]. Those bibliographies strive to offer complete coverage of all known publications by their subject scientists, as well as coverage of publications about them, and their works. Reports of bibliographic omissions are always welcome, and updates will be made in short order. In the case of von Neumann, there are likely numerous still-classified reports of his work in the Manhattan Project, the post-WW-II effort to build the hydrogen bomb, and his consulting with numerous government and military agencies, that remain unknown and unavailable. [In the case of Alan Turing, some of his classified war-time work has finally been released to the public, and every such known instance has been included in his bibliography.] ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From lm at mcvoy.com Sat Feb 3 06:10:09 2018 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 2 Feb 2018 12:10:09 -0800 Subject: [TUHS] Dynamics between BSD and Linux In-Reply-To: <20180202061135.CAEAF156E811@mail.bitblocks.com> References: <20180202034448.GA2796@mcvoy.com> <20180202061135.CAEAF156E811@mail.bitblocks.com> Message-ID: <20180202201009.GH2632@mcvoy.com> On Thu, Feb 01, 2018 at 10:11:20PM -0800, Bakul Shah wrote: > On Thu, 01 Feb 2018 19:44:48 -0800 Larry McVoy wrote: > Larry McVoy writes: > > > > It's a bummer because BSD brings minimalism to the table. You can run > > a BSD machine in 128MB and it works. Hell, it used to work great in 4MB. > > I think this is the crux of the issue. As a group gets bigger, > minimalism is hard to maintain. To have a fighting chance you > have inculcate new people in the same minimalism culture and > that takes time. This puts a higher bar to entry. > > > The BSD stuff isn't being taken seriously because the BSD people aren't > > interested in taking new people seriously. Which is a shame because the > > work that Netflix and other BSD people have done is really cool. > > If you think what BSD folks have done is cool, just join in. > Why not ignore the personalities and the popularity contest. Because I'm old and tired and not really interested in playing that game? And because if BSD wants to succeed it's doing it wrong. I'm not Mr Big Shot but I do have a track record of being somewhat clueful. If I'm not good enough for BSD how will unknown people fare? But I think we're pretty far into the weeds, don't want to give Warren more gray hairs so perhaps this is better if it is taken off list. From dave at horsfall.org Sun Feb 4 06:57:08 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 4 Feb 2018 07:57:08 +1100 (EST) Subject: [TUHS] Happy birthday, Ken Thompson! Message-ID: Co-inventor of Unix, he was born on this day in 1943. Just think: without those two, we'd all be running M$ Windoze and thinking that it's wonderful (I know, it's an exaggeration, but think about it). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From mutiny.mutiny at india.com Sun Feb 4 07:12:53 2018 From: mutiny.mutiny at india.com (Donald ODona) Date: Sat, 3 Feb 2018 21:12:53 +0000 (UTC) Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: Message-ID: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> Happy birthday, Ken, inventor of Unix, Father of Unix! At 3 Feb 2018 20:58:25 +0000 (+00:00) from Dave Horsfall : > Co-inventor of Unix, he was born on this day in 1943. Just think: without > those two, we'd all be running M$ Windoze and thinking that it's > wonderful (I know, it's an exaggeration, but think about it). > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From will.senn at gmail.com Sun Feb 4 07:35:57 2018 From: will.senn at gmail.com (Will Senn) Date: Sat, 3 Feb 2018 15:35:57 -0600 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: Message-ID: <916A0819-D582-4ABE-B975-0D6EFFEE28B1@gmail.com> Not a day goes by when I am not soooo thankful that I don’t have to live in a windows world. Unix and C have both had a huge impact on my career and computing life and I am grateful for their creation and legacy. Thankfully, Ken couldn’t afford a nicer computer and was forced to get creative with what he had to hand. Thanks Ken! Will Sent from my iPhone > On Feb 3, 2018, at 2:57 PM, Dave Horsfall wrote: > > Co-inventor of Unix, he was born on this day in 1943. Just think: without those two, we'd all be running M$ Windoze and thinking that it's wonderful (I know, it's an exaggeration, but think about it). > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From norman at oclsc.org Sun Feb 4 07:46:02 2018 From: norman at oclsc.org (Norman Wilson) Date: Sat, 03 Feb 2018 16:46:02 -0500 Subject: [TUHS] Happy birthday, Ken Thompson! Message-ID: <1517694366.7575.for-standards-violators@oclsc.org> Or as we old 1127ers would put it: What day is it, Ken? From krewat at kilonet.net Sun Feb 4 07:49:35 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Sat, 3 Feb 2018 16:49:35 -0500 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: <916A0819-D582-4ABE-B975-0D6EFFEE28B1@gmail.com> References: <916A0819-D582-4ABE-B975-0D6EFFEE28B1@gmail.com> Message-ID: On 2/3/2018 4:35 PM, Will Senn wrote: > Not a day goes by when I am not soooo thankful that I don’t have to live in a windows world I would imagine that Windows wouldn't be what it is today without UNIX. Matter of fact, Windows NT (which is what Windows has been based on since Windows ME went away) is really DEC's VMS underneath the covers at least to a small extent. Would VMS become what it was without UNIX's influence? Would UNIX become what it later was without VMS? Would UNIX exist, or even be close to what it became without DEC? art k. From akosela at andykosela.com Sun Feb 4 07:59:28 2018 From: akosela at andykosela.com (Andy Kosela) Date: Sat, 3 Feb 2018 15:59:28 -0600 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> References: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> Message-ID: On Saturday, February 3, 2018, Donald ODona wrote: > Happy birthday, Ken, inventor of Unix, Father of Unix! > > Exactly. He is the true father of UNIX. I always admired Ken's passion for minimalism and elegant, simple solutions to IT problems. Ed(1) will always be the most beautiful editor ever written. Besides Go I have not seen him getting involved with other projects recently though and the world needs him now more than ever... Linux and FreeBSD are now two monstrous trolls, bloated and extremely complex and large. Plan 9 is dead. MINIX is dying too... It seems UNIX fate is doomed. The only last remaining production quality UNIX that still maintains minimalism as one of its goals is probably OpenBSD these days... I am glad Rob and Ken gave us Go. It breathed a new life into the complex world of writing software. Happy Birthday, Ken. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sun Feb 4 08:59:27 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 4 Feb 2018 09:59:27 +1100 (EST) Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: <916A0819-D582-4ABE-B975-0D6EFFEE28B1@gmail.com> Message-ID: On Sat, 3 Feb 2018, Arthur Krewat wrote: > I would imagine that Windows wouldn't be what it is today without UNIX. > Matter of fact, Windows NT (which is what Windows has been based on > since Windows ME went away) is really DEC's VMS underneath the covers at > least to a small extent. I thought that NT has a POSIX-y kernel, which is why it was so reliable? Or was VMS a POSIX-like system? I only used it for a couple of years in the early 80s (up to 4.0, I think), and never dug inside it; to me, it was just RSX-11/RSTS-11 on steroids. > Would VMS become what it was without UNIX's influence? Would UNIX become > what it later was without VMS? > > Would UNIX exist, or even be close to what it became without DEC? I've oft wondered that, but we have to use a new thread to avoid embarrassing Ken :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From crossd at gmail.com Sun Feb 4 10:37:32 2018 From: crossd at gmail.com (Dan Cross) Date: Sat, 3 Feb 2018 19:37:32 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) Message-ID: On Sat, Feb 3, 2018 at 5:59 PM, Dave Horsfall wrote: > On Sat, 3 Feb 2018, Arthur Krewat wrote: > >> I would imagine that Windows wouldn't be what it is today without UNIX. >> Matter of fact, Windows NT (which is what Windows has been based on since >> Windows ME went away) is really DEC's VMS underneath the covers at least to >> a small extent. >> > > I thought that NT has a POSIX-y kernel, which is why it was so reliable? > Or was VMS a POSIX-like system? I only used it for a couple of years in > the early 80s (up to 4.0, I think), and never dug inside it; to me, it was > just RSX-11/RSTS-11 on steroids. The design of the original NT kernel was overseen by Dave Cutler, of VMS and RSX-11M fame, and had a very strong and apparent VMS influence. Some VAX wizards I know told me that they saw a lot of VMS in NT's design, but that it probably wasn't as good (different design goals, etc: apparently Gates wanted DOS++ and a quick time to market; Cutler wanted to do a *real* OS and they compromised to wind up with VMS--). It's true that there was (is? I don't know anymore...) a POSIX subsystem, but that seemed more oriented at being a marketing check in the box for sales to the US government and DoD (which had "standardized" on POSIX and made it a requirement when investing in new systems). Now days, I understand that one can run Linux binaries natively; the Linux-compatibility subsystem will even `apt-get install` dependencies for you. Satya Nadella's company isn't your father's Microsoft anymore. VSCode (their new snazzy editor that apparently all the kids love) is Open Source. Note that there is some irony in the NT/POSIX thing: the US Government standardized on Windows about two decades ago and now can't seem to figure out how to get off of it. A short story I can't resist telling: a couple of years ago, some folks tried to recruit me back into the Marine Corps in some kind of technical capacity. I asked if I'd be doing, you know, technical stuff and was told that, since I was an officer no, I wouldn't. Not really interested. I ended up going to a bar with a recon operator (Marine special operations) to get the straight scoop and talking to a light colonel (that's a Lieutenant Colonel) on the phone for an hour for the hard sell. Over a beer, the recon bubba basically said, "It was weird. I went back to the infantry." The colonel kept asking me why I didn't run Windows: "but it's the most popular operating system in the world!" Actually, I suspect Linux and BSD in the guise of iOS/macOS is running on a lot more devices than Windows at this point. I didn't bother pointing that out to him. Would VMS become what it was without UNIX's influence? Would UNIX become >> what it later was without VMS? >> >> Would UNIX exist, or even be close to what it became without DEC? >> > > I've oft wondered that, but we have to use a new thread to avoid > embarrassing Ken :-) > The speculation of, "what would have happened?" is interesting, though of course unanswerable. I suspect that had it not been for Unix, we'd all be running software that was closer to what you'd find on a mainframe or RT-11. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sun Feb 4 10:52:41 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 4 Feb 2018 11:52:41 +1100 (EST) Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> Message-ID: On Sat, 3 Feb 2018, Andy Kosela wrote: > I always admired Ken's passion for minimalism and elegant, simple > solutions to IT problems.  Ed(1) will always be the most beautiful > editor ever written. And the one editor that every sysadmin should know. I still use "expr" in my shell scripts, for example, because I don't know how portable the Penguin "${...}" construct is. [...] > Linux and FreeBSD are now two monstrous trolls, bloated and extremely > complex and large. Looking through /usr/include/***.h, I see: FreeBSD 10.4: #define SYS_MAXSYSCALL 548 MacOS Sierra: #define SYS_MAXSYSCALL 522 Debian 8.10: I don't know where the Penguins have hidden it... > I am glad Rob and Ken gave us Go.  It breathed a new life into the > complex world of writing software. That's the second endorsement I've seen for Go; I guess I should learn it. And yes, I've read the amusing story on Wikipedia :-) I'm becoming annoyed at Perl's bloatedness (I'd hate to see Perl 6), don't like Python's silly indentation (although some swear by it), and looking at Ruby for stuff where I used to use Perl. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From imp at bsdimp.com Sun Feb 4 11:14:30 2018 From: imp at bsdimp.com (Warner Losh) Date: Sat, 3 Feb 2018 18:14:30 -0700 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> Message-ID: On Sat, Feb 3, 2018 at 5:52 PM, Dave Horsfall wrote: > On Sat, 3 Feb 2018, Andy Kosela wrote: > >> Linux and FreeBSD are now two monstrous trolls, bloated and extremely >> complex and large. >> > > Looking through /usr/include/***.h, I see: > > FreeBSD 10.4: #define SYS_MAXSYSCALL 548 > MacOS Sierra: #define SYS_MAXSYSCALL 522 > Debian 8.10: I don't know where the Penguins have hidden it... Part of the reason for the bloat is that newer syscalls replace older ones (with the option for keeping the older one around for compat). So, open becomes openat (since the latter is more expressive). Also, over time, different data types grow to allow, for example, larger than 2G files, which has a big ripple effect on lots of system calls. But looking now, a lot are due to MAC and ACL functions (well, 30). There's 80 'at' system calls (though some are in the ~150 obsolete list)... So it isn't as utterly horrific as it might sound, but it's still pretty bad. (There's 400 defined, with 20 of those being for prior versions of the OS). Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Sun Feb 4 11:07:18 2018 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 3 Feb 2018 17:07:18 -0800 (PST) Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> Message-ID: > That's the second endorsement I've seen for Go; I guess I should learn it. In the scheme of "current" languages, Go is pretty good. With two major caveats, IMO: 1) The build system. It doesn't work with make(1). That makes it a non-starter for anything other than trivial projects at $WORK. While I appreciate the arguments for the apparent simplicity of the "go" command, that doesn't work for us. Which would have been fine, but for the entirely antagonistic bent they have taken against being able to build Go programs with make(1). Our build environment entirely precludes Go's promiscuous insistence on unfettered internet access, and hardwired directory paths. 2) Hardwired directory paths for the development/build environment (see above). It seems they have unlearned all the UNIX lessons. Sad, really. I would love to toss out Python, Ruby, PHP, Perl, et al. And could make the argument for it, I think. But the build environment will never work in our shop, therefore Go won't either. And that ... sucks. From steve at quintile.net Sun Feb 4 10:51:11 2018 From: steve at quintile.net (Steve Simon) Date: Sun, 4 Feb 2018 00:51:11 +0000 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: <916A0819-D582-4ABE-B975-0D6EFFEE28B1@gmail.com> Message-ID: <60E97B5F-FB0F-4302-ACE9-87CCFF36AD2F@quintile.net> Hi, I have to take issue with the “plan9 is dead” statement, I agree it seems on a downward spiral, but are a few who fight on. [sent from my plan9] -Steve From bigatojj at gmail.com Sun Feb 4 11:29:36 2018 From: bigatojj at gmail.com (=?UTF-8?Q?Daniel_Camol=C3=AAs?=) Date: Sat, 3 Feb 2018 23:29:36 -0200 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> Message-ID: You can use make as much as you like; Go just doesn't need it. You can use Go to fetch code from internet if you like, or you can do it yourself if you prefer. Regarding the "hardwired" directories, you can change it through an environment variable. Em 3 de fev de 2018 23:20, "Lyndon Nerenberg" escreveu: That's the second endorsement I've seen for Go; I guess I should learn it. > In the scheme of "current" languages, Go is pretty good. With two major caveats, IMO: 1) The build system. It doesn't work with make(1). That makes it a non-starter for anything other than trivial projects at $WORK. While I appreciate the arguments for the apparent simplicity of the "go" command, that doesn't work for us. Which would have been fine, but for the entirely antagonistic bent they have taken against being able to build Go programs with make(1). Our build environment entirely precludes Go's promiscuous insistence on unfettered internet access, and hardwired directory paths. 2) Hardwired directory paths for the development/build environment (see above). It seems they have unlearned all the UNIX lessons. Sad, really. I would love to toss out Python, Ruby, PHP, Perl, et al. And could make the argument for it, I think. But the build environment will never work in our shop, therefore Go won't either. And that ... sucks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Sun Feb 4 11:35:58 2018 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 3 Feb 2018 17:35:58 -0800 (PST) Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> Message-ID: > You can use make as much as you like; Go just doesn't need it. You can use > Go to fetch code from internet if you like, or you can do it yourself if > you prefer. > > Regarding the "hardwired" directories, you can change it through an > environment variable. My argument is that Go is making that an untenable exercise. E.g., forcing environment variable overrides means I don't have a source tree I can check out *anywhere* and have it just build. No different from the built-in assumptions the go command makes. I get the feeling there won't be any sort of actual argument for or against the Go regime, so I won't. From bigatojj at gmail.com Sun Feb 4 11:51:18 2018 From: bigatojj at gmail.com (=?UTF-8?Q?Daniel_Camol=C3=AAs?=) Date: Sat, 3 Feb 2018 23:51:18 -0200 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: <916A0819-D582-4ABE-B975-0D6EFFEE28B1@gmail.com> <60E97B5F-FB0F-4302-ACE9-87CCFF36AD2F@quintile.net> Message-ID: What do you mean plan9 is dead? It's even possible make a facebook post from inside plan9 nowadays! https://twitter.com/bigatojj/status/949838932841201664 See vmx(1) Em 3 de fev de 2018 23:25, "Steve Simon" escreveu: Hi, I have to take issue with the “plan9 is dead” statement, I agree it seems on a downward spiral, but are a few who fight on. [sent from my plan9] -Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Sun Feb 4 12:59:26 2018 From: cym224 at gmail.com (Nemo Nusquam) Date: Sat, 3 Feb 2018 21:59:26 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: Message-ID: On 02/03/18 19:37, Dan Cross wrote (in part): > The design of the original NT kernel was overseen by Dave Cutler, of VMS > and RSX-11M fame, and had a very strong and apparent VMS influence. Some > VAX wizards I know told me that they saw a lot of VMS in NT's design, > but that it probably wasn't as good (different design goals, etc: > apparently Gates wanted DOS++ and a quick time to market; Cutler wanted > to do a *real* OS and they compromised to wind up with VMS--). I recall that Cutler wanted a portable OS and had a cli version running on MIPS first. Eventually, Gates ordered a GUI "bolted on" and things went bad. > It's true that there was (is? I don't know anymore...) a POSIX > subsystem, but that seemed more oriented at being a marketing check in > the box for sales to the US government and DoD (which had "standardized" > on POSIX and made it a requirement when investing in new systems). Indeed, but it was functionally useless in that it could interact with the NT system. It always reminds of the time that NT obtained FIPS 140 Level 1 but with no network. (Had NIST not re-organised their website, I would link to the certificate.) N. From wobblygong at gmail.com Sun Feb 4 15:06:47 2018 From: wobblygong at gmail.com (Wesley Parish) Date: Sun, 4 Feb 2018 18:06:47 +1300 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: Message-ID: >From what little I know, Dave Cutler was wanting to work on a VMS (Next Generation) at DEC, but couldn't manage to get management to agree, so when the possibility of doing a VMS (Next Gen) at Microsoft came up, he jumped for it. At least that's what I read back in the late 90s. I've forgotten where I read it, unfortunately, so unless someone can come up with a source for it, best treat it with a pinch of salt. Wesley Parish On 2/4/18, Nemo Nusquam wrote: > On 02/03/18 19:37, Dan Cross wrote (in part): >> The design of the original NT kernel was overseen by Dave Cutler, of VMS >> and RSX-11M fame, and had a very strong and apparent VMS influence. Some >> VAX wizards I know told me that they saw a lot of VMS in NT's design, >> but that it probably wasn't as good (different design goals, etc: >> apparently Gates wanted DOS++ and a quick time to market; Cutler wanted >> to do a *real* OS and they compromised to wind up with VMS--). > > I recall that Cutler wanted a portable OS and had a cli version running > on MIPS first. Eventually, Gates ordered a GUI "bolted on" and things > went bad. > >> It's true that there was (is? I don't know anymore...) a POSIX >> subsystem, but that seemed more oriented at being a marketing check in >> the box for sales to the US government and DoD (which had "standardized" >> on POSIX and made it a requirement when investing in new systems). > > Indeed, but it was functionally useless in that it could interact with > the NT system. It always reminds of the time that NT obtained FIPS 140 > Level 1 but with no network. (Had NIST not re-organised their website, I > would link to the certificate.) > > N. > From imp at bsdimp.com Sun Feb 4 15:18:28 2018 From: imp at bsdimp.com (Warner Losh) Date: Sat, 3 Feb 2018 22:18:28 -0700 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: Message-ID: On Sat, Feb 3, 2018 at 10:06 PM, Wesley Parish wrote: > From what little I know, Dave Cutler was wanting to work on a VMS > (Next Generation) at DEC, but couldn't manage to get management to > agree, so when the possibility of doing a VMS (Next Gen) at Microsoft > came up, he jumped for it. > > At least that's what I read back in the late 90s. I've forgotten where > I read it, unfortunately, so unless someone can come up with a source > for it, best treat it with a pinch of salt. This was certainly the story that was going around at the time... Warner > > Wesley Parish > > On 2/4/18, Nemo Nusquam wrote: > > On 02/03/18 19:37, Dan Cross wrote (in part): > >> The design of the original NT kernel was overseen by Dave Cutler, of VMS > >> and RSX-11M fame, and had a very strong and apparent VMS influence. Some > >> VAX wizards I know told me that they saw a lot of VMS in NT's design, > >> but that it probably wasn't as good (different design goals, etc: > >> apparently Gates wanted DOS++ and a quick time to market; Cutler wanted > >> to do a *real* OS and they compromised to wind up with VMS--). > > > > I recall that Cutler wanted a portable OS and had a cli version running > > on MIPS first. Eventually, Gates ordered a GUI "bolted on" and things > > went bad. > > > >> It's true that there was (is? I don't know anymore...) a POSIX > >> subsystem, but that seemed more oriented at being a marketing check in > >> the box for sales to the US government and DoD (which had "standardized" > >> on POSIX and made it a requirement when investing in new systems). > > > > Indeed, but it was functionally useless in that it could interact with > > the NT system. It always reminds of the time that NT obtained FIPS 140 > > Level 1 but with no network. (Had NIST not re-organised their website, I > > would link to the certificate.) > > > > N. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mutiny.mutiny at india.com Sun Feb 4 19:11:40 2018 From: mutiny.mutiny at india.com (Donald ODona) Date: Sun, 4 Feb 2018 09:11:40 +0000 (UTC) Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: Message-ID: <481080680.23531.1517735500590.JavaMail.tomcat@india-live-be03> At 4 Feb 2018 00:39:36 +0000 (+00:00) from Dan Cross : > On Sat, Feb 3, 2018 at 5:59 PM, Dave Horsfall wrote: > The design of the original NT kernel was overseen by Dave Cutler, of VMS > and RSX-11M fame, and had a very strong and apparent VMS influence. Some > VAX wizards I know told me that they saw a lot of VMS in NT's design, but > that it probably wasn't as good (different design goals, etc: apparently > Gates wanted DOS++ and a quick time to market; Cutler wanted to do a *real* > OS and they compromised to wind up with VMS--). Win32/WinNT basically is OS2 Release 3, with IBM as customer and principal leader. Release 3 was OS/2 portable running on more that Intel X86. Furthermore MS hired a Mach developer for NT Kernel, which, like all micro kernels, started as micro kernel and soon became a hybrid out of good reasons. Cutler contribution to Windows is largely overrated, because all these rumors of a VMS heritage serve MS as a marketing campaign to compete against *NIX, because of VMS reputation as very stable and secure OS. In real Windows has nothing to do with VMS. Cutler and his team were hired after DEC stopped the mica project out of good reasons. Windows has a lot to do with OS/2 and IBM is responsible for it. Without the expertise of IBM MS surely would have build windows GUI upon xenix. Remember xenix was MS unix and the most wide spread UNIX of the 80ths. From aap at papnet.eu Sun Feb 4 19:14:35 2018 From: aap at papnet.eu (Angelo Papenhoff) Date: Sun, 4 Feb 2018 10:14:35 +0100 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: Message-ID: <20180204091435.GA22841@indra.papnet.eu> On 03/02/18, Nemo Nusquam wrote: > On 02/03/18 19:37, Dan Cross wrote (in part): > > The design of the original NT kernel was overseen by Dave Cutler, of VMS > > and RSX-11M fame, and had a very strong and apparent VMS influence. Some > > VAX wizards I know told me that they saw a lot of VMS in NT's design, > > but that it probably wasn't as good (different design goals, etc: > > apparently Gates wanted DOS++ and a quick time to market; Cutler wanted > > to do a *real* OS and they compromised to wind up with VMS--). > > I recall that Cutler wanted a portable OS and had a cli version running > on MIPS first. Eventually, Gates ordered a GUI "bolted on" and things > went bad. > You seem to be simplifying things... Windows NT was originally called NT OS/2 and was supposed to be a 32 bit OS with OS/2 compatibility. The name "NT" comes from codename of the processor they initially targetted, the i860 aka N-Ten. When they got the physical hardware they were disappointed by its poor performace and switched to MIPS instead, other ports followed. When the Windows GUI became more and more popular (at the expense of OS/2), they renamed it to Windows NT, but still shipped it with the OS/2 subsystem. The other subsystems were Win32 (an updated version of the original 16 bit Windows API for the NT kernel) and POSIX. None of these APIs is native to NT, they're implemented on top of it. I think only at boot you can run code that uses the NT API directly. At some point they moved some graphical things into the kernel that were in user space originally (I don't know what exactly), this was done for performance reasons. Perhaps that's what you meant with the "bolted on" GUI. aap From tytso at mit.edu Sun Feb 4 23:59:09 2018 From: tytso at mit.edu (Theodore Ts'o) Date: Sun, 4 Feb 2018 08:59:09 -0500 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> Message-ID: <20180204135909.GA11167@thunk.org> On Sat, Feb 03, 2018 at 06:14:30PM -0700, Warner Losh wrote: > >> Linux and FreeBSD are now two monstrous trolls, bloated and extremely > >> complex and large. > > Looking through /usr/include/***.h, I see: > > > > FreeBSD 10.4: #define SYS_MAXSYSCALL 548 > > MacOS Sierra: #define SYS_MAXSYSCALL 522 > > Debian 8.10: I don't know where the Penguins have hidden it... > > Part of the reason for the bloat is that newer syscalls replace older ones > (with the option for keeping the older one around for compat). So, open > becomes openat (since the latter is more expressive). Also, over time, > different data types grow to allow, for example, larger than 2G files, > which has a big ripple effect on lots of system calls. But looking now, a > lot are due to MAC and ACL functions (well, 30). There's 80 'at' system > calls (though some are in the ~150 obsolete list)... So it isn't as utterly > horrific as it might sound, but it's still pretty bad. (There's 400 > defined, with 20 of those being for prior versions of the OS). Indeed. Linux has 292 system calls as of Linux 4.15. If you include the backwards compatibility system calls, the number of system calls goes up to 352. Of course, just comparing system calls isn't really the whole story. There are also system interfaces via /proc and /sys, ioctl's, etc. (And by that measure Plan9 has a lot of complexity that doesn't show up in plain system call counts.) *And* of course, a lot of bloat doesn't show up in kernel/userspace interfaces, but rather in the complexity that people expect to be found in modern Systems, whether they be in the kernel or in the Java class libraries, etc. Complaining about the OS complexity when people are gleefully building super-complex systems in userspace seems to me to be a kind of "get off my lawn" complaint. The question is, given an overall system architecture, *including* userspace, when does it make sense to try to simplify things by pushing some of the work to the lower layers of the software stack, and when does it make sense to force the userspace to deal with the complexity? Of course, if you want to do all of your programming on the equivalent of a Raspberry Pi, that also can be your choice. :-) - Ted From arnold at skeeve.com Mon Feb 5 00:15:40 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 04 Feb 2018 07:15:40 -0700 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <20180204091435.GA22841@indra.papnet.eu> References: <20180204091435.GA22841@indra.papnet.eu> Message-ID: <201802041415.w14EFeJ9005294@freefriends.org> The best description of the development of Windows NT, in my opinion, is the book "Showstopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft" by G. Pascal Zachary: https://www.amazon.com/Showstopper-Breakneck-Windows-Generation-Microsoft/dp/1497638836/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=1517753530&sr=8-1 Although Amazon gives it a 2014 publication date it is much older. Well worth reading. Arnold From ches at cheswick.com Mon Feb 5 00:30:38 2018 From: ches at cheswick.com (William Cheswick) Date: Sun, 4 Feb 2018 09:30:38 -0500 Subject: [TUHS] Fwd: [math-fun] Outside In written accompaniement References: Message-ID: Concerning the sphere eversion video, Tamara writes: > > There's a DVD-supplement bundle that includes a single DVD and the two hardcopy supplements for both Outside In and Not Knot. > https://www.amazon.com/Outside-Not-Knot-DVD-Booklets/dp/1568814534 > https://www.crcpress.com/Outside-In-and-Not-Knot-DVD--two-Booklets/The-Geometry-Center-Univ-Of-Minnesota/p/book/9781568814537 > > That's the only way to get access to the written supplements, they're not posted online. I don't even have the PDF of either one of these in my own possession, I tried to hunt those down when I converted the original master videos onto the DVD version in 2009 but those files have gotten lost in the mists of time... > > So you could order the bundle just for access to the booklets! The Not Knot one is black and white rather than color, but a similar level of care went into the mathematical exposition for that one too. > > Cheers, Tamara > > ---- > Tamara Munzner > Professor, Department of Computer Science, University of British Columbia > http://www.cs.ubc.ca/~tmm , tmm at cs.ubc.ca <> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Mon Feb 5 03:21:41 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 4 Feb 2018 12:21:41 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <20180204091435.GA22841@indra.papnet.eu> References: <20180204091435.GA22841@indra.papnet.eu> Message-ID: <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> > None of these APIs is native to NT, they're implemented on top of it. > I think only at boot you can run code that uses the NT API directly. Amusingly, I have a device in my airplane that runs NT4 without any Windows graphical API on it. You can see the thing printing the NT4 startup and build number when you power it on and it will BSOD. I actually worked with the n10 and i860. IBM build a 4 processor i860 card. We ported the 370/386 AIX to it. The only non x86 chip I worked with NT on was the iTanium (or as we called it the iTanic). I might have had an NT Alpha around but we pretty much were an OSF/1 shop at the time. From toby at telegraphics.com.au Mon Feb 5 03:33:47 2018 From: toby at telegraphics.com.au (Toby Thain) Date: Sun, 4 Feb 2018 12:33:47 -0500 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: <916A0819-D582-4ABE-B975-0D6EFFEE28B1@gmail.com> <60E97B5F-FB0F-4302-ACE9-87CCFF36AD2F@quintile.net> Message-ID: <04b3c33d-6063-8a6a-a44f-1cfb5acc04fb@telegraphics.com.au> On 2018-02-03 8:51 PM, Daniel Camolês wrote: > What do you mean plan9 is dead? It's even possible make a facebook post > from inside plan9 nowadays! So it's not only dead, it's in Hell. > > https://twitter.com/bigatojj/status/949838932841201664 > > See vmx(1) > > Em 3 de fev de 2018 23:25, "Steve Simon" > escreveu: > > Hi, > > I have to take issue with the “plan9 is dead” statement, > I agree it seems on a downward spiral, but are a few who fight on. > > [sent from my plan9] > > -Steve > > > From crossd at gmail.com Mon Feb 5 06:05:11 2018 From: crossd at gmail.com (Dan Cross) Date: Sun, 4 Feb 2018 15:05:11 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> Message-ID: On Sun, Feb 4, 2018 at 12:21 PM, Ron Natalie wrote: > > None of these APIs is native to NT, they're implemented on top of it. > > I think only at boot you can run code that uses the NT API directly. > Amusingly, I have a device in my airplane that runs NT4 without any Windows > graphical API on it. You can see the thing printing the NT4 startup and > build number when you power it on and it will BSOD. > BSOD on an airplane? That sounds kind of scary. One time I was poking around a US Navy landing craft after coming off an amphibious assault ship and somehow found myself down in the engine room. The computer controlling either the engines or the screws was running some variant of Windows. It wasn't my bailiwick at the time (I was a Marine officer; I wasn't even *supposed* to be there ... but I was curious and pretty much had the run of the boat as long as I didn't touch anything) but it sort of scared me. I actually worked with the n10 and i860. IBM build a 4 processor i860 > card. We ported the 370/386 AIX to it. > That actually sounds kind of cool. The only non x86 chip I worked with NT on was the iTanium (or as we called > it the iTanic). I might have had an NT Alpha around but we pretty much > were an OSF/1 shop at the time. I think it was Lockheed Martin that ended up buying a ton of Alphas to run NT for Exchange server. Shoulda stuck with sendmail.... - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Mon Feb 5 06:55:45 2018 From: cym224 at gmail.com (Nemo) Date: Sun, 4 Feb 2018 15:55:45 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> Message-ID: On 04/02/2018, Dan Cross wrote: > One time I was poking around a US Navy landing craft after coming off an > amphibious assault ship and somehow found myself down in the engine room. > The computer controlling either the engines or the screws was running some > variant of Windows. ...] but it sort of scared me. You can google "Windows for warships" on The Register for more frightening stuff. N. From imp at bsdimp.com Mon Feb 5 06:57:46 2018 From: imp at bsdimp.com (Warner Losh) Date: Sun, 4 Feb 2018 13:57:46 -0700 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> Message-ID: On Sun, Feb 4, 2018 at 1:55 PM, Nemo wrote: > On 04/02/2018, Dan Cross wrote: > > One time I was poking around a US Navy landing craft after coming off an > > amphibious assault ship and somehow found myself down in the engine room. > > The computer controlling either the engines or the screws was running > some > > variant of Windows. ...] but it sort of scared me. > > You can google "Windows for warships" on The Register for more > frightening stuff. > And also https://catless.ncl.ac.uk/Risks/19.88.html Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From toby at telegraphics.com.au Mon Feb 5 07:04:34 2018 From: toby at telegraphics.com.au (Toby Thain) Date: Sun, 4 Feb 2018 16:04:34 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> Message-ID: <62376536-f247-2026-82cb-1defdcca7976@telegraphics.com.au> On 2018-02-04 3:05 PM, Dan Cross wrote: > On Sun, Feb 4, 2018 at 12:21 PM, Ron Natalie > wrote: > > > None of these APIs is native to NT, they're implemented on top of it. > > I think only at boot you can run code that uses the NT API directly. > Amusingly, I have a device in my airplane that runs NT4 without any > Windows > graphical API on it.   You can see the thing printing the NT4 > startup and > build number when you power it on and it will BSOD. > > > BSOD on an airplane? That sounds kind of scary. > > One time I was poking around a US Navy landing craft after coming off an > amphibious assault ship and somehow found myself down in the engine > room. The computer controlling either the engines or the screws was > running some variant of Windows. It wasn't my bailiwick at the time (I > was a Marine officer; I wasn't even *supposed* to be there ... but I was > curious and pretty much had the run of the boat as long as I didn't > touch anything) but it sort of scared me. You might remember this: https://www.wired.com/1998/07/sunk-by-windows-nt/ --Toby > > I actually worked with the n10 and i860.   IBM build a 4 processor i860 > card.   We ported the 370/386 AIX to it. > > > That actually sounds kind of cool. > > The only non x86 chip I worked with NT on was the iTanium (or as we > called > it the iTanic).   I might have had an NT Alpha around but we pretty much > were an OSF/1 shop at the time. > > > I think it was Lockheed Martin that ended up buying a ton of Alphas to > run NT for Exchange server. Shoulda stuck with sendmail.... > >         - Dan C. > From jon at fourwinds.com Mon Feb 5 06:59:11 2018 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 04 Feb 2018 12:59:11 -0800 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> Message-ID: <201802042059.w14KxBo3031103@darkstar.fourwinds.com> Nemo writes: > You can google "Windows for warships" on The Register for more > frightening stuff. > > N. It's not just Windows. I remember touring a Navy ship in the early days of Ethernet and noticed that they were using stinger taps on the coax. What could possibly go wrong? Jon From clemc at ccc.com Mon Feb 5 08:12:01 2018 From: clemc at ccc.com (Clem Cole) Date: Sun, 4 Feb 2018 17:12:01 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <201802042059.w14KxBo3031103@darkstar.fourwinds.com> References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <201802042059.w14KxBo3031103@darkstar.fourwinds.com> Message-ID: Funny, I was just going to respond with my story about the USS Carl Vincent - a carrier the USA built in the late 1970s. When the Navy laid its keel, the White House was running Alto's donated by Xerox. The Captain had seen them and wanted then for his new ship and wanted the CIC to be the most modern imagined. Xerox did not sell them (and the Star had not been done yet), so they were sent to the CMU spin off 3 Rivers Computer (aka Triple Drip) to purchase 'PascAltos' ) later renamed the Perq instead. We had a contract at Mellon to make they work as well as a bunch of programming. We had designed the deployment with pre-cut ethernet cable (3Com transceivers) that did not use the 'stinger' technology, but fixed cable lengths, pre-cut and tested before installation. But the Captain would have none of it, he had seen the fact that the taps could be moved and he wants the stinger types. The deployment happen after I had graduated and left, so I never knew how that worked out in practice, but years sailing small boats, I just could not imagine that being reliable. Clem ᐧ On Sun, Feb 4, 2018 at 3:59 PM, Jon Steinhart wrote: > Nemo writes: > > You can google "Windows for warships" on The Register for more > > frightening stuff. > > > > N. > > It's not just Windows. I remember touring a Navy ship in the early > days of Ethernet and noticed that they were using stinger taps on > the coax. What could possibly go wrong? > > Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From akosela at andykosela.com Mon Feb 5 08:22:59 2018 From: akosela at andykosela.com (Andy Kosela) Date: Sun, 4 Feb 2018 16:22:59 -0600 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <62376536-f247-2026-82cb-1defdcca7976@telegraphics.com.au> References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <62376536-f247-2026-82cb-1defdcca7976@telegraphics.com.au> Message-ID: On Sunday, February 4, 2018, Toby Thain wrote: > On 2018-02-04 3:05 PM, Dan Cross wrote: > > On Sun, Feb 4, 2018 at 12:21 PM, Ron Natalie > > wrote: > > > > > None of these APIs is native to NT, they're implemented on top of > it. > > > I think only at boot you can run code that uses the NT API > directly. > > Amusingly, I have a device in my airplane that runs NT4 without any > > Windows > > graphical API on it. You can see the thing printing the NT4 > > startup and > > build number when you power it on and it will BSOD. > > > > > > BSOD on an airplane? That sounds kind of scary. > > > > One time I was poking around a US Navy landing craft after coming off an > > amphibious assault ship and somehow found myself down in the engine > > room. The computer controlling either the engines or the screws was > > running some variant of Windows. It wasn't my bailiwick at the time (I > > was a Marine officer; I wasn't even *supposed* to be there ... but I was > > curious and pretty much had the run of the boat as long as I didn't > > touch anything) but it sort of scared me. > > You might remember this: > https://www.wired.com/1998/07/sunk-by-windows-nt/ > > I like the following part from this article: "Vendors including Oracle, Informix, and Computer Associates have _recently_ announced plans to support Linux". No mention of *BSD systems which were also open source at the time. This was the beginning of the decline of *BSD systems in the server market and it was 20 years ago. Things went much more downhill since then... --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Mon Feb 5 08:43:28 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 5 Feb 2018 09:43:28 +1100 (EST) Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> Message-ID: On Sun, 4 Feb 2018, Dan Cross wrote: > Amusingly, I have a device in my airplane that runs NT4 without > any Windows graphical API on it.   You can see the thing printing > the NT4 startup and build number when you power it on and it will > BSOD. > > BSOD on an airplane? That sounds kind of scary. Dunno if you're joking or not, but if you're serious then yes, NT starts up with a nice bright blue screen and some gibberish, and to log on you have to "CTL/ALT/DEL". Yes, really... I did not endear myself to my Windoze-loving cow-orkers when I commented that a) it comes with its own BSOD, and b) you have to reboot it to log on. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From ggm at algebras.org Mon Feb 5 08:54:15 2018 From: ggm at algebras.org (George Michaelson) Date: Mon, 5 Feb 2018 08:54:15 +1000 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> Message-ID: I did some weak-mode due diligence on the infrastructure side of DirecTV for a potential user/ISP in Australia. This was in the 90s. The TDM sat control logic, the box which fed the Hughes aerospace low level protocol to tell the satellite which user got which timeslots, was OS/2 -I glibly assumed this was initially a typo, and then when I confirmed it, checked it was under maintenance, and indeed it was. it continued to be an actively maintained product until 2006 according to wookiepedia when I read it just now. (it is a little hard to read, but google translate works) So this idea that all good ideas die, and get replaced by bad Microsoft ideas even then, wasn't strictly true: People chose to run systems which worked for them, and if the backend support contracts works, continued to run then way way after they "died" in the visible marketplace. So back then, I shrugged and said "it seems ok. it works, its very small, very fast, has sensible logic behind it, and its a shitload better than windows". We weren't going to interact with this OS/2, somehow they'd sent me the uplink control manual for a consumer internet service we'd resell at arms length: we'd send emails to Hughes staff, who would issue the commands, to configure the customers live (the customer side squareial antenna was designed for anyone, even army PFCs to configure: you line of sight it to north, then hunt-and-check until the whistle said it was on-target. It think the TV could even be a ring-and-dot focus thing checking side-channel SQ to confirm when it was lined up. Then tighten the wall bolts, and its done. Oh right. Did I say north? I'm southern hemisphere. you guys line it south...) Looking back, I don't know what I expected the OS behind this thing to be. Probably, some arcane military-industrial (BESM compatible? Never know when you might sell one to the other side...) protocol designed to cause ICBM to be launched, with Bruce Willis on it riding bareback to wrestle the sat dish into place. Or punch cards. Or maybe you phone Hughes and they type it into a 1960s batch control system on their own fruitbat powered analog computer. Or .. OS/2? why not. That works. DECISION! On Mon, Feb 5, 2018 at 8:43 AM, Dave Horsfall wrote: > On Sun, 4 Feb 2018, Dan Cross wrote: > >> Amusingly, I have a device in my airplane that runs NT4 without >> any Windows graphical API on it. You can see the thing printing >> the NT4 startup and build number when you power it on and it will >> BSOD. >> >> BSOD on an airplane? That sounds kind of scary. > > > Dunno if you're joking or not, but if you're serious then yes, NT starts up > with a nice bright blue screen and some gibberish, and to log on you have to > "CTL/ALT/DEL". Yes, really... I did not endear myself to my Windoze-loving > cow-orkers when I commented that a) it comes with its own BSOD, and b) you > have to reboot it to log on. > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > suffer." From dave at horsfall.org Mon Feb 5 09:25:35 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 5 Feb 2018 10:25:35 +1100 (EST) Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: Message-ID: On Sat, 3 Feb 2018, Dan Cross wrote: > The colonel kept asking me why I didn't run Windows: "but it's the most > popular operating system in the world!" Actually, I suspect Linux and > BSD in the guise of iOS/macOS is running on a lot more devices than > Windows at this point. I didn't bother pointing that out to him. I'm told that Android (Linux?) outnumbers iOS (BSD?) quite heavily in the mobile market; Win/CE (pronounced "wince") never really took off. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From bakul at bitblocks.com Mon Feb 5 09:46:02 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Sun, 04 Feb 2018 15:46:02 -0800 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: Your message of "Mon, 05 Feb 2018 10:25:35 +1100." References: Message-ID: <20180204234617.AA1BC156E80B@mail.bitblocks.com> On Mon, 05 Feb 2018 10:25:35 +1100 Dave Horsfall wrote: > On Sat, 3 Feb 2018, Dan Cross wrote: > > > The colonel kept asking me why I didn't run Windows: "but it's the most > > popular operating system in the world!" Actually, I suspect Linux and > > BSD in the guise of iOS/macOS is running on a lot more devices than > > Windows at this point. I didn't bother pointing that out to him. > > I'm told that Android (Linux?) outnumbers iOS (BSD?) quite heavily in the > mobile market; Win/CE (pronounced "wince") never really took off. Depends on which market you look at. In the desktop/laptop world Windows is still the king. https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Market_share_by_category From dave at horsfall.org Mon Feb 5 09:58:28 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 5 Feb 2018 10:58:28 +1100 (EST) Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <20180204234617.AA1BC156E80B@mail.bitblocks.com> References: <20180204234617.AA1BC156E80B@mail.bitblocks.com> Message-ID: On Sun, 4 Feb 2018, Bakul Shah wrote: >> I'm told that Android (Linux?) outnumbers iOS (BSD?) quite heavily in >> the mobile market; Win/CE (pronounced "wince") never really took off. > > Depends on which market you look at. In the desktop/laptop world > Windows is still the king. I said the *mobile* market. > https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Market_share_by_category Which is exactly what I said... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From robert at timetraveller.org Mon Feb 5 10:06:58 2018 From: robert at timetraveller.org (Robert Brockway) Date: Mon, 5 Feb 2018 10:06:58 +1000 (AEST) Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: Message-ID: On Sat, 3 Feb 2018, Dan Cross wrote: > Now days, I understand that one can run Linux binaries natively; the > Linux-compatibility subsystem will even `apt-get install` dependencies for > you. Satya Nadella's company isn't your father's Microsoft anymore. VSCode > (their new snazzy editor that apparently all the kids love) is Open Source. It's interesting that this hasn't taken off more. A year+ on and I hardly see anyone using it. > The speculation of, "what would have happened?" is interesting, though of > course unanswerable. I suspect that had it not been for Unix, we'd all be > running software that was closer to what you'd find on a mainframe or RT-11. This speaks to the "great man" theory of history. This posits that history would have been different if a great person had died before their moment in history. Eg, Winston Churchill was hit by a car when visiting New York City in the 1930s. He looked the wrong way before trying to cross the road. What if he had died? Would WW2 have turned out substantially differently? The alternative is to presume that a niche exists in to which a someone (or in this case an operating system) will step to become great. Using this alternative view, if Winston Churchill had died in the 1930s (or if UNIX had not been developed) an alternative would have filled that niche. Maybe we'd all be talking about TOPS20 now :) Rob From khm at sciops.net Mon Feb 5 10:27:31 2018 From: khm at sciops.net (Kurt H Maier) Date: Sun, 4 Feb 2018 16:27:31 -0800 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> Message-ID: <20180205002731.GA79027@wopr> On Sun, Feb 04, 2018 at 03:05:11PM -0500, Dan Cross wrote: > > I think it was Lockheed Martin that ended up buying a ton of Alphas to run > NT for Exchange server. Shoulda stuck with sendmail.... > With the advent of mail.mil, the entire DoD is on Exchange now. Sure, it sucks, but since there's no way to get equivalent functionality with actual technical support for anything else, I'm not sure what anyone expected. Until something like Red Hat, but with a willingness to address customer needs, comes around, it's going to be the same old story, ad infinitum. That said, I've worked in a couple of DSRC sites, and at least one of them explicitly considers Windows a security risk... but they still have to keep workstations around because of the tight integration of the Exchange ecosystem. I don't know of anyone happy with the current situation. At least ARL (née BRL, of course) still has a healthy awareness of the architectural ins and outs of UNIX, if only they could get the free hand to innovate in that space. It's the classic problem both inside and outside the military: if too many technical people turn down the management routes, you get paths forward that don't involve any technical considerations... khm From robert at timetraveller.org Mon Feb 5 10:41:26 2018 From: robert at timetraveller.org (Robert Brockway) Date: Mon, 5 Feb 2018 10:41:26 +1000 (AEST) Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <20180204091435.GA22841@indra.papnet.eu> References: <20180204091435.GA22841@indra.papnet.eu> Message-ID: On Sun, 4 Feb 2018, Angelo Papenhoff wrote: > At some point they moved some graphical things into the kernel that were > in user space originally (I don't know what exactly), this was done for > performance reasons. Perhaps that's what you meant with the "bolted on" > GUI. I watched the development of NT during that period and I recall that graphics was originally in ring 1 on i386 until NT 3.51. From NT 4 onwards graphics drivers were moved to ring 0 (the kernel). I believe this push came from the marketting department. Moar speed! Cheers, Rob From ches at cheswick.com Mon Feb 5 11:32:11 2018 From: ches at cheswick.com (William Cheswick) Date: Sun, 4 Feb 2018 20:32:11 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <201802042059.w14KxBo3031103@darkstar.fourwinds.com> References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <201802042059.w14KxBo3031103@darkstar.fourwinds.com> Message-ID: <2EDC8B25-60C9-408C-947C-64B219E9FA64@cheswick.com> One important and sensitive site chose to stick with this technology for a while because one could detect unauthorized taps. I guess TDR isn’t as useful these days. > On 4Feb 2018, at 3:59 PM, Jon Steinhart wrote: > > It's not just Windows. I remember touring a Navy ship in the early > days of Ethernet and noticed that they were using stinger taps on > the coax. What could possibly go wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Mon Feb 5 11:44:29 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 5 Feb 2018 12:44:29 +1100 (EST) Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <2EDC8B25-60C9-408C-947C-64B219E9FA64@cheswick.com> References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <201802042059.w14KxBo3031103@darkstar.fourwinds.com> <2EDC8B25-60C9-408C-947C-64B219E9FA64@cheswick.com> Message-ID: On Sun, 4 Feb 2018, William Cheswick wrote: > One important and sensitive site chose to stick with this technology for > a while becauseone could detect unauthorized taps.  I guess TDR isn’t as > useful these days. I believe that optical TDRs exist, for use on fibre. The ultimate in anti-snooping, of course, is quantum; if you so much as *look* at it, you've disturbed it (which is how quantum key exchange would work etc). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From ron at ronnatalie.com Mon Feb 5 13:35:09 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 4 Feb 2018 22:35:09 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> Message-ID: <003601d39e32$532f2b70$f98d8250$@ronnatalie.com> I'm serious. The thing never gets to the login screen (and I'm quite familiar with it, I was a beta NT user when it was first released. The fact that it asked you to type CTL-ALT-DEL to login was so bizarre I took a photo of the screen). The thing gets the "blue" start up screen with the build number (oddly, on my unit the video screen is upside down as far as NT is concerned so it's upside down). While the software that runs under NT which is the heart of the system hides everything else, I have seen it blue screen on a few occasions. I've looked at the file system it boots off. Not much there. From crossd at gmail.com Mon Feb 5 13:40:09 2018 From: crossd at gmail.com (Dan Cross) Date: Sun, 4 Feb 2018 22:40:09 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> Message-ID: On Sun, Feb 4, 2018 at 5:43 PM, Dave Horsfall wrote: > On Sun, 4 Feb 2018, Dan Cross wrote: > >> Amusingly, I have a device in my airplane that runs NT4 without >> any Windows graphical API on it. You can see the thing printing >> the NT4 startup and build number when you power it on and it will >> BSOD. >> >> BSOD on an airplane? That sounds kind of scary. >> > > Dunno if you're joking or not, but if you're serious then yes, NT starts > up with a nice bright blue screen and some gibberish, and to log on you > have to "CTL/ALT/DEL". Yes, really... I did not endear myself to my > Windoze-loving cow-orkers when I commented that a) it comes with its own > BSOD, and b) you have to reboot it to log on. If by BSOD you mean, "Blue Screen of Death", which was NT's crash-dump indicator then yes: I'm totally serious. I'd find a computer crashing on an airplane frightening (I mean, I'm imagining that it does something important). - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scj at yaccman.com Mon Feb 5 15:37:53 2018 From: scj at yaccman.com (Steve Johnson) Date: Sun, 04 Feb 2018 21:37:53 -0800 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: Message-ID: <59b04299e6f9cdd8c15f854030e1bacee3ed2ef3@webmail.yaccman.com> I have the greatest respect for Ken and Dennis, but I think their drive for simplicity was partly the result of the exceptionally tiny memories we all had to LIVE with.  You had to keep it simple or else it wouldn't fit!  Every feature you added took memory that might have been more usefully employed in another way.  So we all learned to worship Occam just to get things done.  I remember Dennis started out at one time to build a "real" optimizer for C, but by the time he had built the necessary data structures he had no room for the algorithms, or even enough data to be useful...  And, while writing yacc, I came in one day to discover that it would no longer compile.  Dennis had added the 'register' keyword and it turned out that one of my yacc functions had completely filled the symbol table.  I had to rewrite it to use one fewer variable name! When we got a VAX, especially when paging became available, it felt like being released from prison.  My experience is that the problems involved in making a program faster are often quite interesting and fun to work on.   But the problems making things fit in a small space are, IMHO, really deadly. Now things are a million times bigger and it feels like chaos has become the accepted model for how we live...  I see it particularly with the error messages I get from programs like Python and Git.  They seem to have two modes.  One mode gives a large amount of arcane data (e.g., a stack trace of 20 functions, none of which are documented) and then the error message is something like "insufficient frabulation" which is meaningless to me) or they appear to be quite user friendly and spell out the steps to make progress, but use words like "fix" and "resolve" that don't translate into anything concrete for a casual user. There are huge advantages in having a shared frame of reference and vocabulary, especially with co-workers.  But in our field things have become so fragmented...   This is particularly an issue with start ups -- people come from different environments and a lot of time is spent simply learning how to communicate with each other... Steve ----- Original Message ----- From: "Robert Brockway" To: "The Eunuchs Hysterical Society" Cc: Sent: Mon, 5 Feb 2018 10:06:58 +1000 (AEST) Subject: Re: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) . . . . This speaks to the "great man" theory of history. This posits that history would have been different if a great person had died before their moment in history. Eg, Winston Churchill was hit by a car when visiting New York City in the 1930s. He looked the wrong way before trying to cross the road. What if he had died? Would WW2 have turned out substantially differently? The alternative is to presume that a niche exists in to which a someone (or in this case an operating system) will step to become great. Using this alternative view, if Winston Churchill had died in the 1930s (or if UNIX had not been developed) an alternative would have filled that niche. Maybe we'd all be talking about TOPS20 now :) Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Mon Feb 5 15:53:26 2018 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Mon, 5 Feb 2018 16:53:26 +1100 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <59b04299e6f9cdd8c15f854030e1bacee3ed2ef3@webmail.yaccman.com> References: <59b04299e6f9cdd8c15f854030e1bacee3ed2ef3@webmail.yaccman.com> Message-ID: <20180205055326.GE30690@eureka.lemis.com> On Sunday, 4 February 2018 at 21:37:53 -0800, Steve Johnson wrote: > > There are huge advantages in having a shared frame of reference and > vocabulary, especially with co-workers.  But in our field things > have become so fragmented...   This is particularly an issue with > start ups -- people come from different environments and a lot of > time is spent simply learning how to communicate with each other... Amen. Greg -- Sent from my desktop computer. Finger grog at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From robert at timetraveller.org Mon Feb 5 16:57:52 2018 From: robert at timetraveller.org (Robert Brockway) Date: Mon, 5 Feb 2018 16:57:52 +1000 (AEST) Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <59b04299e6f9cdd8c15f854030e1bacee3ed2ef3@webmail.yaccman.com> References: <59b04299e6f9cdd8c15f854030e1bacee3ed2ef3@webmail.yaccman.com> Message-ID: On Sun, 4 Feb 2018, Steve Johnson wrote: > Now things are a million times bigger and it feels like chaos has > become the accepted model for how we live...  I see it particularly Absolutely. It seems like no regard is given to reducing complexity anymore. I think the current path is unsustainable. Increased complexity results in diminishing returns in development work eventually stifling innovation. Time and time again I see people choosing overly-complicated solutions when, in many cases, a small shell script would suffice. A few years ago I was left to manage (as head of the operations team) a monstrosity of an application that seemed to have been designed with the express purpose of using all available components of AWS. I was able to show that there was no deterministic manner in which the application could be cold booted. In the event that it needed to be restarted the operations team was left to bring the entire system up, watch for errors and cycle components in random order until the errors stopped. I'm not kidding. Fortunately that application has been sent to the bit bucket, never to bother anyone again. Here's my prediction: In a few years some people (most likely sales droids) will start talking about simplicity in IT and presenting it as an amazing new concept which no one has thought of before. This will be very similar to the way that "the cloud" is sold today. Cheers, Rob From ron at ronnatalie.com Mon Feb 5 20:49:47 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Mon, 5 Feb 2018 05:49:47 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <20180205055326.GE30690@eureka.lemis.com> References: <59b04299e6f9cdd8c15f854030e1bacee3ed2ef3@webmail.yaccman.com> <20180205055326.GE30690@eureka.lemis.com> Message-ID: <006601d39e6f$0a7a9300$1f6fb900$@ronnatalie.com> The joke was that the entire manual set for V6 UNIX and the kernel source print out would fit into a decent size briefcase, but this was remedied in later versions. From dot at dotat.at Mon Feb 5 23:13:51 2018 From: dot at dotat.at (Tony Finch) Date: Mon, 5 Feb 2018 13:13:51 +0000 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> Message-ID: Andy Kosela wrote: > > MINIX is dying too... Intel are now shipping MINIX as the embedded management OS on all their CPUs. Here's Andrew Tanenbaum's view: http://www.cs.vu.nl/~ast/intel/ Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Thames, Dover, Wight, Portland: Northeast 5 or 6. Slight or moderate. Wintry showers. Good. From ches at cheswick.com Mon Feb 5 23:48:00 2018 From: ches at cheswick.com (William Cheswick) Date: Mon, 5 Feb 2018 08:48:00 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> Message-ID: <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> > On 4Feb 2018, at 10:40 PM, Dan Cross wrote: > > If by BSOD you mean, "Blue Screen of Death", which was NT's crash-dump indicator then yes: I'm totally serious. I'd find a computer crashing on an airplane frightening (I mean, I'm imagining that it does something important). Save design would have the plane controls on a completely air-gapped network from the entertainment stuff. I was told that they don’t, because the captain needs to be able to stop the entertainment system during an announcement. I could build them a very simple gateway that transmits UDP packets in one direction only, that would meet this, and related needs. There have been hacks of the avionics reported from the entertainment network. It is scary, if true, and bush league IMO. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Tue Feb 6 00:31:37 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Mon, 5 Feb 2018 09:31:37 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> Message-ID: <009201d39e8e$0861d410$19257c30$@ronnatalie.com> The unit, the MX20 is really nothing more than a supporting instrument. It can bring up charts and other information but obviously there are backups. Indeed, it has given me the (upside down) blue screen of death. It’s also auto rebooted itself a few times for errors it caught (either watchdog timer or user-mode protection faults). The thing is kind of memory starved I think and really involved weather radar downloads tend to crash the thing. I’ve done some other stuff in planes, not related to flight systems. We built up a couple of image systems and one situation monitor, and later video gear. There’s rules for what goes in planes (at least for the military). We used some real time Linux variants at times. I did actually interview with GE right out of college to work on the 767 flight controls. Now that is some scary bit of software. There were two units, if one fails, the other takes over. If both fails, it writes the error code into non-volatile memory so it can be retrieved from the wreckage. -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Tue Feb 6 01:20:11 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 05 Feb 2018 10:20:11 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) Message-ID: <201802051520.w15FKBat001896@coolidge.cs.Dartmouth.EDU> > My experience is that the problems involved in making a program faster are > often quite interesting and fun to work on.  But the problems making things > fit in a small space are, IMHO, really deadly. First make things "as simple as possible, but no simpler" (Einstein). Ken and Dennis not only cut out fat, they also found generalizations that combined traditionally disparate features, so the new whole was smaller (and more comprehensible) than the sum of the old parts. The going gets tough in the presence of constraints on space or time. Steve's perception, I think, is colored by the experience of facing hard limits on space, but not on time. Describing one complication of hard time constraints, John Kelly used to say that the Packard Bell 250 was "the only machine I ever used where you transfer to a time of day rather than a memory location". (The delay- line memory had two instruction formats: one was operation + address-of- next-instruction, the other was just the operation--the next instruction being whatever came out of the delay line when the operation ended. The latter mode minimized both execution time and code space, but the attention one had to pay to time was, to borrow Steve's phrase, "really deadly".) Design tradeoffs for efficiency pose an almost moral conundrum: whether to make things fast or make them easy. For example, the classic Unix kernel typically did table lookup by linear search, whereas Linux (when I last looked) typically used binary search. The price of Linux's choice is that one must take care to keep the tables sorted. Heavy discipline has to be imposed on making entries and deletions. Doug From bakul at bitblocks.com Tue Feb 6 01:45:14 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 05 Feb 2018 07:45:14 -0800 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: Your message of "Mon, 05 Feb 2018 13:13:51 +0000." References: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> Message-ID: <20180205154529.81037156E812@mail.bitblocks.com> On Mon, 05 Feb 2018 13:13:51 +0000 Tony Finch wrote: Tony Finch writes: > Andy Kosela wrote: > > > > MINIX is dying too... > > Intel are now shipping MINIX as the embedded management OS on all their > CPUs. Here's Andrew Tanenbaum's view: http://www.cs.vu.nl/~ast/intel/ minix3 useland is basically the NetBSD userland. I wonder if any of that is running on the IME. From clemc at ccc.com Tue Feb 6 02:19:56 2018 From: clemc at ccc.com (Clem Cole) Date: Mon, 5 Feb 2018 11:19:56 -0500 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: <20180205154529.81037156E812@mail.bitblocks.com> References: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> <20180205154529.81037156E812@mail.bitblocks.com> Message-ID: Note: I speak for me, not Intel and please don't blame me for the choices as* I have had nothing to do with it.*.. On Mon, Feb 5, 2018 at 10:45 AM, Bakul Shah wrote: > On Mon, 05 Feb 2018 13:13:51 +0000 Tony Finch wrote: > Tony Finch writes: > > Intel are now shipping MINIX as the embedded management OS on all their > > CPUs. Here's Andrew Tanenbaum's view: http://www.cs.vu.nl/~ast/intel/ > > minix3 useland is basically the NetBSD userland. > I wonder if any of that is running on the IME. > ​I can not speak authoritatively (so in some ways this reply might be seen as worthless), but I do not believe so. As I understand it (i.e.when I asked about it with some of the CPU/BIOS types), the >>modified<< minix kernel is basically an small embedded OS​ to support locally created custom code for the management engine user code. There is not much there. The while idea was an 'OS' to support the kinds of functions the management engine needed -- from low level HW/device support to a networking stack -- 'supporting' a complex application that could be written and debugged outside of the production environment and the run 'as it' in the 'rom.' Of course as our friends in the security side of the business point out, the more that is there, the larger the attack surface, but I think the idea is was to keep it small, light and simple and minix won out. Actually, what's cool IMO is the choice of minix, often in my career, I have seen those sorts of folks want to write their own and that to me a more frightening. At least this means more people are likely to have hacked on it >>before<< Intel took it in house [although I believe that action wrankels many in the FOSS community - including a few on this list - who have expressed that they think that the IME code needs to be 'published and free to be inspected']. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Tue Feb 6 03:41:47 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 5 Feb 2018 09:41:47 -0800 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> <20180205154529.81037156E812@mail.bitblocks.com> Message-ID: <68F800F7-967B-448D-8665-88C71E345C86@bitblocks.com> On Feb 5, 2018, at 8:19 AM, Clem Cole wrote: > > Note: I speak for me, not Intel and please don't blame me for the choices as I have had nothing to do with it... > > On Mon, Feb 5, 2018 at 10:45 AM, Bakul Shah wrote: > On Mon, 05 Feb 2018 13:13:51 +0000 Tony Finch wrote: > Tony Finch writes: > > Intel are now shipping MINIX as the embedded management OS on all their > > CPUs. Here's Andrew Tanenbaum's view: http://www.cs.vu.nl/~ast/intel/ > > minix3 useland is basically the NetBSD userland. > I wonder if any of that is running on the IME. > ​I can not speak authoritatively (so in some ways this reply might be seen as worthless), but I do not believe so. As I understand it (i.e.when I asked about it with some of the CPU/BIOS types), the >>modified<< minix kernel is basically an small embedded OS​ to support locally created custom code for the management engine user code. There is not much there. The while idea was an 'OS' to support the kinds of functions the management engine needed -- from low level HW/device support to a networking stack -- 'supporting' a complex application that could be written and debugged outside of the production environment and the run 'as it' in the 'rom.' > > Of course as our friends in the security side of the business point out, the more that is there, the larger the attack surface, but I think the idea is was to keep it small, light and simple and minix won out. Actually, what's cool IMO is the choice of minix, often in my career, I have seen those sorts of folks want to write their own and that to me a more frightening. At least this means more people are likely to have hacked on it >>before<< Intel took it in house [although I believe that action wrankels many in the FOSS community - including a few on this list - who have expressed that they think that the IME code needs to be 'published and free to be inspected']. Makes sense. Thanks! World's most complex processor in service of world's most complex OSes being managed by a microkernel. Sad. Ironic. From paul.winalski at gmail.com Tue Feb 6 05:43:33 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 5 Feb 2018 14:43:33 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: Message-ID: On 2/4/18, Wesley Parish wrote: > From what little I know, Dave Cutler was wanting to work on a VMS > (Next Generation) at DEC, but couldn't manage to get management to > agree, so when the possibility of doing a VMS (Next Gen) at Microsoft > came up, he jumped for it. By the mid-to-late 1980s, advances in CPU technology tilted the performance field in favor of RISC architectures vs. complicated CISC such as VAX or x86. Both DEC and Intel were looking for alternatives. Intel eventually settled on a VLIW architecture that became Itanium. DEC's first attempt at a VAX successor was a RISC architecture called PRISM. It was developed by Dave Cutler's team in Seattle. On the software side, they were working on an OS called MICA. It was to be a successor to the VAXeln microkernel-based realtime system and was to have both VMS and Unix kernel interfaces (personality modules). Someone (Gordon Bell, I think) once said of DEC's decision making process, "any decision worth making once is worth making again". In typical DEC fashion, another RISC architecture was designed by DEC's east coast engineering team. This architecture eventually ended up being called Alpha. The east coast won the political battle. PRISM and MICA were cancelled. The idea of a single kernel with multiple OS personalities was dropped; VMS and Unix were ported separately to Alpha. After PRISM was cancelled, Dave Cutler left DEC and went to Microsoft as architect for their new OS. Under the covers, the original Windows NT looked a lot like MICA, VAXeln, and VMS before it. Not surprising since they shared the same designer. Like MICA, Windows NT was microkernel-based, with OS personality modules layered on top. There were two of these originally: Win32 and POSIX. Microsoft and Intel were having a little lover's quarrel at the time--Intel didn't like Microsoft's forays into the hardware side of things with Xbox and the like; Microsoft wasn't pleased by Intel doing its own compilers, etc. This led to Microsoft porting Windows NT to both PowerPC and Alpha. Neither port caught on in the marketplace. -Paul W. From michael at kjorling.se Tue Feb 6 07:19:23 2018 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Mon, 5 Feb 2018 21:19:23 +0000 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: Message-ID: <20180205211923.GO13685@h-174-65.A328.priv.bahnhof.se> On 5 Feb 2018 14:43 -0500, from paul.winalski at gmail.com (Paul Winalski): > This architecture eventually ended up > being called Alpha. The east coast won the political battle. PRISM > and MICA were cancelled. Out of curiosity, when was this? Obviously it's later than "the mid-to-late 1980s", but more precisely than that? > After PRISM was cancelled, Dave Cutler left DEC and went to Microsoft > as architect for their new OS. Under the covers, the original Windows > NT looked a lot like MICA, VAXeln, and VMS before it. Not surprising > since they shared the same designer. Like MICA, Windows NT was > microkernel-based, with OS personality modules layered on top. There > were two of these originally: Win32 and POSIX. Microsoft and Intel > were having a little lover's quarrel at the time--Intel didn't like > Microsoft's forays into the hardware side of things with Xbox and the > like; Microsoft wasn't pleased by Intel doing its own compilers, etc. > This led to Microsoft porting Windows NT to both PowerPC and Alpha. > Neither port caught on in the marketplace. Honestly, I think you've got the timeline mixed up. Wikipedia puts the Xbox introduction in 2001, which sounds about right to me. Designing the core of the original Windows NT would be about a decade before that, maybe a little earlier still, around 1990-ish. Around 1990 in terms of game consoles was the Super Nintendo and Sega Mega Drive (A.K.A. Sega Genesis), which the original Xbox was definitely _not_ contemporary with. I _think_ (but could certainly be mistaken about this) that Windows 2000 ("NT 5") was the release that dropped several non-Intel architectures; I'm _almost_ certain that NT 4 shipped with a bunch of versions on the same installation CD, and believe that those included both PowerPC and Alpha. Also, I think the original NT "personality modules" included OS/2 (but without Presentation Manager, the OS/2 GUI, so it only supported text-mode OS/2 applications). The way I recall it, the OS/2 module was a first-class citizen in NT 3.x, relegated to second-class citizen status in NT 4.0 (it was there, but you had to jump through some hoops to get it installed), and dropped with 5.0/2000. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “The most dangerous thought that you can have as a creative person is to think you know what you’re doing.” (Bret Victor) From dave at horsfall.org Tue Feb 6 07:51:38 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 6 Feb 2018 08:51:38 +1100 (EST) Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> Message-ID: On Mon, 5 Feb 2018, William Cheswick wrote: > There have been hacks of the avionics reported from the entertainment > network.  It is scary, if true, and bush league IMO. There's certainly been demonstrations of vehicles being taken over via the entertainment system; why the stereo needs to talk to the engine computer I'll never know... I know, wind up the volume the faster you go etc, but surely it ought to be one-way? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From ron at ronnatalie.com Tue Feb 6 07:57:55 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Mon, 5 Feb 2018 16:57:55 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> Message-ID: <013001d39ecc$614dc500$23e94f00$@ronnatalie.com> I've not seen that in an airplane. I'd like a cite. There's certainly issues with the computers in some of the later things (like my Volt which is just a rolling computer. The transmission lever and the gas pedals are just inputs to the computer. They don't directly control things. Even the first bit of brake travel is purely a software input). -----Original Message----- From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Dave Horsfall Sent: Monday, February 5, 2018 4:52 PM To: The Eunuchs Hysterical Society Subject: Re: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) On Mon, 5 Feb 2018, William Cheswick wrote: > There have been hacks of the avionics reported from the entertainment > network. It is scary, if true, and bush league IMO. There's certainly been demonstrations of vehicles being taken over via the entertainment system; why the stereo needs to talk to the engine computer I'll never know... I know, wind up the volume the faster you go etc, but surely it ought to be one-way? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From akosela at andykosela.com Tue Feb 6 07:58:34 2018 From: akosela at andykosela.com (Andy Kosela) Date: Mon, 5 Feb 2018 15:58:34 -0600 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> Message-ID: On Monday, February 5, 2018, Tony Finch wrote: > Andy Kosela wrote: > > > > MINIX is dying too... > > Intel are now shipping MINIX as the embedded management OS on all their > CPUs. Here's Andrew Tanenbaum's view: http://www.cs.vu.nl/~ast/intel/ > > I am well aware of that, but ironically Intel did not even informed Andrew about it... No one in the MINIX community was aware of that. How long ago have you checked how busy are MINIX git commits... there has been literally none since at least a few months. It is practically a dead project as far as new development is concerned. Plus it never really drew attention of really influential luminaries from the open source world... there is no Theo or Alan Cox amongst MINIX kernel hackers. Most of the core members were always coming from VU in Amsterdam (where Andrew teaches). I would love to see MINIX succeed, but it is just not happening and it has been 10 years since the release of MINIX 3. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Tue Feb 6 08:31:27 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 5 Feb 2018 15:31:27 -0700 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <013001d39ecc$614dc500$23e94f00$@ronnatalie.com> References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> <013001d39ecc$614dc500$23e94f00$@ronnatalie.com> Message-ID: On 02/05/2018 02:57 PM, Ron Natalie wrote: > I've not seen that in an airplane. I'd like a cite. I don't have any citations. I do remember in the last few years hearing about two distinct events: 1) A passenger purportedly took over an airplane while while in flight momentarily. I vaguely remember something about altering thrust to one engine for a brief time frame before returning it to where it was, and then doing the same with the other engine. 2) A control research condition by authorities, FBI, FAA, I don't know, reproducing #1 above. I believe both seemed plausible from what I remember. Sorry, I don't have anything more specific. Someone with better search skills than me can probably turn up news articles on both events. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From dave at horsfall.org Tue Feb 6 08:47:00 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 6 Feb 2018 09:47:00 +1100 (EST) Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> Message-ID: On Mon, 5 Feb 2018, Andy Kosela wrote: > I am well aware of that, but ironically Intel did not even informed > Andrew about it... No one in the MINIX community was aware of that. And AndrewT was reportedly pissed off when he found that the ME could actually snoop on (and respond to) network traffic etc without the OS even being aware of it; apparently the ME hooks into the NIC... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From toby at telegraphics.com.au Tue Feb 6 08:52:39 2018 From: toby at telegraphics.com.au (Toby Thain) Date: Mon, 5 Feb 2018 17:52:39 -0500 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> Message-ID: On 2018-02-05 5:47 PM, Dave Horsfall wrote: > On Mon, 5 Feb 2018, Andy Kosela wrote: > >> I am well aware of that, but ironically Intel did not even informed >> Andrew about it... No one in the MINIX community was aware of that. > > And AndrewT was reportedly pissed off when he found that the ME could > actually snoop on (and respond to) network traffic etc without the OS > even being aware of it; apparently the ME hooks into the NIC... > If he thought that was *important* surely he'd have mentioned it in his otherwise self-aggrandising blog post? --T From crossd at gmail.com Tue Feb 6 08:54:57 2018 From: crossd at gmail.com (Dan Cross) Date: Mon, 5 Feb 2018 17:54:57 -0500 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> Message-ID: On Mon, Feb 5, 2018 at 5:47 PM, Dave Horsfall wrote: > On Mon, 5 Feb 2018, Andy Kosela wrote: > > I am well aware of that, but ironically Intel did not even informed Andrew >> about it... No one in the MINIX community was aware of that. >> > > And AndrewT was reportedly pissed off when he found that the ME could > actually snoop on (and respond to) network traffic etc without the OS even > being aware of it; apparently the ME hooks into the NIC... Speaking of things like that...This just landed in my inbox: http://www.mymtaalerts.com/m?78F2F The metrocard vending machines in the NYC subway are little PCs. I could swear I've seen either an OS/2, Windows, or Linux startup sequence on one or more of them before (maybe all three). Anyway, what do you want to bet that the MTA is making people go around with media and manually install updates for Spectre/Meltdown across the transit system? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.unix.pro at gmail.com Tue Feb 6 09:10:05 2018 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Mon, 5 Feb 2018 15:10:05 -0800 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <013001d39ecc$614dc500$23e94f00$@ronnatalie.com> References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> <013001d39ecc$614dc500$23e94f00$@ronnatalie.com> Message-ID: On Mon, Feb 5, 2018 at 1:57 PM, Ron Natalie wrote: > I've not seen that in an airplane. I'd like a cite. > comp.risks: Interconnection of Three Previously Separated Networks in Boeing 737 Joe Loughry Wed, 11 Jun 2014 19:06:37 +0000 "Special Conditions" refers to the fact that certification rules haven't kept pace. The three network domains (aircraft control, operator information, and passenger entertainment) used to run on physically separate wires, primarily for historical reasons, but having obvious engineering benefits as well. In recent years, first the computers and now the networks have migrated to virtual machine separation on shared hardware, for the equally obvious space, weight, and power savings. The *Federal Register* rule published this week mentions interconnection between at least two of the three domains; I hope they paid close attention to UC Berkeley's "Experimental Security Analysis of a Modern Automobile" (2010). > https://federalregister.gov/a/2014-13244 > Source: "Special Conditions: The Boeing Company, Models 737-700, -700C, -800, -900ER, -7, -8, and -9 Series Airplanes; Airplane Electronic Systems Security Protection From Unauthorized External Access" [*Federal Register* vol. 79, no. 109, June 6, 2014, pp. 32640-32641]. > Joe Loughry, Doctoral Student in the Department of Computer Science St Cross College, Oxford and Banned Researcher Commandeered a Plane (Kim Zetter) > > "Peter G. Neumann" > > Fri, 15 May 2015 21:12:42 PDT > > (Courtesy of Dan Farmer: Fly the unfriendly skies?) > > >> Kim Zetter, Feds Say That Banned Researcher Commandeered a Plane > > http://www.wired.com/2015/05/feds-say-banned-researcher-commandeered-plane/ > > >> A security researcher kicked off a United Airlines flight last month after > > tweeting about security vulnerabilities in its system had previously taken > > control of an airplane and caused it to briefly fly sideways, according to > > an application for a search warrant filed by an FBI agent. > > >> Chris Roberts, a security researcher with One World Labs, told the FBI >> agent > > during an interview in February that he had hacked the in-flight > > entertainment system, or IFE, on an airplane and overwrote code on the > > plane's Thrust Management Computer while aboard the flight. He was able to > > issue a climb command and make the plane briefly change course, the >> document > > states. > > >> FBI Special Agent Mark Hurley: “He stated that he thereby caused one of >> the > > airplane engines to climb resulting in a lateral or sideways movement of >> the > > plane during one of these flights, He also stated that he used Vortex > > software after comprising/exploiting or hacking the airplane's networks. He > > used the software to monitor traffic from the cockpit system.'' > > >> Hurley filed the search warrant application last month after Roberts was > > removed from a United Airlines flight from Chicago to Syracuse, New York, > > because he published a facetious tweet suggesting he might hack into the > > plane's network. Upon landing in Syracuse, two FBI agents and two local > > police officers escorted him from the plane and interrogated him for >> several > > hours. They also seized two laptop computers and several hard drives and >> USB > > sticks. Although the agents did not have a warrant when they seized the > > devices, they told Roberts a warrant was pending. > > >> A media outlet in Canada obtained the application for the warrant today >> and > > published it online. > > >> >> http://aptn.ca/news/2015/05/15/hacker-told-f-b-made-plane-fly-sideways-cracking-entertainment-system/ > > >> The information outlined in the warrant application reveals a far more > > serious situation than Roberts has previously disclosed. > > >> Roberts had previously told WIRED that he caused a plane to climb during a > > simulated test on a virtual environment he and a colleague created, but he > > insisted that he had not interfered with the operation of a plane while in > > flight. > > >> He told WIRED that he did access in-flight networks about 15 times during > > various flights but had not done anything beyond explore the networks and > > observe data traffic crossing them. According to the FBI affidavit, >> however, > > he mentioned this to agents as well last February but also added that he >> had > > briefly commandeered a plane during one of those flights. He told the FBI >> he > > accessed the flights in which he accessed the in-flight networks more than >> a > > dozen times occurred between 2011 and 2014, but the affidavit does not > > indicate exactly which flight he allegedly caused to turn to the side. > > >> He obtained physical access to the networks through the Seat Electronic >> Box, > > or SEB. These are installed two to a row, on each side of the aisle under > > passenger seats, on certain planes. After removing the cover to the SEB by > > `wiggling and Squeezing the box', Roberts told agents he attached a Cat6 > > ethernet cable, with a modified connector, to the box and to his laptop and > > then used default IDs and passwords to gain access to the inflight > > entertainment system. Once on that network, he was able to gain access to > > other systems on the planes. > > >> Reaction in the security community to the new revelations in the affidavit > > have been harsh. Although Roberts hasn't been charged yet with any > > crime, and there are questions about whether his actions really did cause > > the plane to list or he simply thought they did, a number of security > > researchers have expressed shock that he attempted to tamper with a plane > > during a flight. > > >> “I find it really hard to believe but if that is the case he deserves >> going > > to jail,'' wrote Jaime Blasco, director of AlienVault Labs in a tweet. > > >> Alex Stamos, chief information security officer of Yahoo, wrote in a >> tweet, > > “You cannot promote the (true) idea that security research benefits > > humanity while defending research that endangered hundreds of innocents.'' > > >> [Wonderful long item truncated for RISKS. PGN] > > > -- Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Tue Feb 6 09:16:38 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 5 Feb 2018 18:16:38 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> <013001d39ecc$614dc500$23e94f00$@ronnatalie.com> Message-ID: Literally, googled "hacker controlled plane engine" https://www.cnn.com/2015/05/17/us/fbi-hacker-flight-computer-systems/index.html On 2/5/2018 5:31 PM, Grant Taylor via TUHS wrote: > Someone with better search skills than me can probably turn up news > articles on both events. From lyndon at orthanc.ca Tue Feb 6 09:18:09 2018 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 5 Feb 2018 15:18:09 -0800 (PST) Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> Message-ID: > Save design would have the plane controls on a completely air-gapped > network from the entertainment stuff. I was told that they don?t, > because the captain needs to be able to stop the entertainment system > during an announcement. I could build them a very simple gateway that > transmits UDP packets in one direction only, that would meet this, and > related needs. This doesn't need a network, just a pair of GPIO pins -- an output pin on the avionics system, and an input pin on the entertainment system. From krewat at kilonet.net Tue Feb 6 09:20:58 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 5 Feb 2018 18:20:58 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <013001d39ecc$614dc500$23e94f00$@ronnatalie.com> References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> <013001d39ecc$614dc500$23e94f00$@ronnatalie.com> Message-ID: <5a838d87-4acb-e2f4-f09e-458d6c5eae49@kilonet.net> The CAN network is bi-directional, and I don't think it has any security. So any node on the CAN can read-write whatever the heck it wants to. Plug in an OBD-II device, and using the right software (like Forscan) you can read/write all sorts of locations in the body-control module, flash new software into the PCM (powertrain control module), etc. I suspect that if you have the entertainment system that has the ability to read PIDs in the PCM, for example, road speed, that same interface could be used to write values as well. My 2013 Taurus SHO came with Sync 2 - which ran Windows CE. Thankfully, it wasn't a "server" and WiFi wasn't enabled. Now my 2016 Taurus SHO has Sync 3 running QNX. I am not amused ;) On 2/5/2018 4:57 PM, Ron Natalie wrote: > There's certainly been demonstrations of vehicles being taken over via the entertainment system; why the stereo needs to talk to the engine computer I'll never know... I know, wind up the volume the faster you go etc, but surely it ought to be one-way? From dave at horsfall.org Tue Feb 6 09:28:27 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 6 Feb 2018 10:28:27 +1100 (EST) Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <5a838d87-4acb-e2f4-f09e-458d6c5eae49@kilonet.net> References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> <013001d39ecc$614dc500$23e94f00$@ronnatalie.com> <5a838d87-4acb-e2f4-f09e-458d6c5eae49@kilonet.net> Message-ID: On Mon, 5 Feb 2018, Arthur Krewat wrote: > On 2/5/2018 4:57 PM, Ron Natalie wrote: >> There's certainly been demonstrations of vehicles being taken over via >> the entertainment system; why the stereo needs to talk to the engine >> computer I'll never know... I know, wind up the volume the faster you >> go etc, but surely it ought to be one-way? Umm, I wrote that, not Ron... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From krewat at kilonet.net Tue Feb 6 09:36:41 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 5 Feb 2018 18:36:41 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> <013001d39ecc$614dc500$23e94f00$@ronnatalie.com> <5a838d87-4acb-e2f4-f09e-458d6c5eae49@kilonet.net> Message-ID: Sorry, Thunderbird strikes again. I highlighted the text to include, and it didn't put the correct address on the quote. My apologies. On 2/5/2018 6:28 PM, Dave Horsfall wrote: > On Mon, 5 Feb 2018, Arthur Krewat wrote: > >> On 2/5/2018 4:57 PM, Ron Natalie wrote: >>> There's certainly been demonstrations of vehicles being taken over >>> via the entertainment system; why the stereo needs to talk to the >>> engine computer I'll never know...  I know, wind up the volume the >>> faster you go etc, but surely it ought to be one-way? > > Umm, I wrote that, not Ron... > From gtaylor at tnetconsulting.net Tue Feb 6 09:49:16 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 5 Feb 2018 16:49:16 -0700 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> <013001d39ecc$614dc500$23e94f00$@ronnatalie.com> Message-ID: On 02/05/2018 04:16 PM, Arthur Krewat wrote: > Literally, googled "hacker controlled plane engine" I tried that as well. I was getting to many "A Pope" type collisions (ala "The Da Vinci Code"). I have no idea what I've done to my Google search results on this machine. I think it's time to reset them. > https://www.cnn.com/2015/05/17/us/fbi-hacker-flight-computer-systems/index.html Yep, that's the first one that I was talking about. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From ggm at algebras.org Tue Feb 6 09:52:42 2018 From: ggm at algebras.org (George Michaelson) Date: Tue, 6 Feb 2018 09:52:42 +1000 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> <013001d39ecc$614dc500$23e94f00$@ronnatalie.com> <5a838d87-4acb-e2f4-f09e-458d6c5eae49@kilonet.net> Message-ID: My understanding is that FAA rated 'ethernet' switches for aircraft are modified ASICs which do TDM. You program in slot reservations, and this is used to give bounded-time delivery guarantees for flight critical stuff. Cheaper to make by modifying existing stuff, the physical and link layer code is almost identical, its just put into a timeslot regime. Its fully isochronous for the flight control and its best effort delivery for the entertainment. So, when people talk about the entertainment being 'isolated' its not opto-isolated and its not airgap discrete switch isolated: the TDM bitfield excludes the customers from talking in the timeslots for the flight control logic. I think the imputed hack, was to "see" the flight control sequences because you can probably fake out read-side, and get passive view of them if you can make the ports broadcast-receive. I am really unconvinced anyone succeeded in write-mode into this model. Not that it couldn't happen and not that I believe I'm smarted than bad people: I just thing the descriptions have the quality of urban myth right now. On Tue, Feb 6, 2018 at 9:36 AM, Arthur Krewat wrote: > Sorry, Thunderbird strikes again. I highlighted the text to include, and it > didn't put the correct address on the quote. > > My apologies. > > > On 2/5/2018 6:28 PM, Dave Horsfall wrote: >> >> On Mon, 5 Feb 2018, Arthur Krewat wrote: >> >>> On 2/5/2018 4:57 PM, Ron Natalie wrote: >>>> >>>> There's certainly been demonstrations of vehicles being taken over via >>>> the entertainment system; why the stereo needs to talk to the engine >>>> computer I'll never know... I know, wind up the volume the faster you go >>>> etc, but surely it ought to be one-way? >> >> >> Umm, I wrote that, not Ron... >> > From usotsuki at buric.co Tue Feb 6 10:37:21 2018 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 5 Feb 2018 19:37:21 -0500 (EST) Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <20180205211923.GO13685@h-174-65.A328.priv.bahnhof.se> References: <20180205211923.GO13685@h-174-65.A328.priv.bahnhof.se> Message-ID: On Mon, 5 Feb 2018, Michael Kjörling wrote: > Honestly, I think you've got the timeline mixed up. Wikipedia puts the > Xbox introduction in 2001, which sounds about right to me. Designing > the core of the original Windows NT would be about a decade before > that, maybe a little earlier still, around 1990-ish. Around 1990 in > terms of game consoles was the Super Nintendo and Sega Mega Drive > (A.K.A. Sega Genesis), which the original Xbox was definitely _not_ > contemporary with. I _think_ (but could certainly be mistaken about > this) that Windows 2000 ("NT 5") was the release that dropped several > non-Intel architectures; I'm _almost_ certain that NT 4 shipped with a > bunch of versions on the same installation CD, and believe that those > included both PowerPC and Alpha. Pretty sure at least PPC was supported by NT4, but don't quote me. > Also, I think the original NT "personality modules" included OS/2 (but > without Presentation Manager, the OS/2 GUI, so it only supported > text-mode OS/2 applications). The way I recall it, the OS/2 module was > a first-class citizen in NT 3.x, relegated to second-class citizen > status in NT 4.0 (it was there, but you had to jump through some hoops > to get it installed), and dropped with 5.0/2000. 3.51 and 4.0, at least, both had a paid add-on for PM application support. -uso. From imp at bsdimp.com Tue Feb 6 10:45:41 2018 From: imp at bsdimp.com (Warner Losh) Date: Mon, 5 Feb 2018 17:45:41 -0700 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180205211923.GO13685@h-174-65.A328.priv.bahnhof.se> Message-ID: On Mon, Feb 5, 2018 at 5:37 PM, Steve Nickolas wrote: > On Mon, 5 Feb 2018, Michael Kjörling wrote: > > Honestly, I think you've got the timeline mixed up. Wikipedia puts the >> Xbox introduction in 2001, which sounds about right to me. Designing >> the core of the original Windows NT would be about a decade before >> that, maybe a little earlier still, around 1990-ish. Around 1990 in >> terms of game consoles was the Super Nintendo and Sega Mega Drive >> (A.K.A. Sega Genesis), which the original Xbox was definitely _not_ >> contemporary with. I _think_ (but could certainly be mistaken about >> this) that Windows 2000 ("NT 5") was the release that dropped several >> non-Intel architectures; I'm _almost_ certain that NT 4 shipped with a >> bunch of versions on the same installation CD, and believe that those >> included both PowerPC and Alpha. >> > > Pretty sure at least PPC was supported by NT4, but don't quote me. > > Also, I think the original NT "personality modules" included OS/2 (but >> without Presentation Manager, the OS/2 GUI, so it only supported >> text-mode OS/2 applications). The way I recall it, the OS/2 module was >> a first-class citizen in NT 3.x, relegated to second-class citizen >> status in NT 4.0 (it was there, but you had to jump through some hoops >> to get it installed), and dropped with 5.0/2000. >> > > 3.51 and 4.0, at least, both had a paid add-on for PM application support. > 3.51 had MIPS support too, though that appears to have been dropped in 4.0. I don't have my NT disks anymore to go check on that detail. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Tue Feb 6 11:44:18 2018 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 6 Feb 2018 11:44:18 +1000 Subject: [TUHS] And .. a reminder of the charter of the TUHS list Message-ID: <20180206014418.GA943@minnie.tuhs.org> TUHS: The Unix Heritage Society So topics that relate to Unix, its development, old Unix systems, Unix anecdotes please! Thanks, Warren From tytso at mit.edu Tue Feb 6 14:58:22 2018 From: tytso at mit.edu (Theodore Ts'o) Date: Mon, 5 Feb 2018 23:58:22 -0500 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> Message-ID: <20180206045822.GA17801@thunk.org> On Mon, Feb 05, 2018 at 05:54:57PM -0500, Dan Cross wrote: > Speaking of things like that...This just landed in my inbox: > > http://www.mymtaalerts.com/m?78F2F > > The metrocard vending machines in the NYC subway are little PCs. I could > swear I've seen either an OS/2, Windows, or Linux startup sequence on one > or more of them before (maybe all three). > Anyway, what do you want to bet that the MTA is making people go around > with media and manually install updates for Spectre/Meltdown across the > transit system? No bet. How much do you want to bet the MTA isn't bothering to update gazillions of *other* already published and known security holes that were zero days years ago? Holes that are probably *Way* easier to exploit than those using Spectre/Meltdown? If it's anything like the MBTA in Massachusetts their security is limited to trying to sue graduate students[1] in an attempt to impose prior restraint on their research (and including the presentation[2] as an exhibit on the lawsuit and letting it be published on the court's website for all to see?). [1] https://en.wikipedia.org/wiki/Massachusetts_Bay_Transportation_Authority_v._Anderson [2] http://tech.mit.edu/V128/N30/subway/Defcon_Presentation.pdf - Ted From gregg.drwho8 at gmail.com Tue Feb 6 15:05:16 2018 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Tue, 6 Feb 2018 00:05:16 -0500 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: <20180206045822.GA17801@thunk.org> References: <184378368.23385.1517692373907.JavaMail.tomcat@india-live-be03> <20180206045822.GA17801@thunk.org> Message-ID: Hello! In NYC the machines who sell MTA transit cards and refill them are running Windows Embedded. And not the most up to date version. I've watched them cause the classic BSOD more then once, and sometimes worse. The actual hardware that's delivers the cards and the single use ones are running something else, and appear to be VME based. The whole thing is a revolting kludge that's asking for trouble. Oh and Dan Cross? Thank you for your service to this country, again and again. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Mon, Feb 5, 2018 at 11:58 PM, Theodore Ts'o wrote: > On Mon, Feb 05, 2018 at 05:54:57PM -0500, Dan Cross wrote: >> Speaking of things like that...This just landed in my inbox: >> >> http://www.mymtaalerts.com/m?78F2F >> >> The metrocard vending machines in the NYC subway are little PCs. I could >> swear I've seen either an OS/2, Windows, or Linux startup sequence on one >> or more of them before (maybe all three). >> Anyway, what do you want to bet that the MTA is making people go around >> with media and manually install updates for Spectre/Meltdown across the >> transit system? > > No bet. How much do you want to bet the MTA isn't bothering to update > gazillions of *other* already published and known security holes that > were zero days years ago? Holes that are probably *Way* easier to > exploit than those using Spectre/Meltdown? > > If it's anything like the MBTA in Massachusetts their security is > limited to trying to sue graduate students[1] in an attempt to impose > prior restraint on their research (and including the presentation[2] > as an exhibit on the lawsuit and letting it be published on the > court's website for all to see?). > > [1] https://en.wikipedia.org/wiki/Massachusetts_Bay_Transportation_Authority_v._Anderson > [2] http://tech.mit.edu/V128/N30/subway/Defcon_Presentation.pdf > > - Ted From wobblygong at gmail.com Tue Feb 6 19:14:04 2018 From: wobblygong at gmail.com (Wesley Parish) Date: Tue, 6 Feb 2018 22:14:04 +1300 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180205211923.GO13685@h-174-65.A328.priv.bahnhof.se> Message-ID: On 2/6/18, Steve Nickolas wrote: > On Mon, 5 Feb 2018, Michael Kjörling wrote: > >> Honestly, I think you've got the timeline mixed up. Wikipedia puts the >> Xbox introduction in 2001, which sounds about right to me. Designing >> the core of the original Windows NT would be about a decade before >> that, maybe a little earlier still, around 1990-ish. Around 1990 in >> terms of game consoles was the Super Nintendo and Sega Mega Drive >> (A.K.A. Sega Genesis), which the original Xbox was definitely _not_ >> contemporary with. I _think_ (but could certainly be mistaken about >> this) that Windows 2000 ("NT 5") was the release that dropped several >> non-Intel architectures; I'm _almost_ certain that NT 4 shipped with a >> bunch of versions on the same installation CD, and believe that those >> included both PowerPC and Alpha. > > Pretty sure at least PPC was supported by NT4, but don't quote me. About a decade ago I had a look at fooling around with NT 4.0 on the PearPC emulator, but didn't have the time. IIRC, WinNT 4.0 Workstation CDROMs came with at least PowerPC and MIPS versions; I'm not sure about the Alpha. Wesley Parish > >> Also, I think the original NT "personality modules" included OS/2 (but >> without Presentation Manager, the OS/2 GUI, so it only supported >> text-mode OS/2 applications). The way I recall it, the OS/2 module was >> a first-class citizen in NT 3.x, relegated to second-class citizen >> status in NT 4.0 (it was there, but you had to jump through some hoops >> to get it installed), and dropped with 5.0/2000. > > 3.51 and 4.0, at least, both had a paid add-on for PM application support. > > -uso. From steffen at sdaoden.eu Wed Feb 7 00:52:55 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 06 Feb 2018 15:52:55 +0100 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> Message-ID: <20180206145255.lBpbv%steffen@sdaoden.eu> Dave Horsfall wrote: |On Mon, 5 Feb 2018, William Cheswick wrote: |> There have been hacks of the avionics reported from the entertainment |> network.  It is scary, if true, and bush league IMO. | |There's certainly been demonstrations of vehicles being taken over via the |entertainment system; why the stereo needs to talk to the engine computer I have seen fly-by i think two CVE announcements for BMW. I can only find one format-string related one via search engine. |I'll never know... I know, wind up the volume the faster you go etc, but |surely it ought to be one-way? Truly hate that; that job used to be fun with craftsmanship rather than plugging in a service computer and reading error logs. I never will forget that film about Rolls Royce in the 80s: one man, his hammer, a small table with tea right beside the working place, and three days of work to get a single fender. I wonder how this will end up when 3-D printers can produce furniture, clothes, houses and all that. No real work to be done anymore, and i do not like Harley-Davidson for having some real work to do. (New Moto Guzzi also have CAN-bus i think.) --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) From rminnich at gmail.com Wed Feb 7 01:56:41 2018 From: rminnich at gmail.com (ron minnich) Date: Tue, 06 Feb 2018 15:56:41 +0000 Subject: [TUHS] Device special files Message-ID: these were in by the time I can along but I was wondering when they got it. They've also always felt a bit like a thing that did not fit to me. I'm pretty sure I was not alone, given that the Unix authors worked out a way to get rid of them in later efforts. I know what came after, in Plan 9; what came before, in Unix, that led to special files? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Wed Feb 7 03:42:55 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 6 Feb 2018 12:42:55 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> <013001d39ecc$614dc500$23e94f00$@ronnatalie.com> Message-ID: <01e701d39f71$ec37d840$c4a788c0$@ronnatalie.com> I find the story hard to believe. A "CLB" command causes the engines to make the airplane climb? It doesn’t work that way. I'm a little familiar with the 757 autothrottles and the overall Airbus logic (if you think a modern UNIX OS looks bizarrely complex, take a look at Airbus "flight law" sometimes);. -----Original Message----- From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Arthur Krewat Sent: Monday, February 5, 2018 6:17 PM To: tuhs at minnie.tuhs.org Subject: Re: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) Literally, googled "hacker controlled plane engine" https://www.cnn.com/2015/05/17/us/fbi-hacker-flight-computer-systems/index.html On 2/5/2018 5:31 PM, Grant Taylor via TUHS wrote: > Someone with better search skills than me can probably turn up news > articles on both events. From lm at mcvoy.com Wed Feb 7 03:56:21 2018 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 6 Feb 2018 09:56:21 -0800 Subject: [TUHS] Device special files In-Reply-To: References: Message-ID: <20180206175621.GK16367@mcvoy.com> Aren't the major numbers just an index into the device driver table? On Tue, Feb 06, 2018 at 03:56:41PM +0000, ron minnich wrote: > these were in by the time I can along but I was wondering when they got it. > > They've also always felt a bit like a thing that did not fit to me. I'm > pretty sure I was not alone, given that the Unix authors worked out a way > to get rid of them in later efforts. I know what came after, in Plan 9; > what came before, in Unix, that led to special files? -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From rminnich at gmail.com Wed Feb 7 04:03:49 2018 From: rminnich at gmail.com (ron minnich) Date: Tue, 06 Feb 2018 18:03:49 +0000 Subject: [TUHS] Device special files In-Reply-To: <20180206175621.GK16367@mcvoy.com> References: <20180206175621.GK16367@mcvoy.com> Message-ID: On Tue, Feb 6, 2018 at 9:56 AM Larry McVoy wrote: > Aren't the major numbers just an index into the device driver table? > > yes. But that's not my question. -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Wed Feb 7 04:23:50 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Tue, 6 Feb 2018 13:23:50 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <01e701d39f71$ec37d840$c4a788c0$@ronnatalie.com> References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> <013001d39ecc$614dc500$23e94f00$@ronnatalie.com> <01e701d39f71$ec37d840$c4a788c0$@ronnatalie.com> Message-ID: <3aeb7a43-29af-28a1-c097-a0d86f1f4a33@kilonet.net> Maybe the autopilot? Still, overly simplistic. On 2/6/2018 12:42 PM, Ron Natalie wrote: > I find the story hard to believe. A "CLB" command causes the engines to make the airplane climb? It doesn’t work that way. > I'm a little familiar with the 757 autothrottles and the overall Airbus logic (if you think a modern UNIX OS looks bizarrely complex, take a look at Airbus "flight law" sometimes);. > > -----Original Message----- > From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Arthur Krewat > Sent: Monday, February 5, 2018 6:17 PM > To: tuhs at minnie.tuhs.org > Subject: Re: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) > > Literally, googled "hacker controlled plane engine" > > https://www.cnn.com/2015/05/17/us/fbi-hacker-flight-computer-systems/index.html > > > > On 2/5/2018 5:31 PM, Grant Taylor via TUHS wrote: >> Someone with better search skills than me can probably turn up news >> articles on both events. > > > From random832 at fastmail.com Wed Feb 7 05:48:19 2018 From: random832 at fastmail.com (Random832) Date: Tue, 06 Feb 2018 14:48:19 -0500 Subject: [TUHS] Device special files In-Reply-To: References: Message-ID: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> On Tue, Feb 6, 2018, at 10:56, ron minnich wrote: > these were in by the time I can along but I was wondering when they got it. > > They've also always felt a bit like a thing that did not fit to me. I'm > pretty sure I was not alone, given that the Unix authors worked out a way > to get rid of them in later efforts. I know what came after, in Plan 9; > what came before, in Unix, that led to special files? V3 and earlier still *called* them special files, but it seems they were essentially just magic inode numbers (there was no physical file on disk, just any directory entry with the given inode would be the special file). http://minnie.tuhs.org/cgi-bin/utree.pl?file=V3/man/man5/fs.5 From crossd at gmail.com Wed Feb 7 07:51:20 2018 From: crossd at gmail.com (Dan Cross) Date: Tue, 6 Feb 2018 16:51:20 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> Message-ID: On Mon, Feb 5, 2018 at 8:48 AM, William Cheswick wrote: > > On 4Feb 2018, at 10:40 PM, Dan Cross wrote: > > If by BSOD you mean, "Blue Screen of Death", which was NT's crash-dump > indicator then yes: I'm totally serious. I'd find a computer crashing on an > airplane frightening (I mean, I'm imagining that it does something > important). > > Save design would have the plane controls on a completely air-gapped > network from the > entertainment stuff. I was told that they don’t, because the captain > needs to be able to > stop the entertainment system during an announcement. I could build them > a very simple gateway > that transmits UDP packets in one direction only, that would meet this, > and related needs. > > There have been hacks of the avionics reported from the entertainment > network. It is scary, > if true, and bush league IMO. > I'll do you one better: have the PA system for the passenger cabin separate from the flight control system. Use an ambient mic or an all-analog audio cable to capture whatever the captain says on the flight recorder (the only reason I can imagine for wanting the PA system hooked up to the rest of the flight systems in the first place). Electrically isolated it with a transformer. Since Ron's windows computer is just a supporting device and doesn't affect flight operations, it's much less scary than I had initially imagined: "Yeah, every now and again the engine BSOD's. Sorta sucks when you're in mid-air...." "Hmm. You may want a new plane...." I do remember the Yorktown being dead in the water. I can just picture a number of various class Petty Officer's and junior sailors running around hopelessly while a Chief bellowed at them to "get the damned engines back online!" and officer country turned into a weeping pool of tears, but since no one knew how a computer works they just couldn't figure it out. Finally someone radioed back: "send out a tug." Oops. In respect of Warren's recent gentle nudge to bring the topic back to a Unix tie-in, I can say that as recently as 2008 I saw an UltraSPARC machine running Solaris on a big-deck amphib. No idea what it was there for; I have a vague recollection of seeing a CDE screen. Also, on a less martial track, one of the things I vividly remember about the NT introduction were the many dire predictions that this spelled the imminent death of Unix. NT would sweep all before it into the dustbin of evolutionary history and Microsoft would achieve total world domination. It seems that Linux was the rebel alliance to that galactic war, though. I'm curious what others thought of those predictions: did they even get onto your radar? - Dan C. (PS to Gregg Levine: thank you for your kind words and you're more than welcome. :-)) -------------- next part -------------- An HTML attachment was scrubbed... URL: From drsalists at gmail.com Wed Feb 7 08:13:51 2018 From: drsalists at gmail.com (Dan Stromberg) Date: Tue, 6 Feb 2018 14:13:51 -0800 Subject: [TUHS] Why BSD didn't catch on more, and Linux did Message-ID: IMO: 1) It kinda did catch on, in the form of macOS, but there was a time when it was nearly dead as the major vendors moved to System V. For some reason, Sun was the last major vendor to make the move, but they caught most of the flack. 2) I think the main reason BSD nearly died, was the AT&T lawsuit. At the time, Linux appeared to be a safer bet legally. 3) Linux got a reputation as an OS you had to be an expert to install, so lots of people started it to install it to "prove themselves". This was sort of true back when Linux came as 2 floppy images, but didn't remain true for very long. 4) I believe the SCO lawsuit "against Linux" was too little, too late to kill Linux's first mover advantage in the opensource *ix department. 5) I think FreeBSD's ports and similar huge-source-tree approaches didn't work out as well Linux developers contributing their changes upstream. From clemc at ccc.com Wed Feb 7 08:38:00 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 6 Feb 2018 17:38:00 -0500 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: Message-ID: On Tue, Feb 6, 2018 at 5:13 PM, Dan Stromberg wrote: > IMO: > 1) It kinda did catch on, in the form of macOS, ​agreed...​ > but there was a time > when it was nearly dead as the major vendors moved to System V. For > some reason, Sun was the last major vendor to make the move, but they > caught most of the flack. > ​This I disagree - Sun was the last. HP-UX to this day is a BSD based kernel with System V interfaces. Tru64 was OSF/1 - ney Mach 2.5 ney BSD + CMU and IBM, was it's own thing which was a combination of BSD, System III and System V salted. You're right that folks >>shipped<< using a SVR3 >>license<< but don't confuse the license with the kernel technology.​ > 2) I think the main reason BSD nearly died, was the AT&T lawsuit. At > the time, Linux appeared to be a safer bet legally. > ​Yes, I explore this in depth in my latest paper. Al biet we thought it was safer for an incorrect reason and if AT&T had won, Linux would have technically had to be removed from the market. Although, in practice, I'm not really sure how that would have worked out. But if AT&T had won, all >>UNIX based<< technology (the IP) - which Linux was just one example​ - would have had to go away. The suit was about >> trade secrets<< not copyright. I really believe this is/was the key item. It's certainly why I started using Linux and I know a number of others that did the same. > 3) Linux got a reputation as an OS you had to be an expert to install, > so lots of people started it to install it to "prove themselves". > This was sort of true back when Linux came as 2 floppy images, but > didn't remain true for very long. > ​Hmmm... possibly. I never saw or thought about it that way, but I was never trying to prove myself. But I take your word for it. ​ > 4) I believe the SCO lawsuit "against Linux" was too little, too late > to kill Linux's first mover advantage in the opensource *ix > department. > By that time - the damage was done.​ I really don't think this has any effect on BSD one way or the other. > 5) I think FreeBSD's ports and similar huge-source-tree approaches > didn't work out as well Linux developers contributing their changes > upstream. > ​Hmmm.. BSD has a similar scheme and in fact, Linux took a lot from FreeBSD​ in the ideas of install, ports *etc*. In time, I think they surpassed it. So I come back, if the original BSDi/UCB vs. AT&T suit had not occurred, it would have been a BSD world. But people like me got scared and even though BSD/386 vs Linux 0.99 was not even a fair comparison (BSD had networking, a window manager, did not crash - basically was a complete system). Linux was good enough with enough solid UNIX hacker making it complete it quickly took over. As I say in the paper, it is a classic Christensen style disruption. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Feb 7 08:44:08 2018 From: imp at bsdimp.com (Warner Losh) Date: Tue, 6 Feb 2018 15:44:08 -0700 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: Message-ID: On Tue, Feb 6, 2018 at 3:13 PM, Dan Stromberg wrote: > 5) I think FreeBSD's ports and similar huge-source-tree approaches > didn't work out as well Linux developers contributing their changes > upstream. > I think you confuse what ports was supposed to do. It was supposed to be "make these patches NOW to make the software available to users" paired with "submit the patches upstream to ease future support burdens". But the latter didn't happen often enough at times, especially as people moved on from the FreeBSD project and complex software became unsupported. It's really no different than what all the distributions have to do on Linux, but had a different bias for forcing the question than FreeBSD did in the early days. That's largely changed, and has mostly worked out.... The bigger issue with 'large trees' is that there was no convenient, binary packaged way to subset. Having everything in one tree avoids much of the version chasing that you have with Linux packages that the package set maintainers have to grapple with... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Wed Feb 7 09:02:54 2018 From: tytso at mit.edu (Theodore Ts'o) Date: Tue, 6 Feb 2018 18:02:54 -0500 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: Message-ID: <20180206230254.GB1977@thunk.org> On Tue, Feb 06, 2018 at 02:13:51PM -0800, Dan Stromberg wrote: > 2) I think the main reason BSD nearly died, was the AT&T lawsuit. At > the time, Linux appeared to be a safer bet legally. At the time of the AT&T lawsuit, most of the people who would be interested in using a Un*x-like system on their personal x86 systems probably wouldn't have been worried about their own personal legal liability. The decision of corporations to use Linux was well *after* the AT&T lawsuit was resolved. The lawsuit have suppressed the willingness of the 386BSD's to advertise what they had --- I had no idea 386BSD was far as advanced as it was, because I didn't happen to have been at that magic BOF where word was apparently passed around on the down low. But that's a little bit different, and more subtle, than just saying "safer bet legally". > 3) Linux got a reputation as an OS you had to be an expert to install, > so lots of people started it to install it to "prove themselves". > This was sort of true back when Linux came as 2 floppy images, but > didn't remain true for very long. Something to remember is that in early 90's, floppy disks was the only affordable way hobbiists to get OS's installed on x86 systems. Even OS/2 as distributed from IBM / Microsoft came on 30+ floppy disks. In 1990, CD-R recording system cost $35,000 (and dollars were bigger back then). In 1992, the price had dropped to $10-12k, and it wasn't until 1995 that he first CD-R system under $1000 was available. So I would argue that Linux was *easier* to bootstrap than NetBSD/FreeBSD during that era. The fact that we could shrink a kernel and a root file system down to two 1.44 MiB floppy disks required an on-trivial engineering effort, and it meant that all you had to was to download and write half-dozen to a dozen flopy disks, and then it was *trivial*. In contrast, bootstrapping a BSD system if you didn't have a quarter-inch tape drive (which was $$$) was non-trivial. So I would argue the reverse; the fact that Linux was easier to install may have helped it. > 5) I think FreeBSD's ports and similar huge-source-tree approaches > didn't work out as well Linux developers contributing their changes > upstream. I'd frame this slightly differently. The fact that we had multiple Linux distributions meant that we had competition to make a better, easier-to-install userspace, while keeping a common kernel. Also, distributions cooperated with each other in a very surprising way. One archetypal story was one where at a Linux meet-up, Bob Young, who was one of the founders of Red Hat, was helping to hand out Slackware CD's because that was what was available. Bob's philosophy was that growing the pie was way more important that fighting over the share of the pie. In contrast, during that era, NetBSD and FreeBSD were busily quarrelling with each others, with politics and ill-will due to people being ejected from the core team which caused the various BSD forks. I can't imagine this being helpful in the long term.... In particular, the kernel engineers who were hired by the distribution vendors were working together on a common kernel, and on low-level userspace subsystems (glibc, PAM, etc.) were also done with a huge amount of cooperation. - Ted From pete at nomadlogic.org Wed Feb 7 08:59:07 2018 From: pete at nomadlogic.org (Pete Wright) Date: Tue, 6 Feb 2018 14:59:07 -0800 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: Message-ID: On 02/06/2018 14:44, Warner Losh wrote: > > > On Tue, Feb 6, 2018 at 3:13 PM, Dan Stromberg > wrote: > > 5) I think FreeBSD's ports and similar huge-source-tree approaches > didn't work out as well Linux developers contributing their changes > upstream. > > > I think you confuse what ports was supposed to do. It was supposed to > be "make these patches NOW to make the software available to users" > paired with "submit the patches upstream to ease future support > burdens". But the latter didn't happen often enough at times, > especially as people moved on from the FreeBSD project and complex > software became unsupported. It's really no different than what all > the distributions have to do on Linux, but had a different bias for > forcing the question than FreeBSD did in the early days. That's > largely changed, and has mostly worked out.... > > The bigger issue with 'large trees' is that there was no convenient, > binary packaged way to subset. Having everything in one tree avoids > much of the version chasing that you have with Linux packages that the > package set maintainers have to grapple with... > I can give a hardy "second" to this statement.  Having to maintain some non-trivial in-house packages on Linux distro's as well as on FreeBSD really drove this point home for me.  For example, the LOE was tremendous to support a Python version which was not supported by RedHat for example, not to mention the ongoing effort to keep the primary packages and their dependencies up to date was a major challenge as well.  Working on the ports tree was much nicer in this regard as it allowed me to reuse work done by others. Having said that it certainly feel that since FreeBSD did not have a good story precompiled package management (as opposed to yum, apt, etc.) was a real detriment to wider adoption to aspiring hackers. Between pkgin/pkgsrc and the new pkg too in FreeBSD I feel they are much better positioned for people who just want to install software and get to the job at hand. -pete -- Pete Wright pete at nomadlogic.org @nomadlogicLA -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfawcus+lists-tuhs at employees.org Wed Feb 7 08:59:59 2018 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Tue, 6 Feb 2018 22:59:59 +0000 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: Message-ID: <20180206225959.GA11642@accordion.employees.org> On Tue, Feb 06, 2018 at 02:13:51PM -0800, Dan Stromberg wrote: > This was sort of true back when Linux came as 2 floppy images, but > didn't remain true for very long. Well I remember starting with the 0.12 root + boot disks, but the MCC distribution (4 or 8 1.44M floppies?) became available not too long after. At the time a colleague and I had been considering coughing up for the BSDi distribution, but found Linux so played with it instead. DF From cym224 at gmail.com Wed Feb 7 09:14:31 2018 From: cym224 at gmail.com (Nemo Nusquam) Date: Tue, 6 Feb 2018 18:14:31 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> Message-ID: <371a22e7-d58f-04e9-f1b6-c8efa0b31406@gmail.com> On 02/06/18 16:51, Dan Cross wrote: > Also, on a less martial track, one of the things I vividly remember > about the NT introduction were the many dire predictions that this > spelled the imminent death of Unix. NT would sweep all before it into > the dustbin of evolutionary history and Microsoft would achieve total > world domination. It seems that Linux was the rebel alliance to that > galactic war, though. I'm curious what others thought of those > predictions: did they even get onto your radar? I remember attending a Unix International meeting where the mood was one of fear and despondency. I thought their attitude insane but the few I spoke with thought that NT would take over the world. (I encountered the same at a satnav meeting. Motorola's satellites were in orbit -- I forgot the name of the actual venture -- and MS had just paired with somebody to put their own satellites up. Fear everywhere.) N. From imp at bsdimp.com Wed Feb 7 09:22:16 2018 From: imp at bsdimp.com (Warner Losh) Date: Tue, 6 Feb 2018 16:22:16 -0700 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: <371a22e7-d58f-04e9-f1b6-c8efa0b31406@gmail.com> References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> <371a22e7-d58f-04e9-f1b6-c8efa0b31406@gmail.com> Message-ID: On Tue, Feb 6, 2018 at 4:14 PM, Nemo Nusquam wrote: > On 02/06/18 16:51, Dan Cross wrote: > >> Also, on a less martial track, one of the things I vividly remember >> about the NT introduction were the many dire predictions that this >> spelled the imminent death of Unix. NT would sweep all before it into >> the dustbin of evolutionary history and Microsoft would achieve total >> world domination. It seems that Linux was the rebel alliance to that >> galactic war, though. I'm curious what others thought of those >> predictions: did they even get onto your radar? >> > > I remember attending a Unix International meeting where the mood was one > of fear and despondency. I thought their attitude insane but the few I > spoke with thought that NT would take over the world. (I encountered the > same at a satnav meeting. Motorola's satellites were in orbit -- I forgot > the name of the actual venture -- and MS had just paired with somebody to > put their own satellites up. Fear everywhere.) Wasn't that Iridium? A joint venture with Qualcomm, IIRC. -------------- next part -------------- An HTML attachment was scrubbed... URL: From akosela at andykosela.com Wed Feb 7 10:22:28 2018 From: akosela at andykosela.com (Andy Kosela) Date: Tue, 6 Feb 2018 18:22:28 -0600 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: <20180206230254.GB1977@thunk.org> References: <20180206230254.GB1977@thunk.org> Message-ID: On Tuesday, February 6, 2018, Theodore Ts'o wrote: > On Tue, Feb 06, 2018 at 02:13:51PM -0800, Dan Stromberg wrote: > > 2) I think the main reason BSD nearly died, was the AT&T lawsuit. At > > the time, Linux appeared to be a safer bet legally. > > At the time of the AT&T lawsuit, most of the people who would be > interested in using a Un*x-like system on their personal x86 systems > probably wouldn't have been worried about their own personal legal > liability. The decision of corporations to use Linux was well *after* > the AT&T lawsuit was resolved. > > Exactly. I always stress that the AT&T lawsuit's negative impact on adoption of Open Source *BSDs is exaggerated. Remember that back in the early 90s both Linux and Net/FreeBSD were just hobbyist systems... We were all doing it as a hobby for fun. No one was aware that this is going to catch on in the enterprise... I think that if somebody was already exposed to BSD code in the 80s it was more natural for him to adopt open source *BSD. Otherwise he went with Linux. Initially I think it was a little bit smaller and simpler too. Until the decision of the really big corporate players like Oracle and IBM to support Linux in the late 90s, both systems went head-to-head, and one could even argue that *BSDs had a technical edge over Linux. It all changed after year 2g when it became apparent that Linux is slowly winning the battle for "hearts and minds". We should be happy that hobbyist Open Source Unix systems have been so widely adopted at all though; otherwise we would all be living in the NT hell. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at timetraveller.org Wed Feb 7 11:02:57 2018 From: robert at timetraveller.org (Robert Brockway) Date: Wed, 7 Feb 2018 11:02:57 +1000 (AEST) Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: <20180206230254.GB1977@thunk.org> Message-ID: On Tue, 6 Feb 2018, Andy Kosela wrote: > I think that if somebody was already exposed to BSD code in the 80s it was > more natural for him to adopt open source *BSD. Otherwise he went with > Linux. Initially I think it was a little bit smaller and simpler too. Here's a case study... I installed Linux on my PC in June 1994 after my university exams had finished. I only decided to go with Linux over NetBSD the night before I was heading to university to start downloading the 30 or 40 floppy images I'd need to do the install. The *nix enthusiasts on campus were split fairly evening between Linux & NetBSD[1] at the time so I was fairly assured of advice and help regardless of which way I went[2]. I chose Linux over NetBSD for one reason. Linux had a DOS emulator (DosEMU). Even then I wanted to run an emulator rather than multiboot. NetBSD got support for the dos emulator later but by then I'd made my choice. As an aside, while downloading the floppy images I came to the notice of local sysadmins. I had to go see one of the sysadmins about my usage of system and network resources. That sysadmin was George Michaelson, who is on this list. Hi George! George and I have since worked together. IIRC the university introduced a local Slackware mirror soon after. [1] FreeBSD wasn't getting as much attention among enthusiasts at my campus and OpenBSD was still a glint in Theo's eye. [2] A year later I founded a computer club on campus which embraced all flavours of *nix hobbyist. It's still running 23 years later. Cheers, Rob From dave at horsfall.org Wed Feb 7 11:14:12 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 7 Feb 2018 12:14:12 +1100 (EST) Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: <20180206225959.GA11642@accordion.employees.org> References: <20180206225959.GA11642@accordion.employees.org> Message-ID: On Tue, 6 Feb 2018, Derek Fawcus wrote: > At the time a colleague and I had been considering coughing up for the > BSDi distribution, but found Linux so played with it instead. It would've been early Linux for me, but some personal issues stopped me from actually doing it (all I had to do was to collect the box -- a 386 -- that someone else had done for me) otherwise I would've learned to loathe Penguin/OS that much earlier :-) As it was, $BOSS paid for my BSDi source licence, and when WinDriver bought them out and suppressed it I went to FreeBSD instead (after a brief tangle with some pompous OpenBSD jerks). FreeBSD is still my main server (an ancient P4 at the moment, with a massive 512MB of memory; it used to be a Celery w/ 128MB) with MacBook and Debian clients. And I really must repair the keyboard on the EeePC 701 (running EeeBuntu) some day... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Wed Feb 7 11:23:45 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 7 Feb 2018 12:23:45 +1100 (EST) Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> Message-ID: On Tue, 6 Feb 2018, Dan Cross wrote: > Also, on a less martial track, one of the things I vividly remember > about the NT introduction were the many dire predictions that this > spelled the imminent death of Unix. [...] I remember when Pick was going to be the imminent death of Unix... And wasn't BeOS going to be, too? I've been mucking about with Unix since Edition 5, and I've seen all the predictions. Unix may not be recognisable in the future, but it's here to stay. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From grog at lemis.com Wed Feb 7 11:25:56 2018 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 7 Feb 2018 12:25:56 +1100 Subject: [TUHS] Device special files In-Reply-To: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> Message-ID: <20180207012556.GL30690@eureka.lemis.com> On Tuesday, 6 February 2018 at 14:48:19 -0500, Random832 wrote: > On Tue, Feb 6, 2018, at 10:56, ron minnich wrote: >> these were in by the time I can along but I was wondering when they got it. >> >> They've also always felt a bit like a thing that did not fit to me. I'm >> pretty sure I was not alone, given that the Unix authors worked out a way >> to get rid of them in later efforts. I know what came after, in Plan 9; >> what came before, in Unix, that led to special files? > > V3 and earlier still *called* them special files, but it seems they > were essentially just magic inode numbers (there was no physical file > on disk, just any directory entry with the given inode would be the > special file). Isn't that still the case? Greg -- Sent from my desktop computer. Finger grog at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From clemc at ccc.com Wed Feb 7 11:29:27 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 6 Feb 2018 20:29:27 -0500 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: <20180206230254.GB1977@thunk.org> References: <20180206230254.GB1977@thunk.org> Message-ID: On Tue, Feb 6, 2018 at 6:02 PM, Theodore Ts'o wrote: > On Tue, Feb 06, 2018 at 02:13:51PM -0800, Dan Stromberg wrote: > > 2) I think the main reason BSD nearly died, was the AT&T lawsuit. At > > the time, Linux appeared to be a safer bet legally. > > At the time of the AT&T lawsuit, most of the people who would be > interested in using a Un*x-like system on their personal x86 systems > probably wouldn't have been worried about their own personal legal > liability. The decision of corporations to use Linux was well *after* > the AT&T lawsuit was resolved. > ​ > ​Ted, I pretty much agree with everything you have said except for one thing. I don't think it was ever about person liability. As you pointed out, we all just wanted something to work on hardware that we owned. In fact, like Linus, I had also purchased Minux for $75 from the book publisher before BSD/386 came out and ran it on my PC. I think many people wanted that. Linus himself is on record, if he had known about BSD/386 - he would have used it. But he got Minix and did not support that we wanted. As I point out in the paper, Unix originally ran on hardware that cost between $50-250K in 1975 dollars, So the Unix users did not own that hardware themself - their school or employer did. But the PC changed situation that pretty dramatically. And just as we wanted UNIX at work on PDP-11s (and later vaxen) we wanted it on our personal machines too. BSD/386 was a UNIX implementation for the hardware that I owned. And many like minded people to myself who did have access to BSD/386, saw the law suit in the light of ``if BSD was in violation of the AT&T Copyrights'' (and I thought it was BTW) - there was an issue, It would mean it would mean the only 'UNIX' for my PC was Minix (which ran without the MMU, small address space etc.). So here is an alternative -- Linux -- that's not perfect, but sure beats Minix. Ok, its not BSD and does not have networking, no graphics/window manger, and it crashes but ... well we can fix that. People added networking, ported X over etc... Like you I started with the bits from Linus and it was a little difficult - lot of DIY - column A, tab B, update this. Then I discovered the first full ``distro'' that seemed to make sense (Slackware) - which in fact was similar to BSD at the time (used V7/BSD conventions) and it mostly worked. IIRC, Networking came shortly their after, and Linux starts getting better and better. I would not say it was fun, I was grumbling because I had already seen BSD/386 - but I pushed on because I was worried BSD/386 was not going to be available to me on my home system. In fact, BSD/386 at that point had a better install and that would get even better after the suit ended with the fork that Jordan Hubbard and Co did, but I think that was good. As the 386 installs for a BSD got better, it pressured the Linux guys to make their stuff even better. And by that time, Linux pretty much had parity on the kernel side, if not started to get the lead [Linux supported modules early on, which I think was a technological development that is overlooked but was huge in making Linux flexible when it needed to be]. BTW: lets not forgot the larger issue. At this point the 'better' kernel technology is in Solaris, Tru64 et al.. but that's not running on PC technology. Few people can afford such a machine for themselves. [BTW: I had proposed that OSF/1 try to market their system directly around then for $100 - but the OSF sponsors were all selling hardware and none saw the need]. But at the same time, BSD/386 is now unclear what is going to happen. And most importantly this new market of users for their personal systems, does not care that PC and Linux is not as good the 'best' - like Solaris/Tru64/Aix -- i.e. The Christensen disruption is complete -- the worse technology, found a new user base that can (and does) grow (grew) incredible fast. Soon the 'worse' technology surpasses the sustaining one. But then it comes out, the suit was not about copyright, but trade secrets. We all had been 'mentally contaminated' by the AT&T IP at our respective colleges and universities. So the court does do the right thing, and AT&T loses the case. By that time, enough people had made Linux work. It was a different comparison and I think the momentum had shifted. Also, I think you are absolutely right about the fighting between the commercial vendors and then later the different *BSD folks. And I think that fighting helped to carry the day - personal users just did not want to mess with it. Linux was (is) an excellent solution. I use it everyday. It helps to pay my salary. But I do think it would have been some flavor of BSD/386 that would be doing that if the law suit had not occurred. To me, the law suit is what moved people that wanted a UNIX on a PC and once they moved from BSD/386 or just discovered Linux, they was (is) not real reason to switch or go back. The suit was certainly what scared a lot of us -- the issue was not liability - it was the risk of losing access to UNIX technology for systems that we owned. And that was/is huge. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Feb 7 11:33:41 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 6 Feb 2018 20:33:41 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> Message-ID: On Tue, Feb 6, 2018 at 8:23 PM, Dave Horsfall wrote: > > > Unix may not be recognisable in the future, but it's here to stay. ​+1​ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Wed Feb 7 11:36:26 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 6 Feb 2018 20:36:26 -0500 Subject: [TUHS] Device special files In-Reply-To: <20180207012556.GL30690@eureka.lemis.com> References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> Message-ID: <007f01d39fb4$12524eb0$36f6ec10$@ronnatalie.com> Speaking of all this. .. Didn't Solaris symlink the device files into some magic file system path rather than using the older major/minor special of the traditional UNIX? \ From jnc at mercury.lcs.mit.edu Wed Feb 7 11:38:25 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 6 Feb 2018 20:38:25 -0500 (EST) Subject: [TUHS] Device special files Message-ID: <20180207013825.2222218C0A4@mercury.lcs.mit.edu> > From: Greg Lehey >> V3 and earlier still *called* them special files, but it seems they >> were essentially just magic inode numbers (there was no physical file >> on disk, just any directory entry with the given inode would be the >> special file). > Isn't that still the case? >From reading the manual page (URL sent earlier), in V3 and before it really was just an inode _number_ (less than 50, IIRC). The first inode, in the first disk block after the super-block, was inode #51. This is of course different from later Versions, where there is an _inode_ for devices, but still no actual _file_. Noel From clemc at ccc.com Wed Feb 7 11:40:05 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 6 Feb 2018 20:40:05 -0500 Subject: [TUHS] Device special files In-Reply-To: <007f01d39fb4$12524eb0$36f6ec10$@ronnatalie.com> References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> <007f01d39fb4$12524eb0$36f6ec10$@ronnatalie.com> Message-ID: Are you refering to specdev when Solaris when file system crazy and everything was it's own file system. ᐧ On Tue, Feb 6, 2018 at 8:36 PM, Ron Natalie wrote: > Speaking of all this. .. Didn't Solaris symlink the device files into some > magic file system path rather than using the older major/minor special of > the traditional UNIX? > > > > \ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Wed Feb 7 11:47:07 2018 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 6 Feb 2018 20:47:07 -0500 Subject: [TUHS] Device special files In-Reply-To: References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> <007f01d39fb4$12524eb0$36f6ec10$@ronnatalie.com> Message-ID: On 6 February 2018 at 20:40, Clem Cole wrote: > Are you refering to specdev when Solaris when file system crazy and > everything was it's own file system. > ᐧ > > On Tue, Feb 6, 2018 at 8:36 PM, Ron Natalie wrote: > >> Speaking of all this. .. Didn't Solaris symlink the device files into >> some >> magic file system path rather than using the older major/minor special of >> the traditional UNIX? >> >> Have you looked at an Android phone? root at quark:/ #mount | wc -l 27 What they are isn't really important. Why on earth does my phone need 27 mounted devices, or pseudo-devices? -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Feb 7 11:48:35 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 7 Feb 2018 12:48:35 +1100 (EST) Subject: [TUHS] Device special files In-Reply-To: <20180207012556.GL30690@eureka.lemis.com> References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> Message-ID: On Wed, 7 Feb 2018, Greg 'groggy' Lehey wrote: >> V3 and earlier still *called* them special files, but it seems they >> were essentially just magic inode numbers (there was no physical file >> on disk, just any directory entry with the given inode would be the >> special file). > > Isn't that still the case? Wasn't that "devfs" (which Penguin/OS calls "udev")? I've never grokked that concept. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From crossd at gmail.com Wed Feb 7 11:54:30 2018 From: crossd at gmail.com (Dan Cross) Date: Tue, 6 Feb 2018 20:54:30 -0500 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> Message-ID: On Tue, Feb 6, 2018 at 8:23 PM, Dave Horsfall wrote: > On Tue, 6 Feb 2018, Dan Cross wrote: > >> Also, on a less martial track, one of the things I vividly remember about >> the NT introduction were the many dire predictions that this spelled the >> imminent death of Unix. [...] >> > > I remember when Pick was going to be the imminent death of Unix... And > wasn't BeOS going to be, too? I've been mucking about with Unix since > Edition 5, and I've seen all the predictions. > > Unix may not be recognisable in the future, but it's here to stay. > Oh, certainly "NT Takes Over the World!" didn't happen, and in retrospect it seems somewhat naive that anyone ever thought that it would; let alone that it would put Unix into the grave. But those doomsday predictions seemed very much to be the order of the day. Interestingly, I saw a lot of what was left of the minicomputer infrastructure around the campus I haunted (but bear in mind I was in high school at the time so had a weird perspective as an outside-insider) as well as a lot of mainframe stuff get replaced by NT. The Unix folks (especially those at the centralized computing facility) pretty much had the attitude that, "well, we're next..." but that never came to pass. But much VMS, whatever HP minicomputer stuff was floating around (MPE?) and all VM/CMS (I guess it was actually VM/ESA by that time) disappeared; VAXstations, serial terminals and 3179G's were all replaced by PCs running Windows and the users were replaced by these smiling robots. It was weird. Somehow, most of the Unix people managed to escape. I wonder why? Part of my sense is that by and large the Unix people were more technically adept than the minicomputer and mainframe people, though to this day one of *the* most technically astute hackers I've ever seen was a diehard VMS guy. He came from TOPS-10 on the PDP-10, though, so maybe that's why. But certainly the median level of technical "clue" was higher amongst the Unix folks than the other communities. I wonder if that wasn't one of the primary factors that enabled folks to stay outside of the NT gravitational pull. I wonder, too, if Unix networking didn't play a major role. I have this dim sense that NT was designed for a world in which it was still assumed that the OSI suite was going to win the networking wars. When, almost to everyone's surprise, the Internet ended up taking off Unix was already well-positioned to respond and NT had to play catch up. I remember going to lunch one afternoon (I guess it was the summer because I didn't have school) and everyone was sitting around complaining about how horrible Microsoft was. One of the older sysadmins said something like, "you know, I can remember saying the exact same things about IBM 15 years ago. Now it's Microsoft. They won't last." I was rather incredulous that the enemy was not being recognized, let alone actively resisted. But in the end, he was absolutely right, and in retrospect it makes perfect sense: the price of hardware is being asymptotically driven to zero; given that, software cost becomes significant, giving rise to things like Linux as commercially viable alternatives to proprietary software. Given that, MS never stood a chance of long term dominance. Of course, as software cost goes to zero than the maintenance and other ongoing costs (space, power, etc) tend to dominate, giving rise to the cloud, etc. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Feb 7 12:06:27 2018 From: crossd at gmail.com (Dan Cross) Date: Tue, 6 Feb 2018 21:06:27 -0500 Subject: [TUHS] Device special files In-Reply-To: References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> Message-ID: On Tue, Feb 6, 2018 at 8:48 PM, Dave Horsfall wrote: > On Wed, 7 Feb 2018, Greg 'groggy' Lehey wrote: > >> V3 and earlier still *called* them special files, but it seems they were >>> essentially just magic inode numbers (there was no physical file on disk, >>> just any directory entry with the given inode would be the special file). >>> >> >> Isn't that still the case? >> > > Wasn't that "devfs" (which Penguin/OS calls "udev")? I've never grokked > that concept. > No. devfs was (is?) a pseudo-filesystem where only special files corresponding to the devices enumerated by the kernel during autoconfiguration are present. The contents are synthesized at boot time and the filesystem is mounted at some canonical location (like /dev), but is otherwise ephemeral. This is in contrast to the older /dev, which is usually just a directory on the root filesystem, wherein one created a number of device files that may (or may not) correspond to an actual hardware device in the system (remember the old dance of, "cd /dev && ./MAKEDEV foo" when you added a "foo" onto your system?). The inodes and directory entries for those files actually exist in the disk-resident filesystem structures (though of course data blocks aren't allocated to those files and the inode doesn't refer to any data blocks). My understanding is that udev is an elaboration on devfs on Linux that includes a rules engine that supports things like assigning set names to specific devices, setting permissions, group/user ownership and the like. For example, one can configure a rule so that when USB UART device with serial number 0xdeadbeef gets attached to the system, it appears as /dev/console_for_foo, owned by group "fooadmin" and mod 660. Presumably whoever configured that knows that that serial device is physically connected to the serial console for "foo". - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Wed Feb 7 12:13:50 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Tue, 06 Feb 2018 18:13:50 -0800 Subject: [TUHS] Device special files In-Reply-To: Your message of "Wed, 07 Feb 2018 12:48:35 +1100." References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> Message-ID: <20180207021405.CF19B156E812@mail.bitblocks.com> On Wed, 07 Feb 2018 12:48:35 +1100 Dave Horsfall wrote: Dave Horsfall writes: > On Wed, 7 Feb 2018, Greg 'groggy' Lehey wrote: > > >> V3 and earlier still *called* them special files, but it seems they > >> were essentially just magic inode numbers (there was no physical file > >> on disk, just any directory entry with the given inode would be the > >> special file). > > > > Isn't that still the case? > > Wasn't that "devfs" (which Penguin/OS calls "udev")? I've never grokked > that concept. In the old days where a limited types of devices were available for a particular kind of machine, they could be statically assigned a major dev number (matching their index in the {b,c}devsw table). To make them accessible to users you did mknod Usually via /dev/MAKEDEV. But this soon fell apart on PCs where you any number of devices can be attached. Even on Fortune Systems (pre PC) the system had an IO bus and static assignments listing out every possible device would've needed a lot of inodes. Recall that on a floppy space taken by each inode matters so we had to find a way! IIRC, the kernel essentially returned a list of mknod commands which was then run at boot time. So the point of devfs is to avoid having to do mknod manually and yet provide access to all found devices from the userland. As a side effect you can also use it for programs that run in their own sandbox or for jails and require access to a device. From dave at horsfall.org Wed Feb 7 13:03:13 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 7 Feb 2018 14:03:13 +1100 (EST) Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> <371a22e7-d58f-04e9-f1b6-c8efa0b31406@gmail.com> Message-ID: On Tue, 6 Feb 2018, Warner Losh wrote: > Motorola's satellites were in orbit -- I forgot the name of the > actual venture -- and MS had just paired with somebody to put > their own satellites up.  Fear everywhere.) > > Wasn't that Iridium? A joint venture with Qualcomm, IIRC. Shouldn't that be called "Osmium"[*] now? :-) [*] Interesting metal, osmium; stinks to high heaven, just like... never mind. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From ggm at algebras.org Wed Feb 7 13:47:33 2018 From: ggm at algebras.org (George Michaelson) Date: Wed, 7 Feb 2018 13:47:33 +1000 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: <20180206230254.GB1977@thunk.org> Message-ID: hah! you ran a damn sight further with your acquired knowledge than I did I hasten to add. I now lean on the knowledge of my betters almost all the time, to do my job. I'm suffering almost 100% continuous imposter syndrome. I remember we were a bit heavy handed with downloads because of paranoia bout funding the data in the AARNet model. Most other international academic nets wound up paying for bandwidth as a capex with no cost recovery because physics and bombs wanted it to exist. (physicists who feel offended, consider yourself astronomers, and then stars are just giant fusion bombs) Australia decided to drive to an economic rationalist model where the money raised paid the cost to increase the bandwidth when the core net was on 65% utilisation all the time, which usefully was the observed rate when TCP clagged up with the window/backoff/RTT of the day. So it was a self-perpetuating perpetual motion mache for making money to buy bandwidth. You (in a very perverse sense) were driving it north to 65% quicker than the UQ people wanted to pay for it, hence our heavy handed back pressure not to do that (tm). We did the mirrors, because squid caches hadn't been invented. If we'd had caches we might not have done the mirrors. By the time squid caches existed we had the mirrors so we kinda had both. Mirrors made life better. I don't think it was this time, but one of the times I was heavy handed with people like you, who used the damn thing, I got carpeted by the computer center director for "not being nice to the users" which was hugely embarrassing and he was kind enough to let me off with a warning instead of a career limiting boot out the door. Now, we just let the floodgates open. I think I throw away .ISO files on my macbook drive, because its easier to refresh off the distro core, or I'm running Docker images and they load way more crap anyway. From dave at horsfall.org Wed Feb 7 15:39:08 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 7 Feb 2018 16:39:08 +1100 (EST) Subject: [TUHS] Device special files In-Reply-To: <20180207021405.CF19B156E812@mail.bitblocks.com> References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> <20180207021405.CF19B156E812@mail.bitblocks.com> Message-ID: On Tue, 6 Feb 2018, Bakul Shah wrote: >> Wasn't that "devfs" (which Penguin/OS calls "udev")? I've never >> grokked that concept. > > In the old days where a limited types of devices were > available for a particular kind of machine, they could be > statically assigned a major dev number (matching their index > in the {b,c}devsw table). To make them accessible to users you > did > > mknod [...] Umm, I've known that since Edition 5; I'm not exactly new to Unix, you know... [...] > So the point of devfs is to avoid having to do mknod manually and yet > provide access to all found devices from the userland. As a side effect > you can also use it for programs that run in their own sandbox or for > jails and require access to a device. That makes sense; bit of a pain when a USB device suddenly disappears just I unplugged it, though... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From tih at hamartun.priv.no Wed Feb 7 18:04:45 2018 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Wed, 07 Feb 2018 09:04:45 +0100 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: <20180206230254.GB1977@thunk.org> (Theodore Ts'o's message of "Tue, 6 Feb 2018 18:02:54 -0500") References: <20180206230254.GB1977@thunk.org> Message-ID: Theodore Ts'o writes: > In contrast, during that era, NetBSD and FreeBSD were busily > quarrelling with each others, with politics and ill-will due to people > being ejected from the core team which caused the various BSD forks. Um, I remember this very differently. The early split between NetBSD and FreeBSD was a friendly disagreement over whether to continue to be cross-platform (NetBSD) or go for maximum performance on x86 (FreeBSD). The only event that fits your description is OpenBSD, which got forked off because Theo de Raadt's abrasive personality managed to get him kicked out of the NetBSD core team, and banned from both NetBSD and FreeBSD mailing list. -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From wobblygong at gmail.com Wed Feb 7 18:27:16 2018 From: wobblygong at gmail.com (Wesley Parish) Date: Wed, 7 Feb 2018 21:27:16 +1300 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: Message-ID: On 2/7/18, Dan Stromberg wrote: > IMO: > 1) It kinda did catch on, in the form of macOS, but there was a time > when it was nearly dead as the major vendors moved to System V. For > some reason, Sun was the last major vendor to make the move, but they > caught most of the flack. And for what it's worth, the iPhone. IIRC, a nephew once showed me a bash prompt on his iPhone and some nifty tricks he was teaching himself with it. > 2) I think the main reason BSD nearly died, was the AT&T lawsuit. At > the time, Linux appeared to be a safer bet legally. > 3) Linux got a reputation as an OS you had to be an expert to install, > so lots of people started it to install it to "prove themselves". > This was sort of true back when Linux came as 2 floppy images, but > didn't remain true for very long. Well, put it this way, to install MS/PC/DR DOS you fooled around with a limited FDISK.COM if the HD was unformated. Then you did FORMAT.COM and (in 3.3 and earlier) SYS.COM to install the core files. Then you could run whatever batch files you needed to install whatever utilities you needed. OS/2 and Windows (including WinNT 3.x) just added a pretty-pretty interface. OS/2 was more sophisticated than WinNT's because OS/2 expected to share the hard drive with some other OS; Microsoft believed it had the computer to itself and is thus not as sophisticated - but they're still MS/PC/DR DOS writ large. To install Linux (I cut my teeth on SLS 0.99pl(largelyforgotten) ) you had to do something with sectors and the like. And if you didn't know about sectors, you screwed up and learnt damn fast. It's quite an education re-installing something because the file system won't fit on the miniscule partition you've made for it, and you pay attention this time!!! > 4) I believe the SCO lawsuit "against Linux" was too little, too late > to kill Linux's first mover advantage in the opensource *ix > department. The major difference between the AT&T versus Berkley and The SCO (Societe Commerciale du Ondit or RumourMongers Incorporated) Group was people knew about the AT&T case and were prepared; in addition, SCO ran into the Internet-powered Groklaw Effect. You can't use vague allegations to win your case when there's a bunch of people around who can take your vague allegations and feed them to the alligators. > 5) I think FreeBSD's ports and similar huge-source-tree approaches > didn't work out as well Linux developers contributing their changes > upstream. > Wesley Parish From arrigo at alchemistowl.org Wed Feb 7 18:51:14 2018 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Wed, 7 Feb 2018 09:51:14 +0100 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: <20180206230254.GB1977@thunk.org> References: <20180206230254.GB1977@thunk.org> Message-ID: <79F6EEC6-6B0C-4C33-89AD-BF5D3BACFBA3@alchemistowl.org> > On 7 Feb 2018, at 00:02, Theodore Ts'o wrote: > > On Tue, Feb 06, 2018 at 02:13:51PM -0800, Dan Stromberg wrote: >> 2) I think the main reason BSD nearly died, was the AT&T lawsuit. At >> the time, Linux appeared to be a safer bet legally. > > At the time of the AT&T lawsuit, most of the people who would be > interested in using a Un*x-like system on their personal x86 systems > probably wouldn't have been worried about their own personal legal > liability. The decision of corporations to use Linux was well *after* > the AT&T lawsuit was resolved. As a long-time Unix user (since around 1978) I agree with the above: the lawsuit was definitely not very high in my concerns when I wanted a Unix on a cheap PC, I just wanted it to work and, at the same time, I appreciated the impossible ecosystem which the PC brought along with a gazillion different cards all requiring a special driver (I am thinking, in particular, of the “SuperIO” card which my 386SX had to provide two RS232 ports, a parallel port and a 3 1/2” drive - made in Taiwan, zero documentation, etc.). The Unix machines I had access to via work/study were all “big iron” coming from large manufacturers and totally out of my price range. > Something to remember is that in early 90's, floppy disks was the only > affordable way hobbiists to get OS's installed on x86 systems. Even > OS/2 as distributed from IBM / Microsoft came on 30+ floppy disks. In > 1990, CD-R recording system cost $35,000 (and dollars were bigger back > then). In 1992, the price had dropped to $10-12k, and it wasn't until > 1995 that he first CD-R system under $1000 was available. It was also really rather easy to share a floppy disk amongst friends whereas copying a CD or a tape was really very expensive for a student/amateur. > So I would argue that Linux was *easier* to bootstrap than > NetBSD/FreeBSD during that era. The fact that we could shrink a > kernel and a root file system down to two 1.44 MiB floppy disks > required an on-trivial engineering effort, and it meant that all you > had to was to download and write half-dozen to a dozen flopy disks, > and then it was *trivial*. Absolutely true. I would have never tried Linux had it been possible to install FreeBSD/NetBSD on the PCs I had access to from a floppy disk. This changed around 1994 when I managed to boot NetBSD from floppy on a Dell 486SX with very specific hardware (network card, etc.) which I had managed to find thrown away by a big bank in the City. My dream was a Sun but all I could afford was a 2nd hand battered 486SX… Arrigo From emu at e-bbes.com Wed Feb 7 18:39:14 2018 From: emu at e-bbes.com (emanuel stiebler) Date: Wed, 7 Feb 2018 09:39:14 +0100 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: Message-ID: <9b4b067a-240d-cfa1-6c44-b9757654afc7@e-bbes.com> On 2018-02-07 09:27, Wesley Parish wrote: > To install Linux (I cut my teeth on SLS 0.99pl(largelyforgotten) ) you > had to do something with sectors and the like. And if you didn't know > about sectors, you screwed up and learnt damn fast. It's quite an > education re-installing something because the file system won't fit on > the miniscule partition you've made for it, and you pay attention this > time!!! But wasn't it the same on *BSD too? If you didn't have a disk which was supported, and had the right entries already you sat there for a while with the calculator ;-) From arrigo at alchemistowl.org Wed Feb 7 20:44:14 2018 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Wed, 7 Feb 2018 11:44:14 +0100 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: <9b4b067a-240d-cfa1-6c44-b9757654afc7@e-bbes.com> References: <9b4b067a-240d-cfa1-6c44-b9757654afc7@e-bbes.com> Message-ID: <5F440CE3-C325-493A-A650-FEEF71BF8879@alchemistowl.org> On 7 Feb 2018, at 09:39, emanuel stiebler wrote: >> To install Linux (I cut my teeth on SLS 0.99pl(largelyforgotten) ) you >> had to do something with sectors and the like. And if you didn't know >> about sectors, you screwed up and learnt damn fast. It's quite an >> education re-installing something because the file system won't fit on >> the miniscule partition you've made for it, and you pay attention this >> time!!! > > But wasn't it the same on *BSD too? If you didn't have a disk which was > supported, and had the right entries already you sat there for a while > with the calculator ;-) Absolutely. In those days it was all about CHS numbers (I also cut my teeth with 0.12 floppies and then SLS, I recently found my X1-X10 “white” floppies with the X11 packages…). Arrigo From chet.ramey at case.edu Wed Feb 7 23:14:46 2018 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 7 Feb 2018 08:14:46 -0500 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: Message-ID: <882cd6b6-aa5c-2576-bdb6-a229542caacc@case.edu> On 2/7/18 3:27 AM, Wesley Parish wrote: > On 2/7/18, Dan Stromberg wrote: >> IMO: >> 1) It kinda did catch on, in the form of macOS, but there was a time >> when it was nearly dead as the major vendors moved to System V. For >> some reason, Sun was the last major vendor to make the move, but they >> caught most of the flack. > > And for what it's worth, the iPhone. IIRC, a nephew once showed me a > bash prompt on his iPhone and some nifty tricks he was teaching > himself with it. iOS and tvOS are derivatives of macOS, so the iphone/ipad/apple tv all run sort-of-BSD. I'm not as sure about watchOS, but I believe it's an iOS variant. So yes, you can have Unix running on your watch. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From cym224 at gmail.com Thu Feb 8 00:42:36 2018 From: cym224 at gmail.com (Nemo) Date: Wed, 7 Feb 2018 09:42:36 -0500 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: Message-ID: On 7 February 2018 at 03:27, Wesley Parish wrote: > OS/2 and Windows (including WinNT 3.x) just > added a pretty-pretty interface. OS/2 was more sophisticated than > WinNT's because OS/2 expected to share the hard drive with some other > OS; Microsoft believed it had the computer to itself and is thus not > as sophisticated - but they're still MS/PC/DR DOS writ large. I would disagree with this assessment. NT's VMS heritage has already been discussed. I do not know the heritage of OS/2 but to call it DOS is simply not true. (Among other things, OS/2 did an excellent job of virtualizing dosboxes. We were developing PCMCIA drivers with OS/2 in dosboxes. When one crashed, you simply opened up another and continued.) N. From tytso at mit.edu Thu Feb 8 01:13:47 2018 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 7 Feb 2018 10:13:47 -0500 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: <20180206230254.GB1977@thunk.org> Message-ID: <20180207151347.GA29650@thunk.org> On Tue, Feb 06, 2018 at 08:29:27PM -0500, Clem Cole wrote: > Like you I started with the bits from Linus and it was a little difficult - > lot of DIY - column A, tab B, update this. Then I discovered the first > full ``distro'' that seemed to make sense (Slackware) - which in fact was > similar to BSD at the time (used V7/BSD conventions) and it mostly worked. The lots of DIY period was between 1990 and 1992. At that point we used HJ Lu's boot/root diskette images, and you then manually installed various software packages (emacs, gcc, etc.) by untarring compressed tar files. The very first distribution was MCC Interim Linux (from the University of Manchester) in February 1992. In May 1992 the University of Texas released the TAMU release, and Peter MacDonald released the Softlanding Linux System (SLS). In December 1992 Yggdrasil released their first relase that had X Windows. And Slackware forked off from SLS in mid-1993. > In fact, BSD/386 at that point had a better install and that would get even > better after the suit ended with the fork that Jordan Hubbard and Co did, > but I think that was good. As the 386 installs for a BSD got better, it > pressured the Linux guys to make their stuff even better. And by that > time, Linux pretty much had parity on the kernel side, if not started to > get the lead [Linux supported modules early on, which I think was a > technological development that is overlooked but was huge in making Linux > flexible when it needed to be]. 386BSD 0.0 was released in March 1992, and BSD/386 first release (0.3.1) was in April 1992. Both of there were *after* the very first Linux distribution from the University of Manchester. From what I can see, the reason why the Linux distributions were getting batter was competition from each other: MCC, SLS, Yggdrasil, Slackware, etc. I certainly see anyone who was saying "ooh, we need to improve our distro's installer because 386BSD or BSD/386 is competing with us". Instead, various Linux enthusiasts were posting reviews comparing the ease of installation of MCC vs SLS vs Slackware, etc. > BTW: lets not forgot the larger issue. At this point the > 'better' kernel technology is in Solaris, Tru64 et al.. but that's not > running on PC technology. Few people can afford such a machine for > themselves. Indeed. From http://www.freebsddiary.org/linux.php, "Why is Linux Successful? An Opinion", published at Uniforum NZ in April 1999: "Linux has always had a pragmatic view of hardware, whist the BSDs carried a purist view. When I got my first 386 I had MFM style disk drives. At that the BSDs only supported SCSI. Now SCSI is undoubtedly the correct choice, however it did not match the common hardware profile out in the market. Linux had the advantage for the first three years that I ran it of supporting a more diverse range of hardware than the BSDs. The BSDs assumed you had purchased a machine to run a Unix-style OS on, while Linux assumed you had a machine and wanted to try Unix. Linux was much friendlier to someone just wanting to dip their toes in the water. In this respect Linux did something that the BSDs were unable to do to any great degree - grow the Unix user base." > But then it comes out, the suit was not about copyright, but trade > secrets. We all had been 'mentally contaminated' by the AT&T IP at our > respective colleges and universities. So the court does do the right > thing, and AT&T loses the case. Well, MIT actually had multiple AT&T Licenses which did *not* have the mental contamination clause. That was because MIT steadfastly refused to allow MIT students and staff to be contaminated, and MIT had more friends in high (low) places at AT&T than USL's licensing department. So although the USL's Licensing division was quite frustrated about this, MIT was able to get research grants that included full Unix source licenses all of MIT without the mental contimnation clause. So that means all of the MIT Project Athena Alumni who first looked at Unix sources at MIT would not have been so contaminated. In addition, given that the POSIX.1 1990 specifications was available, a lot of the more advanced system calls were implemented from that, it seems.... dubious that AT&T would have been able to claim that an ANSI/ISO Standard was somehow a trade secret. Given how ridiculous lawyers can be, I'm sure they could *make* such a claim. But whether it would have been laughed out of court is a different question. - Ted From krewat at kilonet.net Thu Feb 8 02:24:02 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 7 Feb 2018 11:24:02 -0500 Subject: [TUHS] Device special files In-Reply-To: References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> Message-ID: medusa# mount | egrep '^/dev' /devices on /devices read/write/setuid/devices/rstchown/dev=9640000 on Fri Jan 19 16:33:07 2018 /dev on /dev read/write/setuid/devices/rstchown/dev=9680000 on Fri Jan 19 16:33:07 2018 /dev/fd on fd read/write/setuid/devices/rstchown/dev=9940001 on Fri Jan 19 16:33:22 2018 medusa# ls -l /dev/rdsk/c1t*d0 lrwxrwxrwx   1 root     root          65 Jan  2  2015 /dev/rdsk/c1t0d0 -> ../../devices/pci at 0,0/pci8086,340b at 4/pci1028,1f10 at 0/sd at 0,0:wd,raw lrwxrwxrwx   1 root     root          65 Jan  2  2015 /dev/rdsk/c1t1d0 -> ../../devices/pci at 0,0/pci8086,340b at 4/pci1028,1f10 at 0/sd at 1,0:wd,raw medusa# uname -a SunOS medusa 5.11 11.3 i86pc i386 i86pc On 2/6/2018 9:06 PM, Dan Cross wrote: > On Tue, Feb 6, 2018 at 8:48 PM, Dave Horsfall > wrote: > > On Wed, 7 Feb 2018, Greg 'groggy' Lehey wrote: > > V3 and earlier still *called* them special files, but it > seems they were essentially just magic inode numbers > (there was no physical file on disk, just any directory > entry with the given inode would be the special file). > > > Isn't that still the case? > > > Wasn't that "devfs" (which Penguin/OS calls "udev")?  I've never > grokked that concept. > > > No. devfs was (is?) a pseudo-filesystem where only special files > corresponding to the devices enumerated by the kernel during > autoconfiguration are present. The contents are synthesized at boot > time and the filesystem is mounted at some canonical location (like > /dev), but is otherwise ephemeral. This is in contrast to the older > /dev, which is usually just a directory on the root filesystem, > wherein one created a number of device files that may (or may not) > correspond to an actual hardware device in the system (remember the > old dance of, "cd /dev && ./MAKEDEV foo" when you added a "foo" onto > your system?). The inodes and directory entries for those files > actually exist in the disk-resident filesystem structures (though of > course data blocks aren't allocated to those files and the inode > doesn't refer to any data blocks). > > My understanding is that udev is an elaboration on devfs on Linux that > includes a rules engine that supports things like assigning set names > to specific devices, setting permissions, group/user ownership and the > like. For example, one can configure a rule so that when USB UART > device with serial number 0xdeadbeef gets attached to the system, it > appears as /dev/console_for_foo, owned by group "fooadmin" and mod > 660. Presumably whoever configured that knows that that serial device > is physically connected to the serial console for "foo". > >         - Dan C. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Thu Feb 8 02:34:40 2018 From: cym224 at gmail.com (Nemo) Date: Wed, 7 Feb 2018 11:34:40 -0500 Subject: [TUHS] Device special files In-Reply-To: References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> Message-ID: [top-post righted] > On 2/6/2018 9:06 PM, Dan Cross wrote: > > On Tue, Feb 6, 2018 at 8:48 PM, Dave Horsfall wrote: >> >> On Wed, 7 Feb 2018, Greg 'groggy' Lehey wrote: >>>> >>>> V3 and earlier still *called* them special files, but it seems they were >>>> essentially just magic inode numbers (there was no physical file on disk, >>>> just any directory entry with the given inode would be the special file). >>> >>> Isn't that still the case? >> >> Wasn't that "devfs" (which Penguin/OS calls "udev")? I've never grokked >> that concept. > > No. devfs was (is?) a pseudo-filesystem where only special files > corresponding to the devices enumerated by the kernel during > autoconfiguration are present. The contents are synthesized at boot time and > the filesystem is mounted at some canonical location (like /dev), but is > otherwise ephemeral. This is in contrast to the older /dev, which is usually > just a directory on the root filesystem, wherein one created a number of > device files that may (or may not) correspond to an actual hardware device > in the system (remember the old dance of, "cd /dev && ./MAKEDEV foo" when > you added a "foo" onto your system?). The inodes and directory entries for > those files actually exist in the disk-resident filesystem structures > (though of course data blocks aren't allocated to those files and the inode > doesn't refer to any data blocks). [...] > - Dan C. > > On 7 February 2018 at 11:24, Arthur Krewat wrote: > medusa# mount | egrep '^/dev' > /devices on /devices read/write/setuid/devices/rstchown/dev=9640000 on Fri > Jan 19 16:33:07 2018 [...] > SunOS medusa 5.11 11.3 i86pc i386 i86pc Further more (5.10 sun4u): File Systems devfs(7FS) NAME devfs - Devices file system DESCRIPTION The devfs filesystem manages a name space of all devices under the Solaris operating environment and is mounted dur- ing boot on the /devices name space. The /devices name space is dynamic and reflects the current state of accessible devices under the Solaris operating environment. The names of all attached device instances are present under /devices. The content under /devices is under the exclusive control of the devfs filesystem and cannot be changed. N. From crossd at gmail.com Thu Feb 8 02:34:21 2018 From: crossd at gmail.com (Dan Cross) Date: Wed, 7 Feb 2018 11:34:21 -0500 Subject: [TUHS] Device special files In-Reply-To: References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> Message-ID: On Wed, Feb 7, 2018 at 11:24 AM, Arthur Krewat wrote: > medusa# mount | egrep '^/dev' > /devices on /devices read/write/setuid/devices/rstchown/dev=9640000 on > Fri Jan 19 16:33:07 2018 > /dev on /dev read/write/setuid/devices/rstchown/dev=9680000 on Fri Jan 19 > 16:33:07 2018 > /dev/fd on fd read/write/setuid/devices/rstchown/dev=9940001 on Fri Jan > 19 16:33:22 2018 > medusa# ls -l /dev/rdsk/c1t*d0 > lrwxrwxrwx 1 root root 65 Jan 2 2015 /dev/rdsk/c1t0d0 -> > ../../devices/pci at 0,0/pci8086,340b at 4/pci1028,1f10 at 0/sd at 0,0:wd,raw > lrwxrwxrwx 1 root root 65 Jan 2 2015 /dev/rdsk/c1t1d0 -> > ../../devices/pci at 0,0/pci8086,340b at 4/pci1028,1f10 at 0/sd at 1,0:wd,raw > medusa# uname -a > SunOS medusa 5.11 11.3 i86pc i386 i86pc > Some more commentary would be useful here, but yeah: Solaris went pretty crazy with the cheez-whiz on this stuff. /devices was the "this is what we found from autoconfiguration at boot time" thingy, and /dev was the "and here are a bunch of symlinks to those things." I don't really remember why they chose to do it that way.... Linux and BSD's devfs (as in 4.4 and its descendants) was rather simpler (pretty much what I described until udev came around and elaborated on the theme). - Dan C. On 2/6/2018 9:06 PM, Dan Cross wrote: > > On Tue, Feb 6, 2018 at 8:48 PM, Dave Horsfall wrote: > >> On Wed, 7 Feb 2018, Greg 'groggy' Lehey wrote: >> >>> V3 and earlier still *called* them special files, but it seems they were >>>> essentially just magic inode numbers (there was no physical file on disk, >>>> just any directory entry with the given inode would be the special file). >>>> >>> >>> Isn't that still the case? >>> >> >> Wasn't that "devfs" (which Penguin/OS calls "udev")? I've never grokked >> that concept. >> > > No. devfs was (is?) a pseudo-filesystem where only special files > corresponding to the devices enumerated by the kernel during > autoconfiguration are present. The contents are synthesized at boot time > and the filesystem is mounted at some canonical location (like /dev), but > is otherwise ephemeral. This is in contrast to the older /dev, which is > usually just a directory on the root filesystem, wherein one created a > number of device files that may (or may not) correspond to an actual > hardware device in the system (remember the old dance of, "cd /dev && > ./MAKEDEV foo" when you added a "foo" onto your system?). The inodes and > directory entries for those files actually exist in the disk-resident > filesystem structures (though of course data blocks aren't allocated to > those files and the inode doesn't refer to any data blocks). > > My understanding is that udev is an elaboration on devfs on Linux that > includes a rules engine that supports things like assigning set names to > specific devices, setting permissions, group/user ownership and the like. > For example, one can configure a rule so that when USB UART device with > serial number 0xdeadbeef gets attached to the system, it appears as > /dev/console_for_foo, owned by group "fooadmin" and mod 660. Presumably > whoever configured that knows that that serial device is physically > connected to the serial console for "foo". > > - Dan C. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Thu Feb 8 02:59:10 2018 From: rminnich at gmail.com (ron minnich) Date: Wed, 07 Feb 2018 16:59:10 +0000 Subject: [TUHS] Device special files In-Reply-To: References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> Message-ID: Well, those are surprising responses for me anyway I guess. Here's the thing about special files. They have an integer 'x' attached to them which basically means "this file represents an index into an internal kernel struct'. Now if you are comfortable with the idea that a file, with a number attached to its metadata, said number representing an index into an array of structs, which has to work for all time and all kernels: then we're just comfortable with different things. 'nuf said. moving right along, when did /dev first appear? On Wed, Feb 7, 2018 at 8:40 AM Nemo wrote: > [top-post righted] > > On 2/6/2018 9:06 PM, Dan Cross wrote: > > > > On Tue, Feb 6, 2018 at 8:48 PM, Dave Horsfall wrote: > >> > >> On Wed, 7 Feb 2018, Greg 'groggy' Lehey wrote: > >>>> > >>>> V3 and earlier still *called* them special files, but it seems they > were > >>>> essentially just magic inode numbers (there was no physical file on > disk, > >>>> just any directory entry with the given inode would be the special > file). > >>> > >>> Isn't that still the case? > >> > >> Wasn't that "devfs" (which Penguin/OS calls "udev")? I've never grokked > >> that concept. > > > > No. devfs was (is?) a pseudo-filesystem where only special files > > corresponding to the devices enumerated by the kernel during > > autoconfiguration are present. The contents are synthesized at boot time > and > > the filesystem is mounted at some canonical location (like /dev), but is > > otherwise ephemeral. This is in contrast to the older /dev, which is > usually > > just a directory on the root filesystem, wherein one created a number of > > device files that may (or may not) correspond to an actual hardware > device > > in the system (remember the old dance of, "cd /dev && ./MAKEDEV foo" when > > you added a "foo" onto your system?). The inodes and directory entries > for > > those files actually exist in the disk-resident filesystem structures > > (though of course data blocks aren't allocated to those files and the > inode > > doesn't refer to any data blocks). > [...] > > - Dan C. > > > > > On 7 February 2018 at 11:24, Arthur Krewat wrote: > > medusa# mount | egrep '^/dev' > > /devices on /devices read/write/setuid/devices/rstchown/dev=9640000 on > Fri > > Jan 19 16:33:07 2018 > [...] > > SunOS medusa 5.11 11.3 i86pc i386 i86pc > > Further more (5.10 sun4u): > > File Systems devfs(7FS) > > NAME > devfs - Devices file system > > DESCRIPTION > The devfs filesystem manages a name space of all devices > under the Solaris operating environment and is mounted dur- > ing boot on the /devices name space. > > The /devices name space is dynamic and reflects the current > state of accessible devices under the Solaris operating > environment. The names of all attached device instances are > present under /devices. > > The content under /devices is under the exclusive control of > the devfs filesystem and cannot be changed. > > N. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobozo at gmail.com Thu Feb 8 02:59:36 2018 From: nobozo at gmail.com (Jon Forrest) Date: Wed, 7 Feb 2018 08:59:36 -0800 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: <20180207151347.GA29650@thunk.org> References: <20180206230254.GB1977@thunk.org> <20180207151347.GA29650@thunk.org> Message-ID: <37741189-f19f-5e8f-e91b-92657d3ee72a@gmail.com> On 2/7/2018 7:13 AM, Theodore Ts'o wrote: > Well, MIT actually had multiple AT&T Licenses which did *not* have the > mental contamination clause. This was also an issue at UC Berkeley, but with Microsoft Windows. I was working in the Postgres group which Microsoft was very generously supporting with software. There were discussions about getting a Windows source license but the CS department didn't want their people becoming contaminated. I remember the first time I saw Linux. Ironically it was on the desktop machine of a guy who was in the BSD developers office. Jon Forrest From clemc at ccc.com Thu Feb 8 03:27:34 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 7 Feb 2018 12:27:34 -0500 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: <20180207151347.GA29650@thunk.org> References: <20180206230254.GB1977@thunk.org> <20180207151347.GA29650@thunk.org> Message-ID: Again I agree with much of what you said. But there are a couple of things your are forgetting.... On Wed, Feb 7, 2018 at 10:13 AM, Theodore Ts'o wrote: > > > Well, MIT actually had multiple AT&T Licenses which did *not* have the > mental contamination clause. I fear, you are ​falling into an error of thinking about UNIX as the *source cod* *​e from Murray Hill* as opposed the* intellectual property *->* i.e.* an *implementation* *vs,* *the ideas* of how to build the a computing system. The ideas was the point of the AT&T case ​ with BSD (as a number of people including some on this list have said -- AT&T was talking about trade secrets - which are ideas). Note I failed to understand this difference myself at the time, most of us did also I fear because as you said -- we all just wanted Unix for a PC based platform that we own for ourselves. However, I believe that understanding that difference is why the AT&T *vs*. BSDi/UCB case is so important to history, ​ and Linux's history in particular.​ What ​ doomed AT&T was they were required by law to release the IP (1956 consent decree)​ ​ to any interested parties for a fair and reasonable license, but they had to continue to make their IP available to the academic community at no charge [I site the paper from one the law reviews that is really detailed, so I'm summaries the results. Send me a message offline if you want to know more]. The fact is this worked out fine for technologies like the transistor. People licensed it, AT&T never really made the kind of money, TI, Fairchild, *etc* did, but it was AT&T IP that used. Folks took out a license and the wider electronics industry was born from that invention. However, later AT&T's own personal start to publish papers and books about the ​ UNIX​ ​IP in the open literature. ​ It is these two acts together that the court said, meant that AT&T could not longer claim trade secret - they licensed it AND they told people about it. They 'taught' the world - mentally contaminated us all - with their ideas. Linus for instance says he had Maury Bach's book when he was building Linux and I have been lead to understand that Maury's book was used as evidence in the case ( as was the original 1974 paper).​ The point is once the IP was generally known, it was no longer a secret and AT&T could not claim same. It also why the famous 6 files had to be removed from the implementation that BSD had. Those were bases on the copyright ownership and AT&T was allowed to claim copyright (as many people like me, had expected them). They just could not claim copyright on the parts that UCB had developed - even if they were the same ideas (IP) and AT&Ts. So, I'm trying to be careful... this discussion was how did the Linux implementation of the UNIX IP displace the BSD implementation of the same IP? I believe that it is a classic example of a Christensen disruption... a new market (PC based UNIX) was created nd people wanted something to fill it. Linux was there to file it and did a great job and AT&T stopped any alternative (BSD on same) long enough, that it did not matter - Linux had filled the void well. The sustaining technology ​ (BSD) stays with those that could afford it on their platforms (Sun, DEC, *etc*...)​ Stepping back a bit ... an interesting question is what about Sun's 386 attempts? The original RoadRunner was a pretty slick machine. But here is where I think they got stuck the same way DEC and other did. They made their money on the HW but it was the SW that drove the sale. So they wanted to SPARC et al. So they kill RR. By, the time of they retrench and Solaris/386 was released for "commodity HW", again - too expensive for the low end and they did not want the Intel chips on the servers to compete with their own HW. Clem As a minor footnote, I've always wonder about the SCO case being anything but a delay tactic against Linux. Give the courts results from the AT&T* vs*. BSDi case, I'm personally surprised they got as far as they did. I really would expected to be tossed out at the start (hut Im not a lawyer of course). Clearly, the courts had declared that ideas were free and clear for anyone to use. So how SCO could have claimed anything against anyone, I find hard to fathom. Again the courts got it right ​, but it took a loot of time and effort for then to decide something that the another court had already decided.​ ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tih at hamartun.priv.no Thu Feb 8 03:52:23 2018 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Wed, 07 Feb 2018 18:52:23 +0100 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: <20180207151347.GA29650@thunk.org> (Theodore Ts'o's message of "Wed, 7 Feb 2018 10:13:47 -0500") References: <20180206230254.GB1977@thunk.org> <20180207151347.GA29650@thunk.org> Message-ID: Theodore Ts'o writes: > Indeed. From http://www.freebsddiary.org/linux.php, "Why is Linux > Successful? An Opinion", published at Uniforum NZ in April 1999: > > "Linux has always had a pragmatic view of hardware, whist the BSDs > carried a purist view. When I got my first 386 I had MFM style > disk drives. At that the BSDs only supported SCSI. [...] I wonder when that was... *My* first 386 was the one I ran 386bsd on, and later, when it came into existence, NetBSD. It had good old ST506 type disk drives (20MB MFM drives, but I formatted them RLL to get 30MB out of them). Managed to get four such drives onto it, actually, by modifying the driver to support multiple controllers, and then rewiring one controller to hook it to a different interrupt line on the ISA bus. See item 5.1.7 here: http://www.csci.csusb.edu/dick/doc/386bsd.FAQ.txt -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From dot at dotat.at Thu Feb 8 04:01:57 2018 From: dot at dotat.at (Tony Finch) Date: Wed, 7 Feb 2018 18:01:57 +0000 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> Message-ID: Dan Cross wrote: > > [...] But much VMS, whatever HP minicomputer stuff was floating around > (MPE?) and all VM/CMS (I guess it was actually VM/ESA by that time) > disappeared; VAXstations, serial terminals and 3179G's were all replaced > by PCs running Windows and the users were replaced by these smiling > robots. It was weird. > > Somehow, most of the Unix people managed to escape. I wonder why? [...] > > I wonder, too, if Unix networking didn't play a major role. I have this dim > sense that NT was designed for a world in which it was still assumed that > the OSI suite was going to win the networking wars. [...] I was in my late teens around that time but I got the impression that in the early to mid 1990s when this shift was happening, networking was moving to IP and all the IP software was Unix - certainly it was the only option if you wanted to run network services at the scale of a University or ISP. At the same time Windows was all about workgroup-scale office networking. I don't think their network protocols were OSI but Exchange was based on X.400 and to this day still only does Internet mail grudgingly. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Lundy, Fastnet, Irish Sea: West or southwest 4 or 5, increasing 6 at times. Slight or moderate, occasionally rough except in Irish Sea, becoming very rough later in southwest Fastnet. Occasional rain. Good, occasionally poor. From steffen at sdaoden.eu Thu Feb 8 04:36:07 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 07 Feb 2018 19:36:07 +0100 Subject: [TUHS] Device special files In-Reply-To: References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> <20180207021405.CF19B156E812@mail.bitblocks.com> Message-ID: <20180207183607.E3NiH%steffen@sdaoden.eu> Dave Horsfall wrote: |On Tue, 6 Feb 2018, Bakul Shah wrote: |>> Wasn't that "devfs" (which Penguin/OS calls "udev")? I've never |>> grokked that concept. ... |> mknod ... |Umm, I've known that since Edition 5; I'm not exactly new to Unix, you |know... ... |> So the point of devfs is to avoid having to do mknod manually and yet |> provide access to all found devices from the userland. As a side effect ... |That makes sense; bit of a pain when a USB device suddenly disappears just |I unplugged it, though... That was indeed one of my a-ha! moments with FreeBSD, coming from Linux! All those files in /dev and i did not know anything about anything -- which of all those many hundreds of files is actually for real? And then FreeBSD came over with the devfs and there even was a really enlightening paper, which is still shipped with FreeBSD (share/doc/papers/devfs/paper.me). From Linux which back then had the GNU LibC info file and something almost exclusively for kernel hackers in the kernel documentation directory and otherwise almost nil, to FreeBSD and a document which starts An outstanding novelty in UNIX at its introduction was the notion of ``a file is a file is a file and even a device is a file.'' Going from ``hardware only changes when the DEC Field engineer is here'' to ``my toaster has USB'' has put serious strain on the rather crude implementation of the ``devices as files'' concept, an implementation which has survived practically unchanged for 30 years in most UNIX variants. Starting from a high-level view of devices and the semantics that have grown around them over the years, this paper takes the audience on a grand tour of the redesigned FreeBSD device-I/O system, to convey an overview of how it all fits together, and to explain why things ended up as they did, how to use the new features and in particular how not to. That was fantastic, that was enlightening, and that actually seemed as such a brave move of entire FreeBSD (and it was, right)! It is still a good read. And so: suddenly i had so few files in /dev, so few that i even could start looking around a bit! --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) From bakul at bitblocks.com Thu Feb 8 04:50:27 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 7 Feb 2018 10:50:27 -0800 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> Message-ID: > On Feb 6, 2018, at 5:54 PM, Dan Cross wrote: > > But much VMS, whatever HP minicomputer stuff was floating around (MPE?) and all VM/CMS (I guess it was actually VM/ESA by that time) disappeared; VAXstations, serial terminals and 3179G's were all replaced by PCs running Windows and the users were replaced by these smiling robots. It was weird. “Attack of the killer micros”! Anyone remember Eugene Brooks’ 1989 comp.arch article? Brooks was talking about this in relation to supercomputers but the killer micros first killed the minicomputer market. > Somehow, most of the Unix people managed to escape. ... > I wonder, too, if Unix networking didn't play a major role. I have this dim sense that NT was designed for a world in which it was still assumed that the OSI suite was going to win the networking wars. When, almost to everyone's surprise, the Internet ended up taking off Unix was already well-positioned to respond and NT had to play catch up. In 1994 or so, a friend who had been at Microsoft for many years tried to convince me that Windows networking was going to win. Microsoft’s reality distortion field being very strong in Redmond, he simply couldn’t see how windows networking would *not* succeed (I saw similar RDF effects at other big companies). A week late Bill Gates announced Windows will fully support IP. By then most of the internet related services were already running on unix. And anyone technically savvy could bring Linux or BSD for free on an inexpensive PC. From itz at very.loosely.org Thu Feb 8 05:07:59 2018 From: itz at very.loosely.org (Ian Zimmerman) Date: Wed, 7 Feb 2018 11:07:59 -0800 Subject: [TUHS] Device special files In-Reply-To: <20180207183607.E3NiH%steffen@sdaoden.eu> References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> <20180207021405.CF19B156E812@mail.bitblocks.com> <20180207183607.E3NiH%steffen@sdaoden.eu> Message-ID: <20180207190759.7sjrf6ta4m7sct3d@matica.foolinux.mooo.com> On 2018-02-07 19:36, Steffen Nurpmeso wrote: > Going from ``hardware only changes when the DEC Field engineer is > here'' to ``my toaster has USB'' has put serious strain on the rather > crude implementation of the ``devices as files'' concept Well, if you don't try to connect your toaster to the computer, you don't have this problem :-) I had a self-maintained Linux system (ie. no distribution) until about 2000. I had no problem understanding what the two dozen /dev/ entries were for. I even wrote a better (table driven) makedev implementation and I tried to get it into Debian, but by that time rumors of devfs were already on the way so it wasn't worth a transition to them. The real problem with static /dev is on the development side IMO - managing the namespace of device names and major/minor numbers. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet, fetch the TXT record for the domain. From itz at very.loosely.org Thu Feb 8 05:07:59 2018 From: itz at very.loosely.org (Ian Zimmerman) Date: Wed, 7 Feb 2018 11:07:59 -0800 Subject: [TUHS] Device special files In-Reply-To: <20180207183607.E3NiH%steffen@sdaoden.eu> References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> <20180207021405.CF19B156E812@mail.bitblocks.com> <20180207183607.E3NiH%steffen@sdaoden.eu> Message-ID: <20180207190759.7sjrf6ta4m7sct3d@matica.foolinux.mooo.com> On 2018-02-07 19:36, Steffen Nurpmeso wrote: > Going from ``hardware only changes when the DEC Field engineer is > here'' to ``my toaster has USB'' has put serious strain on the rather > crude implementation of the ``devices as files'' concept Well, if you don't try to connect your toaster to the computer, you don't have this problem :-) I had a self-maintained Linux system (ie. no distribution) until about 2000. I had no problem understanding what the two dozen /dev/ entries were for. I even wrote a better (table driven) makedev implementation and I tried to get it into Debian, but by that time rumors of devfs were already on the way so it wasn't worth a transition to them. The real problem with static /dev is on the development side IMO - managing the namespace of device names and major/minor numbers. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet, fetch the TXT record for the domain. From crossd at gmail.com Thu Feb 8 05:21:46 2018 From: crossd at gmail.com (Dan Cross) Date: Wed, 7 Feb 2018 14:21:46 -0500 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: <20180206230254.GB1977@thunk.org> <20180207151347.GA29650@thunk.org> Message-ID: On Wed, Feb 7, 2018 at 12:27 PM, Clem Cole wrote: > Again I agree with much of what you said. But there are a couple of > things your are forgetting.... > > On Wed, Feb 7, 2018 at 10:13 AM, Theodore Ts'o wrote: > >> >> >> Well, MIT actually had multiple AT&T Licenses which did *not* have the >> mental contamination clause. > > I fear, you are > ​falling > into an > error of thinking about UNIX as the *source cod* > *​e from Murray Hill* as opposed the* intellectual property *->* i.e.* an > *implementation* *vs,* *the ideas* of how to build the a computing > system. The ideas was > the point of the AT&T case > ​ with BSD (as a number of people including some on this list have said -- > AT&T was talking about trade secrets - which are ideas). Note I failed to > understand this difference myself at the time, most of us did also I fear > because as you said -- we all just wanted Unix for a PC based platform that > we own for ourselves. However, I believe that understanding that > difference is why the AT&T *vs*. BSDi/UCB case is so important to > history, > ​ and Linux's history in particular.​ > > > What > ​ doomed > AT&T was they were required by law to release the IP (1956 consent > decree)​ > ​ to any interested parties for a fair and reasonable license, but they > had to continue to make their IP available to the academic community at no > charge [I site the paper from one the law reviews that is really detailed, > so I'm summaries the results. Send me a message offline if you want to > know more]. The fact is this worked out fine for technologies like the > transistor. People licensed it, AT&T never really made the kind of money, > TI, Fairchild, *etc* did, but it was AT&T IP that used. Folks took out a > license and the wider electronics industry was born from that invention. > > However, later > AT&T's own personal start to publish papers and books about the > ​ UNIX​ > > ​IP > in the open literature. > ​ It is these two acts together that the court said, meant that AT&T > could not longer claim trade secret - they licensed it AND they told people > about it. They 'taught' the world - mentally contaminated us all - with > their ideas. Linus for instance says he had Maury Bach's book when he was > building Linux and I have been lead to understand that Maury's book was > used as evidence in the case ( as was the original 1974 paper).​ The point > is once the IP was generally known, it was no longer a secret and AT&T > could not claim same. It also why the famous 6 files had to be removed > from the implementation that BSD had. Those were bases on the copyright > ownership and AT&T was allowed to claim copyright (as many people like me, > had expected them). They just could not claim copyright on the parts that > UCB had developed - even if they were the same ideas (IP) and AT&Ts. > > So, I'm trying to be careful... this discussion was how did the Linux > implementation of the UNIX IP displace the BSD implementation of the same > IP? I believe that it is a classic example of a Christensen disruption... > a new market (PC based UNIX) was created nd people wanted something to fill > it. Linux was there to file it and did a great job and AT&T stopped > any alternative (BSD on same) long enough, that it did not matter - Linux > had filled the void well. The sustaining > technology > ​ (BSD) stays with those that could afford it on their platforms (Sun, > DEC, *etc*...)​ > > > Stepping back a bit ... an interesting question is what about Sun's 386 > attempts? The original RoadRunner was a pretty slick machine. But here is > where I think they got stuck the same way DEC and other did. They made > their money on the HW but it was the SW that drove the sale. So they > wanted to SPARC et al. So they kill RR. By, the time of they retrench and > Solaris/386 was released for "commodity HW", again - too expensive for the > low end and they did not want the Intel chips on the servers to compete > with their own HW. > > Clem > > As a minor footnote, I've always wonder about the SCO case being anything > but a delay tactic against Linux. Give the courts results from the AT&T* > vs*. BSDi case, I'm personally surprised they got as far as they did. I > really would expected to be tossed out at the start (hut Im not a lawyer of > course). Clearly, the courts had declared that ideas were free and clear > for anyone to use. So how SCO could have claimed anything against anyone, > I find hard to fathom. Again the courts got it > right > ​, but it took a loot of time and effort for then to decide something that > the another court had already decided.​ > Clem's entire post is too good not to quote in its entirety. But it raises a question I've had for some time: what about clones like COHERENT? COHERENT was kind of primitive by BSD (and even Linux) standards, but had a lot of functionality and was pretty cheap (4 floppies for $99 or so) and ran on more or less standard PC hardware; I'm surprised more people weren't running it at home. Also, it seems that they'd weathered the storm of an AT&T legal challenge managed to stay afloat, as related in Dennis Ritchie's famous telling of it: https://groups.google.com/forum/#!msg/alt.folklore.computers/_ZaYeY46eb4/5B41Uym6d4QJ I wonder why the unchallenged existence of Unix clones like COHERENT and Minix wasn't enough to kill the trade secret argument before it even got out of the gate. Clem, is your paper online somewhere? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Thu Feb 8 05:31:21 2018 From: cym224 at gmail.com (Nemo) Date: Wed, 7 Feb 2018 14:31:21 -0500 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: <20180206230254.GB1977@thunk.org> <20180207151347.GA29650@thunk.org> Message-ID: On 07/02/2018, Clem Cole wrote (in part): > As a minor footnote, I've always wonder about the SCO case being anything > but a delay tactic against Linux. Give the courts results from the AT&T > vs. BSDi case, I'm personally surprised they got as far as they did. I > really would expected to be tossed out at the start (hut Im not a lawyer of > course). Clearly, the courts had declared that ideas were free and clear > for anyone to use. So how SCO could have claimed anything against anyone, > I find hard to fathom. Again the courts got it right​, but it took a loot of time > and effort for then to decide something that the another court had already decided.​ The entire painful journey can be read on Groklaw and well worth reading when you have a spare month or so. N. From tytso at mit.edu Thu Feb 8 05:49:57 2018 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 7 Feb 2018 14:49:57 -0500 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: <20180206230254.GB1977@thunk.org> <20180207151347.GA29650@thunk.org> Message-ID: <20180207194957.GE29650@thunk.org> On Wed, Feb 07, 2018 at 12:27:34PM -0500, Clem Cole wrote: > I fear, you are ​falling into an error of thinking about UNIX as the *source cod* > *​e from Murray Hill* as opposed the* intellectual property *->* i.e.* an > *implementation* *vs,* *the ideas* of how to build the a computing system. So what exactly were they claiming? An interface copyright on open(2), creat(2), etc.? Were they they trying to claim that the concept of an inode was at trade secret? How the Bourne Shell worked? How to implement a virtual memory subsystem? The very first version of POSIX 1003.1 was released in 1988. This is four years befure the AT&T lawsuit. So between the ideas found in say, Multics, and those things which were promulgated in an international standard --- which included AT&T representatives --- exactly what would be covered under Trade Secret law? > ​ It is these two acts together that the court said, meant that AT&T could > not longer claim trade secret - they licensed it AND they told people about > it. That's basic Trade Secret law. That's *not* a new and novel law that the court was promulgating. It's a basic legal principle taught to undergraduates --- at least those who take "IT Law for Managers" offered by the MIT Sloan School :-). (I always tell students that I am mentoring that you they should strongly consider taking a basic legal class and learn enough about accounting to read a balance sheet and income statement). More to the point, Trade Secret works differently from Copyright or Patent. If Alice reveals to Bob a trade secret under an NDA, and Bob reveals it to the world, Alice can sue *Bob* for gazillions. But if Bob publishes the trade secret in a Usenix ATC paper, and Charlie learns about it from said Usenix ATC paper, and there is no NDA between Alice and Charlie --- Alice does *not* have the power to sue Charlie regarding the trade secret. Hence, the concept of "AT&T mentally contaminating the world" is simply not how Trade Secret law works. And that is a reason why the wise I/T manager might have to trade off using Trade Secret (where protection lasts as long as you can keep it a sekrit) versus Patent (where the protection survives even after it is publically disclosed --- and you do have to disclose it --- but the protection is time-limited). - Ted From crossd at gmail.com Thu Feb 8 05:53:10 2018 From: crossd at gmail.com (Dan Cross) Date: Wed, 7 Feb 2018 14:53:10 -0500 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: <20180207194957.GE29650@thunk.org> References: <20180206230254.GB1977@thunk.org> <20180207151347.GA29650@thunk.org> <20180207194957.GE29650@thunk.org> Message-ID: On Wed, Feb 7, 2018 at 2:49 PM, Theodore Ts'o wrote: > On Wed, Feb 07, 2018 at 12:27:34PM -0500, Clem Cole wrote: > > I fear, you are ​falling into an error of thinking about UNIX as the > *source cod* > > *​e from Murray Hill* as opposed the* intellectual property *->* i.e.* an > > *implementation* *vs,* *the ideas* of how to build the a computing > system. > > So what exactly were they claiming? An interface copyright on > open(2), creat(2), etc.? Were they they trying to claim that the > concept of an inode was at trade secret? How the Bourne Shell worked? > How to implement a virtual memory subsystem? > > The very first version of POSIX 1003.1 was released in 1988. This is > four years befure the AT&T lawsuit. So between the ideas found in > say, Multics, and those things which were promulgated in an > international standard --- which included AT&T representatives --- > exactly what would be covered under Trade Secret law? > > > ​ It is these two acts together that the court said, meant that AT&T > could > > not longer claim trade secret - they licensed it AND they told people > about > > it. > > That's basic Trade Secret law. That's *not* a new and novel law that > the court was promulgating. It's a basic legal principle taught to > undergraduates --- at least those who take "IT Law for Managers" > offered by the MIT Sloan School :-). (I always tell students that I > am mentoring that you they should strongly consider taking a basic > legal class and learn enough about accounting to read a balance sheet > and income statement). > > More to the point, Trade Secret works differently from Copyright or > Patent. If Alice reveals to Bob a trade secret under an NDA, and Bob > reveals it to the world, Alice can sue *Bob* for gazillions. But if > Bob publishes the trade secret in a Usenix ATC paper, and Charlie > learns about it from said Usenix ATC paper, and there is no NDA > between Alice and Charlie --- Alice does *not* have the power to sue > Charlie regarding the trade secret. > > Hence, the concept of "AT&T mentally contaminating the world" is > simply not how Trade Secret law works. And that is a reason why the > wise I/T manager might have to trade off using Trade Secret (where > protection lasts as long as you can keep it a sekrit) versus Patent > (where the protection survives even after it is publically disclosed > --- and you do have to disclose it --- but the protection is > time-limited). Yes: AT&T's legal argument was bad. Isn't that why they lost the lawsuit? :-D - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Feb 8 06:17:43 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 8 Feb 2018 07:17:43 +1100 (EST) Subject: [TUHS] RIP John von Neumann Message-ID: We lost computer pioneer John von Neumann on this day in 1957; the "von Neumann" architecture (stored program etc) is the basis of all modern computers, and he almost certainly borrowed it from Charles Babbage. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From tytso at mit.edu Thu Feb 8 06:26:54 2018 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 7 Feb 2018 15:26:54 -0500 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: <20180206230254.GB1977@thunk.org> <20180207151347.GA29650@thunk.org> <20180207194957.GE29650@thunk.org> Message-ID: <20180207202654.GF29650@thunk.org> On Wed, Feb 07, 2018 at 02:53:10PM -0500, Dan Cross wrote: > > Yes: AT&T's legal argument was bad. Isn't that why they lost the lawsuit? > :-D > AT&T's legal argument was against BSDI and UCB. People misunderstanding the difference between Patent law and Trade Secret Law into thinking that we were all contaminated and Unix was Doomed (tm), wasn't, as far as I know, part of AT&T's lawsuit. In the Alice/Bob/Charlie example I gave, the lawsuit was "Alice can sue Bob for gazillions". The assumption that Alice could then sue Charlie who learned about the "trade secret" in a Usenix ATC paper is a fear that others had, and wasn't part of the Alice versus Bob lawsuit. And *that's* why it was so important that MIT's Unix license didn't have the trade secret clause. - Ted From clemc at ccc.com Thu Feb 8 07:06:55 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 7 Feb 2018 16:06:55 -0500 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: <20180207202654.GF29650@thunk.org> References: <20180206230254.GB1977@thunk.org> <20180207151347.GA29650@thunk.org> <20180207194957.GE29650@thunk.org> <20180207202654.GF29650@thunk.org> Message-ID: On Wed, Feb 7, 2018 at 3:26 PM, Theodore Ts'o wrote: > > And *that's* why it was so important that MIT's Unix license didn't > have the trade secret clause. > ​But the court ruled that AT&T had made the ideas public so the any other clause one way or the other does not matter. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 8 07:24:26 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 7 Feb 2018 16:24:26 -0500 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: <20180206230254.GB1977@thunk.org> <20180207151347.GA29650@thunk.org> Message-ID: On Wed, Feb 7, 2018 at 2:21 PM, Dan Cross wrote: > > > I wonder why the unchallenged existence of Unix clones like COHERENT and > Minix wasn't enough to kill the trade secret argument before it even got > out of the gate. > It was a V7 clone (like Minix). I've forgotten but I thought it originally ran on 286 (again like Minix). ​But, ​ I'm not sure why it was not as popular. Maybe the difference was that it was a V7 clone and closed source as it were ​, while ​ Minix was a tad cheaper and you got the sources. ​ Also it (again like Minix) was floppy based. By that time AT&T UNIX or BSD Unix is running on 'JAWS' [just another workstation] those systems tended to have disks in them and UNIX really need one in practice. As Ted points out and I agree (as pointed out by Jolitiz in his DDJ articles, I was partly responsible for the original BSD/386 hard disk driver)​, the Linux support for ST506 and ESDI disks was very early and actually pretty stable in the earliest versions of Linux. In fact, because I was familiar ​with the HD stuff from BSD/386 it was one the first things I had personally checked out and was pleased to see was solid.​ > > Clem, is your paper online somewhere? > ​Not yet - I'll send out an URL when the conference papers all go on line, but if you privately send me a message I'll send you a PDF. Note, a couple of you have an earlier (near final) draft, so send me a note if you want the printed one. The differences are minor-> some clarification/some small rewording to dealing with English colloquialisms that were not understood by the French. ​ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 8 07:31:56 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 7 Feb 2018 16:31:56 -0500 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: <20180207202654.GF29650@thunk.org> References: <20180206230254.GB1977@thunk.org> <20180207151347.GA29650@thunk.org> <20180207194957.GE29650@thunk.org> <20180207202654.GF29650@thunk.org> Message-ID: On Wed, Feb 7, 2018 at 3:26 PM, Theodore Ts'o wrote: > > AT&T's legal argument was against BSDI and UCB. People > misunderstanding the difference between Patent law and Trade Secret > Law into thinking that we were all contaminated and Unix was Doomed > (tm), wasn't, as far as I know, part of AT&T's lawsuit. > Sadly, yes it was so... (and I still have my 'mentally contaminated' button).​ So now you do know, Again this is why (and I have asked counsel this question) so what if they had won? I have been advised that all UNIX implementations would have been subjected to the ruling world-wide or at least subject to a number of treaties enforce in the USA and the EU (although how many AT&T would have litigated against we will never know). My friends that are lawyers that have examined this question have said in practice it would have been very hard to pursue (which may have been part of the reason the court did what it did - i.e. the test could this be enforced). It would have been very different world that I am fairly sure. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Feb 8 08:04:36 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 8 Feb 2018 09:04:36 +1100 (EST) Subject: [TUHS] Device special files In-Reply-To: <20180207183607.E3NiH%steffen@sdaoden.eu> References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> <20180207021405.CF19B156E812@mail.bitblocks.com> <20180207183607.E3NiH%steffen@sdaoden.eu> Message-ID: On Wed, 7 Feb 2018, Steffen Nurpmeso wrote: > And then FreeBSD came over with the devfs and there even was a really > enlightening paper, which is still shipped with FreeBSD > (share/doc/papers/devfs/paper.me). Hmmm... My box (10.4-RELEASE-p3) only has papers/devfs.ascii.gz, but yeah, it's a good read; thanks. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From clemc at ccc.com Thu Feb 8 08:05:05 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 7 Feb 2018 17:05:05 -0500 Subject: [TUHS] Device special files In-Reply-To: <20180207190759.7sjrf6ta4m7sct3d@matica.foolinux.mooo.com> References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> <20180207021405.CF19B156E812@mail.bitblocks.com> <20180207183607.E3NiH%steffen@sdaoden.eu> <20180207190759.7sjrf6ta4m7sct3d@matica.foolinux.mooo.com> Message-ID: On Wed, Feb 7, 2018 at 2:07 PM, Ian Zimmerman wrote: > > > The real problem with static /dev is on the development side IMO - > managing the namespace of device names and major/minor numbers. ​And that is the issue I think that Ron is reacting too. One of the lines I have had about UNIX development is the number if namespaces its has. If you try to develop something like Single System Image Clusters (check out OpenSSI.org) you'll hit all of the namespaces. Let me see how many I can remember quickly.. 1. file system 2. per device inumbers for storage 3. device major numbers 4. per device minor numbers 5. pid 6. gid 7. sockets 8. port numbers within sockets per protocol 9. system V semaphores 10. system V shared memory​ I'll stop here, you get the idea... Ron is right managing the major/minor number externally which have internal meaning to the kernel can be quite an issue. Although, in fairness, it has worked amazing well for over 40 years. It was a simple solution and did not take take up a lot of space in the kernel to implement. I'm not sure for the PDP-11, I would have wanted much more. One might suggest it was pretty damned elegant for the time. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Thu Feb 8 08:38:53 2018 From: rminnich at gmail.com (ron minnich) Date: Wed, 07 Feb 2018 22:38:53 +0000 Subject: [TUHS] Device special files In-Reply-To: References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> <20180207021405.CF19B156E812@mail.bitblocks.com> <20180207183607.E3NiH%steffen@sdaoden.eu> <20180207190759.7sjrf6ta4m7sct3d@matica.foolinux.mooo.com> Message-ID: On Wed, Feb 7, 2018 at 2:06 PM Clem Cole wrote: > One might suggest it was pretty damned elegant for the time. > yes, it was quite fine then. Getting distributed systems right is not simple. There have been lots of efforts to get it right by larding more and more software over what's already there. It can be made to work but it's never very nice. I tend to prefer the take stuff away approach myself, but to each his own. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Thu Feb 8 08:48:52 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 7 Feb 2018 17:48:52 -0500 Subject: [TUHS] Device special files In-Reply-To: References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> <20180207021405.CF19B156E812@mail.bitblocks.com> <20180207183607.E3NiH%steffen@sdaoden.eu> <20180207190759.7sjrf6ta4m7sct3d@matica.foolinux.mooo.com> Message-ID: <01b001d3a065$d3ee30a0$7bca91e0$@ronnatalie.com> Even notwithstanding distributed systems, dev nodes have some interesting problems. At Johns Hopkins we allowed users to mount removable disks (RK05 packs). There were hacks made to the mount program to allow no privileged users to run it. We had to disable dev nodes and setuid/setuid files from working on other than the root filesystem. Amusingly, we still found bugs. I was griping that people would mount on just any directory on the system, the mtab wouldn’t show the absolute path. I suggested we chdir to / early on or better yet, cd to /dev. That way I wouldn’t have to type /dev/ on to the device name. I say the user would have to give an absolute path anyhow since there’s nothing on /dev to mount on. Well my roommate immediately tries to prove me wrong. He tries passing various devnodes and regular files that happen to sit in /dev. Then he gets the great idea of mounting on /dev/. It works, but now we have no way to unmount it. We had to reboot the machine. I quickly modified mount to require an EMPTY directory owned by the user to be required for mounting. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Thu Feb 8 09:06:24 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 07 Feb 2018 15:06:24 -0800 Subject: [TUHS] Device special files In-Reply-To: Your message of "Wed, 07 Feb 2018 17:05:05 -0500." References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> <20180207021405.CF19B156E812@mail.bitblocks.com> <20180207183607.E3NiH%steffen@sdaoden.eu> <20180207190759.7sjrf6ta4m7sct3d@matica.foolinux.mooo.com> Message-ID: <20180207230639.3EE6C156E813@mail.bitblocks.com> On Wed, 07 Feb 2018 17:05:05 -0500 Clem Cole wrote: > > One of the lines I have had about UNIX development is the number if > namespaces its has. If you try to develop something like Single System > Image Clusters (check out OpenSSI.org) you'll hit all of the namespaces. > > Let me see how many I can remember quickly.. > > 1. file system > 2. per device inumbers for storage > 3. device major numbers > 4. per device minor numbers > 5. pid > 6. gid > 7. sockets > 8. port numbers within sockets per protocol > 9. system V semaphores > 10. system V shared memory Most all of these are intrinsic or unavoidable. You can use strings instead of table indices but still the same. And some of these have sub-namespaces. This is why plan9's mountable namespaces is such a neat solution. Too bad Unix just stole /proc & /dev/fd.... And this can be added devfs is too big a sledgehammer (+ it needs /etc/devfs.conf for permissions and ownership using its own DSL). For example, names of devices not accessible in a jail still show up there. From dave at horsfall.org Thu Feb 8 10:39:01 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 8 Feb 2018 11:39:01 +1100 (EST) Subject: [TUHS] Device special files In-Reply-To: References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> Message-ID: On Wed, 7 Feb 2018, Arthur Krewat wrote: > My understanding is that udev is an elaboration on devfs on Linux that > includes a rules engine that supports things like assigning set names to > specific devices, setting permissions, group/user ownership and the > like. [...] Thanks for that; I only have the Penguin for porting porpoises, not for daily use. I write stuff on the Mac (because the USB ports are right in front of me), test it on a known reliable server like FreeBSD, then go and see what the penguins have broken this time...[*] [*] Yes, I do have a certain amount of contempt for a userbase that blithely ignores and rewrites history to the utter exclusion of Unix, such as over on Wikipedia where they claimed that they were the first to use "/dev/fb" to access the frame buffer; I've since corrected that arrant nonsense. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From rafael.obelheiro at gmail.com Thu Feb 8 23:03:35 2018 From: rafael.obelheiro at gmail.com (Rafael R Obelheiro) Date: Thu, 8 Feb 2018 11:03:35 -0200 Subject: [TUHS] Device special files In-Reply-To: References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> <20180207021405.CF19B156E812@mail.bitblocks.com> <20180207183607.E3NiH%steffen@sdaoden.eu> Message-ID: On Wed, Feb 7, 2018 at 8:04 PM, Dave Horsfall wrote: > On Wed, 7 Feb 2018, Steffen Nurpmeso wrote: > > And then FreeBSD came over with the devfs and there even was a really >> enlightening paper, which is still shipped with FreeBSD >> (share/doc/papers/devfs/paper.me). >> > > Hmmm... My box (10.4-RELEASE-p3) only has papers/devfs.ascii.gz, but > yeah, it's a good read; thanks. > FWIW, it's available in other formats at https://www.usenix.org/legacy/publications/library/proceedings/bsdcon02/kamp.html Cheers, Rafael -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Fri Feb 9 02:18:54 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 8 Feb 2018 11:18:54 -0500 Subject: [TUHS] Device special files In-Reply-To: References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> Message-ID: LOL - I did not write that ;) On 2/7/2018 7:39 PM, Dave Horsfall wrote: > On Wed, 7 Feb 2018, Arthur Krewat wrote: > >> My understanding is that udev is an elaboration on devfs on Linux >> that includes a rules engine that supports things like assigning set >> names to specific devices, setting permissions, group/user ownership >> and the like. [...] > > Thanks for that; I only have the Penguin for porting porpoises, not > for daily use.  I write stuff on the Mac (because the USB ports are > right in front of me), test it on a known reliable server like > FreeBSD, then go and see what the penguins have broken this time...[*] > > [*] > Yes, I do have a certain amount of contempt for a userbase that > blithely ignores and rewrites history to the utter exclusion of Unix, > such as over on Wikipedia where they claimed that they were the first > to use "/dev/fb" to access the frame buffer; I've since corrected that > arrant nonsense. > From random832 at fastmail.com Fri Feb 9 04:59:49 2018 From: random832 at fastmail.com (Random832) Date: Thu, 08 Feb 2018 13:59:49 -0500 Subject: [TUHS] Device special files In-Reply-To: <01b001d3a065$d3ee30a0$7bca91e0$@ronnatalie.com> References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> <20180207021405.CF19B156E812@mail.bitblocks.com> <20180207183607.E3NiH%steffen@sdaoden.eu> <20180207190759.7sjrf6ta4m7sct3d@matica.foolinux.mooo.com> <01b001d3a065$d3ee30a0$7bca91e0$@ronnatalie.com> Message-ID: <1518116389.3085544.1264358560.45B003A3@webmail.messagingengine.com> On Wed, Feb 7, 2018, at 17:48, Ron Natalie wrote: > Amusingly, we still found bugs. I was griping that people would mount > on just any directory on the system, the mtab wouldn’t show the absolute > path. I suggested we chdir to / early on or better yet, cd to /dev. > That way I wouldn’t have to type /dev/ on to the device name. I say > the user would have to give an absolute path anyhow since there’s > nothing on /dev to mount on. Well my roommate immediately tries to > prove me wrong. He tries passing various devnodes and regular files > that happen to sit in /dev. Then he gets the great idea of mounting > on /dev/. It works, but now we have no way to unmount it. We had > to reboot the machine. I quickly modified mount to require an EMPTY > directory owned by the user to be required for mounting. Would a mknod (in the new /dev or anywhere else) to "recreate" the device file have worked? Requiring an empty directory seems a bit overkill vs simply requiring an absolute path (perhaps one that does not begin with /dev) or having the mount command calculate the absolute path. (I'm mildly surprised that if this was in the era where . and .. were simply hardlinks created by mkdir(1), mounting on /dev/. didn't simply literally mount on /dev/. leaving /dev alone, which would have been an interesting state but wouldn't have prevented unmounting) Why is it that umount(2) took the device special file name rather than the mount point directory name, anyway? This seems to have been fixed in NFSv2, 4.3BSD-Uwisc, and Linux, but why was it like that in the first place? It *seems* like in the V6 era code the system could have just as well checked m_inodp for a match to the directory as m_dev for the device. From steffen at sdaoden.eu Fri Feb 9 05:06:01 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 08 Feb 2018 20:06:01 +0100 Subject: [TUHS] Device special files In-Reply-To: <20180207190759.7sjrf6ta4m7sct3d@matica.foolinux.mooo.com> References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> <20180207021405.CF19B156E812@mail.bitblocks.com> <20180207183607.E3NiH%steffen@sdaoden.eu> <20180207190759.7sjrf6ta4m7sct3d@matica.foolinux.mooo.com> Message-ID: <20180208190601.tA75W%steffen@sdaoden.eu> Ian Zimmerman wrote: |On 2018-02-07 19:36, Steffen Nurpmeso wrote: |> Going from ``hardware only changes when the DEC Field engineer is |> here'' to ``my toaster has USB'' has put serious strain on the rather |> crude implementation of the ``devices as files'' concept | |Well, if you don't try to connect your toaster to the computer, you |don't have this problem :-) A killer argument. |I had a self-maintained Linux system (ie. no distribution) until about |2000. I had no problem understanding what the two dozen /dev/ entries |were for. I even wrote a better (table driven) makedev implementation |and I tried to get it into Debian, but by that time rumors of devfs were |already on the way so it wasn't worth a transition to them. | |The real problem with static /dev is on the development side IMO - |managing the namespace of device names and major/minor numbers. If you have grown up with this and are experienced, or have a small system, or have a system with good documentation, then you might be right. (You are definitely right with the latter, say.) I was lost in a jungle of things i did not understand including lots of frightening but anyway apparantly dead Z(ombie) processes (SuSE debug distribution offered for very few money and bought as side-effect on 1999-01-11). And then it is indeed true that having a device file does not mean there is actually a driver behind it. No magic springs-into-existence, if i recall correctly. --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) From steffen at sdaoden.eu Fri Feb 9 05:06:01 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 08 Feb 2018 20:06:01 +0100 Subject: [TUHS] Device special files In-Reply-To: <20180207190759.7sjrf6ta4m7sct3d@matica.foolinux.mooo.com> References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> <20180207021405.CF19B156E812@mail.bitblocks.com> <20180207183607.E3NiH%steffen@sdaoden.eu> <20180207190759.7sjrf6ta4m7sct3d@matica.foolinux.mooo.com> Message-ID: <20180208190601.tA75W%steffen@sdaoden.eu> Ian Zimmerman wrote: |On 2018-02-07 19:36, Steffen Nurpmeso wrote: |> Going from ``hardware only changes when the DEC Field engineer is |> here'' to ``my toaster has USB'' has put serious strain on the rather |> crude implementation of the ``devices as files'' concept | |Well, if you don't try to connect your toaster to the computer, you |don't have this problem :-) A killer argument. |I had a self-maintained Linux system (ie. no distribution) until about |2000. I had no problem understanding what the two dozen /dev/ entries |were for. I even wrote a better (table driven) makedev implementation |and I tried to get it into Debian, but by that time rumors of devfs were |already on the way so it wasn't worth a transition to them. | |The real problem with static /dev is on the development side IMO - |managing the namespace of device names and major/minor numbers. If you have grown up with this and are experienced, or have a small system, or have a system with good documentation, then you might be right. (You are definitely right with the latter, say.) I was lost in a jungle of things i did not understand including lots of frightening but anyway apparantly dead Z(ombie) processes (SuSE debug distribution offered for very few money and bought as side-effect on 1999-01-11). And then it is indeed true that having a device file does not mean there is actually a driver behind it. No magic springs-into-existence, if i recall correctly. --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) From steffen at sdaoden.eu Fri Feb 9 05:25:00 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 08 Feb 2018 20:25:00 +0100 Subject: [TUHS] Device special files In-Reply-To: References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> <20180207021405.CF19B156E812@mail.bitblocks.com> <20180207183607.E3NiH%steffen@sdaoden.eu> Message-ID: <20180208192500.1mEsJ%steffen@sdaoden.eu> Dave Horsfall wrote: |On Wed, 7 Feb 2018, Steffen Nurpmeso wrote: |> And then FreeBSD came over with the devfs and there even was a really |> enlightening paper, which is still shipped with FreeBSD |> (share/doc/papers/devfs/paper.me). | |Hmmm... My box (10.4-RELEASE-p3) only has papers/devfs.ascii.gz, but yeah, |it's a good read; thanks. From the sources; FreeBSD 11.1 unfortunately does not survive resume on this old VM so i only boot it for testing here at the moment. I am currently running only a very small OpenRC based Linux that provides binary packages; the same that i use on the server since February 2016. It will surely change again, though. --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) From dave at horsfall.org Fri Feb 9 08:47:35 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 9 Feb 2018 09:47:35 +1100 (EST) Subject: [TUHS] Device special files In-Reply-To: References: <1517946499.3717582.1261737872.3DC598F2@webmail.messagingengine.com> <20180207012556.GL30690@eureka.lemis.com> Message-ID: On Thu, 8 Feb 2018, Arthur Krewat wrote: > LOL - I did not write that ;) Yeah, I've just replied to Dan. The References: line of my reply as received was: References: <1517946499.3717582.1261737872.3DC598F2 at webmail.messagingengine.com> <20180207012556.GL30690 at eureka.lemis.com> so I dunno what happened... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From doug at cs.dartmouth.edu Fri Feb 9 10:09:34 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 08 Feb 2018 19:09:34 -0500 Subject: [TUHS] Device special files Message-ID: <201802090009.w1909YPC129547@tahoe.cs.Dartmouth.EDU> > Why is it that umount(2) took the device special file name rather than the mount point directory name, anyway? Symmetry. You unmount what you mount. A competing model is that of links. Link makes an old file available under a new name. But you unlink by the new name. Necessarily so, because there may be many new names for one old file. This is reminiscent of Don Norman's screed about the unnaturalness of Unix. He didn't like strcpy because the arguments come in the opposite order to those of cp. But stcpy is part of C, and in C the destination of assignment comes before the source. But Norman didn't rail at C. You pays your money and takes your choice. Doug From wobblygong at gmail.com Fri Feb 9 12:35:51 2018 From: wobblygong at gmail.com (Wesley Parish) Date: Fri, 9 Feb 2018 15:35:51 +1300 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> Message-ID: MS/PC/DR DOS networks used Novell Netware's IPX/SPX suite iirc. Then IBM and Microsoft came up with NetBIOS and its development NetBEUI, a simple peer-to-peer network, and MS Windows 3.11 for Workgroups standardized on that, which meant that most small/er networks defaulted to NetBEUI. Then the Internet took off and TCP/IP took over the networking; NetBEUI survived in the form of Samba as a protocol suite for printer sharing. Microsoft had thought it would take over from other public computer networks like Compuserve with its MSN, but the Internet made all of them subnets to itself. Wesley Parish On 2/8/18, Tony Finch wrote: > Dan Cross wrote: >> >> [...] But much VMS, whatever HP minicomputer stuff was floating around >> (MPE?) and all VM/CMS (I guess it was actually VM/ESA by that time) >> disappeared; VAXstations, serial terminals and 3179G's were all replaced >> by PCs running Windows and the users were replaced by these smiling >> robots. It was weird. >> >> Somehow, most of the Unix people managed to escape. I wonder why? [...] >> >> I wonder, too, if Unix networking didn't play a major role. I have this >> dim >> sense that NT was designed for a world in which it was still assumed that >> the OSI suite was going to win the networking wars. [...] > > I was in my late teens around that time but I got the impression that in > the early to mid 1990s when this shift was happening, networking was > moving to IP and all the IP software was Unix - certainly it was the only > option if you wanted to run network services at the scale of a University > or ISP. At the same time Windows was all about workgroup-scale office > networking. I don't think their network protocols were OSI but Exchange > was based on X.400 and to this day still only does Internet mail > grudgingly. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode > Lundy, Fastnet, Irish Sea: West or southwest 4 or 5, increasing 6 at times. > Slight or moderate, occasionally rough except in Irish Sea, becoming very > rough later in southwest Fastnet. Occasional rain. Good, occasionally poor. > From wobblygong at gmail.com Fri Feb 9 12:53:22 2018 From: wobblygong at gmail.com (Wesley Parish) Date: Fri, 9 Feb 2018 15:53:22 +1300 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: Message-ID: On 2/8/18, Nemo wrote: > On 7 February 2018 at 03:27, Wesley Parish wrote: >> OS/2 and Windows (including WinNT 3.x) just >> added a pretty-pretty interface. OS/2 was more sophisticated than >> WinNT's because OS/2 expected to share the hard drive with some other >> OS; Microsoft believed it had the computer to itself and is thus not >> as sophisticated - but they're still MS/PC/DR DOS writ large. > > I would disagree with this assessment. NT's VMS heritage has already > been discussed. I do not know the heritage of OS/2 but to call it DOS > is simply not true. (Among other things, OS/2 did an excellent job of > virtualizing dosboxes. We were developing PCMCIA drivers with OS/2 in > dosboxes. When one crashed, you simply opened up another and > continued.) > > N. > I was referring to the installation procedures. IBM OS/2 2.0 to 4.0 installation procedures were more sophisticated than the equivalent in MS WinNT from 3.x to 5.x because Microsoft did not show any interest in sharing the disk with anyone. But it's still true if one refers to single user versus multiuser - WinNT's got a lot of OS/2 and VMS in its history, and OS/2's got a lot of IBM's MVS and related mainframe OS knowledge in its background, but they're not native multiuser. You need to get add-ons to make them truly multiuser. In that they are still MS/PC/DR DOS writ large. (Which is ironical considering that there have been at least two genuine multiuser DOS clones on the market that I know of, DR's Multiuser DOS - not Concurrent DOS: that was a similar but different product - and PCMOS.) Wesley Parish From jacob.ritorto at gmail.com Fri Feb 9 15:03:59 2018 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Fri, 9 Feb 2018 00:03:59 -0500 Subject: [TUHS] qd32 trouble Message-ID: Hi all, Would anyone here be able to help me troubleshoot my qd32 controller? I have a pdp11/73 that's mostly working, boots 2.11 from rl02 okay, but I need my big disk to work so I can load the rest of the distro. I've been following the manual for the qd32 to enter the geometry of my real working m2333 (jumpered correctly according to the manuals), but when I load the special command into the qd32's SP register that's supposed to load the geometry table from the pdp11 memory to the novram, I get a bad status value from the qd32's SP register and it remains unresponsive when I try to store the geometry. If I go ahead and try the built-in qd32 format command, it responds similarly. When I pull in mkfs from tape (vtserver) and try anyway, despite the failures, to run mkfs on the m2333, I get an !online error from the standalone unix mkfs. The disk does respond (the select light flashes and I can hear heads actuating), but without geometry and format, I'm obviously dead in the water. Any suggestions on how to proceed? thx jake -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfawcus+lists-tuhs at employees.org Mon Feb 12 06:22:14 2018 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Sun, 11 Feb 2018 20:22:14 +0000 Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: References: Message-ID: <20180211202213.GA34045@accordion.employees.org> On Fri, Feb 09, 2018 at 03:53:22PM +1300, Wesley Parish wrote: > (Which is ironical considering that there have been at least two > genuine multiuser DOS clones on the market that I know of, DR's > Multiuser DOS - not Concurrent DOS: that was a similar but different > product - and PCMOS.) DR's Concurrent DOS 286 was multiuser, but never really made it in the market in that form due to the issues they had with the 286. It eventually became FlexOS, but was not really DOS compatible once it that form. There was a DOS compatible add-on for the 386 varient of FlexOS, which hints at how limited the DOS compatibilty of CDOS 286 would have been. Note that CDOS 286 (aka FlexOS) was a distinct product from Concurrent DOS. The former written in C; the latter in assembler and seemingly derived from Concurrent CP/M. DF From robert at timetraveller.org Mon Feb 12 10:31:46 2018 From: robert at timetraveller.org (Robert Brockway) Date: Mon, 12 Feb 2018 10:31:46 +1000 (AEST) Subject: [TUHS] Why BSD didn't catch on more, and Linux did In-Reply-To: <20180211202213.GA34045@accordion.employees.org> References: <20180211202213.GA34045@accordion.employees.org> Message-ID: On Sun, 11 Feb 2018, Derek Fawcus wrote: > Note that CDOS 286 (aka FlexOS) was a distinct product from > Concurrent DOS. The former written in C; the latter in assembler > and seemingly derived from Concurrent CP/M. Also not to be confused with FLEX, a completely different OS. That was what I initially thought you were talking about but the clue was you mentioned FlexOS was multi-user. The original FLEX was single user. https://en.wikipedia.org/wiki/FLEX_(operating_system) Rob From wkt at tuhs.org Wed Feb 14 07:48:29 2018 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 14 Feb 2018 07:48:29 +1000 Subject: [TUHS] PDP-7 Unix Paper Message-ID: <20180213214829.GA19971@minnie.tuhs.org> All, my journal paper on PDP-7 Unix has just been licensed under CC-BY-SA, so here's a link to the PDF version: http://minnie.tuhs.org/Y5/wkt_hapop_paper.pdf Cheers, Warren From clemc at ccc.com Wed Feb 14 07:53:11 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 13 Feb 2018 16:53:11 -0500 Subject: [TUHS] PDP-7 Unix Paper In-Reply-To: <20180213214829.GA19971@minnie.tuhs.org> References: <20180213214829.GA19971@minnie.tuhs.org> Message-ID: Awesome!! Thank you. ᐧ On Tue, Feb 13, 2018 at 4:48 PM, Warren Toomey wrote: > All, my journal paper on PDP-7 Unix has just been licensed under CC-BY-SA, > so here's a link to the PDF version: > http://minnie.tuhs.org/Y5/wkt_hapop_paper.pdf > > Cheers, Warren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From akosela at andykosela.com Wed Feb 14 08:45:59 2018 From: akosela at andykosela.com (Andy Kosela) Date: Tue, 13 Feb 2018 16:45:59 -0600 Subject: [TUHS] PDP-7 Unix Paper In-Reply-To: References: <20180213214829.GA19971@minnie.tuhs.org> Message-ID: On Tuesday, February 13, 2018, Clem Cole wrote: > Awesome!! Thank you. > ᐧ > > On Tue, Feb 13, 2018 at 4:48 PM, Warren Toomey wrote: > >> All, my journal paper on PDP-7 Unix has just been licensed under CC-BY-SA, >> so here's a link to the PDF version: >> http://minnie.tuhs.org/Y5/wkt_hapop_paper.pdf >> >> Cheers, Warren >> > > I especially like the conclusion part. 'Less is more' against 'more is more' was the underlying theme of the original UNIX. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcapp at anteil.com Wed Feb 14 09:04:38 2018 From: jcapp at anteil.com (Jim Capp) Date: Tue, 13 Feb 2018 18:04:38 -0500 Subject: [TUHS] PDP-7 Unix Paper In-Reply-To: <20180213214829.GA19971@minnie.tuhs.org> References: <20180213214829.GA19971@minnie.tuhs.org> Message-ID: <4F4EC0E2-4E7D-4894-9338-7C7863C6ECD2@anteil.com> All I can say is Wow! Thanks for all the hard work to pull this out of dust bin and breath new life into a truly historic event. J > On Feb 13, 2018, at 4:48 PM, Warren Toomey wrote: > > All, my journal paper on PDP-7 Unix has just been licensed under CC-BY-SA, > so here's a link to the PDF version: > http://minnie.tuhs.org/Y5/wkt_hapop_paper.pdf > > Cheers, Warren From ken at google.com Wed Feb 14 09:15:55 2018 From: ken at google.com (Ken Thompson) Date: Tue, 13 Feb 2018 15:15:55 -0800 Subject: [TUHS] PDP-7 Unix Paper In-Reply-To: References: <20180213214829.GA19971@minnie.tuhs.org> Message-ID: outstanding. On Tue, Feb 13, 2018 at 1:53 PM, Clem Cole wrote: > Awesome!! Thank you. > ᐧ > > On Tue, Feb 13, 2018 at 4:48 PM, Warren Toomey wrote: > >> All, my journal paper on PDP-7 Unix has just been licensed under CC-BY-SA, >> so here's a link to the PDF version: >> http://minnie.tuhs.org/Y5/wkt_hapop_paper.pdf >> >> Cheers, Warren >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Feb 14 09:30:52 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 14 Feb 2018 10:30:52 +1100 (EST) Subject: [TUHS] PDP-7 Unix Paper In-Reply-To: <20180213214829.GA19971@minnie.tuhs.org> References: <20180213214829.GA19971@minnie.tuhs.org> Message-ID: On Wed, 14 Feb 2018, Warren Toomey wrote: > All, my journal paper on PDP-7 Unix has just been licensed under > CC-BY-SA, so here's a link to the PDF version: Wow! I'm still astonished at the constraints those guys had to suffer: PDP-7 Unix provided a multitasking environment by dividing the 8K words of memory into two halves. The lower half of memory was reserved for the kernel. The upper half of memory was set aside for the currently running process. But you try and tell the young people today that... and they won't believe you. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From imp at bsdimp.com Wed Feb 14 11:08:38 2018 From: imp at bsdimp.com (Warner Losh) Date: Tue, 13 Feb 2018 18:08:38 -0700 Subject: [TUHS] pdp-11 assembly as a hll? Message-ID: I don't suppose anybody has written a pdp-11 assembler to C translator... My google fu is insufficient for the day. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Feb 14 12:21:22 2018 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 13 Feb 2018 18:21:22 -0800 Subject: [TUHS] PDP-7 Unix Paper In-Reply-To: References: <20180213214829.GA19971@minnie.tuhs.org> Message-ID: <20180214022122.GA7026@mcvoy.com> On Wed, Feb 14, 2018 at 10:30:52AM +1100, Dave Horsfall wrote: > I'm still astonished at the constraints those guys had to suffer: > > PDP-7 Unix provided a multitasking environment by dividing the 8K > words of memory into two halves. The lower half of memory was > reserved for the kernel. The upper half of memory was set aside for > the currently running process. > > But you try and tell the young people today that... and they won't believe > you. Don't even get me started. Young people think that a VM is a server. I wrote a microbenchmark suite, lmbench, and I get people sending me email that they get inconsistent results on their VM. The lack of knowledge that would make someone ask about that is stunning. From fair-tuhs at netbsd.org Wed Feb 14 12:19:41 2018 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Tue, 13 Feb 2018 18:19:41 -0800 Subject: [TUHS] PDP-7 Unix Paper In-Reply-To: References: <20180213214829.GA19971@minnie.tuhs.org> Message-ID: <20007.1518574781@cesium.clock.org> That depends on the youngin' - the same technique was also used with the Dual Systems Version 7 Unix port to the mc68000 without an MMU in 1981: split the address space in half at 0x800000, top for kernel, bottom for running process, swap to context switch, and any reference to RAM below 0x800000 while in CPU user mode faulted, to protect the kernel from errant user code. I can also tell you some S-100 (IEEE-696) device driver horror stories because CP/M-68k and its ilk were not multitasking like Unix and let us say that allowed the S-100 add-in board hardware designers to be ... lazy. The work-arounds in software were very ugly. Main irritant: customers who claimed our hardware was broken because dereferencing a NULL pointer (0) resulted in a fault, rather than returning 0. "No, your C code is broken because address zero is not in the available address space of processes, and your code should not assume it is." (not a popular response from our customer service engineer). IIRC, most of the Unix code was well-behaved because it had grown up on computers with MMUs by the time we got it ... except for that issue. Later, Dual produced a CPU board with an mc68451 MMU on it, and that helped. Sort of. Erik Fair From dave at horsfall.org Wed Feb 14 13:18:40 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 14 Feb 2018 14:18:40 +1100 (EST) Subject: [TUHS] pdp-11 assembly as a hll? In-Reply-To: References: Message-ID: On Tue, 13 Feb 2018, Warner Losh wrote: > I don't suppose anybody has written a pdp-11 assembler to C > translator... My google fu is insufficient for the day. I'd like to see it handle "JSR PC,@(SP)+"... Are you reverse-engineering something, writing a PDP-11 simulator, or what? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From imp at bsdimp.com Wed Feb 14 15:06:06 2018 From: imp at bsdimp.com (Warner Losh) Date: Tue, 13 Feb 2018 22:06:06 -0700 Subject: [TUHS] PDP-7 Unix Paper In-Reply-To: References: <20180213214829.GA19971@minnie.tuhs.org> Message-ID: On Tue, Feb 13, 2018 at 4:30 PM, Dave Horsfall wrote: > On Wed, 14 Feb 2018, Warren Toomey wrote: > > All, my journal paper on PDP-7 Unix has just been licensed under CC-BY-SA, >> so here's a link to the PDF version: >> > > Wow! > > I'm still astonished at the constraints those guys had to suffer: > > PDP-7 Unix provided a multitasking environment by dividing the 8K > words of memory into two halves. The lower half of memory was > reserved for the kernel. The upper half of memory was set aside for > the currently running process. > > But you try and tell the young people today that... and they won't believe > you. Today's FreeBSD boot loader is 450k. Of course, it can read half a dozen different file systems, supports crypto and has a Lua interpreter. Lua is ~140k of that. FreeBSD's boot2 program is 16k in size, but can barely read a kernel into memory from a UFS file system and jump to it.... 4k words (4608 bytes) for all of unix is impressive... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Feb 14 15:12:50 2018 From: imp at bsdimp.com (Warner Losh) Date: Tue, 13 Feb 2018 22:12:50 -0700 Subject: [TUHS] pdp-11 assembly as a hll? In-Reply-To: References: Message-ID: On Tue, Feb 13, 2018 at 8:18 PM, Dave Horsfall wrote: > On Tue, 13 Feb 2018, Warner Losh wrote: > > I don't suppose anybody has written a pdp-11 assembler to C translator... >> My google fu is insufficient for the day. >> > > I'd like to see it handle "JSR PC,@(SP)+"... Are you reverse-engineering > something, writing a PDP-11 simulator, or what? I was wondering what it would take to convert the v6/v7 basic program into something that can be run today. http://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s1/bas.s or http://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/bas/bas.s Its 2128 lines. It doesn't have that fun instruction in it :) Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Feb 14 16:43:34 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 14 Feb 2018 17:43:34 +1100 (EST) Subject: [TUHS] pdp-11 assembly as a hll? In-Reply-To: References: Message-ID: On Tue, 13 Feb 2018, Warner Losh wrote: > I was wondering what it would take to convert the v6/v7 basic program > into something that can be run today. Hmmm... If it were C-generated then it would be (somewhat) easy, but it's hand-written and hand-optimised... You'd have to do some functional analysis on it e.g. what does this routine do, etc. > Its 2128 lines. It doesn't have that fun instruction in it :) I know! Say ~2,000 lines, say ~100 people on this list, distributed computing to the rescue! That's only 20 lines each, so it ought to be a piece of cake :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From bakul at bitblocks.com Wed Feb 14 17:27:42 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Tue, 13 Feb 2018 23:27:42 -0800 Subject: [TUHS] pdp-11 assembly as a hll? In-Reply-To: Your message of "Tue, 13 Feb 2018 22:12:50 -0700." References: Message-ID: <20180214072757.7A391156E811@mail.bitblocks.com> On Tue, 13 Feb 2018 22:12:50 -0700 Warner Losh wrote: > > On Tue, Feb 13, 2018 at 8:18 PM, Dave Horsfall wrote: > > > On Tue, 13 Feb 2018, Warner Losh wrote: > > > > I don't suppose anybody has written a pdp-11 assembler to C translator... > >> My google fu is insufficient for the day. > >> > > > > I'd like to see it handle "JSR PC,@(SP)+"... Are you reverse-engineering > > something, writing a PDP-11 simulator, or what? > > > I was wondering what it would take to convert the v6/v7 basic program into > something that can be run today. > > http://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s1/bas.s > or > http://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/bas/bas.s > > Its 2128 lines. It doesn't have that fun instruction in it :) May be it just needs a perl script to generate C code? Example: 2: label(lab0); cmp r0,(r3) cmp(r0,deref(r3)); beq 2f beq(lab1); tst (r3) => tst(deref(r3)); beq 2f beq(lab1); add $6,r3 add(6,r3); br 2b br(lab0); 2: label(lab1); C calls are to macros or inline functions. From itz at very.loosely.org Wed Feb 14 17:28:44 2018 From: itz at very.loosely.org (Ian Zimmerman) Date: Tue, 13 Feb 2018 23:28:44 -0800 Subject: [TUHS] pdp-11 assembly as a hll? In-Reply-To: References: Message-ID: <20180214072844.cdkm73l2x23odgj3@matica.foolinux.mooo.com> On 2018-02-14 14:18, Dave Horsfall wrote: > I'd like to see it handle "JSR PC,@(SP)+"... BTW, isn't that precisely the "retpoline" that we've seen in the news recently ? -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com. From pnr at planet.nl Wed Feb 14 18:41:25 2018 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 14 Feb 2018 09:41:25 +0100 Subject: [TUHS] pdp-11 assembly as a hll? Message-ID: <08FA5285-3A14-491E-B723-B40AE85B4151@planet.nl> >> I was wondering what it would take to convert the v6/v7 basic program >> into something that can be run today. > > Hmmm... If it were C-generated then it would be (somewhat) easy, but it's > hand-written and hand-optimised... You'd have to do some functional > analysis on it e.g. what does this routine do, etc. > >> Its 2128 lines. It doesn't have that fun instruction in it :) > > I know! Say ~2,000 lines, say ~100 people on this list, distributed > computing to the rescue! That's only 20 lines each, so it ought to be a > piece of cake :-) I'm up for that! However, only if the resulting C program can be compiled/run on a V6/PDP11 again. Let's assume that reverse engineering a subroutine of 20 lines takes an hour. That then makes for 100 hours. If 10 people participate and contribute one hour/routine per week, it will be done by May. However, the initial analysis of the code architecture is a (time) hurdle. Paul PS: the Fortran66 of V6 is also assembler only... From mutiny.mutiny at india.com Wed Feb 14 19:13:53 2018 From: mutiny.mutiny at india.com (Donald ODona) Date: Wed, 14 Feb 2018 09:13:53 +0000 (UTC) Subject: [TUHS] PDP-7 Unix Paper In-Reply-To: <20180213214829.GA19971@minnie.tuhs.org> References: <20180213214829.GA19971@minnie.tuhs.org> Message-ID: <1481767510.34979.1518599633677.JavaMail.tomcat@india-live-be02> Thanks a lot! At 13 Feb 2018 21:50:20 +0000 (+00:00) from Warren Toomey : > All, my journal paper on PDP-7 Unix has just been licensed under CC-BY-SA, > so here's a link to the PDF version: > http://minnie.tuhs.org/Y5/wkt_hapop_paper.pdf > > Cheers, Warren From mutiny.mutiny at india.com Wed Feb 14 19:18:58 2018 From: mutiny.mutiny at india.com (Donald ODona) Date: Wed, 14 Feb 2018 09:18:58 +0000 (UTC) Subject: [TUHS] PDP-7 Unix Paper In-Reply-To: <20180214022122.GA7026@mcvoy.com> References: <20180213214829.GA19971@minnie.tuhs.org> , <20180214022122.GA7026@mcvoy.com> Message-ID: <970809088.34989.1518599938314.JavaMail.tomcat@india-live-be02> already 20 years ago I met a guy (masters degree, university) who never freed dynamically allocated memory. He told me he is 'instantiating a object', but had no idea what an heap is, and what dynamically allocated memory means. At 14 Feb 2018 02:23:07 +0000 (+00:00) from Larry McVoy : > On Wed, Feb 14, 2018 at 10:30:52AM +1100, Dave Horsfall wrote: > > I'm still astonished at the constraints those guys had to suffer: > > > > PDP-7 Unix provided a multitasking environment by dividing the 8K > > words of memory into two halves. The lower half of memory was > > reserved for the kernel. The upper half of memory was set aside for > > the currently running process. > > > > But you try and tell the young people today that... and they won't believe > > you. > > Don't even get me started. Young people think that a VM is a server. > I wrote a microbenchmark suite, lmbench, and I get people sending me > email that they get inconsistent results on their VM. > > The lack of knowledge that would make someone ask about that is stunning. From jnc at mercury.lcs.mit.edu Wed Feb 14 23:15:04 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 14 Feb 2018 08:15:04 -0500 (EST) Subject: [TUHS] pdp-11 assembly as a hll? Message-ID: <20180214131504.2DBD418C095@mercury.lcs.mit.edu> > From: Dave Horsfall > I'd like to see it handle "JSR PC,@(SP)+"... Heh! But that does point out that the general concept is kind of confused - at least, if you hope to get a fully working program out the far end. The only way to do that is build (effectively) a simulator, one that _exactly_ re-creates the effects on the memory and registers of the original program. Only instead of reading binary machine code, this one's going to read in the machine language source, and produce a custom simulator, one that can run only one program - the one fed into it. Think of it as a 'simulator compiler'! :-) Noel From ron at ronnatalie.com Thu Feb 15 00:28:50 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 14 Feb 2018 09:28:50 -0500 Subject: [TUHS] Clueless programmers Message-ID: <005301d3a5a0$226410d0$672c3270$@ronnatalie.com> > already 20 years ago I met a guy (masters degree, university) who never freed dynamically allocated memory. He told me he is 'instantiating a object', but had no idea what an heap is, and what dynamically allocated memory means. Years ago, I had an new programmer who I just couldn't teach. He never understood the difference between an array and pointer, and apparently couldn't be bothered to learn. After string him along for three months, I was on my way into his office to fire him when I found out he had quit, but not before he checked a bunch of drek into our source code control system. I thought I backed all his commits out at the time. Years later I was running "purify" on our product looking for memory leaks. I found this small utility function that predated the source code control system leaking. This, I thought was odd, as it had been there FOREVER and was well tested. I brought up the source code system and checked it anyhow and found the afore mentioned programmer had checked in one change: he deleted the "free" call in it. I KNOW what happened. He did something else to corrupt the malloc heap in his code and often this causes a core dump in a subsequent malloc/free call. Apparently this was the place it struck him, so he just deleted the free call there. From paul.winalski at gmail.com Thu Feb 15 02:03:44 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 14 Feb 2018 11:03:44 -0500 Subject: [TUHS] pdp-11 assembly as a hll? In-Reply-To: References: Message-ID: On 2/13/18, Warner Losh wrote: > I don't suppose anybody has written a pdp-11 assembler to C translator... > My google fu is insufficient for the day. > Or you could write a compiler that translates PDP-11 assembler to LLVM intermediate language. That was the technique used to port VMS to the DEC Alpha and Intel Itanium. A lot of VMS was in VAX assembler, so DEC's compiler group wrote a compiler that took in VAX assembler and generated IL for the GEM back end used by all of DEC's Alpha and Itanium compilers. -Paul W. From imp at bsdimp.com Thu Feb 15 02:56:44 2018 From: imp at bsdimp.com (Warner Losh) Date: Wed, 14 Feb 2018 09:56:44 -0700 Subject: [TUHS] pdp-11 assembly as a hll? In-Reply-To: References: Message-ID: On Wed, Feb 14, 2018 at 9:03 AM, Paul Winalski wrote: > On 2/13/18, Warner Losh wrote: > > I don't suppose anybody has written a pdp-11 assembler to C translator... > > My google fu is insufficient for the day. > > > Or you could write a compiler that translates PDP-11 assembler to LLVM > intermediate language. That was the technique used to port VMS to the > DEC Alpha and Intel Itanium. A lot of VMS was in VAX assembler, so > DEC's compiler group wrote a compiler that took in VAX assembler and > generated IL for the GEM back end used by all of DEC's Alpha and > Itanium compilers. > Yea, I was kinda hoping someone else had already done the translation for basic. But it actually looks to be from v5, using the v5 calling conventions and library routines now that I have had a chance to study it. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Thu Feb 15 03:47:29 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 14 Feb 2018 12:47:29 -0500 (EST) Subject: [TUHS] Oddness in V6 'mv' Message-ID: <20180214174729.5147518C09E@mercury.lcs.mit.edu> So, in: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s2/mv.c what's the point of this piece of code: p = place; p1 = p; while(*p++ = *argp3++); p2 = p; while(*p++ = *argp4++); execl("/bin/cp","cp", p1, p2, 0); I mean, I get that it's copying the two strings pointed to by 'argp3' and 'argp4' into a temporary buffer at 'place', and leaving 'p1' and 'p2' as pointers to the copies of said strings, but... why is it doing that? I at first thought that maybe the execl() call was smashing the stack (and thus the copies pointed to by 'argp3' and 'argp4'), or something, but I don't think it does that. So why couldn't the code have just been: execl("/bin/cp","cp", argp3, argp4, 0); Is this code maybe just a left-over from some previous variant? Noel From clemc at ccc.com Thu Feb 15 06:53:45 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 14 Feb 2018 15:53:45 -0500 Subject: [TUHS] Do Interface specifications such POSIX or the LSB Still Matter Message-ID: I've send a couple of you private messages with some more details of why I ask this, but I'll bring the large question to debate here: ​Have POSIX and​ LSB lost ​their usefulness/relevance? If so, we know ISV’s like Ansys are not going to go ‘FOSS’ and make their sources available (ignore religious beliefs, it just is not their business model); how to we get that level of precision to allow ​the part of the market ​ that will be 'binary only' continue to create applications? Seriously, please try to stay away from religion on this ​ question. Clearly, there are a large number of ISVs have traditionally used interface specifications. To me it started with things like the old Cobol and Fortran standards for the languages. That was not good enough since the systems diverge, and /usr/group then IEEE/ANSI/ISO did Posix. Clearly, Posix enabled Unix implementations such a Linux to shine, although Linux does not doggedly follow it. Apple was once Posix conformant, but I'd not think they worry to much about it. Linux created LSB, but I see fewer and fewer references to it. I worry that without a real binary definition, it's darned hard (at least in the higher end of the business that I live day-to-day) to get ISV's to care. What do you folks think? Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Feb 15 07:06:36 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 15 Feb 2018 08:06:36 +1100 (EST) Subject: [TUHS] Happy birthday, Niklaus Wirth! Message-ID: Computer pioneer Niklaus Wirth was born on this day in 1934; he basically designed ALGOL, one of the most influential languages ever, with just about every programming language in use today tracing its roots to it. His name is pronounced "vurt" but he would accept "worth", and he joked that you could call him by name or by value (you need to know ALGOL to understand). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From clemc at ccc.com Thu Feb 15 07:12:51 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 14 Feb 2018 16:12:51 -0500 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: Message-ID: On Wed, Feb 14, 2018 at 4:06 PM, Dave Horsfall wrote: > > His name is pronounced "vurt" but he would accept "worth", and he joked > that you could call him by name or by value (you need to know ALGOL to > understand). ​The actual joke was Europeans called him by name(ni-klaus vurt) and Americans by value [nickel-less worth].​ ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From toby at telegraphics.com.au Thu Feb 15 07:24:15 2018 From: toby at telegraphics.com.au (Toby Thain) Date: Wed, 14 Feb 2018 16:24:15 -0500 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: Message-ID: On 2018-02-14 4:06 PM, Dave Horsfall wrote: > ALGOL, one of the most influential languages ever, with just about every > programming language in use today tracing its roots to it. Worth mentioning one significant exception: the Lisp family. --T From ggm at algebras.org Thu Feb 15 08:07:38 2018 From: ggm at algebras.org (George Michaelson) Date: Thu, 15 Feb 2018 08:07:38 +1000 Subject: [TUHS] Clueless programmers In-Reply-To: <005301d3a5a0$226410d0$672c3270$@ronnatalie.com> References: <005301d3a5a0$226410d0$672c3270$@ronnatalie.com> Message-ID: "worked for him" is an allowed rule under the "I don't know why it worked but it did" hacking code, for a deadline. somebody in product land has a sign saying 'the best is the enemy of the good enough" which people in tech support want to ritually burn because all he did is shift cost out of his bucket into somebody elses, but thats also allowed under the "not my problem" rule. I (and I am self-confessed as the worlds least competent programmer) frequently found the delay between where corruption in malloc is applied and where its detected sufficiently confusing that I would have been tempted to follow this well trodden "remove the free()" path. -G On Thu, Feb 15, 2018 at 12:28 AM, Ron Natalie wrote: > >> already 20 years ago I met a guy (masters degree, university) who never freed dynamically allocated memory. He told me he is 'instantiating a object', but had no idea what an heap is, and what dynamically allocated memory means. > > Years ago, I had an new programmer who I just couldn't teach. He never understood the difference between an array and pointer, and apparently couldn't be bothered to learn. > After string him along for three months, I was on my way into his office to fire him when I found out he had quit, but not before he checked a bunch of drek into our source code control system. > I thought I backed all his commits out at the time. > > Years later I was running "purify" on our product looking for memory leaks. I found this small utility function that predated the source code control system leaking. This, I thought was odd, as it had been there FOREVER and was well tested. I brought up the source code system and checked it anyhow and found the afore mentioned programmer had checked in one change: he deleted the "free" call in it. > > I KNOW what happened. He did something else to corrupt the malloc heap in his code and often this causes a core dump in a subsequent malloc/free call. Apparently this was the place it struck him, so he just deleted the free call there. > From ggm at algebras.org Thu Feb 15 08:13:34 2018 From: ggm at algebras.org (George Michaelson) Date: Thu, 15 Feb 2018 08:13:34 +1000 Subject: [TUHS] Do Interface specifications such POSIX or the LSB Still Matter In-Reply-To: References: Message-ID: once you have virtualized OS support embedded in a wrap like docker why do you need the definition of the sysctl() calls as a spec? Ok so clearly the people who write virtualization need some equivalent, but basically, virtualbox or parallels or vmware plus docker == "I run a miniature clone of the real underlying OS" so the premise behind the ABI spec in POSIX which made it possible to write code depending on runtime calls into systems libraries is somewhat moot. I suspect that a minority of programs tickle things which are POSIX+/- later and they never work well. LSB sort of works. Sort of. WINE manages to handle an amazing number of things, with no formalized POSIX equivalent boundary definition. So this is a view from the "I want to run this binary I have been given" world view, which is mostly the consumerist take. "I want a roughly plausible story to compile this code on a different OS" is a different take. I recently had some code which had to compile a C to Python shared library to extend the python core, with OpenSSL calls. its well written. It works on FreeBSD from its porting base in Debian, and the author is not stupid, and writes code in wide public support (I won't out him but he's an old school MIT graduate and really can code very well) it simply doesn't work as-is on OSX. So clearly, something in the API/ABI space as compiled up for OSX, for this source mashup gets outside the boundary of what I believe POSIX tries to do. So.. how did POSIX help? Did it avoid the problem? Nope. Did it make the problem surface smaller? Probably. -G On Thu, Feb 15, 2018 at 6:53 AM, Clem Cole wrote: > I've send a couple of you private messages with some more details of why I > ask this, but I'll bring the large question to debate here: > > > Have POSIX and > LSB lost > their > usefulness/relevance? If so, we know ISV’s like Ansys are not going to go > ‘FOSS’ and make their sources available (ignore religious beliefs, it just > is not their business model); how to we get that level of precision to allow > the part of the > market > that will be 'binary only' continue to > create applications? > > Seriously, please try to stay away from religion on this > question. Clearly, there are a large number of ISVs have traditionally > used interface specifications. To me it started with things like the old > Cobol and Fortran standards for the languages. That was not good enough > since the systems diverge, and /usr/group then IEEE/ANSI/ISO did Posix. > > > Clearly, Posix enabled Unix implementations such a Linux to shine, although > Linux does not doggedly follow it. Apple was once Posix conformant, but I'd > not think they worry to much about it. Linux created LSB, but I see fewer > and fewer references to it. > > I worry that without a real binary definition, it's darned hard (at least in > the higher end of the business that I live day-to-day) to get ISV's to care. > > What do you folks think? > > Clem > From ggm at algebras.org Thu Feb 15 08:15:00 2018 From: ggm at algebras.org (George Michaelson) Date: Thu, 15 Feb 2018 08:15:00 +1000 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: Message-ID: the joke was extended on my Uni course to include "call by reference" but I forget what it was. probably "hey! YOU" -G On Thu, Feb 15, 2018 at 7:12 AM, Clem Cole wrote: > > > On Wed, Feb 14, 2018 at 4:06 PM, Dave Horsfall wrote: > >> >> His name is pronounced "vurt" but he would accept "worth", and he joked >> that you could call him by name or by value (you need to know ALGOL to >> understand). > > ​The actual joke was Europeans called him by name(ni-klaus vurt) and > Americans by value [nickel-less worth].​ > ᐧ > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davida at pobox.com Thu Feb 15 08:45:47 2018 From: davida at pobox.com (David Arnold) Date: Thu, 15 Feb 2018 09:45:47 +1100 Subject: [TUHS] Do Interface specifications such POSIX or the LSB Still Matter In-Reply-To: References: Message-ID: <781FBCD1-A2D9-4F6A-A0CF-452C243900E8@pobox.com> Purely from my own perspective, and perhaps a little round about … As an ISV, the best customer experience comes from having your software provided in the distribution’s repositories. That implies that your product be both gratis and libre (to some definition). At that point, it’s an ‘apt’, ‘yum’, etc away. Second best is in the distribution’s secondary repositories (Universe, Extras, EPEL, etc). A customer potentially has to fiddle with their enabled repositories, but that’s a one-off, and afterwards plain sailing. This mostly requires source availability unless your product is something that’s very widely demanded, and the source not feasibly made available (eg. Adobe Flash player browser plugins, or similar). Note that for some customers, they are not permitted (by their internal compliance people) to enable eg. EPEL. Third best is where you host package repositories yourself for a selection of distributions you care about. This is basically the best customer experience possible for commercially-licensed binary-only distribution. The end-user has to import your repository definition, approve your certificate, etc, but that’s a one-off thing, fairly simple to do, and thereafter they can install and update anything you publish with minimal effort. Compliance-wise, this is actually easier than the vendors’ secondary repos, because it’s limited to one company with whom there’s a contractual relationship. In that context … POSIX matters largely as an historical artefact: it means that Linux and macOS are mostly compatible. But new features are added relatively frequently, and there’s apparently minimal value placed on compatibility with others. The bulk of your application code is compatible (ie. all the POSIX stuff), but corner cases need compatibility handling. The UI, the filesystem, etc, often ends up being entirely different. LSB had numerous issues: * It was too minimal, not including much beyond basic POSIX. IIRC, it didn’t include even OpenSSL, for example (at least in earlier editions) * It was often an optional package, needing to be installed before LSB-based applications would work * It then had different versions, and vendors were late to implement the later (more broad) requirements, so in practice you could only rely on the base set * After all of that, an LSB-based package was still typically installed and maintained differently from everything else on the system, so the end-user’s experience was pretty bad In my experience, you were actually better off just building on glibc and making a minimal (POSIX-ish) set of assumptions about installed utilities and filesystem layout). That way at least you avoided the issues of needing to install LSB-compatibility packages, versioning of the LSB packages, etc. Implicit in all of this is that the market for commercial Unix and the BSDs is negligible, and has been for basically 10 years. Aside from a brief uptick for Solaris 10, that was pretty-much true from about Solaris 7 onwards. RHEL3+ and SLES9+, and then later Ubuntu LTS, and perhaps Darwin/Mac OS X/macOS covered enough of the market. Today, macOS is the worst to support, since it doesn’t have a system package manager so you have to handle the patching/update process yourself, AND it’s a different kernel, C runtime, and vendor userland libraries. RHEL/CentOS and Ubuntu LTS cover most customers. SLES still has a few niches, but it's dying. macOS is used only as a client, and mostly that doesn’t matter since applications are using a web UI on a Linux backend anyway. I think the bigger question is really … is there really still a market for commercially-licensed installable software packages? The set of things that cannot be delivered via the web, and are not available as Free/Open Source is ever-shrinking. The operating system as we know it has become a substrate. Linux has won, and the battle has moved on to the services layer. d > On 15 Feb 2018, at 07:53, Clem Cole wrote: > > I've send a couple of you private messages with some more details of why I ask this, but I'll bring the large question to debate here: > > ​Have POSIX and​ LSB lost ​their usefulness/relevance? If so, we know ISV’s like Ansys are not going to go ‘FOSS’ and make their sources available (ignore religious beliefs, it just is not their business model); how to we get that level of precision to allow ​the part of the market ​ that will be 'binary only' continue to create applications? > > Seriously, please try to stay away from religion on this​ question. Clearly, there are a large number of ISVs have traditionally used interface specifications. To me it started with things like the old Cobol and Fortran standards for the languages. That was not good enough since the systems diverge, and /usr/group then IEEE/ANSI/ISO did Posix. > > > Clearly, Posix enabled Unix implementations such a Linux to shine, although Linux does not doggedly follow it. Apple was once Posix conformant, but I'd not think they worry to much about it. Linux created LSB, but I see fewer and fewer references to it. > > I worry that without a real binary definition, it's darned hard (at least in the higher end of the business that I live day-to-day) to get ISV's to care. > > What do you folks think? > > Clem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Thu Feb 15 09:19:39 2018 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 15 Feb 2018 10:19:39 +1100 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: Message-ID: <20180214231939.GB87639@eureka.lemis.com> On Thursday, 15 February 2018 at 8:06:36 +1100, Dave Horsfall wrote: > Computer pioneer Niklaus Wirth was born on this day in 1934; he basically > designed ALGOL, one of the most influential languages ever, with just > about every programming language in use today tracing its roots to it. > > His name is pronounced "vurt" Maybe some English speakers pronounce it like that. In German it's, well, "Wirth". English speakers might write it as "veart", where the "ea" is as in the word "hear" or "fear". Greg -- Sent from my desktop computer. Finger grog at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From dave at horsfall.org Thu Feb 15 09:31:37 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 15 Feb 2018 10:31:37 +1100 (EST) Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180214231939.GB87639@eureka.lemis.com> References: <20180214231939.GB87639@eureka.lemis.com> Message-ID: On Thu, 15 Feb 2018, Greg 'groggy' Lehey wrote: >> His name is pronounced "vurt" > > Maybe some English speakers pronounce it like that. In German it's, > well, "Wirth". English speakers might write it as "veart", where the > "ea" is as in the word "hear" or "fear". I wasn't giving a pedantic pronunciation lesson; as you pointed out, there is no direct English equivalent. Hell, the English even pronounce words differently in different counties (and I should know). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Thu Feb 15 09:37:06 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 15 Feb 2018 10:37:06 +1100 (EST) Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: Message-ID: On Wed, 14 Feb 2018, Clem Cole wrote: > The actual joke was Europeans called him by name(ni-klaus vurt) and > Americans by value [nickel-less worth].​ Thanks; noted in my list. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Thu Feb 15 09:50:43 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 15 Feb 2018 10:50:43 +1100 (EST) Subject: [TUHS] Clueless programmers In-Reply-To: References: <005301d3a5a0$226410d0$672c3270$@ronnatalie.com> Message-ID: On Thu, 15 Feb 2018, George Michaelson wrote: > I (and I am self-confessed as the worlds least competent programmer) > frequently found the delay between where corruption in malloc is applied > and where its detected sufficiently confusing that I would have been > tempted to follow this well trodden "remove the free()" path. MALLOC_CONF and Electric Fence are your friends; I never released any of my dynamic code without first running it past those (and some of my linked lists were hideous). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From cym224 at gmail.com Thu Feb 15 12:30:00 2018 From: cym224 at gmail.com (Nemo) Date: Wed, 14 Feb 2018 21:30:00 -0500 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: Message-ID: On 14/02/2018, Dave Horsfall wrote: > Computer pioneer Niklaus Wirth was born on this day in 1934; he basically > designed ALGOL, one of the most influential languages ever, with just > about every programming language in use today tracing its roots to it. And he is still tinkering: https://www.srf.ch/radio-srf-3/digital/computer-pionier-niklaus-wirth-80-und-aktiv N. From ggm at algebras.org Thu Feb 15 12:42:11 2018 From: ggm at algebras.org (George Michaelson) Date: Thu, 15 Feb 2018 12:42:11 +1000 Subject: [TUHS] Clueless programmers In-Reply-To: References: <005301d3a5a0$226410d0$672c3270$@ronnatalie.com> Message-ID: I've successfully debugged analogous modern code longline with smart people by judicious use of valgrind. Never underestimate the power of sending them current source, and running a tool against it with good diagnostic. Its probable that electric fence would have got there too, but this method worked for the person in question (event driven code, C++, linked to the libevent library, lots of malloc/free) It was quite entertaining for me to do this because back in the 80s when I worked at Leeds university I had to run student debug clinic, and the litany was "bring me a fresh listing" which got rid of 3/4 of the problems up front. So here I am, debugging and the moral equivalent is "send me a link to the checked in code repository in github, and valgrind output, and I'll find the problem". I am pretty sure some of the problems vanished once I got code up to date, before sending it in. On Thu, Feb 15, 2018 at 9:50 AM, Dave Horsfall wrote: > On Thu, 15 Feb 2018, George Michaelson wrote: > >> I (and I am self-confessed as the worlds least competent programmer) >> frequently found the delay between where corruption in malloc is applied and >> where its detected sufficiently confusing that I would have been tempted to >> follow this well trodden "remove the free()" path. > > > MALLOC_CONF and Electric Fence are your friends; I never released any of my > dynamic code without first running it past those (and some of my linked > lists were hideous). > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > suffer." From kevin.bowling at kev009.com Thu Feb 15 21:43:45 2018 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 15 Feb 2018 04:43:45 -0700 Subject: [TUHS] Clueless programmers In-Reply-To: <005301d3a5a0$226410d0$672c3270$@ronnatalie.com> References: <005301d3a5a0$226410d0$672c3270$@ronnatalie.com> Message-ID: I've never seen anything this bad, and it gave me a hearty laugh out loud. I guess in my years people mostly self select toward safer languages if they are human fuzzers. On Wed, Feb 14, 2018 at 7:28 AM, Ron Natalie wrote: > >> already 20 years ago I met a guy (masters degree, university) who never freed dynamically allocated memory. He told me he is 'instantiating a object', but had no idea what an heap is, and what dynamically allocated memory means. > > Years ago, I had an new programmer who I just couldn't teach. He never understood the difference between an array and pointer, and apparently couldn't be bothered to learn. > After string him along for three months, I was on my way into his office to fire him when I found out he had quit, but not before he checked a bunch of drek into our source code control system. > I thought I backed all his commits out at the time. > > Years later I was running "purify" on our product looking for memory leaks. I found this small utility function that predated the source code control system leaking. This, I thought was odd, as it had been there FOREVER and was well tested. I brought up the source code system and checked it anyhow and found the afore mentioned programmer had checked in one change: he deleted the "free" call in it. > > I KNOW what happened. He did something else to corrupt the malloc heap in his code and often this causes a core dump in a subsequent malloc/free call. Apparently this was the place it struck him, so he just deleted the free call there. > From tfb at tfeb.org Thu Feb 15 23:23:18 2018 From: tfb at tfeb.org (Tim Bradshaw) Date: Thu, 15 Feb 2018 13:23:18 +0000 Subject: [TUHS] Windows roots and Unix influence (was Re: Happy birthday, Ken Thompson!) In-Reply-To: References: <20180204091435.GA22841@indra.papnet.eu> <00d001d39ddc$a069a380$e13cea80$@ronnatalie.com> <0B2B7C84-12D8-49A6-BAA3-BD434823D41D@cheswick.com> Message-ID: <81E1EECB-9461-456D-B76A-437E574CD8BA@tfeb.org> On 7 Feb 2018, at 01:54, Dan Cross wrote: > > Oh, certainly "NT Takes Over the World!" didn't happen, and in retrospect it seems somewhat naive that anyone ever thought that it would; let alone that it would put Unix into the grave. But those doomsday predictions seemed very much to be the order of the day. Sometime around 1994 someone asked me to write a document explaining why Linux (or, perhaps Unix in general) was so much better than NT to make some business case. I got a copy of NT (3.x) and an NT design book (I'm not sure which one but there probably only was one at the time), read the book and declined to write the article, because I thought that NT would probably win, much to my dismay. I think my reasoning was that people would care about security and NT actually had a security architecture which Unix really didn't. Obviously I should have taken the money. --tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Fri Feb 16 03:32:46 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 15 Feb 2018 18:32:46 +0100 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: <20180214231939.GB87639@eureka.lemis.com> Message-ID: <20180215173246.0ep3Z%steffen@sdaoden.eu> Dave Horsfall wrote: |On Thu, 15 Feb 2018, Greg 'groggy' Lehey wrote: |>> His name is pronounced "vurt" |> |> Maybe some English speakers pronounce it like that. In German it's, |> well, "Wirth". English speakers might write it as "veart", where the |> "ea" is as in the word "hear" or "fear". | |I wasn't giving a pedantic pronunciation lesson; as you pointed out, there |is no direct English equivalent. Hell, the English even pronounce words |differently in different counties (and I should know). Just to add that (Gast)"Wirt"h is an innkeeper, and on the Nikolaus-Day children place shoes in front of their doors so that Nikolaus can put something in (chocolade!, for example). But if you would speak "e" just like "ea" than "Wert"h would surely be "Worth" it, too. I want to affiliate to the colony of thankful who appreciate your messages. Unfortunately i started collecting them just a few months ago and thus missed quite a lot of them. --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) From itz at very.loosely.org Fri Feb 16 05:18:00 2018 From: itz at very.loosely.org (Ian Zimmerman) Date: Thu, 15 Feb 2018 11:18:00 -0800 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180215173246.0ep3Z%steffen@sdaoden.eu> References: <20180214231939.GB87639@eureka.lemis.com> <20180215173246.0ep3Z%steffen@sdaoden.eu> Message-ID: <20180215191800.43vlk6mltwnmdzed@matica.foolinux.mooo.com> On 2018-02-15 18:32, Steffen Nurpmeso wrote: > I want to affiliate to the colony of thankful who appreciate your > messages. Unfortunately i started collecting them just a few months > ago and thus missed quite a lot of them. Not to worry, you'll catch up within a year or so :-P Birthdays and Yahrzeits are strange things to observe. OB-Unix: when did the "message of the day" mechanism make it into our favorite system? -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com. From steffen at sdaoden.eu Fri Feb 16 06:56:31 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 15 Feb 2018 21:56:31 +0100 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180215191800.43vlk6mltwnmdzed@matica.foolinux.mooo.com> References: <20180214231939.GB87639@eureka.lemis.com> <20180215173246.0ep3Z%steffen@sdaoden.eu> <20180215191800.43vlk6mltwnmdzed@matica.foolinux.mooo.com> Message-ID: <20180215205631.D9f0u%steffen@sdaoden.eu> Ian Zimmerman wrote: |On 2018-02-15 18:32, Steffen Nurpmeso wrote: |> I want to affiliate to the colony of thankful who appreciate your |> messages. Unfortunately i started collecting them just a few months |> ago and thus missed quite a lot of them. | |Not to worry, you'll catch up within a year or so :-P Well, maybe not. And then i have an incomplete archive. |Birthdays and Yahrzeits are strange things to observe. No, i think here you are mistaken. Likely only so if you are either young or moved away from the natural world. I can assure you the remains of biodiversity here where i live currently has a very strong notion of the Jahreszeit. |OB-Unix: when did the "message of the day" mechanism make it into our |favorite system? I do not run a BSD system daily at the moment, my own calendar file is thus unused for a while. Maybe i should write an awk script or so to have it portably available. But still an automated mail by script is something different than spending a minute to write an email to a list. I mean, you can use a drone to deliver flowers to your girl friend, or you can pretty up yourself and bring it in person. That is something very, totally, completely different. And that reminds me of a film with hrhrm Sylvester Stallone and Sandra Bullock some decades ago which joked with that exact difference. --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) From reed at reedmedia.net Fri Feb 16 07:31:22 2018 From: reed at reedmedia.net (Jeremy C. Reed) Date: Thu, 15 Feb 2018 15:31:22 -0600 (CST) Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180215191800.43vlk6mltwnmdzed@matica.foolinux.mooo.com> References: <20180214231939.GB87639@eureka.lemis.com> <20180215173246.0ep3Z%steffen@sdaoden.eu> <20180215191800.43vlk6mltwnmdzed@matica.foolinux.mooo.com> Message-ID: On Thu, 15 Feb 2018, Ian Zimmerman wrote: > OB-Unix: when did the "message of the day" mechanism make it into our > favorite system? Always there! (My favorite is NetBSD which derived from BSD which originally derived from 32V and before that as enhancements and patches against v4 through v6.) v1 has the concept http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/man/man7/login.7 but I don't find the code for it. v2 has it http://minnie.tuhs.org/cgi-bin/utree.pl?file=V2/cmd/login.s (By the way, where is the shell code referenced in init.s for the earlier Unix? http://minnie.tuhs.org/cgi-bin/utree.pl?file=PDP7-Unix ) From dave at horsfall.org Fri Feb 16 10:01:22 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 16 Feb 2018 11:01:22 +1100 (EST) Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: Message-ID: On Wed, 14 Feb 2018, Toby Thain wrote: >> ALGOL, one of the most influential languages ever, with just about >> every programming language in use today tracing its roots to it. > > Worth mentioning one significant exception: the Lisp family. I know about LISP (and even used it); it's on my history list. Actually, I can't think of any language that derived exclusively from LISP (other than Scheme etc)... Oh, and EMACS :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From crossd at gmail.com Fri Feb 16 10:51:14 2018 From: crossd at gmail.com (Dan Cross) Date: Thu, 15 Feb 2018 19:51:14 -0500 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: Message-ID: On Thu, Feb 15, 2018 at 7:01 PM, Dave Horsfall wrote: > On Wed, 14 Feb 2018, Toby Thain wrote: > >> ALGOL, one of the most influential languages ever, with just about every >>> programming language in use today tracing its roots to it. >>> >> >> Worth mentioning one significant exception: the Lisp family. >> > > I know about LISP (and even used it); it's on my history list. > > Actually, I can't think of any language that derived exclusively from LISP > (other than Scheme etc)... Oh, and EMACS :-) > There were (and are!) a whole bunch of dialects of Lisp: Common Lisp and Scheme might be the best known, with Clojure a modern entrant. Arc is sort of a thing. Most folks know about emacs Lisp. All of these derive from the original Lisp. But there were a whole slew of historical dialects descended from Lisp 1.5: MacLisp, InterLisp, FranzLisp, Lisp Machine Lisp, the original variant implemented by Symbolics before they adopted Common Lisp, Portable Standard Lisp...and any number of others that were implemented as extension languages: AutoLisp from AutoCAD, the aforementioned Emacs Lisp, the pseudo-Lisp from Gosling's Emacs, and plenty of others. And how about implementations? VAX Lisp, LispWorks, Allegro, etc. I think the thing is that "Lisp" isn't a single language, but rather a family of languages that all share common features (code is data, macros, etc, etc, etc) with lots of variation between them (I understand that there was serious argument about whether integer literals should be written in octal in Common Lisp, as they were in MacLisp. Somehow common sense prevailed). So, how's this relevant to Unix? Well, I'd like to know more about the historical interplay between the Unix and Lisp communities. What about the Lisp done at Berkeley on the VAX (Franz Lisp). One of the things that strikes me about Lisp and Unix is the conceptual similarity between image based languages (like Lisp) with a REPL and the Unix "process as virtual machine" model with a shell and set of utilities. An image is a sort of virtual machine and a REPL is a sort of shell; callable functions in the REPL are sort of like discrete programs in the $PATH. To a first order approximation, at any rate. So anyway...some of you who were there, was there cross-pollination? Was Franz Lisp a thing Unix people at Berkeley played with, or was it mostly Lisp people who just happened to be using Unix because VAXen were expensive? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Feb 16 11:06:59 2018 From: clemc at ccc.com (Clem cole) Date: Thu, 15 Feb 2018 20:06:59 -0500 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: Message-ID: The whole reason VM was developed at UCB was because Ernie (the original) Vax was funded to develop the ability to port MacLisp and more importantly Macsyma from ITS. V32’s static address space was not going to work. Btw the program we used to debug the VM system on the original mc500 was macsyma’s competition, sms (which would later become wolfram). In both cases the idea was to ensure the memory system was being exercised. Clem Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Feb 15, 2018, at 7:51 PM, Dan Cross wrote: > >> On Thu, Feb 15, 2018 at 7:01 PM, Dave Horsfall wrote: >> On Wed, 14 Feb 2018, Toby Thain wrote: >>>> ALGOL, one of the most influential languages ever, with just about every programming language in use today tracing its roots to it. >>> >>> Worth mentioning one significant exception: the Lisp family. >> >> I know about LISP (and even used it); it's on my history list. >> >> Actually, I can't think of any language that derived exclusively from LISP (other than Scheme etc)... Oh, and EMACS :-) > > There were (and are!) a whole bunch of dialects of Lisp: Common Lisp and Scheme might be the best known, with Clojure a modern entrant. Arc is sort of a thing. Most folks know about emacs Lisp. All of these derive from the original Lisp. > > But there were a whole slew of historical dialects descended from Lisp 1.5: MacLisp, InterLisp, FranzLisp, Lisp Machine Lisp, the original variant implemented by Symbolics before they adopted Common Lisp, Portable Standard Lisp...and any number of others that were implemented as extension languages: AutoLisp from AutoCAD, the aforementioned Emacs Lisp, the pseudo-Lisp from Gosling's Emacs, and plenty of others. And how about implementations? VAX Lisp, LispWorks, Allegro, etc. I think the thing is that "Lisp" isn't a single language, but rather a family of languages that all share common features (code is data, macros, etc, etc, etc) with lots of variation between them (I understand that there was serious argument about whether integer literals should be written in octal in Common Lisp, as they were in MacLisp. Somehow common sense prevailed). > > So, how's this relevant to Unix? Well, I'd like to know more about the historical interplay between the Unix and Lisp communities. What about the Lisp done at Berkeley on the VAX (Franz Lisp). > > One of the things that strikes me about Lisp and Unix is the conceptual similarity between image based languages (like Lisp) with a REPL and the Unix "process as virtual machine" model with a shell and set of utilities. An image is a sort of virtual machine and a REPL is a sort of shell; callable functions in the REPL are sort of like discrete programs in the $PATH. To a first order approximation, at any rate. > > So anyway...some of you who were there, was there cross-pollination? Was Franz Lisp a thing Unix people at Berkeley played with, or was it mostly Lisp people who just happened to be using Unix because VAXen were expensive? > > - Dan C. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Feb 16 11:18:15 2018 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 15 Feb 2018 17:18:15 -0800 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: Message-ID: <20180216011815.GD8295@mcvoy.com> On Thu, Feb 15, 2018 at 07:51:14PM -0500, Dan Cross wrote: > >> Worth mentioning one significant exception: the Lisp family. > > So anyway...some of you who were there, was there cross-pollination? Was > Franz Lisp a thing Unix people at Berkeley played with, or was it mostly > Lisp people who just happened to be using Unix because VAXen were expensive? This is just my opinion so there is a grain of salt. Or a salt shaker. I think there are two (at least) sorts of programmers, the systems people and the lisp people. Sometimes you get both kinds in the same person but that tends to be rare (and awesome, I've employeed several of those, they were magic). I'm a systems guy. I've played with lisp, even wrote a tiny lisp (haven't we all?), tried to get to like it and utterly failed. All sorts of smart people I knew in my career loved lisp, sneered at any other language, tended to think in ASTs, etc, etc. I definitely felt inferior and tried to like lisp but just never got what was so neat about it. For good reason, I think. Nobody has written a serious operating system, or a serious $BIG_PROJECT in Lisp. Not one that has been commercially successful, so far as I know. I know there were attempts but all those attempts failed. Why? Performance I think. C performs far better even though it is, in the eyes of lisp people, far more awkward to do things. I can't tell you the number of times I've heard "If we were using Lisp we'd be done by now". 100's, 1000's. What I have never heard is "I recoded this pile of C in lisp and it's 10x faster". I think the thing is that lisp programmers were optimizing for speed of coding and C programmers were optimizing for speed of execution. So I suspect that Franz Lisp was mostly lisp people who happened to be using Unix. But I wasn't at Berkeley so what do I know? --lm From itz at very.loosely.org Fri Feb 16 11:25:54 2018 From: itz at very.loosely.org (Ian Zimmerman) Date: Thu, 15 Feb 2018 17:25:54 -0800 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: Message-ID: <20180216012554.zvfmbi7uhjtuwnd6@matica.foolinux.mooo.com> On 2018-02-15 19:51, Dan Cross wrote: > So, how's this relevant to Unix? Well, I'd like to know more about the > historical interplay between the Unix and Lisp communities. What about > the Lisp done at Berkeley on the VAX (Franz Lisp). I know one of the Franz founders, I'll ask him when I have a chance. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com. From ggm at algebras.org Fri Feb 16 11:55:48 2018 From: ggm at algebras.org (George Michaelson) Date: Fri, 16 Feb 2018 11:55:48 +1000 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180216011815.GD8295@mcvoy.com> References: <20180216011815.GD8295@mcvoy.com> Message-ID: syntactically, semantically, a lot of the strongly typed functional programming outcomes have roots into ideas explored in the LISP family. the quants are using it heavily. The declarative, checked-at-compile qualities reduce errors, the statements have some authority and the formulaic expression of things as compositions over functions works for their brains. the typing wasn't strong in LISP but the FP expressive quality and lazy eval was. Sure, it was in Algol family languages too, but I think it got sort-of left out when C hit the road. I struggle with FP. I have major envy of minds which can think like that. I wish I had that kind of mind. I sit with someone who does. He front loads his problems with type statements and produces terse but very efficient code. Its a marketable skill in the right place. I think you're right its not very system-y but the lines are blurring. Go introduces the need for GC. Once you need GC, you enter a door where all the things we said we didn't do pop back into view, including lazy evaluation which is in the foundation of FP, and .. LISP. So for the set of problems which people say "coded in GO" you can think "hmm: maybe GHC with the right frobs would work there" Rust apparently doesn't do GC. So maybe its more in the 'not in my world' camp. Syntactically Go is of course nothing LIKE an FP as I understand it, but then I can't program functionally, so I don't entirely know what I know any more here. On Fri, Feb 16, 2018 at 11:18 AM, Larry McVoy wrote: > On Thu, Feb 15, 2018 at 07:51:14PM -0500, Dan Cross wrote: >> >> Worth mentioning one significant exception: the Lisp family. >> >> So anyway...some of you who were there, was there cross-pollination? Was >> Franz Lisp a thing Unix people at Berkeley played with, or was it mostly >> Lisp people who just happened to be using Unix because VAXen were expensive? > > This is just my opinion so there is a grain of salt. Or a salt shaker. > > I think there are two (at least) sorts of programmers, the systems people > and the lisp people. Sometimes you get both kinds in the same person > but that tends to be rare (and awesome, I've employeed several of those, > they were magic). > > I'm a systems guy. I've played with lisp, even wrote a tiny lisp (haven't > we all?), tried to get to like it and utterly failed. All sorts of smart > people I knew in my career loved lisp, sneered at any other language, > tended to think in ASTs, etc, etc. I definitely felt inferior and tried > to like lisp but just never got what was so neat about it. > > For good reason, I think. Nobody has written a serious operating system, > or a serious $BIG_PROJECT in Lisp. Not one that has been commercially > successful, so far as I know. I know there were attempts but all those > attempts failed. Why? Performance I think. C performs far better even > though it is, in the eyes of lisp people, far more awkward to do things. > > I can't tell you the number of times I've heard "If we were using Lisp > we'd be done by now". 100's, 1000's. What I have never heard is "I > recoded this pile of C in lisp and it's 10x faster". > > I think the thing is that lisp programmers were optimizing for speed > of coding and C programmers were optimizing for speed of execution. > > So I suspect that Franz Lisp was mostly lisp people who happened to be > using Unix. But I wasn't at Berkeley so what do I know? > > --lm From stewart at serissa.com Fri Feb 16 11:56:21 2018 From: stewart at serissa.com (Lawrence Stewart) Date: Thu, 15 Feb 2018 20:56:21 -0500 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180216011815.GD8295@mcvoy.com> References: <20180216011815.GD8295@mcvoy.com> Message-ID: ITA’s airline flight booking system, that was used by Orbitz and others was pretty much entirely written in Common LISP, and it was certainly both large and commercially successful. Orbitz was bought by Google for $700 million. I don’t know how much of the LISP survived sustained attention by Google. Paul Graham’s company Viaweb was all LISP. It was bought by Yahoo! for $50 million and became Yahoo! Store. I think of myself as a systems person and C is still my primary language, but I wrote the routing software for the wacky Kautz graph in the Sicortex machines in Common LISP. It was substantially easier! After it worked I recoded in C for production. It isn’t that Common LISP isn’t perfectly fast enough, we just didn’t want garbage collection at that level of the software. My favorite LISP story is the time I was hired to evaluate a proposed Cryptosystem. I was handed 40 pages of C code. I reimplemented it in 15 (short) lines of Common LISP. It wasn’t hard to crack after it fit on one page! I came to LISP 30 years late because I was in 6-1 at MIT rather than 6-3 so I didn’t learn LISP or Scheme. I am not one of the awesome folks of which you speak, but I’ve met them and know what you mean. One MIT physicist I met thought MILC was too complicated so his quantum chromodynamics code was in LISP. He wrote his own LISP->C translator to get it to generate exactly the code he wanted. -L > On 2018, Feb 15, at 8:18 PM, Larry McVoy wrote: > > On Thu, Feb 15, 2018 at 07:51:14PM -0500, Dan Cross wrote: >>>> Worth mentioning one significant exception: the Lisp family. >> >> So anyway...some of you who were there, was there cross-pollination? Was >> Franz Lisp a thing Unix people at Berkeley played with, or was it mostly >> Lisp people who just happened to be using Unix because VAXen were expensive? > > This is just my opinion so there is a grain of salt. Or a salt shaker. > > I think there are two (at least) sorts of programmers, the systems people > and the lisp people. Sometimes you get both kinds in the same person > but that tends to be rare (and awesome, I've employeed several of those, > they were magic). > > I'm a systems guy. I've played with lisp, even wrote a tiny lisp (haven't > we all?), tried to get to like it and utterly failed. All sorts of smart > people I knew in my career loved lisp, sneered at any other language, > tended to think in ASTs, etc, etc. I definitely felt inferior and tried > to like lisp but just never got what was so neat about it. > > For good reason, I think. Nobody has written a serious operating system, > or a serious $BIG_PROJECT in Lisp. Not one that has been commercially > successful, so far as I know. I know there were attempts but all those > attempts failed. Why? Performance I think. C performs far better even > though it is, in the eyes of lisp people, far more awkward to do things. > > I can't tell you the number of times I've heard "If we were using Lisp > we'd be done by now". 100's, 1000's. What I have never heard is "I > recoded this pile of C in lisp and it's 10x faster". > > I think the thing is that lisp programmers were optimizing for speed > of coding and C programmers were optimizing for speed of execution. > > So I suspect that Franz Lisp was mostly lisp people who happened to be > using Unix. But I wasn't at Berkeley so what do I know? > > --lm From bakul at bitblocks.com Fri Feb 16 12:09:29 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 15 Feb 2018 18:09:29 -0800 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: Your message of "Thu, 15 Feb 2018 19:51:14 -0500." References: Message-ID: <20180216020944.AF0ED156E80B@mail.bitblocks.com> On Thu, 15 Feb 2018 19:51:14 -0500 Dan Cross wrote: Dan Cross writes: > > On Thu, Feb 15, 2018 at 7:01 PM, Dave Horsfall wrote: > > > On Wed, 14 Feb 2018, Toby Thain wrote: > > > >> ALGOL, one of the most influential languages ever, with just about every > >>> programming language in use today tracing its roots to it. > >>> > >> > >> Worth mentioning one significant exception: the Lisp family. > >> > > > > I know about LISP (and even used it); it's on my history list. > > > > Actually, I can't think of any language that derived exclusively from LISP > > (other than Scheme etc)... Oh, and EMACS :-) > > > > There were (and are!) a whole bunch of dialects of Lisp: Common Lisp and > Scheme might be the best known, with Clojure a modern entrant. Arc is sort > of a thing. Most folks know about emacs Lisp. All of these derive from the > original Lisp. Scheme's lexical scope and block structure came from Algol. The rest from Lisp. The joke was that the shortest and longest language specs were of lisp dialects. The C++ spec may be longer now. > But there were a whole slew of historical dialects descended from Lisp 1.5: > MacLisp, InterLisp, FranzLisp, Lisp Machine Lisp, the original variant > implemented by Symbolics before they adopted Common Lisp, Portable Standard > Lisp...and any number of others that were implemented as extension > languages: AutoLisp from AutoCAD, the aforementioned Emacs Lisp, the IIRC AutoLISP came from David Betz' Xlisp. Before it became a superset of Scheme. > So, how's this relevant to Unix? Well, I'd like to know more about the > historical interplay between the Unix and Lisp communities. What about the > Lisp done at Berkeley on the VAX (Franz Lisp). > > One of the things that strikes me about Lisp and Unix is the conceptual > similarity between image based languages (like Lisp) with a REPL and the > Unix "process as virtual machine" model with a shell and set of utilities. > An image is a sort of virtual machine and a REPL is a sort of shell; > callable functions in the REPL are sort of like discrete programs in the > $PATH. To a first order approximation, at any rate. They feel very different to me. Lisp was/is a closed world & its FFI (foreign func. interface) always seemed like an afterthought. In a shell you can string together programs written in any language so long as they input/output text lines. Its pipe symbol allowed infix notation for function composition. As a programming language I prefer Scheme over almost everything else but have to admit that most of my oneliner scripts are in sh and I mostly program in Go these days. From jnc at mercury.lcs.mit.edu Fri Feb 16 12:19:31 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 15 Feb 2018 21:19:31 -0500 (EST) Subject: [TUHS] Happy birthday, Niklaus Wirth! Message-ID: <20180216021931.7450118C088@mercury.lcs.mit.edu> > From: Larry McVoy I am completely non-LISP person (I think my brain was wired in C before C existed :-), but... > Nobody has written a serious operating system Well, the LISP Machine OS was written entirely in LISP. Dunno if you call that a 'serious OS', but it was a significantly more capable OS than, say, DOS. (OK, there was a lot of microcde that did a lot of the low-level stuff, but...) > or a serious $BIG_PROJECT in Lisp. Have you ever seen a set of Symbolics manuals? Sylph-like, it wesn't! > Not one that has been commercially successful, so far as I know. It's true that Symbolics _eventually_ crashed, but I think the biggest factor there was that commodity microprocessors (e.g. Pentium) got faster so much faster than Symbolics' custom LISP hardware, so that the whole rationale for Symbolics (custom hardware to run LISP fast) went away. They still exist as a software company selling their coding environment, FWTW. > C performs far better even though it is, in the eyes of lisp people, far > more awkward to do things. I think it depend on what you're doing. For some kinds of things, LISP is probably better. I mean, for most of the kind of things I do, I think C is the bees' knees (well, except I had to add conditions and condition handlers when I went to write a compiler in it), but for some of the AI projects I know a little about, LISP seems (from a distance, admittedly) to be a better match. Noel From toby at telegraphics.com.au Fri Feb 16 12:31:14 2018 From: toby at telegraphics.com.au (Toby Thain) Date: Thu, 15 Feb 2018 21:31:14 -0500 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180216020944.AF0ED156E80B@mail.bitblocks.com> References: <20180216020944.AF0ED156E80B@mail.bitblocks.com> Message-ID: <309ca15a-4625-d0f4-5693-76253d27f93f@telegraphics.com.au> On 2018-02-15 9:09 PM, Bakul Shah wrote: > Scheme's lexical scope and block structure came from Algol. I'd have said lambda calculus but OK From crossd at gmail.com Fri Feb 16 12:38:02 2018 From: crossd at gmail.com (Dan Cross) Date: Thu, 15 Feb 2018 21:38:02 -0500 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: <20180216011815.GD8295@mcvoy.com> Message-ID: On Thu, Feb 15, 2018 at 8:56 PM, Lawrence Stewart wrote: > ITA’s airline flight booking system, that was used by Orbitz and others > was pretty much entirely written in Common LISP, and it was certainly both > large and commercially successful. Orbitz was bought by Google for $700 > million. I don’t know how much of the LISP survived sustained attention by > Google. > Google bought ITA, not Orbitz. Most of the logic in QPX is still in Common Lisp, but it's not what you'd call "idiomatic" CL code. If one reads a bunch of Paul Graham and Peter Norvig books and then gets onto QPX with the expectation of that sort of elegance, you end up pretty unhappy pretty quick. They do a lot of things very differently to squeeze as much performance as they can out of what has, historically speaking, been a fairly mediocre compiler. - Dan C. Paul Graham’s company Viaweb was all LISP. It was bought by Yahoo! for $50 > million and became Yahoo! Store. > > I think of myself as a systems person and C is still my primary language, > but I wrote the routing software for the wacky Kautz graph in the Sicortex > machines in Common LISP. It was substantially easier! After it worked I > recoded in C for production. It isn’t that Common LISP isn’t perfectly > fast enough, we just didn’t want garbage collection at that level of the > software. > > My favorite LISP story is the time I was hired to evaluate a proposed > Cryptosystem. I was handed 40 pages of C code. I reimplemented it in 15 > (short) lines of Common LISP. It wasn’t hard to crack after it fit on one > page! > > I came to LISP 30 years late because I was in 6-1 at MIT rather than 6-3 > so I didn’t learn LISP or Scheme. I am not one of the awesome folks of > which you speak, but I’ve met them and know what you mean. One MIT > physicist I met thought MILC was too complicated so his quantum > chromodynamics code was in LISP. He wrote his own LISP->C translator to > get it to generate exactly the code he wanted. > > -L > > > On 2018, Feb 15, at 8:18 PM, Larry McVoy wrote: > > > > On Thu, Feb 15, 2018 at 07:51:14PM -0500, Dan Cross wrote: > >>>> Worth mentioning one significant exception: the Lisp family. > >> > >> So anyway...some of you who were there, was there cross-pollination? Was > >> Franz Lisp a thing Unix people at Berkeley played with, or was it mostly > >> Lisp people who just happened to be using Unix because VAXen were > expensive? > > > > This is just my opinion so there is a grain of salt. Or a salt shaker. > > > > I think there are two (at least) sorts of programmers, the systems people > > and the lisp people. Sometimes you get both kinds in the same person > > but that tends to be rare (and awesome, I've employeed several of those, > > they were magic). > > > > I'm a systems guy. I've played with lisp, even wrote a tiny lisp > (haven't > > we all?), tried to get to like it and utterly failed. All sorts of smart > > people I knew in my career loved lisp, sneered at any other language, > > tended to think in ASTs, etc, etc. I definitely felt inferior and tried > > to like lisp but just never got what was so neat about it. > > > > For good reason, I think. Nobody has written a serious operating system, > > or a serious $BIG_PROJECT in Lisp. Not one that has been commercially > > successful, so far as I know. I know there were attempts but all those > > attempts failed. Why? Performance I think. C performs far better even > > though it is, in the eyes of lisp people, far more awkward to do things. > > > > I can't tell you the number of times I've heard "If we were using Lisp > > we'd be done by now". 100's, 1000's. What I have never heard is "I > > recoded this pile of C in lisp and it's 10x faster". > > > > I think the thing is that lisp programmers were optimizing for speed > > of coding and C programmers were optimizing for speed of execution. > > > > So I suspect that Franz Lisp was mostly lisp people who happened to be > > using Unix. But I wasn't at Berkeley so what do I know? > > > > --lm > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Feb 16 12:41:08 2018 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 15 Feb 2018 18:41:08 -0800 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: <20180216011815.GD8295@mcvoy.com> Message-ID: <20180216024108.GG8295@mcvoy.com> On Thu, Feb 15, 2018 at 09:38:02PM -0500, Dan Cross wrote: > On Thu, Feb 15, 2018 at 8:56 PM, Lawrence Stewart > wrote: > > > ITA???s airline flight booking system, that was used by Orbitz and others > > was pretty much entirely written in Common LISP, and it was certainly both > > large and commercially successful. Orbitz was bought by Google for $700 > > million. I don???t know how much of the LISP survived sustained attention by > > Google. > > > > Google bought ITA, not Orbitz. Most of the logic in QPX is still in Common > Lisp, but it's not what you'd call "idiomatic" CL code. If one reads a > bunch of Paul Graham and Peter Norvig books and then gets onto QPX with the > expectation of that sort of elegance, you end up pretty unhappy pretty > quick. They do a lot of things very differently to squeeze as much > performance as they can out of what has, historically speaking, been a > fairly mediocre compiler. Which is sort of my point. I don't know all the details but lisp and performance is not a thing. From lm at mcvoy.com Fri Feb 16 12:48:57 2018 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 15 Feb 2018 18:48:57 -0800 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180216021931.7450118C088@mercury.lcs.mit.edu> References: <20180216021931.7450118C088@mercury.lcs.mit.edu> Message-ID: <20180216024857.GH8295@mcvoy.com> > I think it depend on what you're doing. For some kinds of things, LISP is > probably better. I'd like to be told, as a systems guy, what those things are. I know that people have done awesome stuff in lisp. But there is swimming downstream and there is swimming upstream. From toby at telegraphics.com.au Fri Feb 16 12:51:21 2018 From: toby at telegraphics.com.au (Toby Thain) Date: Thu, 15 Feb 2018 21:51:21 -0500 Subject: [TUHS] Clueless programmers - was Re: Happy birthday, Niklaus Wirth! In-Reply-To: <20180216024108.GG8295@mcvoy.com> References: <20180216011815.GD8295@mcvoy.com> <20180216024108.GG8295@mcvoy.com> Message-ID: <1f34ab53-3424-7561-ba15-b85d6af89bea@telegraphics.com.au> On 2018-02-15 9:41 PM, Larry McVoy wrote: > On Thu, Feb 15, 2018 at 09:38:02PM -0500, Dan Cross wrote: >> On Thu, Feb 15, 2018 at 8:56 PM, Lawrence Stewart >> wrote: >> >>> ITA???s airline flight booking system, that was used by Orbitz and others >>> was pretty much entirely written in Common LISP, and it was certainly both >>> large and commercially successful. Orbitz was bought by Google for $700 >>> million. I don???t know how much of the LISP survived sustained attention by >>> Google. >>> >> >> Google bought ITA, not Orbitz. Most of the logic in QPX is still in Common >> Lisp, but it's not what you'd call "idiomatic" CL code. If one reads a >> bunch of Paul Graham and Peter Norvig books and then gets onto QPX with the >> expectation of that sort of elegance, you end up pretty unhappy pretty >> quick. They do a lot of things very differently to squeeze as much >> performance as they can out of what has, historically speaking, been a >> fairly mediocre compiler. > > Which is sort of my point. I don't know all the details but lisp and > performance is not a thing. > You can stop at "I don't know all the details". That meme about performance is not actually true, but it's popular among people who don't know Lisp technically or use it professionally. There are a number of mature Common Lisp compilers and some of them boast outstanding performance. --T From crossd at gmail.com Fri Feb 16 12:51:20 2018 From: crossd at gmail.com (Dan Cross) Date: Thu, 15 Feb 2018 21:51:20 -0500 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180216024108.GG8295@mcvoy.com> References: <20180216011815.GD8295@mcvoy.com> <20180216024108.GG8295@mcvoy.com> Message-ID: On Thu, Feb 15, 2018 at 9:41 PM, Larry McVoy wrote: > On Thu, Feb 15, 2018 at 09:38:02PM -0500, Dan Cross wrote: > > On Thu, Feb 15, 2018 at 8:56 PM, Lawrence Stewart > > wrote: > > > > > ITA???s airline flight booking system, that was used by Orbitz and > others > > > was pretty much entirely written in Common LISP, and it was certainly > both > > > large and commercially successful. Orbitz was bought by Google for > $700 > > > million. I don???t know how much of the LISP survived sustained > attention by > > > Google. > > > > > > > Google bought ITA, not Orbitz. Most of the logic in QPX is still in > Common > > Lisp, but it's not what you'd call "idiomatic" CL code. If one reads a > > bunch of Paul Graham and Peter Norvig books and then gets onto QPX with > the > > expectation of that sort of elegance, you end up pretty unhappy pretty > > quick. They do a lot of things very differently to squeeze as much > > performance as they can out of what has, historically speaking, been a > > fairly mediocre compiler. > > Which is sort of my point. I don't know all the details but lisp and > performance is not a thing. > That's a tad unfair. It *can* be fast, it's just that the "Lisp" you're writing in that case probably isn't the Lisp you wanted to be writing when you read about how cool and elegant Lisp was: you're avoiding some constructs to prevent boxing and unboxing arguments (e.g., put things inside of labels or flet's instead of defun's or passing arbitrary lambdas around) or generating useless garbage (don't cons up a list; setq the cdr) and favoring others that are less elegant to get better object code out of the compiler. If you can stomach the death-defying twists and turns from all the hoops you have to jump through for all of that nonsense, then you can make it fast -- but at the loss of the expressive advantage. But that trade-off begs the question: why not write in a language that lets you write fast (executing) code without jumping through hoops? That's a fair thing to ask and most of the answers in Lisp's favor aren't particularly great. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Feb 16 12:55:35 2018 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 15 Feb 2018 18:55:35 -0800 Subject: [TUHS] Clueless programmers - was Re: Happy birthday, Niklaus Wirth! In-Reply-To: <1f34ab53-3424-7561-ba15-b85d6af89bea@telegraphics.com.au> References: <20180216011815.GD8295@mcvoy.com> <20180216024108.GG8295@mcvoy.com> <1f34ab53-3424-7561-ba15-b85d6af89bea@telegraphics.com.au> Message-ID: <20180216025535.GI8295@mcvoy.com> On Thu, Feb 15, 2018 at 09:51:21PM -0500, Toby Thain wrote: > On 2018-02-15 9:41 PM, Larry McVoy wrote: > > On Thu, Feb 15, 2018 at 09:38:02PM -0500, Dan Cross wrote: > >> On Thu, Feb 15, 2018 at 8:56 PM, Lawrence Stewart > >> wrote: > >> > >>> ITA???s airline flight booking system, that was used by Orbitz and others > >>> was pretty much entirely written in Common LISP, and it was certainly both > >>> large and commercially successful. Orbitz was bought by Google for $700 > >>> million. I don???t know how much of the LISP survived sustained attention by > >>> Google. > >>> > >> > >> Google bought ITA, not Orbitz. Most of the logic in QPX is still in Common > >> Lisp, but it's not what you'd call "idiomatic" CL code. If one reads a > >> bunch of Paul Graham and Peter Norvig books and then gets onto QPX with the > >> expectation of that sort of elegance, you end up pretty unhappy pretty > >> quick. They do a lot of things very differently to squeeze as much > >> performance as they can out of what has, historically speaking, been a > >> fairly mediocre compiler. > > > > Which is sort of my point. I don't know all the details but lisp and > > performance is not a thing. > > > > You can stop at "I don't know all the details". That meme about > performance is not actually true, but it's popular among people who > don't know Lisp technically or use it professionally. > > There are a number of mature Common Lisp compilers and some of them > boast outstanding performance. I'm fine with your claim but I'd like to see a pile of C code that was rewritten in lisp and it is faster. I'm 99.9% sure that's not a thing. Lisp is fantastic for programmers who know how to use it, which is why so many people are lisp fanatics. But performant it is not. Feel free to show me how I'm wrong, I love being wrong, that's where I learn. --lm From ggm at algebras.org Fri Feb 16 12:56:59 2018 From: ggm at algebras.org (George Michaelson) Date: Fri, 16 Feb 2018 12:56:59 +1000 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: <20180216011815.GD8295@mcvoy.com> <20180216024108.GG8295@mcvoy.com> Message-ID: I tried to hire an engineer in the 1990s. She came to the interview with her (probably over-controlling) father who was the founder of the two person consulting company she'd been working for. They coded a huge traffic-light management system entirely in LISP. Major stuff. >From memory, we offered but I think daddy didn't like the way we behaved, she didn't accept. I think she was an incredibly good programmer. Really smart, competent. It was my first clue that out in the "real world" (I was working in a university) you could code in LISP and sell solutions that ran things like traffic lights: People die if you get that wrong. Awesome. (it's equally likely we didn't offer, being stupid) On Fri, Feb 16, 2018 at 12:51 PM, Dan Cross wrote: > On Thu, Feb 15, 2018 at 9:41 PM, Larry McVoy wrote: >> >> On Thu, Feb 15, 2018 at 09:38:02PM -0500, Dan Cross wrote: >> > On Thu, Feb 15, 2018 at 8:56 PM, Lawrence Stewart >> > wrote: >> > >> > > ITA???s airline flight booking system, that was used by Orbitz and >> > > others >> > > was pretty much entirely written in Common LISP, and it was certainly >> > > both >> > > large and commercially successful. Orbitz was bought by Google for >> > > $700 >> > > million. I don???t know how much of the LISP survived sustained >> > > attention by >> > > Google. >> > > >> > >> > Google bought ITA, not Orbitz. Most of the logic in QPX is still in >> > Common >> > Lisp, but it's not what you'd call "idiomatic" CL code. If one reads a >> > bunch of Paul Graham and Peter Norvig books and then gets onto QPX with >> > the >> > expectation of that sort of elegance, you end up pretty unhappy pretty >> > quick. They do a lot of things very differently to squeeze as much >> > performance as they can out of what has, historically speaking, been a >> > fairly mediocre compiler. >> >> Which is sort of my point. I don't know all the details but lisp and >> performance is not a thing. > > > That's a tad unfair. > > It *can* be fast, it's just that the "Lisp" you're writing in that case > probably isn't the Lisp you wanted to be writing when you read about how > cool and elegant Lisp was: you're avoiding some constructs to prevent boxing > and unboxing arguments (e.g., put things inside of labels or flet's instead > of defun's or passing arbitrary lambdas around) or generating useless > garbage (don't cons up a list; setq the cdr) and favoring others that are > less elegant to get better object code out of the compiler. > > If you can stomach the death-defying twists and turns from all the hoops you > have to jump through for all of that nonsense, then you can make it fast -- > but at the loss of the expressive advantage. But that trade-off begs the > question: why not write in a language that lets you write fast (executing) > code without jumping through hoops? That's a fair thing to ask and most of > the answers in Lisp's favor aren't particularly great. > > - Dan C. > From toby at telegraphics.com.au Fri Feb 16 13:10:51 2018 From: toby at telegraphics.com.au (Toby Thain) Date: Thu, 15 Feb 2018 22:10:51 -0500 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: Message-ID: <384ec24d-bb53-18a2-b90f-f47d897de67d@telegraphics.com.au> On 2018-02-15 8:06 PM, Clem cole wrote: > The whole reason VM was developed at UCB was because Ernie (the > original) Vax was funded to develop the ability to port MacLisp and more > importantly Macsyma from ITS.   > V32’s static address space was not going to work.  > > > Btw the program we used to debug the VM system on the original mc500 was > macsyma’s competition, sms (which would later become wolfram). > You probably meant "SMP", built by Wolfram and others at Caltech: http://www.stephenwolfram.com/publications/smp-symbolic-manipulation-program/ It sounds like Mathematica probably did not _directly_ derive from SMP due to a court ruling. "A dispute with the administration over the intellectual property rights regarding SMP—patents, copyright, and faculty involvement in commercial ventures—eventually caused him to resign from Caltech. SMP was further developed and marketed commercially by Inference Corp. of Los Angeles during 1983–1988." Curiously, the above text has been copied and pasted verbatim all over the web and it's not clear where it originated. "SMP was essentially Version Zero of the more ambitious Mathematica system" is also all over the web including Wikipedia. > In both cases the idea was to ensure the memory system was being exercised. Nowadays we'd just run gcc :) --Toby > > Clem > > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not > quite.  > ... From drsalists at gmail.com Fri Feb 16 13:17:01 2018 From: drsalists at gmail.com (Dan Stromberg) Date: Thu, 15 Feb 2018 19:17:01 -0800 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: Message-ID: On Thu, Feb 15, 2018 at 4:51 PM, Dan Cross wrote: > One of the things that strikes me about Lisp and Unix is the conceptual > similarity between image based languages (like Lisp) with a REPL and the > Unix "process as virtual machine" model with a shell and set of utilities. > An image is a sort of virtual machine and a REPL is a sort of shell; > callable functions in the REPL are sort of like discrete programs in the > $PATH. To a first order approximation, at any rate. > > So anyway...some of you who were there, was there cross-pollination? Was > Franz Lisp a thing Unix people at Berkeley played with, or was it mostly > Lisp people who just happened to be using Unix because VAXen were expensive? I definitely "wasn't there", but it's occurred to me before that /bin/sh going through a file line by line, is similar to LISP going through a list element by element. When I took a "comparative languages" course, the professor said there were two kinds of languages: 1) Languages that make you add convenience yourself to keep things fast even though many people don't need the speed 2) Languages that make everyone pay (in performance) for conveniences many developers will never need So it's kind of the C vs. LISP thing from a (very) slightly different perspective. I still count C and bash among my favorites, but I mostly use Python these days, and although I haven't done a ton in LISP, Python feels kind of LISPy semantically - but not syntactically or lexically. But that's a happy accident: Python wasn't particularly influence by LISP. On the other hand, with LISP focused on Linked Lists, and Python focused on realloc()'d arrays, the similarly isn't especially deep. But they're both "convenience at the expense of performance, even though not everyone will need those conveniences". And yes, there are exceptions. As has already been mentioned, LISP has some impressive compilers, and Python has things like Pypy and Shedskin. From paul at mcjones.org Fri Feb 16 12:40:33 2018 From: paul at mcjones.org (Paul McJones) Date: Thu, 15 Feb 2018 18:40:33 -0800 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: Message-ID: On Feb 15, 2018, Ian Zimmerman wrote: >> >> So, how's this relevant to Unix? Well, I'd like to know more about the >> historical interplay between the Unix and Lisp communities. What about >> the Lisp done at Berkeley on the VAX (Franz Lisp). > > I know one of the Franz founders, I'll ask him when I have a chance. There is some information about Franz Lisp and its origins here: http://www.softwarepreservation.org/projects/LISP/maclisp_family/#Franz_Lisp_ (And lots more information about many other varieties of Lisp at the same web site.) From usotsuki at buric.co Fri Feb 16 14:19:13 2018 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 15 Feb 2018 23:19:13 -0500 (EST) Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180216024857.GH8295@mcvoy.com> References: <20180216021931.7450118C088@mercury.lcs.mit.edu> <20180216024857.GH8295@mcvoy.com> Message-ID: On Thu, 15 Feb 2018, Larry McVoy wrote: >> I think it depend on what you're doing. For some kinds of things, LISP is >> probably better. > > I'd like to be told, as a systems guy, what those things are. > > I know that people have done awesome stuff in lisp. But there is swimming > downstream and there is swimming upstream. > Would MDL be considered a variety or derivative of LISP? Zork was originally written in that. -uso. From tfb at tfeb.org Fri Feb 16 20:01:36 2018 From: tfb at tfeb.org (Tim Bradshaw) Date: Fri, 16 Feb 2018 10:01:36 +0000 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180216020944.AF0ED156E80B@mail.bitblocks.com> References: <20180216020944.AF0ED156E80B@mail.bitblocks.com> Message-ID: <98310912-009A-438C-B7C6-82C8DF25621B@tfeb.org> On 16 Feb 2018, at 02:09, Bakul Shah wrote: > > Scheme's lexical scope and block structure came from Algol. > The rest from Lisp. The joke was that the shortest and longest > language specs were of lisp dialects. The C++ spec may be > longer now. I don't think this is true in any meaningful sense. There are famous plays on words which relate Scheme to Algol (The Scheme specifications are 'revised^n reports on the algorithmic language scheme', and I think lexical scope in Lisps probably originated with the Scheme people, but Scheme was the first standard language, anywhere, which took lexical scope seriously: in particular it was the first standard language with first-class continuations. (I'm saying 'standard language' because I'm sure there were research prototype implementations.). The Common Lisp spec was very long at the time -- I think it was 1100 pages. It was mostly as long as it was because they decided not to split out what other languages would call parts of the standard library. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfb at tfeb.org Fri Feb 16 20:26:57 2018 From: tfb at tfeb.org (Tim Bradshaw) Date: Fri, 16 Feb 2018 10:26:57 +0000 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180216024108.GG8295@mcvoy.com> References: <20180216011815.GD8295@mcvoy.com> <20180216024108.GG8295@mcvoy.com> Message-ID: On 16 Feb 2018, at 02:41, Larry McVoy wrote: > > I don't know all the details but lisp and > performance is not a thing. What this actually means is three things. (1) Once upon a time, a very long time ago, there may have been some implementations of Lisp-family languages which, because people didn't know much about writing compilers or memory management systems in the early 1960s, were significantly slow compared to hand-written assembler or FORTRAN. This problem got solved in the 1970s and 1980s as people learnt about compiling high-level languages and about how to manage memory efficiently. (2) The most distinctive (but never the only) compound data structure in Lisp-family languages is the singly-linked list (which Lisp calls just 'lists'). Incompetent or poorly-taught programmers make use of lists without understanding their performance characteristics (particularly they treat them like arrays), and this can result in programs which have terrible performance characteristics: they're slow and they scale poorly. This is made worse because Lisp is an enormously safer language than, say, C. This means that incompetent programmers can make their programs work *at all* which, in C, would be a mass of memory errors. (3) People use Lisp-family languages to solve hard problems, such as 'attempt to show that this metric in GR describes the same spacetime as this other metric'. Problems which don't *have* general solutions and whose heuristic solutions involve enormous amounts of computation, much of it speculative as the program searches for ways of simplifying expressions. These programs are 'slow' in the sense that it takes them many minutes to do what a human can spend three years getting a PhD doing (oh, and the program finds that the human made some mistakes). The end result of this is that a myth grows up: 'Lisp is slow'. This might have been true once, although even that is doubtful: like cannibals, it turns out that the implementation you can find was never, really, slow, but always, just across the river, over the hills, there was another implementation, which was. But still the myth persists: it will always persist. --tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfb at tfeb.org Fri Feb 16 21:27:50 2018 From: tfb at tfeb.org (Tim Bradshaw) Date: Fri, 16 Feb 2018 11:27:50 +0000 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180216024857.GH8295@mcvoy.com> References: <20180216021931.7450118C088@mercury.lcs.mit.edu> <20180216024857.GH8295@mcvoy.com> Message-ID: On 16 Feb 2018, at 02:48, Larry McVoy wrote: > > I'd like to be told, as a systems guy, what those things are. This is a story I was told in the 1980s about something which happened in the 1960s. But I was told it by the person who did the thing in the 1960s so I believe it to be true subject to the limitations of my fading memory. In General Relativity, one of the things you need to do is, starting from a metric (which is a specification, in terms of some basis -- usually a coordinate basis -- of how distances work in that basis), compute various geometrically and physically interesting properties. Some of these are things like curvature, which tells you whether the spacetime the metric describes is flat, and some of them are related to understanding whether, given two apparently different metrics, do these metrics in fact describe the same spacetime, or parts of the same spacetime. These calculations are laborious: really, seriously laborious. They're also not algorithmic: it's been known for a long time (this is all pretty much a corollary of Gödel incompleteness) that, for two quite simple algebraic expressions, you can't in general know if they are equal. But they matter if you want to make progress in GR, because unless you can solve problems like this you end up with people churning out endless metrics and never knowing whether they describe the same spacetimes. An early concrete example of this is the Schwarzschild metric (which describes nontorating, uncharged things and is a very good approximation for the gravitational field around stars and, famously, black holes). In the obvious expression for this metric, it blows up in a horrible way at a particular radius (the Schwarzschild radius). It took people a very long time to understand that this blowing up was not because something physically horrible happened at that radius, but because the coordinate system in which the metric was expressed went bad at that radius. Eventually people found other metrics which were equivalent to the original one and which did not blow up at the Schwarzschild radius. There's an important metric which I have always known as the 'Bondi metric' but I think is more properly known as the 'Lemaître–Tolman–Bondi metric', which was under investigation in the 1960s, towards the start of the GR renaissance. Various properties of this thing needed to be computed, and this was assigned to a student as a PhD project (this is how laborious the computations are: they take a human several years). I'm not sure who this person was, but they duly got their PhD for it. At the same time another person (Ray d'Inverno) got interested in whether these computations could be done by machine. He wrote a program on the Atlas (a second-generation British machine), and he may have written the Lisp in which it was implemented. This was called ALAM: Atlas Lisp Algebraic Manipulation, and it gave rise to a slightly later thing called LAM (just dropping the 'Atlas': perhaps this was after it was ported somewhere else). And it turns out that yes, these calculations can be done by machine: I was told that (A)LAM replicated the calculation that the PhD student had done over several years, and it took seven minutes (on, I think I was told, the Atlas). Better: *it found mistakes in the original computation*. LAM grew up and became, inevitably, SHEEP, in which form I used it in the 1980s. SHEEP and its derivatives (CLASSI) was widely used for computations in GR (and may still be), often extended by using another algebra system, REDUCE, to do some of the harder simplification -- REDUCE was also written in Lisp of course. One of my early explorations in retrocomputing was to find the source of the original LAM, persuade it to run on a PC running muLisp that I discovered I could use at night, and use it to redo this original calculation. I remember it took much longer than seven minutes: 8088-based PCs were still much slower than the Atlas in the early 1980s. (This had all already been done on the mini we had, the interesting thing was making it work on a PC.) Now of course, someone will make the silly argument that these systems could be written in C. Yes, indeed they could be, and the way you do this is *by writing a Lisp system in C*. Indeed there is a famous aphorism about this, Greenspun's tenth rule of programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." There is a corollary to this due to Morris (of the worm): "Including Common Lisp." There are some very well-known examples of Greenspun's tenth: I don't want to describe the best one here because it would involve being rude about famous people with extremely large egos in a public forum, and I also own a copy of the thing so I'd be being at least a bit hypocritical. However I currently work with a very large Fortran program and I can confirm at first hand that it -- specifically its runtime configuration system -- contains a grotty implementation of half of CL (actually less than half, but the configuration system would be *so much nicer* if it was in Lisp). If only the people who had written this thing had *known* about Lisp rather than known only about Fortran and Python, the world would be a better place. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Fri Feb 16 21:28:48 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 16 Feb 2018 04:28:48 -0700 Subject: [TUHS] Do Interface specifications such POSIX or the LSB Still Matter In-Reply-To: References: Message-ID: <201802161128.w1GBSmsg012148@freefriends.org> There was an article about this in ;login: in 2015 if I recall correctly. Worth trying to find. The issue is a real one. HTH, Arnold Clem Cole wrote: > I've send a couple of you private messages with some more details of why I > ask this, but I'll bring the large question to debate here: > > > ???Have POSIX and??? > LSB lost > ???their > usefulness/relevance? If so, we know ISV???s like Ansys are not going to go > ???FOSS??? and make their sources available (ignore religious beliefs, it just > is not their business model); how to we get that level of precision to > allow > ???the part of the > market > ??? that will be 'binary only' continue to > create applications? > > Seriously, please try to stay away from religion on this > ??? question. Clearly, there are a large number of ISVs have traditionally > used interface specifications. To me it started with things like the old > Cobol and Fortran standards for the languages. That was not good enough > since the systems diverge, and /usr/group then IEEE/ANSI/ISO did Posix. > > > Clearly, Posix enabled Unix implementations such a Linux to shine, although > Linux does not doggedly follow it. Apple was once Posix conformant, but > I'd not think they worry to much about it. Linux created LSB, but I see > fewer and fewer references to it. > > I worry that without a real binary definition, it's darned hard (at least > in the higher end of the business that I live day-to-day) to get ISV's to > care. > > What do you folks think? > > Clem From bakul at bitblocks.com Fri Feb 16 22:10:46 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Fri, 16 Feb 2018 04:10:46 -0800 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: Your message of "Fri, 16 Feb 2018 10:01:36 +0000." <98310912-009A-438C-B7C6-82C8DF25621B@tfeb.org> References: <20180216020944.AF0ED156E80B@mail.bitblocks.com> <98310912-009A-438C-B7C6-82C8DF25621B@tfeb.org> Message-ID: <20180216121102.0DFC2156E80B@mail.bitblocks.com> On Fri, 16 Feb 2018 10:01:36 +0000 Tim Bradshaw wrote: Tim Bradshaw writes: > > On 16 Feb 2018, at 02:09, Bakul Shah wrote: > >=20 > > Scheme's lexical scope and block structure came from Algol. > > The rest from Lisp. The joke was that the shortest and longest > > language specs were of lisp dialects. The C++ spec may be > > longer now. > > I don't think this is true in any meaningful sense. There are famous > plays on words which relate Scheme to Algol (The Scheme specifications > are 'revised^n reports on the algorithmic language scheme', and I think > Scheme was the first standard language, anywhere, which took lexical > scope seriously: in particular it was the first standard language with > first-class continuations. (I'm saying 'standard language' because I'm > sure there were research prototype implementations.). On the second page of Sussman & Steele's "Scheme, an Interpreter for Extended Lambda Calculus", AI Memo 349, it says "The solution, which Hewitt also uses, is to adopt an ALGOLesque block syntax". And it goes on to describe lexical scoping. They even call it BLOCK! Algol is mentioned a number of times. The discovery of correspondence between actor semantics and lambda calculus was a happy coincidence. From wikipedia article on the history of Scheme: 25 years later, in 1998, Sussman and Steele reflected that the minimalism of Scheme was not a conscious design goal, but rather the unintended outcome of the design process. "We were actually trying to build something complicated and discovered, serendipitously, that we had accidentally designed something that met all our goals but was much simpler than we had intended... we realized that the lambda calculus, a small, simple formalism, could serve as the core of a powerful and expressive programming language." Now you may quibble about "came from" but I think the debt is to Algol or at least Algol related papers. Even the connection to lambda calculus is via Algol (Peter Landin's papers on mechanical evaluation expressions (1964) and formal description of Algol60 (1965)). From tfb at tfeb.org Fri Feb 16 22:37:39 2018 From: tfb at tfeb.org (tfb at tfeb.org) Date: Fri, 16 Feb 2018 12:37:39 +0000 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180216121102.0DFC2156E80B@mail.bitblocks.com> References: <20180216020944.AF0ED156E80B@mail.bitblocks.com> <98310912-009A-438C-B7C6-82C8DF25621B@tfeb.org> <20180216121102.0DFC2156E80B@mail.bitblocks.com> Message-ID: <3A4DF9EC-F287-4CD9-85E8-21EE729B37ED@tfeb.org> On 16 Feb 2018, at 12:10, Bakul Shah wrote: > > Now you may quibble about "came from" I do so quibble. In particular I quibble that features *that were not present in Algol*, such as full continuations (which I think exist in the AIM-349 language via CATCH) can have 'come from Algol'. Full continuations are the place where Scheme actually takes lexical scope seriously. But I'm not interested in getting into a fight about this. (I think, in terms of modern Scheme, CATCH is: (define-syntax catch (syntax-rules () ((_ tag form ...) (call/cc (λ (tag) form ...))))) although I might be wrong) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Fri Feb 16 23:34:56 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Fri, 16 Feb 2018 05:34:56 -0800 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: Your message of "Fri, 16 Feb 2018 12:37:39 +0000." <3A4DF9EC-F287-4CD9-85E8-21EE729B37ED@tfeb.org> References: <20180216020944.AF0ED156E80B@mail.bitblocks.com> <98310912-009A-438C-B7C6-82C8DF25621B@tfeb.org> <20180216121102.0DFC2156E80B@mail.bitblocks.com> <3A4DF9EC-F287-4CD9-85E8-21EE729B37ED@tfeb.org> Message-ID: <20180216133512.24B19156E811@mail.bitblocks.com> On Fri, 16 Feb 2018 12:37:39 +0000 tfb at tfeb.org wrote: tfb at tfeb.org writes: > > On 16 Feb 2018, at 12:10, Bakul Shah wrote: > >=20 > > Now you may quibble about "came from"=20 > > I do so quibble. In particular I quibble that features *that were not > present in Algol*, such as full continuations (which I think exist in > the AIM-349 language via CATCH) can have 'come from Algol'. Full > continuations are the place where Scheme actually takes lexical scope > seriously. They did lexical scoping "right", no doubt. But back when Landin first found that lambda calculus was useful for modeling programming languages these concepts were not clearly understood. I do not recall reading anything about whether Algol designers not allowing full lexical scopin was due to an oversight or realizing that efficient implementation of functional argument was not possible. May be Algol's call by name was deemed sufficient? At any rate Algol's not having full lexical scoping does not mean one can simply reject the idea of being influenced by it. Often at the start there is lots of fumbling before people get it right. May be someone should ask Steele? And no, I do not think first class continuations automatically follow from lexical scoping. Go has lexical scoping including closures but no call/cc. The idea of representing future program state as a function I think comes from Strachey, Wadsworth and Reynolds. They used it extensively in denotational semantics to model program behavior. > But I'm not interested in getting into a fight about this. We are just presenting our interpretation of history! Not that anybody cares! From clemc at ccc.com Fri Feb 16 23:36:50 2018 From: clemc at ccc.com (Clem Cole) Date: Fri, 16 Feb 2018 08:36:50 -0500 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <384ec24d-bb53-18a2-b90f-f47d897de67d@telegraphics.com.au> References: <384ec24d-bb53-18a2-b90f-f47d897de67d@telegraphics.com.au> Message-ID: On Thu, Feb 15, 2018 at 10:10 PM, Toby Thain wrote: > On 2018-02-15 8:06 PM, Clem cole wrote: > > The whole reason VM was developed at UCB was because Ernie (the > > original) Vax was funded to develop the ability to port MacLisp and more > > importantly Macsyma from ITS. > > V32’s static address space was not going to work. > > > > > > Btw the program we used to debug the VM system on the original mc500 was > > macsyma’s competition, sms (which would later become wolfram). > > > > You probably meant "SMP", ​yes thank you... typo/dyslexia (I did not notice the error until you pointed it out). > > In both cases the idea was to ensure the memory system was being > exercised. > > Nowadays we'd just run gcc :) > ​indeed ​ - as for wolfram vs SMP sorry not trying to dig into old wounds, just trying to point out how ironic that two early UNIX VM systems used the same style of application (symbolic math) as a way to find corner cases in the VM code. ​ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri Feb 16 23:42:43 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 16 Feb 2018 08:42:43 -0500 (EST) Subject: [TUHS] Happy birthday, Niklaus Wirth! Message-ID: <20180216134243.62D8C18C098@mercury.lcs.mit.edu> > From: Larry McVoy > I don't know all the details but lisp and performance is not a thing. This isn't really about Unix, but I hate to see inaccuracies go into archives... You might want to read: http://multicians.org/lcp.html Of course, when it comes to the speed/efficientcy of the compiled code, much depends on the program/programmer. If one uses CONS wildly, there will have to be garbage collection, which is of course not fast. But properly coded to stay away from expensive constructs, my understanding is that 'lcp' and NCOMPLR produced pretty amazing object code. Noel From bakul at bitblocks.com Sat Feb 17 00:07:34 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Fri, 16 Feb 2018 06:07:34 -0800 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: Your message of "Fri, 16 Feb 2018 05:34:56 -0800." <20180216133512.24B19156E811@mail.bitblocks.com> References: <20180216020944.AF0ED156E80B@mail.bitblocks.com> <98310912-009A-438C-B7C6-82C8DF25621B@tfeb.org> <20180216121102.0DFC2156E80B@mail.bitblocks.com> <3A4DF9EC-F287-4CD9-85E8-21EE729B37ED@tfeb.org> <20180216133512.24B19156E811@mail.bitblocks.com> Message-ID: <20180216140749.71318156E80B@mail.bitblocks.com> On Fri, 16 Feb 2018 05:34:56 -0800 Bakul Shah wrote: Bakul Shah writes: > closures but no call/cc. The idea of representing future > program state as a function I think comes from Strachey, s/state/behavior/ From clemc at ccc.com Sat Feb 17 01:03:11 2018 From: clemc at ccc.com (Clem Cole) Date: Fri, 16 Feb 2018 10:03:11 -0500 Subject: [TUHS] Do Interface specifications such POSIX or the LSB Still Matter In-Reply-To: <201802161128.w1GBSmsg012148@freefriends.org> References: <201802161128.w1GBSmsg012148@freefriends.org> Message-ID: Aharon - is this article you were referring: POSIX Has Become Outdated: Atlidakis, Andrus & Geambasu I have it and have read it. It is a great piece and I think spot on for new(er) applications being written fresh for Mac OSx, Android, *etc.* I'm personally poking at this from the large (clustered) view of a commercial ISV (think in Geo Sciences, Mech E CAD, Fluids, Chem, or Financial) that has valuable code (much still in Fortran BTW). More over their customers have huge amounts of data developed over 30-40 years using those codes, so if you magically tried to replace the codes, you need to revalidate the data too. So how do your define/agree upon/build interfaces that that ISV can trust and an IHV/OEM can use to sell systems, particularly for the commercial part of the market. The very high end (national labs/high energy physics types) write their own code. But the main part of the commercial scientific community does not. POSIX.1 and LSB certainly helped to solve a set of problems. But it seems like the developers of the systems don't care any more. They have a use my 'framework' and my app store mentality. Which sort of is working for mass market where you sell millions of copies. The problem is that those codes were all developed when an older market model and market model has changed as the market great to include a new group of players. The problem is that the market does not care much for that older portion of the total market these days, so their model is squeezed. But as I said, even if magically new codes appeared to replace the old ones, the old data is still an issue. Clem ᐧ On Fri, Feb 16, 2018 at 6:28 AM, wrote: > There was an article about this in ;login: in 2015 if I recall > correctly. Worth trying to find. The issue is a real one. > > HTH, > > Arnold > > Clem Cole wrote: > > > I've send a couple of you private messages with some more details of why > I > > ask this, but I'll bring the large question to debate here: > > > > > > ???Have POSIX and??? > > LSB lost > > ???their > > usefulness/relevance? If so, we know ISV???s like Ansys are not going > to go > > ???FOSS??? and make their sources available (ignore religious beliefs, > it just > > is not their business model); how to we get that level of precision to > > allow > > ???the part of the > > market > > ??? that will be 'binary only' continue to > > create applications? > > > > Seriously, please try to stay away from religion on this > > ??? question. Clearly, there are a large number of ISVs have > traditionally > > used interface specifications. To me it started with things like the old > > Cobol and Fortran standards for the languages. That was not good enough > > since the systems diverge, and /usr/group then IEEE/ANSI/ISO did Posix. > > > > > > Clearly, Posix enabled Unix implementations such a Linux to shine, > although > > Linux does not doggedly follow it. Apple was once Posix conformant, but > > I'd not think they worry to much about it. Linux created LSB, but I see > > fewer and fewer references to it. > > > > I worry that without a real binary definition, it's darned hard (at least > > in the higher end of the business that I live day-to-day) to get ISV's to > > care. > > > > What do you folks think? > > > > Clem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Feb 17 01:12:12 2018 From: clemc at ccc.com (Clem Cole) Date: Fri, 16 Feb 2018 10:12:12 -0500 Subject: [TUHS] Do Interface specifications such POSIX or the LSB Still Matter In-Reply-To: References: Message-ID: On Wed, Feb 14, 2018 at 5:13 PM, George Michaelson wrote: > once you have virtualized OS support embedded in a wrap like docker > why do you need the definition of the sysctl() calls as a spec? > ​Maybe -- HPC folks use UNIX/Linux but really don't want an OS between the HW and their application. And its not just the *.1 style system functions. Think SPEC1170 where we discovered 1170 difference interfaces, database file etc... that ISV had to know about to deal with a 'UNIX' application.​ And that was before we had things like fabric and messaging. Within the >>Linux<< (which 'never forked' like UNIX did) the test matrix is still huge for an ISV these days. > > LSB sort of works. Sort of. > agreed - hence my question. But is sort of RHish and its not clear it being maintained because people don't care. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Feb 17 01:19:37 2018 From: clemc at ccc.com (Clem Cole) Date: Fri, 16 Feb 2018 10:19:37 -0500 Subject: [TUHS] Do Interface specifications such POSIX or the LSB Still Matter In-Reply-To: <781FBCD1-A2D9-4F6A-A0CF-452C243900E8@pobox.com> References: <781FBCD1-A2D9-4F6A-A0CF-452C243900E8@pobox.com> Message-ID: On Wed, Feb 14, 2018 at 5:45 PM, David Arnold wrote: > is there really still a market for commercially-licensed installable > software packages? The set of things that cannot be delivered via the web, > and are not available as Free/Open Source is ever-shrinking. > ​I agree with the later, but for the folks that have traditionally made a market in the former (think commercial HPC - geo science, mech-e cad, financial, chemistry, etc..) - they have codes [often in Fortran] and years and year of data that those codes have been used to create an validate. Ever-shrinking is right, but those folks have very valuable (billions of dollars) invested in that data and their businesses behind them. The code they use is proprietary and closed. As I said in another message, the test matrix for the folks that develop that code got unwieldy. Containers is the only alternative I have seen so far that might solve this, but .... that same folks don't like no stinking OS between their app and the HW, so using virtualization technology to solve a problem is usually a no-no. Thanks again, Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Sat Feb 17 01:45:05 2018 From: cym224 at gmail.com (Nemo) Date: Fri, 16 Feb 2018 10:45:05 -0500 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: <20180216021931.7450118C088@mercury.lcs.mit.edu> <20180216024857.GH8295@mcvoy.com> Message-ID: On 16/02/2018, Tim Bradshaw wrote (in part): > In General Relativity, one of the things you need to do is, starting from a > metric [...], compute various geometrically and physically interesting properties. Susssman is trying to teach DG via lisp. (Vide his "Functional Differential Geometry".) And a really nice post, by the way. N. P.S. Graham wants everyone to use LISP (http://www.paulgraham.com/hp.html ). From lm at mcvoy.com Sat Feb 17 01:45:16 2018 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 16 Feb 2018 07:45:16 -0800 Subject: [TUHS] Do Interface specifications such POSIX or the LSB Still Matter In-Reply-To: References: <781FBCD1-A2D9-4F6A-A0CF-452C243900E8@pobox.com> Message-ID: <20180216154516.GB14249@mcvoy.com> On Fri, Feb 16, 2018 at 10:19:37AM -0500, Clem Cole wrote: > On Wed, Feb 14, 2018 at 5:45 PM, David Arnold wrote: > > is there really still a market for commercially-licensed installable > > software packages? The set of things that cannot be delivered via the web, > > and are not available as Free/Open Source is ever-shrinking. > > ???I agree with the later, but for the folks that have traditionally made a > market in the former (think commercial HPC - geo science, mech-e cad, > financial, chemistry, etc..) - they have codes [often in Fortran] and years > and year of data that those codes have been used to create an validate. > > Ever-shrinking is right, but those folks have very valuable (billions of > dollars) invested in that data and their businesses behind them. The code > they use is proprietary and closed. > > As I said in another message, the test matrix for the folks that develop > that code got unwieldy. Meh, not really. Until Git ate our market, we supported everything you might imagine. Windows, MacOS, Linux-{x86,x86_64,sparc,ppc,itanium,mips}, AIX, IRIX, HP-UX, Solaris. Source base of 2.6 million lines of code and docs. The coding part that was bad was Windows vs Posix, that was painful (no fork on Windows, had to map windows error codes to errnos, link, stat, utime, sockets, all had to be emulated, file names mapped from unix to windows and back again, etc, etc). The rest of it was pretty easy. We limited our stuff to very basic stuff, we shipped our own stdio (based on NetBSD's) because we stacked stuff on top of it /* * Open a stdio handle to file that is gzipped * After the fpush you can fread/gets/fseek/whatever. */ FILE *f = fopen(file, "r"); fpush(&f, fopen_zip(f->fh, "r")); For a long time I was careful about what we used in libc, I'd been burned by realloc() implementations that didn't work. In the last 5 years or so I loosened up about that, the bugs were always in the odd ball Unixes and they had gone away. I think it gets harder the more "fancy" you get. If you are doing commandline/compute stuff it's pretty easy. Want GUI stuff that is cross platform? That's a mess, we went with Tcl/Tk (which will drive the pure lisp people even more crazy, sorry; we "solved" that problem with a byte code compiler that took a C like dialect and spit out tcl byte codes). Probably would do Qt or something else today (didn't want to have C++ in the tool chain 20+ years ago). Want video? Oh, my. Want sound? Oh, my. I don't see any standard trying to fix that cross platform, windows and Linux are too different. Though maybe the Linux on windows stuff solves that? I dunno. > Containers is the only alternative I have seen so far that might solve > this, but .... that same folks don't like no stinking OS between their app > and the HW, so using virtualization technology to solve a problem is > usually a no-no. Netflix does a lot in AWS. And they care about performance. But they code around the variance that you get from containers, I could see that as an issue for the old school fortran people. I'm sort of struggling to see what problem it is you want to solve. From rudi.j.blom at gmail.com Sat Feb 17 01:54:50 2018 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Fri, 16 Feb 2018 22:54:50 +0700 Subject: [TUHS] Clueless programmers Message-ID: Clueless or careless? A customer program worked for many years till one of the transaction messages had a few bytes added. Looking into it I discovered that the program had only worked because the receive buffer was followed by another buffer which was used in a later sequence. Only when also that buffer overflowed some critical integers got overwritten and used as index in tables that gave a lot of fun. Well, as all here know, C is fun :-) From steffen at sdaoden.eu Sat Feb 17 02:08:02 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 16 Feb 2018 17:08:02 +0100 Subject: [TUHS] Do Interface specifications such POSIX or the LSB Still Matter In-Reply-To: References: <201802161128.w1GBSmsg012148@freefriends.org> Message-ID: <20180216160802.rmqUz%steffen@sdaoden.eu> Clem Cole wrote: |Aharon - is this article you were referring:  [1]POSIX Has Become Outdated: \ |Atlidakis, Andrus & Geambasu[/1] | | [1] https://www.usenix.org/system/files/login/articles/login_fall16_02_atl\ | idakis.pdf | |I have it and have read it.   It is a great piece and I think spot \ They seem to have made it. Congratulations! Just five people and six pages of text, graphs and images it took to throw several different generations of programmers and experience over board. That is brilliant. |on for new(er) applications being written fresh for Mac OSx, Android, etc.  Thankfully they describe what they are talking about (apps). I do not use one of those. I believe most of them use Java, an all-in-one environment which only uses some basic system-calls where absolutely necessary. ... |POSIX.1 and LSB certainly helped to solve a set of problems.   But \ |it seems like the developers of the systems don't care any more.  They \ |have a use my |'framework' and my app store mentality.    Which sort of is working \ |for mass market where you sell millions of copies.  ... All the servers, mail, web, database etc., they all build upon ISO C and the much more serious POSIX superset. POSIX clearly has a number of dramatical deficiencies, but much less than ISO C has. Internationalized string processing is a huge problem, internationalized calendars a second: this is a shortcoming inherited from the first generations that created C and UNIX. They definitely had to face completely different problems, but that UTF-8 did not made it into C and POSIX in the 1995 amendment, for example, for this people are to blame. I am not clever enough to realize how strxfrm() can be made to work for complicated languages, but it actually seems to be possible. And select(2) is not capable to bring the performance that modern super-parallel code requires, it is a bottleneck. Several different interfaces which can do better exist on the different platforms (e.g., of kevent on FreeBSD and epoll on Linux my opinion is that kevent is better), but they are not portable and so they are not yet standardized. But a FreeBSD developer brought up the issue, and so maybe the future brings an improvement there. P.S.: that developer has also created a completely new and portable UNIX-style interface for (GUI-less) programs in the cloud, cloudabi the name. Programs are compiled once and run on any system that supports the syscall interface, for example FreeBSD. You do not have a terminal, too, i think, though. --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) -------------- next part -------------- An embedded message was scrubbed... From: unknown sender Subject: no subject Date: no date Size: 149 URL: From clemc at ccc.com Sat Feb 17 01:03:11 2018 From: clemc at ccc.com (Clem Cole) Date: Fri, 16 Feb 2018 10:03:11 -0500 Subject: [TUHS] Do Interface specifications such POSIX or the LSB Still Matter In-Reply-To: <201802161128.w1GBSmsg012148@freefriends.org> References: <201802161128.w1GBSmsg012148@freefriends.org> Message-ID: Aharon - is this article you were referring: POSIX Has Become Outdated: Atlidakis, Andrus & Geambasu I have it and have read it. It is a great piece and I think spot on for new(er) applications being written fresh for Mac OSx, Android, *etc.* I'm personally poking at this from the large (clustered) view of a commercial ISV (think in Geo Sciences, Mech E CAD, Fluids, Chem, or Financial) that has valuable code (much still in Fortran BTW). More over their customers have huge amounts of data developed over 30-40 years using those codes, so if you magically tried to replace the codes, you need to revalidate the data too. So how do your define/agree upon/build interfaces that that ISV can trust and an IHV/OEM can use to sell systems, particularly for the commercial part of the market. The very high end (national labs/high energy physics types) write their own code. But the main part of the commercial scientific community does not. POSIX.1 and LSB certainly helped to solve a set of problems. But it seems like the developers of the systems don't care any more. They have a use my 'framework' and my app store mentality. Which sort of is working for mass market where you sell millions of copies. The problem is that those codes were all developed when an older market model and market model has changed as the market great to include a new group of players. The problem is that the market does not care much for that older portion of the total market these days, so their model is squeezed. But as I said, even if magically new codes appeared to replace the old ones, the old data is still an issue. Clem ᐧ On Fri, Feb 16, 2018 at 6:28 AM, wrote: > There was an article about this in ;login: in 2015 if I recall > correctly. Worth trying to find. The issue is a real one. > > HTH, > > Arnold > > Clem Cole wrote: > > > I've send a couple of you private messages with some more details of why > I > > ask this, but I'll bring the large question to debate here: > > > > > > ???Have POSIX and??? > > LSB lost > > ???their > > usefulness/relevance? If so, we know ISV???s like Ansys are not going > to go > > ???FOSS??? and make their sources available (ignore religious beliefs, > it just > > is not their business model); how to we get that level of precision to > > allow > > ???the part of the > > market > > ??? that will be 'binary only' continue to > > create applications? > > > > Seriously, please try to stay away from religion on this > > ??? question. Clearly, there are a large number of ISVs have > traditionally > > used interface specifications. To me it started with things like the old > > Cobol and Fortran standards for the languages. That was not good enough > > since the systems diverge, and /usr/group then IEEE/ANSI/ISO did Posix. > > > > > > Clearly, Posix enabled Unix implementations such a Linux to shine, > although > > Linux does not doggedly follow it. Apple was once Posix conformant, but > > I'd not think they worry to much about it. Linux created LSB, but I see > > fewer and fewer references to it. > > > > I worry that without a real binary definition, it's darned hard (at least > > in the higher end of the business that I live day-to-day) to get ISV's to > > care. > > > > What do you folks think? > > > > Clem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Feb 17 02:32:00 2018 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 16 Feb 2018 08:32:00 -0800 Subject: [TUHS] Clueless programmers In-Reply-To: References: Message-ID: <20180216163200.GC14249@mcvoy.com> We had the same problem that was uncovered by a naive programmer "removing unneeded whitespaces". Moved some stuff around and exposed a buffer overrun. On Fri, Feb 16, 2018 at 10:54:50PM +0700, Rudi Blom wrote: > Clueless or careless? > > A customer program worked for many years till one of the transaction > messages had a few bytes added. > > Looking into it I discovered that the program had only worked because > the receive buffer was followed by another buffer which was used in a > later sequence. Only when also that buffer overflowed some critical > integers got overwritten and used as index in tables that gave a lot > of fun. > > Well, as all here know, C is fun :-) -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From paul at mcjones.org Sat Feb 17 03:40:01 2018 From: paul at mcjones.org (Paul McJones) Date: Fri, 16 Feb 2018 09:40:01 -0800 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: Message-ID: <70F8C9FE-1390-4868-831C-25E6D4B37C7C@mcjones.org> Actually, Algol 60 did allow functions and procedures as arguments (with correct static scoping), but not as results, so they weren’t “first class” in the Scheme sense. The Algol 60 report (along with its predecessor and successor) is available, among other places, here: http://www.softwarepreservation.org/projects/ALGOL/standards/ On Feb 16, 2018, Bakul Shah wrote: > They did lexical scoping "right", no doubt. But back when > Landin first found that lambda calculus was useful for > modeling programming languages these concepts were not clearly > understood. I do not recall reading anything about whether > Algol designers not allowing full lexical scopin was due to an > oversight or realizing that efficient implementation of > functional argument was not possible. May be Algol's call by > name was deemed sufficient? At any rate Algol's not having > full lexical scoping does not mean one can simply reject the > idea of being influenced by it. Often at the start there is > lots of fumbling before people get it right. May be someone > should ask Steele? -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Feb 17 04:36:14 2018 From: clemc at ccc.com (Clem Cole) Date: Fri, 16 Feb 2018 13:36:14 -0500 Subject: [TUHS] Do Interface specifications such POSIX or the LSB Still Matter In-Reply-To: <20180216154516.GB14249@mcvoy.com> References: <781FBCD1-A2D9-4F6A-A0CF-452C243900E8@pobox.com> <20180216154516.GB14249@mcvoy.com> Message-ID: On Fri, Feb 16, 2018 at 10:45 AM, Larry McVoy wrote: > > > Meh, not really. Until Git ate our market, we supported everything you > might imagine. Windows, MacOS, Linux-{x86,x86_64,sparc,ppc,itanium,mips}, > AIX, IRIX, HP-UX, Solaris. > > Source base of 2.6 million lines of code and docs. > ​Did you have messaging (Co-Arrays, MPI or SHMEM) mixed in? I'm guess not., but your system is (was) extensive so I'm asking.... Commercial HPC code from folks like Western Geco, Ansys, Pam and the like do... Within a manufacturer these can differ. Want to run both Pam Crash and Fluent -- be careful, their MPI's libraries were (may still be) mutually exclusive. > > ​....​ > We limited our stuff to very basic > ​ ​ > stuff > ​Yup -- very wise. Simple library to insulate you from OS. Did you shipped statically bound or use *.so's Also how much are you dependant on OS databases (password & credential libraries and other things stored in /etc, /usr/lib or /var)​? ​This is were even within Linux, life can get messy pretty fast.​ > > I think it gets harder the more "fancy" you get. If you are doing > commandline/compute stuff it's pretty easy. > ​Agreed... but multi-thousand costing/leasing @ dollar/euro codes because they save you millions at the design, or before you drill time, tend to have a high bar. ​ > > Want video? Oh, my. > ​exactly...​ > > Want sound? Oh, my. > > I don't see any standard trying to fix that cross platform, windows and > Linux are too different. Though maybe the Linux on windows stuff solves > that? I dunno. > In the old days, I was just trying to be consistent within UNIX flavors so we created POSIX. These days, ​I'm just trying to be consistent within Linux ... so I've tried to use LSB to define something for an ISV that they can rely. > > Netflix does a lot in AWS. And they care about performance. But they > code around the variance that you get from containers, I could see that > as an issue for the old school fortran people. > ​Good .. you get it.​ > > I'm sort of struggling to see what problem it is you want to solve. > ​Without revealing the ISV, I know very well know HPC ISV that used to have a >>Linux<< only test matrix of over 140 perminations before they could release and they only supported RH and SuSE. But between different manufacturers, distributed file systems, interconnect, messaging stacks, compilers *et al​* *​ *it got messy very fast.​ We helped to that down to a much smaller number today and I think they now may even include Ubuntu, but maybe not; because most of the commercial folks are traditionally RH or SuSE (HPC moving to a more cloud oriented deployment have cause the push for Ubuntu support by the ISVs). But most commercial folks doing traditional scientific work loads run their own clusters (and are not cloud based )-- for a number of reasons. As I said, they like the HW by themselves, they tend to use fabrics for the interconnect *etc*... Thanks again, Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Sat Feb 17 04:48:51 2018 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 16 Feb 2018 13:48:51 -0500 (EST) Subject: [TUHS] Do Interface specifications such POSIX or the LSB Still Matter In-Reply-To: <20180216154516.GB14249@mcvoy.com> References: <781FBCD1-A2D9-4F6A-A0CF-452C243900E8@pobox.com> <20180216154516.GB14249@mcvoy.com> Message-ID: On Fri, 16 Feb 2018, Larry McVoy wrote: > Want video? Oh, my. > > Want sound? Oh, my. > > I don't see any standard trying to fix that cross platform, windows and > Linux are too different. Though maybe the Linux on windows stuff solves > that? I dunno. Doesn't SDL take care of that reasonably well? Most modern apps also seem to dispense with the OS-native audio and video codecs and use some form of the FFMPEG code to handle that. -uso. From bakul at bitblocks.com Sat Feb 17 05:24:15 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Fri, 16 Feb 2018 11:24:15 -0800 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <70F8C9FE-1390-4868-831C-25E6D4B37C7C@mcjones.org> References: <70F8C9FE-1390-4868-831C-25E6D4B37C7C@mcjones.org> Message-ID: <866B8E9B-679F-4AC2-B5D7-9151C97B0FFB@bitblocks.com> Thanks for the correction. A stack is sufficient for invoking functional arguments but not for invoking functional results. And once you allow functional results you may have to use a heap to hold their lexical environment and GC is pretty much a requirement. Algol60 avoided GC by disallowing functional results. C avoided GC by disallowing nesting. > On Feb 16, 2018, at 9:40 AM, Paul McJones wrote: > > Actually, Algol 60 did allow functions and procedures as arguments (with correct static scoping), but not as results, so they weren’t “first class” in the Scheme sense. The Algol 60 report (along with its predecessor and successor) is available, among other places, here: > > http://www.softwarepreservation.org/projects/ALGOL/standards/ > >> On Feb 16, 2018, Bakul Shah wrote: >> >> They did lexical scoping "right", no doubt. But back when >> Landin first found that lambda calculus was useful for >> modeling programming languages these concepts were not clearly >> understood. I do not recall reading anything about whether >> Algol designers not allowing full lexical scopin was due to an >> oversight or realizing that efficient implementation of >> functional argument was not possible. May be Algol's call by >> name was deemed sufficient? At any rate Algol's not having >> full lexical scoping does not mean one can simply reject the >> idea of being influenced by it. Often at the start there is >> lots of fumbling before people get it right. May be someone >> should ask Steele? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfb at tfeb.org Sat Feb 17 06:13:24 2018 From: tfb at tfeb.org (tfb at tfeb.org) Date: Fri, 16 Feb 2018 20:13:24 +0000 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180216133512.24B19156E811@mail.bitblocks.com> References: <20180216020944.AF0ED156E80B@mail.bitblocks.com> <98310912-009A-438C-B7C6-82C8DF25621B@tfeb.org> <20180216121102.0DFC2156E80B@mail.bitblocks.com> <3A4DF9EC-F287-4CD9-85E8-21EE729B37ED@tfeb.org> <20180216133512.24B19156E811@mail.bitblocks.com> Message-ID: <056F188D-E6E5-4B8F-9BD1-30FAA6E4EDDD@tfeb.org> On 16 Feb 2018, at 13:34, Bakul Shah wrote: > > At any rate Algol's not having > full lexical scoping does not mean one can simply reject the > idea of being influenced by it. Often at the start there is > lots of fumbling before people get it right. May be someone > should ask Steele? Yes, I certainly did not mean to imply that Scheme was not influenced by Algol: sorry if my message read that way. What I was arguing against was that Scheme just somehow imported some concepts from Algol into Lisp: it *did* do that, but it also invented (or, at least, implemented in a practical, standardised language) a bunch of new concepts which were *not* present in Algol. You are right of course that someone should ask Steele &co. > And no, I do not think first class continuations automatically > follow from lexical scoping. I think they don't either, but I think that's because we've been talking about two things under one name: scope and extent. What Scheme did was to say that it was going to be a language with lexical scope and indefinite extent, and it was going to take that seriously. Most languages, even ones which purport to be lexically scoped, are usually both not entirely lexically scoped, and only take the indefinite extent thing seriously in sufficiently easy cases if they are. An example of that is Common Lisp (I'm picking CL because CL is my favourite programming language which I've used for a very long time, so I think I'm allowed to be rude about it without causing offence). CL has lexical scope and indefinite extent for variable and function bindings, so it has closures, for instance. But it has dynamic scope and definite extent for condition handlers, for instance, as well as catch tags. And finally it has lexical scope but definite extent for block names and go tags. Scheme has lexical scope and indefinite extent for everything, and takes the attitude that if that makes it hard to implement then fine. And I think that *that* was the new thing that Scheme did. Whether the people designing Scheme knew that at the beginning (and whether their attitude was that rigorous from the beginning) I don't know. (Of course, Scheme also made other Lisp people realise that lexical scope and mostly-indefinite-extent was a better approach than the older dynamic-scope-except-that-compiled-code-is-mostly-lexical horridness. And I think all the Scheme implementations I've used have some mechanism of adding dynamic scope / definite extent for various things, because that's the obviously right scope for, say, condition handlers.) I think this may be off-topic for this list, although I'm enjoying talking about it. --tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Feb 17 07:01:14 2018 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 16 Feb 2018 13:01:14 -0800 Subject: [TUHS] lisp challenge Message-ID: <20180216210114.GA27574@mcvoy.com> So people have called me on the claim that lisp is not fast. Here's a rebuttal. Please write a clone of GNU grep in lisp to demonstrate that the claim that lisp is slower that C is false. Best of luck and I'll be super impressed if you can get even remotely close without dropping into C or assembler. If you do get close, I will with draw my claim, stand corrected, point future "lisp is slow" people at the lisp-grep, and buy you dinner and/or drinks. --lm From tfb at tfeb.org Sat Feb 17 07:02:46 2018 From: tfb at tfeb.org (Tim Bradshaw) Date: Fri, 16 Feb 2018 21:02:46 +0000 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <20180216134243.62D8C18C098@mercury.lcs.mit.edu> References: <20180216134243.62D8C18C098@mercury.lcs.mit.edu> Message-ID: On 16 Feb 2018, at 13:42, Noel Chiappa wrote: > > This isn't really about Unix, but I hate to see inaccuracies go into > archives... I think it's also important to say that claims like 'lisp is slow' are essentially meaningless. It is reasonable to say that 'this program is slow', where 'this program' refers to some definite bit of code, implicitly qualified by the machine it is running on, when the statement was made &c &c. That's clearly a thing you can go out and test. It's often safe to say that particular implementations of programming languages are slow, which means that many or most programs run using the specified implementation of the programming language are slower than they might be either using some other implementation of the same language, or written in some other programming language and run using an implementation of that. In particular I can say 'CPython is slow' for instance: this statement might be wrong, but it does at least have some content. For programming languages which only *have* one implementation or have a single dominant implementation, you can get lazy and say, for instance 'Python is slow'. What this really means is 'CPython is slow' (ie it's the same as the previous statement). It's also dangerous because it tacitly assumes that there is only one implementation of Python, which is not true (or at least has not been true in the past). But you can usually get away with this. For programming languages which have many implementations, and still more for *families* of related programming languages, each member of which may have many implementations, the statement loses all meaning. What does the statement 'Lisp is slow' *mean*? The only meaning it could really have is something like 'all implementations of Lisp that there have been are slow and all implementations *there ever will be* will also be slow'. The only way this could possibly make sense is if the person making the statement understood that some feature or features of any Lisp-family language was so hard to implement that it was really clear that no fast implementation could ever exist. I claim (without evidence) that Lisp-family languages, considered as a whole, do not contain such toxic features. So the statement simply does not have any meaning. I think that people making such statements, assuming they are not making them merely as insults (which very often, historically, they are, although I assume not here), make them because they are confused. What they really mean, at best, is that certain implementations of Lisp-family languages of which they have (often apocryphal) experience have been rather slow. In fact what they usually mean is even weaker than that: some particular programs (which someone told them about) run in some particular implementations were slow. But somehow this becomes generalised to 'Lisp is slow': I think it would be interesting to understand how this generalisation happens, although its probably even more off-topic here than messages about Lisp are. To bring it slightly back on-topic, I think these statements are very like statements along the lines of 'Unix is insecure', which I think we could all agree is meaningless: a particular implementation of Unix might be insecure, but I think the claim that Unix is *inherently* insecure simply has no content. Finally I'll just add this quote about Stalin, a Scheme compiler by Siskind: "Stalin is the highest performing Scheme compiler and one of the highest performing compilers for any language". -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Feb 17 07:03:13 2018 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 16 Feb 2018 13:03:13 -0800 Subject: [TUHS] lisp challenge In-Reply-To: <20180216210114.GA27574@mcvoy.com> References: <20180216210114.GA27574@mcvoy.com> Message-ID: <20180216210313.GB27574@mcvoy.com> On Fri, Feb 16, 2018 at 01:01:14PM -0800, Larry McVoy wrote: > So people have called me on the claim that lisp is not fast. Here's a > rebuttal. > > Please write a clone of GNU grep in lisp to demonstrate that the claim > that lisp is slower that C is false. > > Best of luck and I'll be super impressed if you can get even remotely > close without dropping into C or assembler. If you do get close, I > will with draw my claim, stand corrected, point future "lisp is slow" > people at the lisp-grep, and buy you dinner and/or drinks. > > --lm And to help you, here is Mike explaining how he made GNU grep fast. You are welcome to use the same techniques in lisp. https://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html# From bakul at bitblocks.com Sat Feb 17 08:05:09 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Fri, 16 Feb 2018 14:05:09 -0800 Subject: [TUHS] lisp challenge In-Reply-To: Your message of "Fri, 16 Feb 2018 13:01:14 -0800." <20180216210114.GA27574@mcvoy.com> References: <20180216210114.GA27574@mcvoy.com> Message-ID: <20180216220524.3B9A4156E80B@mail.bitblocks.com> On Fri, 16 Feb 2018 13:01:14 -0800 Larry McVoy wrote: Larry McVoy writes: > So people have called me on the claim that lisp is not fast. Here's a > rebuttal. > > Please write a clone of GNU grep in lisp to demonstrate that the claim > that lisp is slower that C is false. > > Best of luck and I'll be super impressed if you can get even remotely > close without dropping into C or assembler. If you do get close, I > will with draw my claim, stand corrected, point future "lisp is slow" > people at the lisp-grep, and buy you dinner and/or drinks. If you want to do more of an apples to apples comparison, you should pick a brand new problem not known to be solved in either C or Lisp so that both sides start at the same point! I do think that if you consider just the raw performance as the sole metric, C will almost always win. After all it is sort of a portable assembly language & you can compile programs in most language to C. But in the real world many other factors matter too. So to make the contest a bit more fair, you should put a time limit on the effort. From lm at mcvoy.com Sat Feb 17 08:28:35 2018 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 16 Feb 2018 14:28:35 -0800 Subject: [TUHS] lisp challenge In-Reply-To: <20180216220524.3B9A4156E80B@mail.bitblocks.com> References: <20180216210114.GA27574@mcvoy.com> <20180216220524.3B9A4156E80B@mail.bitblocks.com> Message-ID: <20180216222835.GC27574@mcvoy.com> On Fri, Feb 16, 2018 at 02:05:09PM -0800, Bakul Shah wrote: > On Fri, 16 Feb 2018 13:01:14 -0800 Larry McVoy wrote: > Larry McVoy writes: > > So people have called me on the claim that lisp is not fast. Here's a > > rebuttal. > > > > Please write a clone of GNU grep in lisp to demonstrate that the claim > > that lisp is slower that C is false. > > > > Best of luck and I'll be super impressed if you can get even remotely > > close without dropping into C or assembler. If you do get close, I > > will with draw my claim, stand corrected, point future "lisp is slow" > > people at the lisp-grep, and buy you dinner and/or drinks. > > If you want to do more of an apples to apples comparison, you > should pick a brand new problem not known to be solved in > either C or Lisp so that both sides start at the same point! Nope. It's my challenge and it stands as I stated it. People said I was wrong when I said Lisp was perceived as slow. I picked a perfectly reasonable example of a common problem (text processing), gave a benchmark, gave a pointer to how the C program was made fast, and asked for a lisp program that even comes close. If that can't be done, then the claim that lisp is slow still stands. When people said I was "putting inaccuracies into the archives" or "perpetuating a myth" I wondered if I was wrong. Nobody said "well, yes, C is faster for systems stuff or this or that, but lisp is faster in this domain". They said that the claim that lisp is slow is not true. Just saying that lisp is not slow is not the same as demonstrating it. I'm more than willing to be wrong, that's how I learn. But the proof here is to show up with a pure lisp grep that is fast as the C version. I'm no lisp expert, not by any stretch, but I've never seen a lisp program that out performed a well written C program. The point was that lisp was/is perceived as a slow language. Several people said that's false, I'm just asking for them to demonstrate that it is false by writing grep in lisp. Who knows? Maybe it can be done. From doug at cs.dartmouth.edu Sat Feb 17 08:44:08 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Fri, 16 Feb 2018 17:44:08 -0500 Subject: [TUHS] [Re: Happy Birthday, Nicklaus Wirth Message-ID: <201802162244.w1GMi8Ns013597@coolidge.cs.Dartmouth.EDU> > Computer pioneer Niklaus Wirth was born on this day in 1934; he basically > designed ALGOL, one of the most influential languages ever, with just > about every programming language in use today tracing its roots to it. Rather than "tracing its roots to it", I'd say "has some roots in it". Algol per se hardly made a ripple in the US market, partly due to politics and habit, but also because it didn't espouse separate compilation. However, as asserted above, it had a profound impact on language designers and counts many languages as descendants. To bring the subject back to Unix, C followed Fortran's modularity and Algol's block structure. (But it reached back across the definitive Algol 60 to pick up the "for" statement from Algol 58.) Like PL/I, it also borrowed the indispensable notion of structs from business languages (Flowmatic, Comtran, Cobol). It adopted pointers from Lisp, as polished by BCPL (pointer arithmetic) and PL/I (the -> operator). For better or worse, it went its own way by omitting multidimensional arrays. So C has many roots. It just isn't fashionable in computer-language circles to highlight Cobol in your family tree. Doug From mutiny.mutiny at india.com Sat Feb 17 08:53:49 2018 From: mutiny.mutiny at india.com (Donald ODona) Date: Fri, 16 Feb 2018 22:53:49 +0000 (UTC) Subject: [TUHS] lisp challenge In-Reply-To: <20180216222835.GC27574@mcvoy.com> References: <20180216210114.GA27574@mcvoy.com> <20180216220524.3B9A4156E80B@mail.bitblocks.com>, <20180216222835.GC27574@mcvoy.com> Message-ID: <903259418.38276.1518821629141.JavaMail.tomcat@india-live-be02> I definitely agree with your words. Furthermore I point to the fact that lisp is totally different to any other language, the archaic algol, cobol and fortran languages included. Therefore one makes automatically mistakes after longer periods of intensive lisp coding and vice versa, despite the fact that the lisp approach basically is very simple, not to say oversimplified. Anyhow there aren't many lispers anymore. In business lisp plays no role at all. Its a pet of so backward oriented academicians. At 16 Feb 2018 22:29:33 +0000 (+00:00) from Larry McVoy : > Nope. It's my challenge and it stands as I stated it. People said > I was wrong when I said Lisp was perceived as slow. I picked a > perfectly reasonable example of a common problem (text processing), > gave a benchmark, gave a pointer to how the C program was made fast, > and asked for a lisp program that even comes close. > >... From krewat at kilonet.net Sat Feb 17 08:56:59 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Fri, 16 Feb 2018 17:56:59 -0500 Subject: [TUHS] lisp challenge In-Reply-To: <20180216222835.GC27574@mcvoy.com> References: <20180216210114.GA27574@mcvoy.com> <20180216220524.3B9A4156E80B@mail.bitblocks.com> <20180216222835.GC27574@mcvoy.com> Message-ID: <8a4ac448-9ed2-016a-6440-33597e36915d@kilonet.net> Has ANY language (except assembler) EVER outperformed C in a big way? Give or take any optimizations that may be done by either? On 2/16/2018 5:28 PM, Larry McVoy wrote: > I'm no lisp expert, not by any stretch, but I've never seen a lisp > program that out performed a well written C program. From krewat at kilonet.net Sat Feb 17 09:01:23 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Fri, 16 Feb 2018 18:01:23 -0500 Subject: [TUHS] lisp challenge In-Reply-To: <903259418.38276.1518821629141.JavaMail.tomcat@india-live-be02> References: <20180216210114.GA27574@mcvoy.com> <20180216220524.3B9A4156E80B@mail.bitblocks.com> <20180216222835.GC27574@mcvoy.com> <903259418.38276.1518821629141.JavaMail.tomcat@india-live-be02> Message-ID: <5a43a59d-dea5-e4e7-9c29-af20e483f154@kilonet.net> On 2/16/2018 5:53 PM, Donald ODona wrote: > Anyhow there > aren't many lispers anymore. In business lisp plays no role at all. I know of a first-person shooter game that has embedded scripts in the maps. The scripting language in the maps is ... LISP. ;) - Not sure if it's JIT, but it's definitely interpreted and not compiled. It's been around since the early 2000's, has versions on XBOX and PC and newer versions are being released to this day. Knowing the company creating these new versions and maps, I doubt they moved away from LISP. Good ole Halo. From lm at mcvoy.com Sat Feb 17 09:02:33 2018 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 16 Feb 2018 15:02:33 -0800 Subject: [TUHS] lisp challenge In-Reply-To: <8a4ac448-9ed2-016a-6440-33597e36915d@kilonet.net> References: <20180216210114.GA27574@mcvoy.com> <20180216220524.3B9A4156E80B@mail.bitblocks.com> <20180216222835.GC27574@mcvoy.com> <8a4ac448-9ed2-016a-6440-33597e36915d@kilonet.net> Message-ID: <20180216230233.GD27574@mcvoy.com> I suspect that back in the day Fortran may have beat C for scientific computations (vector stuff would be my guess). But x86 extensions do vectors as do the GPUs so I don't know of anything that beats C in a big way. On Fri, Feb 16, 2018 at 05:56:59PM -0500, Arthur Krewat wrote: > Has ANY language (except assembler) EVER outperformed C in a big way? > > Give or take any optimizations that may be done by either? > > On 2/16/2018 5:28 PM, Larry McVoy wrote: > >I'm no lisp expert, not by any stretch, but I've never seen a lisp > >program that out performed a well written C program. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From toby at telegraphics.com.au Sat Feb 17 09:18:28 2018 From: toby at telegraphics.com.au (Toby Thain) Date: Fri, 16 Feb 2018 18:18:28 -0500 Subject: [TUHS] lisp challenge In-Reply-To: <8a4ac448-9ed2-016a-6440-33597e36915d@kilonet.net> References: <20180216210114.GA27574@mcvoy.com> <20180216220524.3B9A4156E80B@mail.bitblocks.com> <20180216222835.GC27574@mcvoy.com> <8a4ac448-9ed2-016a-6440-33597e36915d@kilonet.net> Message-ID: <1982c016-3eb6-cadd-75e7-80d2a081ac07@telegraphics.com.au> On 2018-02-16 5:56 PM, Arthur Krewat wrote: > Has ANY language (except assembler) EVER outperformed C in a big way? > > Give or take any optimizations that may be done by either? > As Tim wisely pointed out, performance isn't a property of a language, but a program, so the idea that C is some kind of untouchable ultimate in speed makes no sense. There are aspects of its design that militate _against_ performance and preclude optimisations that are possible in other languages. Therefore nobody should be shocked that programs in other languages certainly _have_ beaten C for the same tasks. An illuminating example is the Haskell Mio system which has benchmarked to outperform C web servers. Expect more progress from that direction. --Toby From akosela at andykosela.com Sat Feb 17 09:34:13 2018 From: akosela at andykosela.com (Andy Kosela) Date: Fri, 16 Feb 2018 17:34:13 -0600 Subject: [TUHS] lisp challenge In-Reply-To: <20180216210114.GA27574@mcvoy.com> References: <20180216210114.GA27574@mcvoy.com> Message-ID: On Friday, February 16, 2018, Larry McVoy wrote: > So people have called me on the claim that lisp is not fast. Here's a > rebuttal. > > Please write a clone of GNU grep in lisp to demonstrate that the claim > that lisp is slower that C is false. > > Best of luck and I'll be super impressed if you can get even remotely > close without dropping into C or assembler. If you do get close, I > will with draw my claim, stand corrected, point future "lisp is slow" > people at the lisp-grep, and buy you dinner and/or drinks. > > --lm > Good challenge. I consider anything that came out of MIT's ITS/Lisp (including Emacs) culture as totally opposite to the UNIX/C culture. Complexity vs. minimalism are the best words to explain both approaches to computing. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Feb 17 09:41:47 2018 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 16 Feb 2018 15:41:47 -0800 Subject: [TUHS] lisp challenge In-Reply-To: <1982c016-3eb6-cadd-75e7-80d2a081ac07@telegraphics.com.au> References: <20180216210114.GA27574@mcvoy.com> <20180216220524.3B9A4156E80B@mail.bitblocks.com> <20180216222835.GC27574@mcvoy.com> <8a4ac448-9ed2-016a-6440-33597e36915d@kilonet.net> <1982c016-3eb6-cadd-75e7-80d2a081ac07@telegraphics.com.au> Message-ID: <20180216234147.GF27574@mcvoy.com> On Fri, Feb 16, 2018 at 06:18:28PM -0500, Toby Thain wrote: > On 2018-02-16 5:56 PM, Arthur Krewat wrote: > > Has ANY language (except assembler) EVER outperformed C in a big way? > > > > Give or take any optimizations that may be done by either? > > As Tim wisely pointed out, performance isn't a property of a language, > but a program, so the idea that C is some kind of untouchable ultimate > in speed makes no sense. Nobody claimed that. I claimed, based on what I've been told by people who programmed in lisp and some small personal experience, that lisp was and is perceived as a slow language, certainly slower than C. Lisp fans hate that claim because they want everyone to program in Lisp, or at least let them program in lisp. I tipped my hat to the belief, I've never experience it myself but I've heard it claimed, that a skilled lisp coder solves problems, especially compiler like problems, in lisp faster than a skilled C programmer would. I think that reality is that lispers like lisp because they can claim they are "done" faster than they would if they had to do the same thing in C (or other procedural) languages. That is a HORRIBLE reason to like a language. In my not at all humble opinion. If lisp were a language that was easy to read, for all programmers not just people who love lisp, OK, maybe. But it is not, it's a miserable language to scan and understand. Contrast it with C or go or any of other procedural languages. Any programmer can read C and quickly understand what it is doing. The same is not true of lisp. I strongly suspect that lisp people optimize for speed of writing whereas most experienced people optimize for the speed of reading. It's write one, read many. > Therefore nobody should be shocked that programs in other languages > certainly _have_ beaten C for the same tasks. But not lisp. Or at least, nobody wants to take up my grep challenge. --lm P.S. For the record, I tried to like lisp. I wrote lisp programs, I tried. Just like I tried to like emacs. I'm apparently not smart enough to join the hallowed grounds where the lispers live. C/vi for stupid me. From jnc at mercury.lcs.mit.edu Sat Feb 17 09:44:32 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 16 Feb 2018 18:44:32 -0500 (EST) Subject: [TUHS] lisp challenge Message-ID: <20180216234432.75A2318C08F@mercury.lcs.mit.edu> > From: Larry McVoy > the proof here is to show up with a pure lisp grep that is fast as the C > version. ... I've never seen a lisp program that out performed a well > written C program. Your exact phrase (which my response was in reply to) was "lisp and performance is not a thing". You didn't say 'LISP is not just as fast as C' - a different thing entirely. I disagreed with your original statement, which seems to mean 'LISP doesn't perform well'. Quite a few people spent quite a lot of time making LISP compiler output fast, to the point that it was possible to say "this compiler is also intended to compete with the S-1 Pascal and FORTRAN compilers for quality of compiled numeric code" [Brooks,Gabriel and Steele, 1982] and "with the development of the S-1 Lisp compiler, it once again became feasible to implement Lisp in Lisp and to expect similar performance to the best hand-tuned, assembly-language-based Lisp systems" [Steele and Gabriel, 1993]. Noel From bakul at bitblocks.com Sat Feb 17 09:49:35 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Fri, 16 Feb 2018 15:49:35 -0800 Subject: [TUHS] lisp challenge In-Reply-To: Your message of "Fri, 16 Feb 2018 14:28:35 -0800." <20180216222835.GC27574@mcvoy.com> References: <20180216210114.GA27574@mcvoy.com> <20180216220524.3B9A4156E80B@mail.bitblocks.com> <20180216222835.GC27574@mcvoy.com> Message-ID: <20180216234950.67D80156E9AD@mail.bitblocks.com> On Fri, 16 Feb 2018 14:28:35 -0800 Larry McVoy wrote: > On Fri, Feb 16, 2018 at 02:05:09PM -0800, Bakul Shah wrote: > > > > If you want to do more of an apples to apples comparison, you > > should pick a brand new problem not known to be solved in > > either C or Lisp so that both sides start at the same point! > > Nope. It's my challenge and it stands as I stated it. People said > I was wrong when I said Lisp was perceived as slow. I picked a > perfectly reasonable example of a common problem (text processing), > gave a benchmark, gave a pointer to how the C program was made fast, > and asked for a lisp program that even comes close. By issuing this challenge you automatically "win" as no one is going to take up your challenge and spend the kind of time that was needed to optimize GNU grep. Very clever of you! But if you are serious, it is only fair that both sides start with a clean slate. Here's a somewhat related problem: Consider trees with zero or more integers as leaves. For example, ((1 2)3(4 (5 () 6))). A file contains 0 or more such trees. Write a tree-grep to find and print trees with matching fringes. For example: .*3.*5.* matches the above tree .*(3).* doesn't as there is no subtree with 3 as its sole leaf .*(.*2)[2,3].* also matches .*(.*2.+).* doesn't as 2 is the last leaf and we want at least one more .*(4#(.*().*).*).* matches -- (4...) contains (.*().*) 0 or more levels down. . is any, * is 0 or more, + is 1 or more, # is like ** in zsh. [...] is used to specify alternatives. e.g {0-5,11-23, 99-}. Assume unsigned ints. #(5.*) says there is some subtree with 5 as the first leaf. Syntax needs to be refined to be able to exactly specify the shape one wants. For extra credit also generate a tree-sed! > I'm more than willing to be wrong, that's how I learn. But the proof > here is to show up with a pure lisp grep that is fast as the C version. > I'm no lisp expert, not by any stretch, but I've never seen a lisp > program that out performed a well written C program. http://www.ffconsultancy.com/ocaml/ray_tracer/languages.html Has a comparison of several languages used for implementing raytracing. Harrop's graph is weird but for 32bit word machines Stalin comes close to g++ results. From wkt at tuhs.org Sat Feb 17 09:50:31 2018 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 17 Feb 2018 09:50:31 +1000 Subject: [TUHS] And it's time to close the C vs. Lisp thread Message-ID: <20180216235031.GA31469@minnie.tuhs.org> as it's strayed too far from the charter of the TUHS mailing list. There must be a more suitable forum to discuss language issues! Thanks, Warren From pnr at planet.nl Sat Feb 17 11:32:20 2018 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 17 Feb 2018 02:32:20 +0100 Subject: [TUHS] Happy Birthday, Nicklaus Wirth Message-ID: From: Doug McIlroy > Like PL/I, it also > borrowed the indispensable notion of structs from business languages > (Flowmatic, Comtran, Cobol). That is an interesting insight. I always thought that structs were inspired by the assembler DORG construct, and hence the shared namespace for members. The above insight goes some way to explain why PDP11 “as” did not have a DORG construct, but early C did have ‘struct'. Paul From paul at mcjones.org Sat Feb 17 14:09:24 2018 From: paul at mcjones.org (Paul McJones) Date: Fri, 16 Feb 2018 20:09:24 -0800 Subject: [TUHS] TUHS Digest, Vol 27, Issue 37 In-Reply-To: References: Message-ID: <3D568654-03CD-4304-8CF9-C2FCE3662533@mcjones.org> > On Feb 14, 2018, Dave Horsfall wrote: > > Computer pioneer Niklaus Wirth was born on this day in 1934; he basically > designed ALGOL, one of the most influential languages ever, with just > about every programming language in use today tracing its roots to it. Wirth designed many languages, including Euler, Algol W, Pascal, Modula, and Oberon, but he did not design Algol; more specifically, he did not design Algol 60. Instead, a committee (J. W. Backus, F. L. Bauer, J. Green, C. Katz, J. McCarthy, P. Naur, A. J. Perlis, H. Rutishauser, K. Samelson, B. Vauquois, J .H. Wegstein, A. van Wijngaarden, and M. Woodger) designed it, and Peter Naur edited the remarkable Algol 60 specification. A few others, including Edsgar Dijkstra, who completed the first implementation, participated in meetings leading up to the final design. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Feb 17 16:47:22 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 17 Feb 2018 17:47:22 +1100 (EST) Subject: [TUHS] Of birthdays etc Message-ID: Blimey... How was I to know that a throw-away remark would almost develop into a shitfight? It would help if people changed the Subject line too, as I'm sure that Ken must've been a little peeved... It would also help if users didn't bloody top-post either, but I suspect that I've lost that fight. Anyway, this whole business started when I thought it might be a good idea to post reminders of historical events here, as I do with some of the other lists that I infest^W infect^W inhabit. I figured that the old farts here might like to be reminded of (IMHO) significant events, and similarly the youngsters might want to be reminded that there was indeed life before Linux (which, by the way, I happen to loathe, but that's a different story). I'm glad that some people appreciate it; and don't worry, Steffen, you'll soon catch up, as they should all be in the archives :-) A long-term goal (if I live that long) is to set up one of those "this day in history" sites, but it looks like Harris' Lament[*] has already applied :-( I've had a number of corrections (thanks!), some weird comments on pronunciation (an Englishman can probably pick my ancestry from me saying "castle" as "c-AH-stle" and "dance" as "d-A-nce" etc), but oddly enough no criticism (well, unless I'm talking about mounting a magtape as a filesystem; no, I will not forget the implication that I was a liar), and Warren has yet to spank me... For the morbidly curious I keep these events in Calendar on my MacBook (which actually spends most of its time in Terminal, and I don't even know how to use the Finder!), and am always noting things which interest me and therefore possibly others. Anyway, thanks all; it is an honour and a privilege to share a mailing list with some of the people who wrote the software that I have both used in the past and still use to this day. [*] Harris' Lament? Look it up with your favourite search engine (I don't use Google). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Sun Feb 18 06:43:20 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 18 Feb 2018 07:43:20 +1100 (EST) Subject: [TUHS] Happy birthday, Dick Hustvedt! Message-ID: Let's see how much thread-drift I can generate this time... Dick Hustvedt was born on this day in 1946; an architect of RSX-11 and VMS, he also had a weird sense of humour which he demonstrated by enshrining the "microfortnight" into VMS. Sadly, we lost him in a car accident in 2008. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From krewat at kilonet.net Sun Feb 18 06:50:33 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Sat, 17 Feb 2018 15:50:33 -0500 Subject: [TUHS] Happy birthday, Dick Hustvedt! In-Reply-To: References: Message-ID: <95d19f3a-38a4-a990-26be-fab187bbba3a@kilonet.net> On 2/17/2018 3:43 PM, Dave Horsfall wrote: > Let's see how much thread-drift I can generate this time... Keep up the good work, I really like the birthday/obituary announcements you provide. From lyndon at orthanc.ca Sun Feb 18 06:56:30 2018 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 17 Feb 2018 12:56:30 -0800 (PST) Subject: [TUHS] Happy birthday, Dick Hustvedt! In-Reply-To: References: Message-ID: > Let's see how much thread-drift I can generate this time... I miss my mid-90s (physical) Usenix calendar. It listed, among other important dates, the anniversary of the first airing of the Rocky and Bullwinkle show. --lyndon From paul.winalski at gmail.com Sun Feb 18 08:16:04 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Sat, 17 Feb 2018 17:16:04 -0500 Subject: [TUHS] Happy birthday, Dick Hustvedt! In-Reply-To: References: Message-ID: On 2/17/18, Dave Horsfall wrote: > Let's see how much thread-drift I can generate this time... > > Dick Hustvedt was born on this day in 1946; an architect of RSX-11 and > VMS, he also had a weird sense of humour which he demonstrated by > enshrining the "microfortnight" into VMS. > > Sadly, we lost him in a car accident in 2008. THE best engineer and software architect that I ever worked with. At least as talented as Dave Cutler, without the arrogance and nasty temper. A conference room in DEC's Nashua NH software engineering facility was named after him. One of Dick's April Fool's Day hacks, the SD-730 Solar Horologue was kept in the Hustvedt conference room for many years. It is now at VMS Software, Inc. -Paul W. From lm at mcvoy.com Sun Feb 18 11:01:58 2018 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 17 Feb 2018 17:01:58 -0800 Subject: [TUHS] Do Interface specifications such POSIX or the LSB Still Matter In-Reply-To: References: <781FBCD1-A2D9-4F6A-A0CF-452C243900E8@pobox.com> <20180216154516.GB14249@mcvoy.com> Message-ID: <20180218010158.GE17873@mcvoy.com> On Fri, Feb 16, 2018 at 01:36:14PM -0500, Clem Cole wrote: > On Fri, Feb 16, 2018 at 10:45 AM, Larry McVoy wrote: > > Meh, not really. Until Git ate our market, we supported everything you > > might imagine. Windows, MacOS, Linux-{x86,x86_64,sparc,ppc,itanium,mips}, > > AIX, IRIX, HP-UX, Solaris. > > > > Source base of 2.6 million lines of code and docs. > > > ???Did you have messaging (Co-Arrays, MPI or SHMEM) mixed in? I'm guess > not., but your system is (was) extensive so I'm asking.... Nope. We did our own protocol over TCP and HTTP. > > We limited our stuff to very basic stuff > > > ???Yup -- very wise. Simple library to insulate you from OS. > Did you shipped statically bound or use *.so's We could build static, we had a "make crank-static", but we rarely did that, it was only for some oddball targets. 99.9999% of the time it was dynamic and it was not a problem because I was so careful about what we used in libc (as I said before, it was only in the last 5 years that I trusted that realloc() actually worked). > Also how much are you dependant on OS databases (password & credential > libraries and other things stored in /etc, /usr/lib or /var)???? > ???This is were even within Linux, life can get messy pretty fast.??? We really didn't use much, we were not parsing that stuff for the most part. There were some things we did, for example, we have a fstype() function that called disktype(). It tried to find the mount point, looking through /etc/mtab /etc/mnttab /var/log/mount.today and it figured out if it was NFS or not. If it was not NFS then it called disktype which tried to figure out if it was SSD or not by pawing through stuff like /sys/block/%s/queue/rotational All of that was so we could auto-optimize parallelism, NFS wants 8 way, SSD wants all the CPUS, rotating disk wants just one or you thrash the arm. > > Netflix does a lot in AWS. And they care about performance. But they > > code around the variance that you get from containers, I could see that > > as an issue for the old school fortran people. > > > ???Good .. you get it.??? Maybe. > > I'm sort of struggling to see what problem it is you want to solve. > > > ???Without revealing the ISV, I know very well know HPC ISV that used to have > a >>Linux<< only test matrix of over 140 perminations before they could > release and they only supported RH and SuSE. But between different > manufacturers, distributed file systems, interconnect, messaging stacks, > compilers *et al???* > > *??? *it got messy very fast.??? I really don't see why. I can see why if they are using every library known to man, but if you want portable you don't do that. From akosela at andykosela.com Sun Feb 18 14:53:54 2018 From: akosela at andykosela.com (Andy Kosela) Date: Sat, 17 Feb 2018 22:53:54 -0600 Subject: [TUHS] Happy birthday, Dick Hustvedt! In-Reply-To: References: Message-ID: On Saturday, February 17, 2018, Dave Horsfall wrote: > Let's see how much thread-drift I can generate this time... > > Dick Hustvedt was born on this day in 1946; an architect of RSX-11 and > VMS, he also had a weird sense of humour which he demonstrated by > enshrining the "microfortnight" into VMS. > > Sadly, we lost him in a car accident in 2008. > > Hmm, that's actually not true. He had a car accident in 1984 on his way to the office which left him with brain damage. He later died in 2008. Dick Hustvedt, Peter Lipman and David Cutler were the principal engineers responsible for VMS. Lipman left DEC the same year (1984) and we all know the later history of Cutler... ;) --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.j.blom at gmail.com Sun Feb 18 19:42:15 2018 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Sun, 18 Feb 2018 16:42:15 +0700 Subject: [TUHS] Of birthdays etc Message-ID: >Date: Sat, 17 Feb 2018 17:47:22 +1100 (EST) >From: Dave Horsfall >To: The Eunuchs Hysterical Society >Subject: [TUHS] Of birthdays etc >Message-ID: >Content-Type: text/plain; format=flowed; charset=US-ASCII > >... >Harris' Lament? Look it up with your favourite search engine (I don't use Google). > probably early 1995 I dabbled a bit in AltaVista Search. So even now still using Yahoo somehow :-) Keep it coming Dave, it's appreciated, at least by me. >From a former DECcie, uncle rubl From norman at oclsc.org Mon Feb 19 01:17:21 2018 From: norman at oclsc.org (Norman Wilson) Date: Sun, 18 Feb 2018 10:17:21 -0500 Subject: [TUHS] PDP-7 Unix Paper Message-ID: <1518967044.12864.for-standards-violators@oclsc.org> Donald ODana: already 20 years ago I met a guy (masters degree, university) who never freed dynamically allocated memory. He told me he is 'instantiating a object', but had no idea what an heap is, and what dynamically allocated memory means. ==== This is the sort of programmer for whom garbage collection was named: his programs are a collection of garbage. Norman Wilson Toronto ON (In 1127-snark mode this evening) From mutiny.mutiny at india.com Mon Feb 19 03:35:28 2018 From: mutiny.mutiny at india.com (Donald ODona) Date: Sun, 18 Feb 2018 17:35:28 +0000 (UTC) Subject: [TUHS] PDP-7 Unix Paper In-Reply-To: <1518967044.12864.for-standards-violators@oclsc.org> References: <1518967044.12864.for-standards-violators@oclsc.org> Message-ID: <824800681.39832.1518975328765.JavaMail.tomcat@india-live-be02> indeed. ;-) At 18 Feb 2018 15:18:55 +0000 (+00:00) from Norman Wilson : > Donald ODana: > > already 20 years ago I met a guy (masters degree, university) who never > freed dynamically allocated memory. He told me he is 'instantiating > a object', but had no idea what an heap is, and what dynamically > allocated memory means. > > ==== > > This is the sort of programmer for whom garbage collection was named: > his programs are a collection of garbage. > > Norman Wilson > Toronto ON > (In 1127-snark mode this evening) From norman at oclsc.org Mon Feb 19 06:50:46 2018 From: norman at oclsc.org (Norman Wilson) Date: Sun, 18 Feb 2018 15:50:46 -0500 Subject: [TUHS] Happy birthday, Niklaus Wirth! Message-ID: <1518987049.23498.for-standards-violators@oclsc.org> As an aside about Wolfram and SMP (and one that actually has something to do with UNIX): I ran the VAX on which Wolfram et al (and it was very much et al) developed SMP. It started out running UNIX/TS 1.0. I know how that system was snuck out of Bell Labs, but if I told you I'd have to terminate you with extreme prejudice. (I wasn't involved anyway.) SMP really needed dynamic paging; the TS 1.0 kernel had only swapping. We had quite a few discussions about what to do. Moving wholesale to 3BSD or early 4BSD (this was in 1981) would have been a big upheaval for our entire user community. Those systems were also notorious at the time for their delicate stability: some people reported that they ran well, others that they crashed frequently. Our existing system was pretty solid, and I had already put some work into making it more so (better handling of low-level machine errors, for example). Somehow we ended up deciding that the least-painful path was to lift the VM code out of 4BSD and shoehorn it into our existing kernel, creating what we called Bastardized Paging UNIX. I did most of the work; I was younger and more energetic back then. Also considerably grumpier. In the heart of the page-in (I think) code, the Berkeley guys had written a single C function that stretched to about ten printed pages. (For those too young to remember printers, that means about 600 lines.) I was then and still am adamant that that's the wrong way to write anything, but I didn't want to take the time to rewrite it all, so (being young and grumpy) I relieved my feelings by adding a grumpy comment at the top of the source file. I also wrote a paper about the work, which was published in (of all places) AUUGN. I haven't read it in years but it was probably a bit snotty. It nevertheless ended up causing a local UNIX-systems-software company to head-hunt me (but at the time I had no interest in leaving Caltech), so it must not have been too rude. What days those were, when a single person could understand enough of the OS to do stuff like that in only a month or two, and get it pretty much right too. I did end up finding some interesting race-condition bugs, probably introduced by me, but fascinating to track down; e.g. something that went wrong only if a page fault happened at exactly the right time with respect to something else. Norman Wilson Toronto ON From dave at horsfall.org Mon Feb 19 10:28:22 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 19 Feb 2018 11:28:22 +1100 (EST) Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: <1518987049.23498.for-standards-violators@oclsc.org> References: <1518987049.23498.for-standards-violators@oclsc.org> Message-ID: On Sun, 18 Feb 2018, Norman Wilson wrote: > I also wrote a paper about the work, which was published in (of all > places) AUUGN. I haven't read it in years but it was probably a bit > snotty. It nevertheless ended up causing a local UNIX-systems-software > company to head-hunt me (but at the time I had no interest in leaving > Caltech), so it must not have been too rude. Norman is obviously too modest to toot his own trumpet, so me being me I'll do it for him: AUUGN-V04.2.pdf A bastardized paging UNIX ABSTRACT One of the VAXes in the Caltech High Energy Physics Group runs a peculiar hybrid of several versions of UNIX. Its principle claim to fame is that it is recognizably a variant of UNIX/TS, but has virtual memory code grafted in from Berkeley’s 4BSD. It is also compatible with the UNIX/TS system run on our PDP-II/45. This paper is meant to give some idea of what our system is, why it exists, and how much effort went into its creation. My favourite quote: Philosophy - We feel that many of Berkeley’s changes to the system and the supporting programs are unnecessary, un-UNIX-like, and just plain silly. To take a favourite example: anyone who will add a flag to _cat_ to make it number lines, remove blank lines, and make control characters visible, rather than writing separate filters, simply doesn’t understand what UNIX is all about. Well said, bro! -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From clemc at ccc.com Tue Feb 20 01:01:04 2018 From: clemc at ccc.com (Clem Cole) Date: Mon, 19 Feb 2018 10:01:04 -0500 Subject: [TUHS] Do Interface specifications such POSIX or the LSB Still Matter In-Reply-To: <20180218010158.GE17873@mcvoy.com> References: <781FBCD1-A2D9-4F6A-A0CF-452C243900E8@pobox.com> <20180216154516.GB14249@mcvoy.com> <20180218010158.GE17873@mcvoy.com> Message-ID: On Sat, Feb 17, 2018 at 8:01 PM, Larry McVoy wrote: > > I really don't see why. I can see why if they are using every library > known to man, but if you want portable you don't do that. > ​The ISV's customers are interesting in getting a specific job done - be it a simulation, ​ ​geo or therma prediction. Time to money is what matters to the end user - so they pick the 'best' product to do their job. ​Hence, e xecution speed is typically the prime directive for an ISV like this and they are using Fortran for portability.​ Which is different from your design point I suspect. You need to be fast enough, but the choice of bitkeeper vs cvs vs ... is likely made with a different high order bit. ​For the ISV​, at a minimum, it is a testing issue of the different perminations. They need to be fast, but their production code is deployed a top of 'a stack of turtles.' As I said RH Linux != SuSE != Ubuntu (they are similar but the kernels are not the same and the system DB's vary -- those tend to cause installation issues). GFortran != Intel ifort != PCG FTN != Cray FTN != IBM fortran. Much less GCC != Clang != Intel​ icc != IBM CC - cause interesting issues with dynamic loading. IBM MPI != HP MPI != OpenMPI != Intel MPI etc..tend to cause ISV code to step on each other. ​ Then you add Mellanox IB is not IBM is not Intel and .... Mellanox Verbs is not Cisco Verbs is not PSM is not OFED ​ and locking and scaling starts to get strange​ . Each of these can be a 'little different' even though they all follow standards. It becomes a old Al Haig - style - "I'm in charge" problem. Moreover, I know of one large distro insists on only testing their IB stack point to point with two system, even when they have been offered a HW from a vendor ​ that has 4 compute nodes plus a head node, just to chase and tease out the corner cases that drive the ISV mad. ​ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Feb 20 04:12:45 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 19 Feb 2018 13:12:45 -0500 Subject: [TUHS] Happy birthday, Dick Hustvedt! In-Reply-To: References: Message-ID: On 2/17/18, Andy Kosela wrote: > On Saturday, February 17, 2018, Dave Horsfall wrote: > > Dick Hustvedt, Peter Lipman and David Cutler were the principal engineers > responsible for VMS. Lipman left DEC the same year (1984) and we all know > the later history of Cutler... ;) Dave Cutler was in the VMS group only for VMS version 1. He rarely stayed on around for version 2 of anything. Hustvedt's and Lipman's contributions for VMS were more extensive and longer-lasting than Cutler's. -Paul W. From dave at horsfall.org Tue Feb 20 15:20:51 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 20 Feb 2018 16:20:51 +1100 (EST) Subject: [TUHS] Happy birthday, Dick Hustvedt! In-Reply-To: References: Message-ID: On Sun, 18 Feb 2018, Dave Horsfall wrote: > Sadly, we lost him in a car accident in 2008. Thanks, all; correction noted. I love being wrong, because I learn a lot that way... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From mutiny.mutiny at india.com Tue Feb 20 19:11:51 2018 From: mutiny.mutiny at india.com (Donald ODona) Date: Tue, 20 Feb 2018 09:11:51 +0000 (UTC) Subject: [TUHS] Happy birthday, Dick Hustvedt! In-Reply-To: References: , Message-ID: <145840281.42647.1519117911421.JavaMail.tomcat@india-live-be01> since '86 he was working on an operating system, named Mica, which failed. At 19 Feb 2018 18:13:59 +0000 (+00:00) from Paul Winalski : > Dave Cutler was in the VMS group only for VMS version 1. He rarely > stayed on around for version 2 of anything. Hustvedt's and Lipman's > contributions for VMS were more extensive and longer-lasting than > Cutler's. > > -Paul W. From paul.winalski at gmail.com Wed Feb 21 02:33:59 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 20 Feb 2018 11:33:59 -0500 Subject: [TUHS] Dave Cutler (was Re: Re: Happy birthday, Dick Hustvedt!) Message-ID: On 2/20/18, Donald ODona wrote: > since '86 he was working on an operating system, named Mica, which failed. > > At 19 Feb 2018 18:13:59 +0000 (+00:00) from Paul Winalski > : >> Dave Cutler was in the VMS group only for VMS version 1. He rarely >> stayed on around for version 2 of anything. Hustvedt's and Lipman's >> contributions for VMS were more extensive and longer-lasting than >> Cutler's. Cutler had already left the VMS OS group by the time I joined DEC in February of 1980. After VMS he led the team developing PL/I and C compilers for VMS. These shared a common back end called the VAX Code Generator (VCG). The other VMS compilers at the time (Fortran, Pascal, Cobol) had their own separate optimizers and code generators. The VAX Ada compiler would also use VCG. When version 1 of VAX PL/i and VAX C shipped, Cutler worked on subsetting the VAX architecture so that a single chip implementation could be done, and led the team that produced the MicroVAX I. The MicroVAX architecture emulated expensive instructions such as packed decimal. All of the later, single-chip VAXes used this architecture. When the MicroVAX I shipped, Cutler devised a microkernel-based real-time operating system for the VAX called VAXeln. After VAXeln, Cutler led the team developing a RISC architecture follow-on to the VAX called PRISM, and an operating system for it called Mica. Mica had a VAXeln-like microkernel, and the plan was to layer personality modules on top of that to implement VMS and Unix-style ABIs and system calls. Alpha was chosen instead of PRISM as the VAX successor, and that is when Cutler left DEC for Microsoft. Windows NT has a lot of design concepts and details previously seen in PRISM and VMS. -Paul W. From ggm at algebras.org Wed Feb 21 11:20:19 2018 From: ggm at algebras.org (George Michaelson) Date: Wed, 21 Feb 2018 11:20:19 +1000 Subject: [TUHS] Dave Cutler (was Re: Re: Happy birthday, Dick Hustvedt!) In-Reply-To: References: Message-ID: I used the VMS PL/1 to write an ISO transport layer as a gigantic finite state machine in the computed GOTO via a jump table. First job from graduating. Not my finest moment, but the compiler was awesome. Fast, rigid. I think I had to get somebody to write some bliss32 or even ASM to do a trick in the stack for some debug, cool moment for me. The box of fiches of the OS code was there in the machineroom, It was a revalation to me you could do that: go "read" the code, and see what it did. I don't know if we used VMS C from Dec. I have a feeling if you ran Eunice, you used pcc or a derivative of pcc. Cross library calling was pretty straightforward (ok, so passing function addresses and dynamic structures into FORTRAN not such) and VMS had a well defined 'postbox' mechanism for async I/O which was wierd if you were used to UNIX but then .. the entire FS in VMS was wierd if you were used to UNIX. Wierd, but also comforting: you told the filesystem you wanted fast record indexing into a file as a binary construct and it said "sure: I'll do that" and as long as you opened the file with the right semantics, thats what you got. I still have my thin-form PL/1 cheetsheet booklet. Its fat. Most of these were 3-fold cards, its got staples. Not a big language mind you. So basically, his compiler got me my first paper. http://onlinelibrary.wiley.com/doi/10.1002/spe.4380150503/full On Wed, Feb 21, 2018 at 2:33 AM, Paul Winalski wrote: > On 2/20/18, Donald ODona wrote: >> since '86 he was working on an operating system, named Mica, which failed. >> >> At 19 Feb 2018 18:13:59 +0000 (+00:00) from Paul Winalski >> : >>> Dave Cutler was in the VMS group only for VMS version 1. He rarely >>> stayed on around for version 2 of anything. Hustvedt's and Lipman's >>> contributions for VMS were more extensive and longer-lasting than >>> Cutler's. > > Cutler had already left the VMS OS group by the time I joined DEC in > February of 1980. After VMS he led the team developing PL/I and C > compilers for VMS. These shared a common back end called the VAX Code > Generator (VCG). The other VMS compilers at the time (Fortran, > Pascal, Cobol) had their own separate optimizers and code generators. > The VAX Ada compiler would also use VCG. > > When version 1 of VAX PL/i and VAX C shipped, Cutler worked on > subsetting the VAX architecture so that a single chip implementation > could be done, and led the team that produced the MicroVAX I. The > MicroVAX architecture emulated expensive instructions such as packed > decimal. All of the later, single-chip VAXes used this architecture. > > When the MicroVAX I shipped, Cutler devised a microkernel-based > real-time operating system for the VAX called VAXeln. > > After VAXeln, Cutler led the team developing a RISC architecture > follow-on to the VAX called PRISM, and an operating system for it > called Mica. Mica had a VAXeln-like microkernel, and the plan was to > layer personality modules on top of that to implement VMS and > Unix-style ABIs and system calls. > > Alpha was chosen instead of PRISM as the VAX successor, and that is > when Cutler left DEC for Microsoft. Windows NT has a lot of design > concepts and details previously seen in PRISM and VMS. > > -Paul W. From cym224 at gmail.com Thu Feb 22 06:18:27 2018 From: cym224 at gmail.com (Nemo) Date: Wed, 21 Feb 2018 15:18:27 -0500 Subject: [TUHS] Dave Cutler (was Re: Re: Happy birthday, Dick Hustvedt!) In-Reply-To: References: Message-ID: On 20/02/2018, George Michaelson wrote (in part): > I don't know if we used VMS C from Dec. I have a feeling if you ran > Eunice, you used pcc or a derivative of pcc. Cross library calling was > pretty straightforward (ok, so passing function addresses and dynamic > structures into FORTRAN not such) [...] Hhmmm... I recall using DEC's C compiler, which we called VAX C. Calling C stuff from VAX FORTRAN required jiggery-pokery and the other way was hopeless. I recall (assuming no wetware bit-rot on my part) that DEC's languages did not pass on the stack but stuffed the arguments somewhere, passing a pointer to the somewhere. N. From ron at ronnatalie.com Thu Feb 22 06:26:16 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 21 Feb 2018 15:26:16 -0500 Subject: [TUHS] VMS C / Whitesmiths Message-ID: <004a01d3ab52$39f03d70$add0b850$@ronnatalie.com> At Rutgers Newark, we had VMS system that had Whitesmith's C on it. At one point, Whitesmiths decided to "fight piracy" by sending you a sticker you were supposed to stick on the front of your computer to show that you had a licensed copy. I suppose I might have been in trouble if the Whitesmiths police came to my machine room. I was a bit miffed when one of the other employees actually stuck the thing to the machine. Years later I was loosely affiliated with Unipress. I did some consulting for them when I was between jobs. I went out to dinner with their principal, a man named Mark Krieger. After a bit of conversation it occurred to me. "Didn't you get booed off the stage at the University of Delaware UNIX users group meeting." He admitted he had, he was half of Whitesmiths with Paul Plauger. It then came back to me about Idris and the software stamps. I mentioned the stamps and he said he was gone by then but that was his sign that Plauger had gone over the edge. I carefully peeled our sticker off the Vax and gave it to him the next time I saw him. From dave at horsfall.org Thu Feb 22 07:33:39 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 22 Feb 2018 08:33:39 +1100 (EST) Subject: [TUHS] Dave Cutler (was Re: Re: Happy birthday, Dick Hustvedt!) In-Reply-To: References: Message-ID: On Wed, 21 Feb 2018, Nemo wrote: > Hhmmm... I recall using DEC's C compiler, which we called VAX C. Calling > C stuff from VAX FORTRAN required jiggery-pokery and the other way was > hopeless. I recall (assuming no wetware bit-rot on my part) that DEC's > languages did not pass on the stack but stuffed the arguments somewhere, > passing a pointer to the somewhere. Would that have anything to do with F*RTR*N being call by value-result? I.e. if you modified a formal parameter, and that corresponding actual parameter was a constant (and only stored once), then... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From imp at bsdimp.com Thu Feb 22 08:16:11 2018 From: imp at bsdimp.com (Warner Losh) Date: Wed, 21 Feb 2018 15:16:11 -0700 Subject: [TUHS] Dave Cutler (was Re: Re: Happy birthday, Dick Hustvedt!) In-Reply-To: References: Message-ID: On Wed, Feb 21, 2018 at 1:18 PM, Nemo wrote: > On 20/02/2018, George Michaelson wrote (in part): > > I don't know if we used VMS C from Dec. I have a feeling if you ran > > Eunice, you used pcc or a derivative of pcc. Cross library calling was > > pretty straightforward (ok, so passing function addresses and dynamic > > structures into FORTRAN not such) [...] > > Hhmmm... I recall using DEC's C compiler, which we called VAX C. > Calling C stuff from VAX FORTRAN required jiggery-pokery and the other > way was hopeless. I recall (assuming no wetware bit-rot on my part) > that DEC's languages did not pass on the stack but stuffed the > arguments somewhere, passing a pointer to the somewhere. > The arguments were on the stack, but the calling convention also had some metadata about the arguments you needed to worry about when calling into/out of C, but rarely any time else. %DESCRIPTOR sticks in my head for some traumatic reason. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Thu Feb 22 08:25:14 2018 From: ggm at algebras.org (George Michaelson) Date: Thu, 22 Feb 2018 08:25:14 +1000 Subject: [TUHS] Dave Cutler (was Re: Re: Happy birthday, Dick Hustvedt!) In-Reply-To: References: Message-ID: I'm dredging up from tapestore memory but I think for things we'd morally call "varargs" you had to have a way of telling the call binding what the variant elements were. It's one thing to be inside a language model where the heap and type bindings are known, and another to break out into another language. NAG library (leeds uni had some role in this, maybe maintenance contract. I lunched with the people who worked on it. They were awesome gods of computing including one feller who had a glass eyeball. Thats hardcore pirate programmers right there!) its pretty well understood you passed numbers and arrays of numbers, so the variations on call args were rather limited. Other things? not such. There were various warnings about using const and register and other #pragma too. Compilers mucking around too much. The only language aside from LISP (sorry. forget I said that) which I couldn't get to fly on the UNIX systems was Pascal, the Berkeley compiler made completely different assumptions to the DEC-10 compiler I'd used at university. Syntactically, the language felt different even if it really wasn't. I think Berkeley did Pascal to get over some educational funding barrier, it didn't feel like a real investment (the p-system aside) Actually I tell a lie. Snobol defeated me. I had no brain capacity to understand it. APL had left me behind, on the DECwriter with the modified alphabet. Keyboard in greek? Ok.. fool me once, more fool you: fool me twice, Lambda Sigma Phi me. On Thu, Feb 22, 2018 at 8:16 AM, Warner Losh wrote: > > > On Wed, Feb 21, 2018 at 1:18 PM, Nemo wrote: >> >> On 20/02/2018, George Michaelson wrote (in part): >> > I don't know if we used VMS C from Dec. I have a feeling if you ran >> > Eunice, you used pcc or a derivative of pcc. Cross library calling was >> > pretty straightforward (ok, so passing function addresses and dynamic >> > structures into FORTRAN not such) [...] >> >> Hhmmm... I recall using DEC's C compiler, which we called VAX C. >> Calling C stuff from VAX FORTRAN required jiggery-pokery and the other >> way was hopeless. I recall (assuming no wetware bit-rot on my part) >> that DEC's languages did not pass on the stack but stuffed the >> arguments somewhere, passing a pointer to the somewhere. > > > The arguments were on the stack, but the calling convention also had some > metadata about the arguments you needed to worry about when calling into/out > of C, but rarely any time else. %DESCRIPTOR sticks in my head for some > traumatic reason. > > Warner From dave at horsfall.org Thu Feb 22 12:38:55 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 22 Feb 2018 13:38:55 +1100 (EST) Subject: [TUHS] Dave Cutler (was Re: Re: Happy birthday, Dick Hustvedt!) In-Reply-To: References: Message-ID: On Thu, 22 Feb 2018, George Michaelson wrote: > Actually I tell a lie. Snobol defeated me. I had no brain capacity to > understand it. APL had left me behind, on the DECwriter with the > modified alphabet. Keyboard in greek? Ok.. fool me once, more fool you: > fool me twice, Lambda Sigma Phi me. In final year Comp Sci we had to write a compiler, so I told my lecturer (Ken Robinson) that I was going to do it in SNOBOL. He threatened to fail me if I did... I ended up using ALGOLW instead, and IMHO it was an amazing piece of work, being able to correct syntax errors so that it could continue compiling etc, and proved it by writing a program with every possible error being auto-corrected and producing the correct output when run. That listing and deck of cards are long gone, alas. As for APL, I see you've never used APL\360 on the Kleinschmidt (pronounced "Kline-shit") terminal. A matrix printer, it regularly punched holes right through the paper; one joker put a page on the Comp Sci noticed board with a reddish IBM JCL card showing through, with the inscription "Who said APL programs weren't transparent?". No, it wasn't me; I was responsible for certain other shenanigans instead, but I'm unsure of the Statute of Limitations... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Thu Feb 22 12:44:29 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 22 Feb 2018 13:44:29 +1100 (EST) Subject: [TUHS] Dave Cutler (was Re: Re: Happy birthday, Dick Hustvedt!) In-Reply-To: References: Message-ID: On Tue, 20 Feb 2018, Paul Winalski wrote: > When the MicroVAX I shipped, Cutler devised a microkernel-based > real-time operating system for the VAX called VAXeln. Damn; I'm trying to remember a little ditty around that time, something like: I love my little MicroVax I like it when it fails etc. Does it stir anyone's memories? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From sauer at technologists.com Thu Feb 22 13:25:29 2018 From: sauer at technologists.com (Charles H. Sauer) Date: Wed, 21 Feb 2018 21:25:29 -0600 Subject: [TUHS] in defense of SNOBOL, APL (and Icon) (was Re: Dave Cutler (was Re: Re: Happy birthday, Dick Hustvedt!) In-Reply-To: References: Message-ID: [I’ll bring this back to AIX so as to not be straying too far from Unix.] I learned SNOBOL in an undergraduate programming languages course at UT-Austin. When I went to Yorktown in 1975, I brought with me a queueing network simulation program, APLOMB, that I wrote in Fortran. I thought of APLOMB as almost incidental to my dissertation (chapter VI at http://technologists.com/sauer/CONFIGURATION%20OF%20COMPUTING%20SYSTEMS%20-%20AN%20APPROACH%20USING%20QUEUEING%20NETWORK%20MODELS.pdf ). The group I joined in Yorktown was very interested in APLOMB. I was encouraged to enhance it considerably, which I did, continuing with Fortran, in spite of wishing I was using a language with support for structured data types, pointers, etc. One of my colleagues, the late Martin Reiser, had developed a numerical package, QNET4, for solving a subset of the queueing networks considered by APLOMB. Martin was adept with APL and designed QNET4 in APL, but subsequently maintained a PL/I version in parallel with the APL original. I never did much more than play with APL, though I think I had a Selectric ball for APL and may have had a 3277 with APL (IIRC, APL was an optional extra). It soon came to pass that we wanted to put APLOMB and QNET4 under one roof and the combination became RESQ (http://web.archive.org/web/20130627040507/http://www.research.ibm.com/compsci/performance/history.html ), based on extending QNET4 and cobbling it with the Fortran APLOMB. RESQ was very well received. Our management bemoaned the kludgey implementation, wishing APLOMB was in PL/I, convinced that getting APLOMB into PL/I would be an enormous effort. Remembering my pleasant course experiences with SNOBOL, I used SNOBOL to create a Fortran to PL/I translator of sorts. I think it took me less than two weeks to write the translator, use it with APLOMB and begin working with the all-PL/I version of RESQ. Management, Martin, Ed MacNair (other primary RESQ developer), and I were all thrilled. One of SNOBOL’s creators, Ralph Griswold, created a somewhat analogous but less syntactically intimidating successor, Icon (https://www2.cs.arizona.edu/icon/ ). When we in AIX development bemoaned all the code that still existed as PL.8, I remembered the SNOBOL experience and prototyped a PL.8 to C translator in Icon. Dave Farber of ISC (not the CMU Prof. Farber) enhanced it and it was used to assist in getting the PL.8 code to C in AIX. Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 web: http://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Feb 23 11:10:31 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 23 Feb 2018 12:10:31 +1100 (EST) Subject: [TUHS] Pipes as temp. files Message-ID: Just curious; am I the only who, back in the early days of V6, used pipes as temporary files? I mean that after calling pipe(), instead of then forking and playing "file-descriptor footsie" you just read and wrote within the same process. I seem to recall that it worked, as long as you avoided the 8-block limit (or whatever it was then); I have no idea why I tried it, other than to see if it worked i.e. avoid the creat() (without the "e") etc. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Sat Feb 24 07:44:22 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 24 Feb 2018 08:44:22 +1100 (EST) Subject: [TUHS] RIP Claude Shannon Message-ID: We lost Claude Shannon on this day in 2001. He was a mathematician, electrical engineer, and cryptographer; he is regarded as the "father" of information theory, and he pioneered digital circuit design. Amongst other things he built a barbed-wire telegraph, the "Ultimate Machine" (it reached up and switched itself off), a Roman numeral computer ("THROBAC"), the Minivac 601 (a digital trainer), a Rubik's Cube solver, a mechanical mouse that learned how to solve mazes, and outlined a chess program (pre-Belle). He formulated the security mantra "The enemy knows the system", and did top-secret work in WW-2 on crypto and fire-control systems. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From rudi.j.blom at gmail.com Sat Feb 24 17:28:20 2018 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Sat, 24 Feb 2018 14:28:20 +0700 Subject: [TUHS] RIP Claude Shannon Message-ID: Never heard of Claude Shannon. So a good opportunity to do some searching reading to 'catch up'. Interesting person and this quota tends to make him my type of guy "I just wondered how things were put together. – C.E. Shannon" http://themathpath.com/documents/ee376a_win0809_aboutClaudeShannon_willywu.pdf Now wondering if I should register for this THORIAC project or just read some more and do it. Not in the mood for learning Python I'd probably do some fumbling in C. https://www.engage-csedu.org/find-resources/shannons-throbac Keeps me busy and amuzed, uncle rubl From doug at cs.dartmouth.edu Sun Feb 25 01:51:19 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 24 Feb 2018 10:51:19 -0500 Subject: [TUHS] [TUHS} RIP Claude Shannon Message-ID: <201802241551.w1OFpJ50004264@coolidge.cs.Dartmouth.EDU> So many memories. The "ultimate machine" (which was brought out and demonstrated from time to time while I was at the Labs) was built in collaboration with Ed Moore (he of Moore-model automata, who published "Dijkstra's algorithm" for shortest paths a year before Dijkstra) and (I believe) Dave Hagelbarger. Moore endowed the machine with a longevity property seldom remarked on: majority logic so that any electrical component can be removed without harming its observable behavior. Shannon moved to MIT from Bell Labs some weeks before I moved the other way, so I only met him much later when he visited the Unix room (an excuse, albeit weak, for this distant detour from TUHS). By that time Shannon was descending into Alzheimer's fog, but his wife who accompanied him was a memorably curious and perceptive visitor. I have wondered what role she may have played as a sounding board or more in Shannon's research. As a child, I used to ski on the 50-foot hill that was the lawn of the mansion that Shannon would buy when he moved to Massachusetts. We kids would ski down and climb back up. Not Shannon. He installed a chairlift. One house separated mine from the ski hill. It belonged to John Trump, another MIT prof who engineered the Van de Graaff generator into a commercial product for generating million-volt x-rays and, yes, was uncle of the Donald. John, as kind as he was bright, fortunately did not live to see the apotheosis of his wayward nephew. Doug > We lost Claude Shannon on this day in 2001. He was a mathematician, > electrical engineer, and cryptographer; he is regarded as the "father" of > information theory, and he pioneered digital circuit design. Amongst > other things he built a barbed-wire telegraph, the "Ultimate Machine" (it > reached up and switched itself off), a Roman numeral computer ("THROBAC"), > the Minivac 601 (a digital trainer), a Rubik's Cube solver, a mechanical > mouse that learned how to solve mazes, and outlined a chess program > (pre-Belle). He formulated the security mantra "The enemy knows the > system", and did top-secret work in WW-2 on crypto and fire-control > systems. From lm at mcvoy.com Sun Feb 25 02:01:12 2018 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 24 Feb 2018 08:01:12 -0800 Subject: [TUHS] [TUHS} RIP Claude Shannon In-Reply-To: <201802241551.w1OFpJ50004264@coolidge.cs.Dartmouth.EDU> References: <201802241551.w1OFpJ50004264@coolidge.cs.Dartmouth.EDU> Message-ID: <20180224160112.GE14684@mcvoy.com> Just for the record, I love these memories. A glimpse into history. Detours like these are very welcome in my opinion. I had forgotten about this: https://www.youtube.com/watch?v=Gw2Bq0HYu1M On Sat, Feb 24, 2018 at 10:51:19AM -0500, Doug McIlroy wrote: > So many memories. The "ultimate machine" (which was brought out and > demonstrated from time to time while I was at the Labs) was built in > collaboration with Ed Moore (he of Moore-model automata, who published > "Dijkstra's algorithm" for shortest paths a year before Dijkstra) and > (I believe) Dave Hagelbarger. Moore endowed the machine with a longevity > property seldom remarked on: majority logic so that any electrical > component can be removed without harming its observable behavior. > > Shannon moved to MIT from Bell Labs some weeks before I moved the > other way, so I only met him much later when he visited the Unix room > (an excuse, albeit weak, for this distant detour from TUHS). By that > time Shannon was descending into Alzheimer's fog, but his wife who > accompanied him was a memorably curious and perceptive visitor. I have > wondered what role she may have played as a sounding board or more in > Shannon's research. > > As a child, I used to ski on the 50-foot hill that was the lawn of the > mansion that Shannon would buy when he moved to Massachusetts. We kids > would ski down and climb back up. Not Shannon. He installed a chairlift. > One house separated mine from the ski hill. It belonged to John Trump, > another MIT prof who engineered the Van de Graaff generator into a > commercial product for generating million-volt x-rays and, yes, was uncle > of the Donald. John, as kind as he was bright, fortunately did not live > to see the apotheosis of his wayward nephew. > > Doug > > > > We lost Claude Shannon on this day in 2001. He was a mathematician, > > electrical engineer, and cryptographer; he is regarded as the "father" of > > information theory, and he pioneered digital circuit design. Amongst > > other things he built a barbed-wire telegraph, the "Ultimate Machine" (it > > reached up and switched itself off), a Roman numeral computer ("THROBAC"), > > the Minivac 601 (a digital trainer), a Rubik's Cube solver, a mechanical > > mouse that learned how to solve mazes, and outlined a chess program > > (pre-Belle). He formulated the security mantra "The enemy knows the > > system", and did top-secret work in WW-2 on crypto and fire-control > > systems. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From otto at drijf.net Sun Feb 25 02:18:11 2018 From: otto at drijf.net (Otto Moerbeek) Date: Sat, 24 Feb 2018 17:18:11 +0100 Subject: [TUHS] [TUHS} RIP Claude Shannon In-Reply-To: <201802241551.w1OFpJ50004264@coolidge.cs.Dartmouth.EDU> References: <201802241551.w1OFpJ50004264@coolidge.cs.Dartmouth.EDU> Message-ID: <20180224161811.GA25319@clue.drijf.net> On Sat, Feb 24, 2018 at 10:51:19AM -0500, Doug McIlroy wrote: > So many memories. The "ultimate machine" (which was brought out and > demonstrated from time to time while I was at the Labs) was built in > collaboration with Ed Moore (he of Moore-model automata, who published > "Dijkstra's algorithm" for shortest paths a year before Dijkstra) and > (I believe) Dave Hagelbarger. Moore endowed the machine with a longevity > property seldom remarked on: majority logic so that any electrical > component can be removed without harming its observable behavior. Keep the stories coming, much apprectaied. But a note on Dijkstra's algorithm: Moore and Dijsktra both published in 1959. http://www-m3.ma.tum.de/foswiki/pub/MN0506/WebHome/dijkstra.pdf https://books.google.nl/books/about/The_Shortest_Path_Through_a_Maze.html?id=IVZBHAAACAAJ&redir_esc=y But it is documented Dijkstra's algorithm has been invented and used by him in 1956. See e.g. https://amturing.acm.org/award_winners/dijkstra_1053701.cfm -Otto From dave at horsfall.org Sun Feb 25 07:33:58 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 25 Feb 2018 08:33:58 +1100 (EST) Subject: [TUHS] EOF on pipes? Message-ID: Many years ago (when the dinosaurs were using V6), I had a crazy idea[*] that a write(fd, 0, NULL) would somehow signal EOF to the reader i.e. a subsequent read would wait for further data instead of ENOTOBACCO. Did any *nix ever implement that? I have no idea how it would be done. [*] I was full of crazy ideas then, such as extending stty() to an arbitrary device and was told by the anti-CSU mob that it was a stupid idea... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From ron at ronnatalie.com Sun Feb 25 09:13:02 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Sat, 24 Feb 2018 18:13:02 -0500 Subject: [TUHS] EOF on pipes? In-Reply-To: References: Message-ID: <00a201d3adc5$058b1580$10a14080$@ronnatalie.com> Unix pipes are not allowed in non-smoking areas. -----Original Message----- Many years ago (when the dinosaurs were using V6), I had a crazy idea[*] that a write(fd, 0, NULL) would somehow signal EOF to the reader i.e. a subsequent read would wait for further data instead of ENOTOBACCO. From bakul at bitblocks.com Sun Feb 25 09:42:42 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Sat, 24 Feb 2018 15:42:42 -0800 Subject: [TUHS] EOF on pipes? In-Reply-To: Your message of "Sat, 24 Feb 2018 18:13:02 -0500." <00a201d3adc5$058b1580$10a14080$@ronnatalie.com> References: <00a201d3adc5$058b1580$10a14080$@ronnatalie.com> Message-ID: <20180224234257.E2F0C156E812@mail.bitblocks.com> On Sat, 24 Feb 2018 18:13:02 -0500 "Ron Natalie" wrote: Ron Natalie writes: > Unix pipes are not allowed in non-smoking areas. > > -----Original Message----- > > > Many years ago (when the dinosaurs were using V6), I had a crazy idea[*] > that a write(fd, 0, NULL) would somehow signal EOF to the reader i.e. a > subsequent read would wait for further data instead of ENOTOBACCO. pipe, ch(e)root.... Any more unix connections to smoking? From jon at fourwinds.com Sun Feb 25 09:46:06 2018 From: jon at fourwinds.com (Jon Steinhart) Date: Sat, 24 Feb 2018 15:46:06 -0800 Subject: [TUHS] EOF on pipes? In-Reply-To: <20180224234257.E2F0C156E812@mail.bitblocks.com> References: <00a201d3adc5$058b1580$10a14080$@ronnatalie.com> <20180224234257.E2F0C156E812@mail.bitblocks.com> Message-ID: <201802242346.w1ONk6Rh005026@darkstar.fourwinds.com> Bakul Shah writes: > > pipe, ch(e)root.... Any more unix connections to smoking? Well, I don't have any more smoking connections but since we're so off topic, an old Laugh-In gag always pops into my head when I'm thinking about networking. It make be a communications endpoint to you but it's a socket to me. Jon From sauer at technologists.com Sun Feb 25 10:03:23 2018 From: sauer at technologists.com (Charles H Sauer) Date: Sat, 24 Feb 2018 18:03:23 -0600 Subject: [TUHS] RIP Claude Shannon In-Reply-To: References: Message-ID: In the early 70s I became aware of Shannon, the Nyquist Theorem, and digital audio, and naively started collecting TTL parts to try to build my own music computer (I still have bags of those parts in the garage...). >From http://www.indiana.edu/~emusic/etext/digital_audio/chapter5_digital.shtml: "Twenty years later, Claude Shannon, mathematician and early computer scientist, also working at Bells Labs and then M.I.T., developed a proof for the Nyquist theory (thereby making it a theorem)*. The importance of their work to information theory, computing, networks and digital audio cannot be understated." CHS -----Original Message----- From: Dave Horsfall Sent: Friday, February 23, 2018 3:44 PM To: The Eunuchs Hysterical Society Subject: [TUHS] RIP Claude Shannon We lost Claude Shannon on this day in 2001. He was a mathematician, electrical engineer, and cryptographer; he is regarded as the "father" of information theory, and he pioneered digital circuit design. Amongst other things he built a barbed-wire telegraph, the "Ultimate Machine" (it reached up and switched itself off), a Roman numeral computer ("THROBAC"), the Minivac 601 (a digital trainer), a Rubik's Cube solver, a mechanical mouse that learned how to solve mazes, and outlined a chess program (pre-Belle). He formulated the security mantra "The enemy knows the system", and did top-secret work in WW-2 on crypto and fire-control systems. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From beebe at math.utah.edu Sun Feb 25 09:46:02 2018 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Sat, 24 Feb 2018 16:46:02 -0700 Subject: [TUHS] EOF on pipes? In-Reply-To: <20180224234257.E2F0C156E812@mail.bitblocks.com> Message-ID: >> pipe, ch(e)root.... Any more unix connections to smoking? How about ash, one of the Bourne-family shells? ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From norman at oclsc.org Sun Feb 25 10:53:13 2018 From: norman at oclsc.org (Norman Wilson) Date: Sat, 24 Feb 2018 19:53:13 -0500 Subject: [TUHS] EOF on pipes? Message-ID: <1519519996.29346.for-standards-violators@oclsc.org> Many years ago (when the dinosaurs were using V6), I had a crazy idea[*] that a write(fd, 0, NULL) would somehow signal EOF to the reader i.e. a subsequent read would wait for further data instead of ENOTOBACCO. Did any *nix ever implement that? I have no idea how it would be done. Have an ENOGORILLA. To answer the real question: stream pipes, which became the only sort of pipe in the Research stream (sic) sometime between the 8/e and 9/e manuals. The implementation was trivial, because from the beginning the metadata within a stream admitted delimiters: markers that meant `when this object reaches read(2) at the head end, return from read with whatever has already been delivered.' Empty messages (two consecutive delimiters) were explicitly allowed. If a stream was marked as using delimeters (and pipes always were), a delimeter was inserted after every write(2). So write(2) generated an empty message, and read(2) returned it. Norman Wilson Toronto ON From mike.ab3ap at gmail.com Sun Feb 25 22:44:30 2018 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Sun, 25 Feb 2018 07:44:30 -0500 Subject: [TUHS] RIP Claude Shannon In-Reply-To: References: Message-ID: <7f98ae64-1d08-8fe8-579c-02de4ee19748@gmail.com> Maybe more accurate, "cannot be *overstated*"? :-) - Mike Markowski On 02/24/2018 07:03 PM, Charles H Sauer wrote: > In the early 70s I became aware of Shannon, the Nyquist Theorem, and > digital audio, and naively started collecting TTL parts to try to build > my own music computer (I still have bags of those parts in the garage...). > > From > http://www.indiana.edu/~emusic/etext/digital_audio/chapter5_digital.shtml: > "Twenty years later, Claude Shannon, mathematician and early computer > scientist, also working at Bells Labs and then M.I.T., developed a proof > for the Nyquist theory (thereby making it a theorem)*. The importance of > their work to information theory, computing, networks and digital audio > cannot be understated." > > CHS > > -----Original Message----- From: Dave Horsfall > Sent: Friday, February 23, 2018 3:44 PM > To: The Eunuchs Hysterical Society > Subject: [TUHS] RIP Claude Shannon > > We lost Claude Shannon on this day in 2001.  He was a mathematician, > electrical engineer, and cryptographer; he is regarded as the "father" of > information theory, and he pioneered digital circuit design.  Amongst > other things he built a barbed-wire telegraph, the "Ultimate Machine" (it > reached up and switched itself off), a Roman numeral computer ("THROBAC"), > the Minivac 601 (a digital trainer), a Rubik's Cube solver, a mechanical > mouse that learned how to solve mazes, and outlined a chess program > (pre-Belle).  He formulated the security mantra "The enemy knows the > system", and did top-secret work in WW-2 on crypto and fire-control > systems. > From doug at cs.dartmouth.edu Sun Feb 25 23:07:10 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 25 Feb 2018 08:07:10 -0500 Subject: [TUHS] EOF on pipes? Message-ID: <201802251307.w1PD7AVI013492@coolidge.cs.Dartmouth.EDU> >> pipe, ch(e)root.... Any more unix connections to smoking? I have a slide that's a quadralingual pun (French, English, Art, shell) in which Magritte's painting of a pipe with the words "Ceci n'est pas une pipe" has been altered to read "Ceci n'est pas une |". The altered phrase was borrowed from Jay Misra et al, who used it as an example of a message in a paper on communicating processes. From doug at cs.dartmouth.edu Sun Feb 25 23:16:36 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 25 Feb 2018 08:16:36 -0500 Subject: [TUHS] RIP Claude Shannon Message-ID: <201802251316.w1PDGaZV013631@coolidge.cs.Dartmouth.EDU> > But a note on Dijkstra's algorithm: Moore and Dijsktra both published > in 1959. I was off by one on the year, but the sign of the error is debatable. Moore's paper was presented in a conference held in early April, 1957, proceedings from which were not issued until 1959. I learned about it from Moore when I first I met him, in 1958. Then, he described the algorithm in vivid, instantly understandable terms: imagine a flood spreading at uniform speed through the network and record the distance to nodes in order of wetting. > But it is documented Dijkstra's algorithm has been invented and used > by him in 1956. Taking into account the lead time for conference submissions, one can confidently say that Moore devised the algorithm before 1957. I do not know, though, when it first ran on a Bell Labs computer. That said, Moore's paper, which presented the algorithm essentially by example, was not nearly as clear as the capsule summary he gave me. It seems amateurish by comparison with Dijkstra's elegant treatment. Dijkstra's name has been attached to the method with good reason. Doug From ggm at algebras.org Sun Feb 25 23:16:58 2018 From: ggm at algebras.org (George Michaelson) Date: Sun, 25 Feb 2018 13:16:58 +0000 Subject: [TUHS] EOF on pipes? In-Reply-To: <201802251307.w1PD7AVI013492@coolidge.cs.Dartmouth.EDU> References: <201802251307.w1PD7AVI013492@coolidge.cs.Dartmouth.EDU> Message-ID: I often wondered about the circumstance which led to | because it felt like the oddest pipe in the world to me. Its zero pipe units long, its just an entry and an exit, bolted together. I thought = would have been much better. I guess there was a good reason that wouldn't fly. But then I learned there was some clumsy pre-ur-pipe notations which bolted what > and < do together somehow. I guess if you were there, it made perfect sense. Confusing as well that | and || both have to co-exist in the shell, one for IO redirection and process chaining, and one for expression short circuit operation. So, clearly a lexer is in the mix, which means maybe == could have worked. Thats a pipe! I also had long beer filled arguments about how if | was a process, not just IO bolting, it could be instrumented. Somebody said I should do that in tee and I did play with that a bit, putting a box on tee to say what flowed through the pipe. So, maybe the pipe symbol | could have been modified to be T and then you had a side flow to monitor on. Designing things is hard. I guess the reality is, you do the bare minimum neccessary to make it work. Anything else is adding cost. (I hesitate to say <- and -> might have worked too. few pipes are bi-directional. Also, the = is being used in ls -lF to denote what things are non-normal files...) G On Sun, Feb 25, 2018 at 1:07 PM, Doug McIlroy wrote: >>> pipe, ch(e)root.... Any more unix connections to smoking? > > I have a slide that's a quadralingual pun (French, English, Art, shell) > in which Magritte's painting of a pipe with the words "Ceci n'est pas > une pipe" has been altered to read "Ceci n'est pas une |". The > altered phrase was borrowed from Jay Misra et al, who used it as > an example of a message in a paper on communicating processes. > From arnold at skeeve.com Sun Feb 25 23:56:08 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 25 Feb 2018 06:56:08 -0700 Subject: [TUHS] EOF on pipes? In-Reply-To: References: <201802251307.w1PD7AVI013492@coolidge.cs.Dartmouth.EDU> Message-ID: <201802251356.w1PDu8jJ028334@freefriends.org> George Michaelson wrote: > Designing things is hard. I guess the reality is, you do the bare > minimum neccessary to make it work. Anything else is adding cost. Amen! > (I hesitate to say <- and -> might have worked too. few pipes are > bi-directional. Also, the = is being used in ls -lF to denote what > things are non-normal files...) The = as part of the -F option originates from BSD. It was in 4.2 for sure (circa 1983); I don't know if it appeared any earlier. But this is close to 10 years after | was invented for pipes. Arnold From otto at drijf.net Sun Feb 25 23:59:27 2018 From: otto at drijf.net (Otto Moerbeek) Date: Sun, 25 Feb 2018 14:59:27 +0100 Subject: [TUHS] RIP Claude Shannon In-Reply-To: <201802251316.w1PDGaZV013631@coolidge.cs.Dartmouth.EDU> References: <201802251316.w1PDGaZV013631@coolidge.cs.Dartmouth.EDU> Message-ID: <20180225135927.GF25319@clue.drijf.net> On Sun, Feb 25, 2018 at 08:16:36AM -0500, Doug McIlroy wrote: > > But a note on Dijkstra's algorithm: Moore and Dijsktra both published > > in 1959. > > I was off by one on the year, but the sign of the error is debatable. > > Moore's paper was presented in a conference held in early April, 1957, > proceedings from which were not issued until 1959. I learned about it > from Moore when I first I met him, in 1958. Then, he described the > algorithm in vivid, instantly understandable terms: imagine a flood > spreading at uniform speed through the network and record the > distance to nodes in order of wetting. > > > But it is documented Dijkstra's algorithm has been invented and used > > by him in 1956. > > Taking into account the lead time for conference submissions, one > can confidently say that Moore devised the algorithm before 1957. > I do not know, though, when it first ran on a Bell Labs computer. > > That said, Moore's paper, which presented the algorithm essentially > by example, was not nearly as clear as the capsule summary he gave > me. It seems amateurish by comparison with Dijkstra's elegant treatment. > Dijkstra's name has been attached to the method with good reason. > > Doug On the subject of independent (re)discovery, it is interesting to note that the second problem in Dijkstra's paper describes a solution to the minimum spanning tree problem that was already pubslished in 1957 by Prim and in 1930 by Jarnik. I guess that in those days searching for existing solutions wasn't as easy as it is now. -Otto From sauer at technologists.com Mon Feb 26 00:26:57 2018 From: sauer at technologists.com (Charles H Sauer) Date: Sun, 25 Feb 2018 08:26:57 -0600 Subject: [TUHS] RIP Claude Shannon In-Reply-To: <7f98ae64-1d08-8fe8-579c-02de4ee19748@gmail.com> References: <7f98ae64-1d08-8fe8-579c-02de4ee19748@gmail.com> Message-ID: <433353005FDC4DD7B4B0BC8CCC9BAF49@studyvista> Of course -- wonder how many people have read that as intended vs. what it says. -----Original Message----- From: Mike Markowski Sent: Sunday, February 25, 2018 6:44 AM To: tuhs at minnie.tuhs.org Subject: Re: [TUHS] RIP Claude Shannon Maybe more accurate, "cannot be *overstated*"? :-) - Mike Markowski On 02/24/2018 07:03 PM, Charles H Sauer wrote: > In the early 70s I became aware of Shannon, the Nyquist Theorem, and > digital audio, and naively started collecting TTL parts to try to build my > own music computer (I still have bags of those parts in the garage...). > > From > http://www.indiana.edu/~emusic/etext/digital_audio/chapter5_digital.shtml: > "Twenty years later, Claude Shannon, mathematician and early computer > scientist, also working at Bells Labs and then M.I.T., developed a proof > for the Nyquist theory (thereby making it a theorem)*. The importance of > their work to information theory, computing, networks and digital audio > cannot be understated." > > CHS > > -----Original Message----- From: Dave Horsfall > Sent: Friday, February 23, 2018 3:44 PM > To: The Eunuchs Hysterical Society > Subject: [TUHS] RIP Claude Shannon > > We lost Claude Shannon on this day in 2001. He was a mathematician, > electrical engineer, and cryptographer; he is regarded as the "father" of > information theory, and he pioneered digital circuit design. Amongst > other things he built a barbed-wire telegraph, the "Ultimate Machine" (it > reached up and switched itself off), a Roman numeral computer ("THROBAC"), > the Minivac 601 (a digital trainer), a Rubik's Cube solver, a mechanical > mouse that learned how to solve mazes, and outlined a chess program > (pre-Belle). He formulated the security mantra "The enemy knows the > system", and did top-secret work in WW-2 on crypto and fire-control > systems. > From will.senn at gmail.com Mon Feb 26 00:45:33 2018 From: will.senn at gmail.com (Will Senn) Date: Sun, 25 Feb 2018 08:45:33 -0600 Subject: [TUHS] TUHS Digest, Vol 27, Issue 60 In-Reply-To: References: Message-ID: <9E7BF0AE-D5BA-4ABC-8573-D93D34916EF1@gmail.com> Re: RIP Claude Shannon > Never heard of Claude Shannon. So a good opportunity to do some > searching reading to 'catch up'. Shannon did some amazing work. My field is Information science and without Shannon, it would be a dull field indeed. His masters thesis laid out an elegant use of digital logic for switching systems that we take for granted today, his mathematical theory of communication, while dense, is foundational - ever heard of a bit?, and he actually loved juggling so much he created a juggling machine - what’s not to love? :) All that said, he was also in the right place at the right time and was surrounded by genius. Will From paul.winalski at gmail.com Mon Feb 26 02:29:50 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Sun, 25 Feb 2018 11:29:50 -0500 Subject: [TUHS] EOF on pipes? In-Reply-To: <1519519996.29346.for-standards-violators@oclsc.org> References: <1519519996.29346.for-standards-violators@oclsc.org> Message-ID: On 2/24/18, Norman Wilson wrote: > Many years ago (when the dinosaurs were using V6), I had a crazy idea[*] > that a write(fd, 0, NULL) would somehow signal EOF to the reader i.e. a > subsequent read would wait for further data instead of ENOTOBACCO. > > Did any *nix ever implement that? I have no idea how it would be done. > The pipe device driver that I wrote for VMS implemented EOF. Mailboxes (the moral equivalent of pipes in VMS) had a WRITE_EOF I/O command in addition to the usual WRITE. This placed a special record in the mailbox's data stream that caused the driver to return end-of-file when a READ was done instead of simply waiting for further data. My pipe driver had to be fully compatible with mailboxes, so it also had WRITE_EOF. -Paul W. From lyndon at orthanc.ca Mon Feb 26 08:25:51 2018 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sun, 25 Feb 2018 14:25:51 -0800 (PST) Subject: [TUHS] EOF on pipes? In-Reply-To: <1519519996.29346.for-standards-violators@oclsc.org> References: <1519519996.29346.for-standards-violators@oclsc.org> Message-ID: > If a stream was marked as using delimeters (and pipes always > were), a delimeter was inserted after every write(2). So > write(2) generated an empty message, and read(2) returned it. And this lived on in the IL network protocol. I've always thought that was one of the more elegant aspects of IL, but of course it didn't have a hope in hell of surviving outside the Plan 9 ecosystem. --lyndon From bakul at bitblocks.com Mon Feb 26 09:18:59 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Sun, 25 Feb 2018 15:18:59 -0800 Subject: [TUHS] EOF on pipes? In-Reply-To: Your message of "Sun, 25 Feb 2018 14:25:51 -0800." References: <1519519996.29346.for-standards-violators@oclsc.org> Message-ID: <20180225231914.542B1156E812@mail.bitblocks.com> On Sun, 25 Feb 2018 14:25:51 -0800 Lyndon Nerenberg wrote: Lyndon Nerenberg writes: > > If a stream was marked as using delimeters (and pipes always > > were), a delimeter was inserted after every write(2). So > > write(2) generated an empty message, and read(2) returned it. > > And this lived on in the IL network protocol. I've always thought that was > one of the more elegant aspects of IL, but of course it didn't have a hope > in hell of surviving outside the Plan 9 ecosystem. BSD networking has had sequenced packet protocol (SPP) support pretty much from the beginning (probably due to early XNS influence). From socket(2): SOCK_SEQPACKET sockets employ the same system calls as SOCK_STREAM sockets. The only difference is that read(2) calls will return only the amount of data requested, and any remaining in the arriving packet will be discarded. Even today you can do int fd = socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP); Presumably read(fd, ptr, 0) works too. From bakul at bitblocks.com Mon Feb 26 09:31:08 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Sun, 25 Feb 2018 15:31:08 -0800 Subject: [TUHS] RIP Claude Shannon In-Reply-To: Your message of "Sat, 24 Feb 2018 18:03:23 -0600." References: Message-ID: <20180225233123.6C92C156E9AD@mail.bitblocks.com> Mitchell Waldrop's "The Dream Machine: J. C. R. Licklider and the Revolution That Made Computing Personal" book has probably been discussed on this list in the past. It has pages full of fascinating stuff about Claude Shannon & his work. For instance: "A Symbolic Analysis of Relay and Switching Circuits" has just the kind of cerebral exuberance you'd expect from a very bright twenty-one-year-old. Shannon's thesis is downright fun to read--and strangely compelling, given what's happened in the six decades since it was written. ... That ability, in turn, is ultimately what makes a modern digital computer so much more than just an adding machine: it can work its way through a sequence of such decisions automatically. In a word, it can be programmed. And that's why "A Symbolic Analysis of Relay and Switching Circuits" is arguably the most influential master's thesis of the twentieth century: in it Claude Shannon laid the theoretical foundation for all of modern computer design ... Legend has it that Claude Shannon published "A Mathematical Theory of Communication" in 1948 only because his boss at Bell Labs finally badgered him into it. And whatever the truth of that story, the point is that no one who knew Shannon has any trouble believing it. "He wrote beautiful papers--when he wrote," says Robert Fano, who became a leader of MIT's information-theory group in the 1950s and still has a reverential photograph of Shannon hanging in his office. "And he gave beautiful talks- when he gave a talk. But he hated to do it." It wasn't a matter of Shannon's being lazy, Fano says; he was constantly filling up notebooks with ideas, theorems, and calculations. He just wouldn't publish--or not very often, anyway. No, Shannon's reticence seems to have been more a matter of extraordinary self-sufficiency. and much more. A book well worth reading. From gtaylor at tnetconsulting.net Mon Feb 26 12:39:02 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sun, 25 Feb 2018 19:39:02 -0700 Subject: [TUHS] EOF on pipes? In-Reply-To: References: <1519519996.29346.for-standards-violators@oclsc.org> Message-ID: <4d9279f8-e920-0f7a-ebac-1115d6fd68e2@spamtrap.tnetconsulting.net> On 02/25/2018 03:25 PM, Lyndon Nerenberg wrote: > And this lived on in the IL network protocol. I've always thought that > was one of the more elegant aspects of IL, but of course it didn't have > a hope in hell of surviving outside the Plan 9 ecosystem. "IL network protocol"? I've never heard of it. …Quick web search ~> Wikipedia… Interesting. #LearnSomethingEveryDay I really should mess with Plan9 one of these days. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From rudi.j.blom at gmail.com Tue Feb 27 02:03:55 2018 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Mon, 26 Feb 2018 23:03:55 +0700 Subject: [TUHS] EOF on pipes? Message-ID: >From a piece of code I have in some SCO UNIX 3.2V4.2 source. SCO doesn't have pipes, but you can simulate them. int fd[2] int rc; struct strfdinsert ins; queue_t *pointer = (queue_t *)NULL; rc = -1; /* * First open the stream clone device "/dev/spx" twice, * obtaining the two file descriptors. */ if ( (fd[0] = open(SPX_DEVICE, O_RDWR)) < 0) { gen_trace(gtr_flag, "-gen_pipe(): -open(fd[0]): %s\n", strerror(errno)); break; } if ( (fd[1] = open(SPX_DEVICE, O_RDWR)) < 0) { gen_trace(gtr_flag, ">gen_pipe(): -open(fd[1]): %s\n", strerror(errno)); close(fd[0]); break; } /* * Now link these two streams together with an * I_FDINSERT ioctl. */ ins.ctlbuf.buf = (char *) &pointer; /* no ctl info, just the ptr */ ins.ctlbuf.maxlen = sizeof(queue_t *); ins.ctlbuf.len = sizeof(queue_t *); ins.databuf.buf = (char *) 0; /* no data to send */ ins.databuf.len = -1; /* magic: must be -1, not 0, for stream pipe */ ins.databuf.maxlen = 0; ins.fildes = fd[1]; /* the fd to connect with fd[0] */ ins.flags = 0; /* nonpriority message */ ins.offset = 0; /* offset of pointer in control buffer */ if (ioctl(fd[0], I_FDINSERT, (char * ) &ins) < 0) { gen_trace(gtr_flag, ">gen_pipe(): -ioctl(I_FDINSERT): %s\n", strerror(errno)); close(fd[0]); close(fd[1]); break; } From itz at very.loosely.org Tue Feb 27 02:58:02 2018 From: itz at very.loosely.org (Ian Zimmerman) Date: Mon, 26 Feb 2018 08:58:02 -0800 Subject: [TUHS] EOF on pipes? In-Reply-To: References: Message-ID: <20180226165802.sz5eklp6lfamzv2m@matica.foolinux.mooo.com> On 2018-02-26 23:03, Rudi Blom wrote: > From a piece of code I have in some SCO UNIX 3.2V4.2 source. SCO > doesn't have pipes, but you can simulate them. Is this a SCO speciality, or are there other UNIXes like that? Does it not even have pipe() in its libc? -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com. From ron at ronnatalie.com Tue Feb 27 03:14:48 2018 From: ron at ronnatalie.com (Ron Natalie) Date: Mon, 26 Feb 2018 12:14:48 -0500 Subject: [TUHS] Unix without pipes Message-ID: <005901d3af25$4e9ba3f0$ebd2ebd0$@ronnatalie.com> If I'm remembering correctly, miniunix didn't have pipes. The shell faked it by taking the output of the first program into a file and then using it as the input for the second. Didn't really multitask anyhow, so it was pretty much fine. -----Original Message----- From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Ian Zimmerman Sent: Monday, February 26, 2018 11:58 AM To: tuhs at minnie.tuhs.org Subject: Re: [TUHS] EOF on pipes? On 2018-02-26 23:03, Rudi Blom wrote: > From a piece of code I have in some SCO UNIX 3.2V4.2 source. SCO > doesn't have pipes, but you can simulate them. Is this a SCO speciality, or are there other UNIXes like that? Does it not even have pipe() in its libc? From lm at mcvoy.com Tue Feb 27 03:19:17 2018 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 26 Feb 2018 09:19:17 -0800 Subject: [TUHS] EOF on pipes? In-Reply-To: <20180226165802.sz5eklp6lfamzv2m@matica.foolinux.mooo.com> References: <20180226165802.sz5eklp6lfamzv2m@matica.foolinux.mooo.com> Message-ID: <20180226171917.GL16114@mcvoy.com> What?!?! I put networking in some version of SCO, it most certainly did have pipes. Maybe they were faked in the shell but I tend to think I would have noticed that, I did all sorts of pipelines on that project. So are you _sure_ the kernel doesn't implement pipes? SCO would have to have taken them out, v7 has usr/sys/sys/pipe.c On Mon, Feb 26, 2018 at 08:58:02AM -0800, Ian Zimmerman wrote: > On 2018-02-26 23:03, Rudi Blom wrote: > > > From a piece of code I have in some SCO UNIX 3.2V4.2 source. SCO > > doesn't have pipes, but you can simulate them. > > Is this a SCO speciality, or are there other UNIXes like that? > > Does it not even have pipe() in its libc? > > -- > Please don't Cc: me privately on mailing lists and Usenet, > if you also post the followup to the list or newsgroup. > To reply privately _only_ on Usenet and on broken lists > which rewrite From, fetch the TXT record for no-use.mooo.com. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From doug at cs.dartmouth.edu Tue Feb 27 06:47:46 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 26 Feb 2018 15:47:46 -0500 Subject: [TUHS] RIP Claude Shannon Message-ID: <201802262047.w1QKlkk1025992@coolidge.cs.Dartmouth.EDU> > [Bob Fano} still has a reverential photograph of Shannpn > hanging in his office. Alas, no, Fano died in 2016 at age 98. More memories: Fano was among the grad students who came to ice-skating parties at our house in the mid-40s--the house near Shannon's later abode. I did not really get to know him until Multics days. His gravelly mafioso voice would scare you off--until you saw the irrepressible twinkle in his eye. A beloved and inspiring leader, worthy of Dave Horsfall's calendar. Doug From dave at horsfall.org Tue Feb 27 07:16:51 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 27 Feb 2018 08:16:51 +1100 (EST) Subject: [TUHS] RIP Claude Shannon In-Reply-To: <201802262047.w1QKlkk1025992@coolidge.cs.Dartmouth.EDU> References: <201802262047.w1QKlkk1025992@coolidge.cs.Dartmouth.EDU> Message-ID: On Mon, 26 Feb 2018, Doug McIlroy wrote: > More memories: Fano was among the grad students who came to ice-skating > parties at our house in the mid-40s--the house near Shannon's later > abode. I did not really get to know him until Multics days. His gravelly > mafioso voice would scare you off--until you saw the irrepressible > twinkle in his eye. A beloved and inspiring leader, worthy of Dave > Horsfall's calendar. Noted; thank you! More additions are welcome, of course. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From rudi.j.blom at gmail.com Tue Feb 27 15:04:46 2018 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Tue, 27 Feb 2018 12:04:46 +0700 Subject: [TUHS] EOF on pipes? Message-ID: pipes in SCO UNIX 3.2V4.2, It's long, long ago, so excuses for vagueness. I think the issue was not pipe() perse, but the difference in functionality between 'pipe filesystem' and streams pipes. By using pipe() you create a FIFO pipe with certain limitations (including 5120 write limit). When you open the streams device twice and ioctl() two file descriptors together you have more flexibility. Excuses for the possible confusion. From dave at horsfall.org Tue Feb 27 15:17:22 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 27 Feb 2018 16:17:22 +1100 (EST) Subject: [TUHS] You can buy an Ultimate Machine... Message-ID: Following the Claude Shannon discussion: http://www.jaycar.com.au/useless-box/p/GT3706 I tried to explain to the Young Thing (tm) behind the shop counter that it was invented several decades ago etc, but I suspect it was beyond her ken... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Tue Feb 27 15:48:38 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 27 Feb 2018 16:48:38 +1100 (EST) Subject: [TUHS] EOF on pipes? In-Reply-To: References: Message-ID: On Tue, 27 Feb 2018, Rudi Blom wrote: > By using pipe() you create a FIFO pipe with certain limitations > (including 5120 write limit). When you open the streams device twice and > ioctl() two file descriptors together you have more flexibility. There's always been a limit on the write until the reader got around to it; that's why you had to take care to avoid deadlocks. Heck, I fell into a deadlock the other day with Perl; I thought that "say <$reader_pipe>" (to echo whatever was read) as a neat shortcut would work... It deadlocked, because "<>" was evaluated in list context (because of "say") and hence waited for the EOF that would never arrive so that I could close the writer end. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."