From wobblygong at gmail.com Mon Jun 1 11:16:56 2020 From: wobblygong at gmail.com (Wesley Parish) Date: Mon, 1 Jun 2020 13:16:56 +1200 Subject: [COFF] X Windows use in Nutek Mac clone Message-ID: Hi I'm wondering if anybody knows what happened with this? (Besides the fact it crashed and burnt. I mean, where are the source trees?) lowendmac.com/2016/nutek-mac-clones/ It was a Macintosh clone that reverse-engineered the Mac interface and appearance, using the X Window System as the GUI library - what in Macs of that era was locked into the Mac system BIOS. As such, it's an interesting use of the X Window System. Wesley Parish From robert at timetraveller.org Mon Jun 1 16:01:15 2020 From: robert at timetraveller.org (Robert Brockway) Date: Mon, 1 Jun 2020 16:01:15 +1000 (AEST) Subject: [COFF] X Windows use in Nutek Mac clone In-Reply-To: References: Message-ID: On Mon, 1 Jun 2020, Wesley Parish wrote: > It was a Macintosh clone that reverse-engineered the Mac interface and > appearance, using the X Window System as the GUI library - what in > Macs of that era was locked into the Mac system BIOS. I hadn't heard of this before. I wonder if it used the mlvwm (Mac-like Virtual Window Manager). Around 1995 a friend of mine installed Linux on a Sun box and ran the mlvwm just to confuse people. Our Unix user group did a few demos and we'd bring it along. https://opensource.com/article/19/12/linux-mlvwm-desktop Rob From clemc at ccc.com Mon Jun 8 05:36:51 2020 From: clemc at ccc.com (Clem Cole) Date: Sun, 7 Jun 2020 15:36:51 -0400 Subject: [COFF] was [TUHS] - History of popularity of C Message-ID: Moving to COFF where this discussion really belongs ... On Sun, Jun 7, 2020 at 2:51 PM Nemo Nusquam wrote: > On 06/07/20 11:26, Clem Cole wrote (in part): > > Neither language is used for anything in production in our world at this > point. > > They seem to be used in some worlds: https://blog.golang.org/10years and > https://www.rust-lang.org/production Nemo, That was probably not my clearest wording. I did not mean to imply either Go or Rust was not being used by any imagination. My point was that in SW development environments that I reside (HPC, some startups here in New England and the Bay Area, as well as Intel in general) -- Go and Rust both have smaller use cases compared to C and C++ (much less Python and Java for that matter). And I know of really no 'money' project that relies yet on either. That does not mean I know of no one using either; as I know of projects using both (including a couple of my own), but no one that had done anything production or deployed 'mission-critical' SW with one or the other. Nor does that mean it has not happened, it just means I have not seen been exposed. I also am saying that in my own personal opinion, I expect it too, in particular in Go in userspace code - possibly having a chance to push out Java and hopefully pushing out C++ a bit. My response was to an earlier comment about C's popularity WRT to C++. I answered with my experience and I widened it to suggest that maybe C++ was not the guaranteed incumbent as the winner for production. What I did not say then, but I alluded too was the particularly since nothing in nearly 70 years has displaced Fortran, which >>is<< still the #1 language for production codes (as you saw with the Archer statistics I pointed out). Reality time ... Intel, IBM, *et al,* spend a lot of money making sure that there are >>production quality<< Fortran compilers easily available. Today's modern society is from Weather prediction to energy, to param, chemistry, and physics. As I have here and in other places, over my career, Fortran has paid me and my peeps salary. It is the production enabler and without a solid answer to having a Fortran solution, you are unlikely to make too much progress, certainly in the HPC space. Let me take this in a slightly different direction. I tend to use the 'follow the money' as a way to root out what people care about. Where firms spend money to create or purchase tools to help their staff? The answer is in tools that give them return that they can measure. So using that rule: What programming languages have the largest ecosystems for tools that help find performance and operation issues? Fortran, C, C++ have the largest that I know. My guess would be Java and maybe JavaScript/PHP would be next, but I don't know of any. If I look at Intel, were do we spend money on the development tools: C/C++ and Fortran (which all use a common backend) are #1. Then we invest in other versions of the same (GCC/LLVM) for particularly things we care about. After that, it's Python and used to be Java and maybe some JavaScript. Why? because ensuring that those ecosystems are solid on devices that we make is good for us, even it means we help some of our competitors' devices also. But our investment helps us and Fortran, C/C++ is where people use our devices (and our most profitable versions in particular), so it's our own best interest to make sure there are tools to bring out the best. BTW: I might suggest you take a peek at where other firms do the same thing, and I think you'll find the follow the money rule is helpful to understand what people care the most about. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Mon Jun 8 09:14:34 2020 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 8 Jun 2020 09:14:34 +1000 Subject: [COFF] Comparative languages In-Reply-To: <202006072256.057Muo1h090326@elf.torek.net> References: <202006072256.057Muo1h090326@elf.torek.net> Message-ID: <20200607231434.GA13571@minnie.tuhs.org> All, as the discussion on C has moved on to other languages, we might move the followups to COFF. Thanks, Warren From crossd at gmail.com Mon Jun 8 22:47:03 2020 From: crossd at gmail.com (Dan Cross) Date: Mon, 8 Jun 2020 08:47:03 -0400 Subject: [COFF] [TUHS] History of popularity of C In-Reply-To: References: <202006072256.057Muo1h090326@elf.torek.net> Message-ID: [-TUHS, +COFF as per wkt's request] On Sun, Jun 7, 2020 at 8:26 PM Bram Wyllie wrote: > Dependent types aren't needed for sum types though, which is what you'd > normally use for an array that carries its size, correct? > No, I don't think so. I've never heard of the dimensionality of an array in such a context described in terms of a sum type, but have often heard of it described in terms of a dependent type. However, I'm no type theorist. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Mon Jun 8 22:51:57 2020 From: crossd at gmail.com (Dan Cross) Date: Mon, 8 Jun 2020 08:51:57 -0400 Subject: [COFF] [TUHS] History of popularity of C In-Reply-To: <7w4krmw1kc.fsf@junk.nocrew.org> References: <202006072115.057LFV6v089953@elf.torek.net> <7w4krmw1kc.fsf@junk.nocrew.org> Message-ID: [ -TUHS and +COFF ] On Mon, Jun 8, 2020 at 1:49 AM Lars Brinkhoff wrote: > Chris Torek wrote: > > You pay (sometimes noticeably) for the GC, but the price is not > > too bad in less time-critical situations. The GC has a few short > > stop-the-world points but since Go 1.6 or so, it's pretty smooth, > > unlike what I remember from 1980s Lisp systems. :-) > > I'm guessing those 1980s Lisp systems would also be pretty smooth on > 2020s hardware. > I worked on a big system written in Common Lisp at one point, and it used a pretty standard Lispy garbage collector. It spent something like 15% of its time in GC. It was sufficiently bad that we forced a full GC between every query. The Go garbage collector, on the other hand, is really neat. I believe it reserves something like 25% of available CPU time for itself, but it runs concurrently with your program: having to stop the world for GC is very, very rare in Go programs and even when you have to do it, the concurrent code (which, by the way, can make use of full physical parallelism on multicore systems) has already done much of the heavy lifting, meaning you spend less time in a GC pause. It's a very impressive piece of engineering. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From akosela at andykosela.com Tue Jun 9 00:14:01 2020 From: akosela at andykosela.com (Andy Kosela) Date: Mon, 8 Jun 2020 16:14:01 +0200 Subject: [COFF] [TUHS] History of popularity of C In-Reply-To: References: <202006072115.057LFV6v089953@elf.torek.net> <7w4krmw1kc.fsf@junk.nocrew.org> Message-ID: On 6/8/20, Dan Cross wrote: > [ -TUHS and +COFF ] > > On Mon, Jun 8, 2020 at 1:49 AM Lars Brinkhoff wrote: > >> Chris Torek wrote: >> > You pay (sometimes noticeably) for the GC, but the price is not >> > too bad in less time-critical situations. The GC has a few short >> > stop-the-world points but since Go 1.6 or so, it's pretty smooth, >> > unlike what I remember from 1980s Lisp systems. :-) >> >> I'm guessing those 1980s Lisp systems would also be pretty smooth on >> 2020s hardware. >> > > I worked on a big system written in Common Lisp at one point, and it used a > pretty standard Lispy garbage collector. It spent something like 15% of its > time in GC. It was sufficiently bad that we forced a full GC between every > query. > > The Go garbage collector, on the other hand, is really neat. I believe it > reserves something like 25% of available CPU time for itself, but it runs > concurrently with your program: having to stop the world for GC is very, > very rare in Go programs and even when you have to do it, the concurrent > code (which, by the way, can make use of full physical parallelism on > multicore systems) has already done much of the heavy lifting, meaning you > spend less time in a GC pause. It's a very impressive piece of engineering. > The real question is can Go be really faster than C/C++? The last time I checked it was at least two times slower on an average. Plus it will not run on older systems; I think you need at least kernel 2.6.23 and its executables are rather big compared to C. In the beginning it was fun to create some clones of classic Unix tools in Go, but in reality they were still slower and bigger than the original utilities. I jumped on the Go bandwagon in 2010 (like a lot of people from the open source community) but recently I find myself coming back more and more to C. It is still a superior language in almost all areas. Plus it works on everything from retro 8-bit micros to modern big HPC systems. --Andy From crossd at gmail.com Tue Jun 9 01:22:59 2020 From: crossd at gmail.com (Dan Cross) Date: Mon, 8 Jun 2020 11:22:59 -0400 Subject: [COFF] [TUHS] History of popularity of C In-Reply-To: References: <202006072115.057LFV6v089953@elf.torek.net> <7w4krmw1kc.fsf@junk.nocrew.org> Message-ID: On Mon, Jun 8, 2020 at 10:14 AM Andy Kosela wrote: > On 6/8/20, Dan Cross wrote: > > [snip] > The real question is can Go be really faster than C/C++? The last > time I checked it was at least two times slower on an average. This is an unanswerable question, because it lacks enough detail to really answer the question honestly: what does it mean to be "faster"? It really depends on the problem being solved. If I'm writing straight-line matrix multiplication code on statically-allocated structures, I see little reason why Go would be inherently slower than C, other than that the compiler perhaps isn't as advanced. If my program is a systems-y sort of thing that's frequently blocked on IO anyway, then e.g. GC overhead may not matter at all. If my program is highly concurrent, then perhaps I can bring some of the concurrency primitives baked into Go to bear and the result may be closer to correct than a comparable C program which lacks things like channels as synchronization primitives and light-weight threads a la goroutines. Putting that last point another way, more expressive abstractions allow me to develop a correct solution faster. As an example of this, for my current project at work, I build a custom board that lets me control the power and reset circuitry on ATX motherboards; think of it as a remote-controlled solid-state switch in parallel with the motherboard power and reset switches. Each board can control up to 8 other computers. The control interface to that board is a USB<->UART bridge; USB also provides power. Since I'm controlling multiple other machines, possibly in parallel, I wrote an interface daemon that talks to the firmware on the board itself but presents a high-level abstraction ("reboot the host named 'foo'"). I wrote it in Go; a single go-routine owns the serial device and accepts commands corresponding to each system on a channel; controlling each system itself is a goroutine. The whole things speaks a simple JSON-based RPC protocol over a Unix domain socket. It's possible to control any of those 8 machines in parallel. It was only 200 lines of code and worked correctly almost immediately; I was really impressed with how _easy_ it was to write. I dare say a similar program in C would have been much more difficult to write. Further, while GC undoubtedly has overhead, it gives rise to optimization alternatives that aren't available in non-GC languages. For example, instead of atomically incrementing or decrementing a reference count in a tight loop before manipulating some shared data structure, I don't bother in a GC'd language; the offending memory will be automatically reclaimed when it's no longer referenced elsewhere in the program. Here's a really well-written post from 2011 about profiling and optimizing a Go program, and comparing the result to (approximately) the same program written in several other languages: https://blog.golang.org/pprof Plus it will not run on older systems; I think you need at least kernel > 2.6.23 and its executables are rather big compared to C. Now we have to differentiate between what we do for fun and what we do professionally. I don't care about targeting new software I write professionally at old versions of Linux or obsolete hardware platforms. Storage devices are huge, and the size of executables isn't really a concern for the sort of hosted software I write in Go. It may be for some domains, but no one said that Go is for _everything_. In the > beginning it was fun to create some clones of classic Unix tools in > Go, but in reality they were still slower and bigger than the original > utilities. I'm not sure I buy this. Here's an example. I've never liked the `cut` command; I've always thought it contained some really odd corner cases and didn't generally solve some of the problems I had. I've usually been satisfied with using `awk` to do things like pull fields out of lines of text, but in the spirit of laziness that typifies the average Unix programmer, I wanted to type less, so I had a little Perl script that I called "field" that I carted around with me. One could type "field 1" and get the first field out of a line; etc. The default delimiter was whitespace, it could handle leading and trailing blanks, separators could be specified by regular expressions, etc. When the Harvey project got off the ground, one of the first things done was retiring the aged "APE", which meant that awk was gone too and of course there was no Perl, so I rewrote `field` in C: https://github.com/Harvey-OS/harvey/blob/master/sys/src/cmd/field.c It works, but has issues. But I got to rewrite it in Go for the u-root project: https://github.com/u-root/u-root/blob/master/cmds/exp/field/field.go Not only is the Go rewrite a little shorter (-75 lines, or around 12% shorter than the C version), I would argue it's simpler and probably a little faster: instead of rolling my own slices in C, I just use what the language gives me. I jumped on the Go bandwagon in 2010 (like a lot of people from the > open source community) but recently I find myself coming back more and > more to C. It is still a superior language in almost all areas. C is my first love as a programming language, but I really don't think one can say that it's "still a superior language in almost all areas." It's just too hard to get some things right in it, and programmers who think that they can do so are often deluding themselves. Here's an example: unsigned short mul(unsigned short a, unsigned short b) { return a * b; } Is this function well-defined? Actually, no; not for all inputs at least. Why? Consider a 32-bit target environment with 16-bit `short`. Since the type `short` is of lesser rank than `int`, when the multiplication is executed, both 'a' and 'b' will be converted by the "usual arithmetic conversions" to (signed) `int`; if both 'a' and 'b' are, say, 60,0000, then the product will overflow a signed `int`, which is undefined behavior. The solution to this is simple enough, just rewrite it as: unsigned short mul(unsigned short a, unsigned short b) { unsigned int aa = a; unsigned int bb = b; return aa * bb; } But it's shenanigans like this that make using C really dangerous. Thankfully, Go doesn't have these kinds of issues, and the Rust people by and large avoid them as well by mandating explicit type conversions and explicit requests for modular arithmetic for unsigned types. In Rust, this would be: fn mul(a: u16, b: u16) -> u16 { a.wrapping_mul(b) } Plus > it works on everything from retro 8-bit micros to modern big HPC > systems. > That's a fair point, but I would counter that different tools are useful for different things. If I want to target an 8-bit micro, C may be the right tool for the job, but Go almost certainly wouldn't. I'd likely choose Rust instead, if I could, though. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jun 9 01:38:20 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 8 Jun 2020 11:38:20 -0400 Subject: [COFF] [TUHS] History of popularity of C In-Reply-To: References: <202006072115.057LFV6v089953@elf.torek.net> <7w4krmw1kc.fsf@junk.nocrew.org> Message-ID: On Mon, Jun 8, 2020 at 10:14 AM Andy Kosela wrote: > The real question is can Go be really faster than C/C++? > That's really a matter of economics more than architecture. Obviously how to measure it and a ton of things like that will have to be agreed upon. But in the end, it has to have a wide enough use that it started to be a financial driver for 'enough' of the business. If people or important customers start to use it enough, firms like my own will start to say, it's in our best interest to help create a better code generator. As I said, we pay more people to work on LLVM than anyone else at this point and when it finally can handle Fortran as well or better, we have told the world, we will move to that compiler. We got to that point when it was clear, that it was the compiler technology of future and 'enough' customer demand it (BTW: we still have a ton of working to gcc also, but the effort there is much less than when I started at Intel). BTW: Apple ships clang - but guess what product compiler Apple's product teams use for things like Aperture and GarageBand. Intel spends a ton of money making sure icc(1) is the best for them [And again, when clang's C/C++ can match icc - our execs will want to go there in a heartbeat I suspect]. A couple of years ago at an HPC workshop, I was talking to the folks. They all screamed for a parallel language, but was all over the map. Chapel turns to have a small backing (Cray wrote it for a DoD contract), but even the spooks don't use it for production (that all Fortran an C). After a enough digging, we just rolled the dice with DPC++ because the Venn diagram of 'enough' of our HPC customers showed it would be helpful. We shall see (that took some convincing in management to make that investment) and right now, its a parallel effort to C++. As I have said before Cole's law: 'inexpensive economics beats sophisticated architecture.' If Go (or Rust - whatever) starts driving silicon sales for enough folks, you see IBM, Intel et al start getting really excited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cezar.ionescu at conted.ox.ac.uk Mon Jun 8 23:46:32 2020 From: cezar.ionescu at conted.ox.ac.uk (Cezar Ionescu) Date: Mon, 08 Jun 2020 15:46:32 +0200 Subject: [COFF] [TUHS] History of popularity of C In-Reply-To: References: <202006072256.057Muo1h090326@elf.torek.net> Message-ID: <87ftb5hdqf.fsf@virtdeb.speedport.ip> > I've never heard of the dimensionality of an array in such a context > described in terms of a sum type,[...] I was also puzzled by this remark. Perhaps Bram was thinking of an infinite sum type such as Arrays_0 + Arrays_1 + Arrays_2 + ... where "Arrays_n" is the type of arrays of size n. However, I don't see a way of defining this without dependent (or at least indexed) types. > [...] but have often heard of it described in terms of a dependent > type. I think that's right, yes. We want the type checker to decide, at compile time, whether a certain operation on arrays, such as scalar product, or multiplication with a matrix, will respect the types. That means providing the information about the size to the type checker: types need to know about values, hence the need for dependent types. Ideally, a lot of the type information can then be erased at run time, so that we don't need the arrays to carry their sizes around. But the distinction between what can and what cannot be erased at run time is muddled in a dependently-typed programming language. Best wishes, Cezar Dan Cross writes: > [-TUHS, +COFF as per wkt's request] > > On Sun, Jun 7, 2020 at 8:26 PM Bram Wyllie wrote: > >> Dependent types aren't needed for sum types though, which is what you'd >> normally use for an array that carries its size, correct? >> > > No, I don't think so. I've never heard of the dimensionality of an array in > such a context described in terms of a sum type, but have often heard of it > described in terms of a dependent type. However, I'm no type theorist. > > - Dan C. > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff From dave at horsfall.org Sat Jun 13 14:14:55 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 13 Jun 2020 14:14:55 +1000 (EST) Subject: [COFF] Mercury delay lines Message-ID: ABC-TV "Grantchester" (a detective-priest series[*]) featured someone who died from mercury poisoning, when someone opened the tanks. Apart from the beautiful Teletype in the foreground, there was a machine with lots of dials in the background; obviously some early computer, but not enough footage for me to tell which one, but is a British show if that helps. [*] I suppose that I need not remind any Monty Python freaks of these lines: "There's another dead bishop on the landing, Vicar-Sergeant!" "Err, Detective-Parsons, Madam." Etc... Otherwise I'd go on all day :-) -- Dave From ats at offog.org Sat Jun 13 23:55:00 2020 From: ats at offog.org (Adam Sampson) Date: Sat, 13 Jun 2020 14:55:00 +0100 Subject: [COFF] Mercury delay lines In-Reply-To: (Dave Horsfall's message of "Sat, 13 Jun 2020 14:14:55 +1000 (EST)") References: Message-ID: Dave Horsfall writes: > Apart from the beautiful Teletype in the foreground, there was a > machine with lots of dials in the background; obviously some early > computer, but not enough footage for me to tell which one, There are some shots in this trailer: https://www.youtube.com/watch?v=_JQmO2fC00E The racks are mockups (there's a nice National HRO radio in the middle of one!), but I think what they're trying to represent is the EDSAC computer at Cambridge; the noughts and crosses game pictured ran on EDSAC. -- Adam Sampson From dot at dotat.at Tue Jun 16 02:38:18 2020 From: dot at dotat.at (Tony Finch) Date: Mon, 15 Jun 2020 17:38:18 +0100 Subject: [COFF] Mercury delay lines In-Reply-To: References: Message-ID: Adam Sampson wrote: > Dave Horsfall writes: > > > Apart from the beautiful Teletype in the foreground, there was a > > machine with lots of dials in the background; obviously some early > > computer, but not enough footage for me to tell which one, > > There are some shots in this trailer: > https://www.youtube.com/watch?v=_JQmO2fC00E > > The racks are mockups (there's a nice National HRO radio in the middle > of one!), but I think what they're trying to represent is the EDSAC > computer at Cambridge; the noughts and crosses game pictured ran on > EDSAC. A picture of Wilkes with some mercury delay lines and a corner of an EDSAC rack. https://images.computerhistory.org/revonline/images/500004368-03-01.jpg?w=600 There was a lot of loose mercury kicking around on that site. Some of the Victorian lecture theatres I attended as an undergrad were later refurbished for use by another department and the rumours were that they discovered there had been a lot of spillage from old physics demonstrations when they were part of the Cavendish laboratory. More recently (10ish years ago?) my boss was briefly evicted from his office in the Phoenix building after they discovered mercury under the floorboards. The building was not named after the IBM mainframe computer, but because it had been burned down and rebuilt such that the top two storeys looked quite different from the bottom two. Tony. -- f.anthony.n.finch http://dotat.at/ Biscay: West or southwest 4 to 6. Moderate, occasionally slight in north. Thundery showers. Good, occasionally poor. From grog at lemis.com Tue Jun 16 13:21:35 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 16 Jun 2020 13:21:35 +1000 Subject: [COFF] Mercury delay lines In-Reply-To: References: Message-ID: <20200616032135.GD7773@eureka.lemis.com> On Monday, 15 June 2020 at 17:38:18 +0100, Tony Finch wrote: > Adam Sampson wrote: >> Dave Horsfall writes: >> >>> Apart from the beautiful Teletype in the foreground, there was a >>> machine with lots of dials in the background; obviously some early >>> computer, but not enough footage for me to tell which one, >> >> There are some shots in this trailer: >> https://www.youtube.com/watch?v=_JQmO2fC00E >> >> The racks are mockups (there's a nice National HRO radio in the middle >> of one!), but I think what they're trying to represent is the EDSAC >> computer at Cambridge; the noughts and crosses game pictured ran on >> EDSAC. > > A picture of Wilkes with some mercury delay lines and a corner of an EDSAC > rack. > > https://images.computerhistory.org/revonline/images/500004368-03-01.jpg?w=600 That looks very much like the delay lines on CSIRAC, the oldest Australian computer, currently on display at Scienceworks in Melbourne. I have a number of photos of the machine at http://www.lemis.com/grog/photos/Photos.php?dirdate=20040904 , and there's a delay line at http://www.lemis.com/grog/Photos/20040904/big/Delay-line-1.jpeg CSIRAC was built in 1949. If you're in Melbourne, it's well worth looking at. 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 lars at nocrew.org Thu Jun 25 04:46:01 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 24 Jun 2020 18:46:01 +0000 Subject: [COFF] [TUHS] VFS prior to 1984 In-Reply-To: (Richard Salz's message of "Wed, 24 Jun 2020 14:13:20 -0400") References: <20200624175149.7947118C0BC@mercury.lcs.mit.edu> Message-ID: <7wsgek5ml2.fsf@junk.nocrew.org> Redirected to COFF, since this isn't very TUHS related. Richard Salz wrote: > Noel Chiappa wote: >> MLDEV on ITS would, I think, fit under that description. >> I don't know if there's a paper on it; it's mid-70's. I don't think there's anything like an academic paper. The earliest evidence I found for the MLDEV facility, or a predecessor, is from 1972: https://retrocomputing.stackexchange.com/questions/13709/what-are-some-early-network-file-systems > A web search for "its mldev" finds several things (mostly by Lars Brinkhoff > it seems) , including > https://github.com/larsbrinkhoff/mldev/blob/master/doc/mldev.protoc That's just a copy I made. From gtaylor at tnetconsulting.net Mon Jun 29 10:50:27 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sun, 28 Jun 2020 18:50:27 -0600 Subject: [COFF] UUCP on macOS / *BSD Message-ID: Does anyone have any experience with UUCP on macOS or *BSD systems that would be willing to help me figure something out? I'm working on adding a macOS X system to my micro UUCP network and running into some problems. - uuto / uucp copy files from my non-root / non-(_)uucp user to the UUCP spool. But the (demand based) ""call (pipe over SSH) is failing. - running "uucico -r1 -s -f" as the (_)uucp user (via sudo) works. - I'm using the pipe port type and running things over an SSH connection. - The (_)uucp user can ssh to the remote system as expected without any problems or being prompted for a password. (Service specific keys w/ forced command.) I noticed that the following files weren't set UID or GID like they are on Linux. But I don't know if that's a macOS and / or *BSD difference when compared to Linux. /usr/bin/uucp /usr/bin/uuname /usr/bin/uustat /usr/bin/uux /usr/sbin/uucico /usr/sbin/uuxqt Adding the set UID & GID bits allowed things to mostly work. Aside: Getting the contemporary macOS so that I could edit the (/usr/share/uucp/) sys & port files was a treat. I figured that it was worth inquiring if anyone had any more experience / tips / gotchas before I go bending ~> breaking things even more. Thank you. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From lm at mcvoy.com Tue Jun 30 01:37:39 2020 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 29 Jun 2020 08:37:39 -0700 Subject: [COFF] UUCP on macOS / *BSD In-Reply-To: References: Message-ID: <20200629153739.GH16252@mcvoy.com> So UUCP, depending which version, really needed a baby sitter. I think the latest one was sort of reliable but my ancient memory is that you had to unwedge things on a daily basis. On Sun, Jun 28, 2020 at 06:50:27PM -0600, Grant Taylor via COFF wrote: > Does anyone have any experience with UUCP on macOS or *BSD systems that > would be willing to help me figure something out? > > I'm working on adding a macOS X system to my micro UUCP network and running > into some problems. > > - uuto / uucp copy files from my non-root / non-(_)uucp user to the UUCP > spool. But the (demand based) ""call (pipe over SSH) is failing. > - running "uucico -r1 -s -f" as the (_)uucp user (via > sudo) works. > - I'm using the pipe port type and running things over an SSH connection. > - The (_)uucp user can ssh to the remote system as expected without any > problems or being prompted for a password. (Service specific keys w/ forced > command.) > > I noticed that the following files weren't set UID or GID like they are on > Linux. But I don't know if that's a macOS and / or *BSD difference when > compared to Linux. > > /usr/bin/uucp > /usr/bin/uuname > /usr/bin/uustat > /usr/bin/uux > /usr/sbin/uucico > /usr/sbin/uuxqt > > Adding the set UID & GID bits allowed things to mostly work. > > Aside: Getting the contemporary macOS so that I could edit the > (/usr/share/uucp/) sys & port files was a treat. > > I figured that it was worth inquiring if anyone had any more experience / > tips / gotchas before I go bending ~> breaking things even more. > > Thank you. > > > > -- > Grant. . . . > unix || die > > > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From gtaylor at tnetconsulting.net Tue Jun 30 02:13:13 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 29 Jun 2020 10:13:13 -0600 Subject: [COFF] UUCP on macOS / *BSD In-Reply-To: <20200629153739.GH16252@mcvoy.com> References: <20200629153739.GH16252@mcvoy.com> Message-ID: On 6/29/20 9:37 AM, Larry McVoy wrote: > So UUCP, depending which version, really needed a baby sitter. I think > the latest one was sort of reliable but my ancient memory is that you > had to unwedge things on a daily basis. Hum. That's interesting. I'd be curious to know more about that. Thus far, I'm messing with Taylor UUCP 1.x or higher. (No known relation.) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From arrigo at alchemistowl.org Tue Jun 30 01:53:30 2020 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Mon, 29 Jun 2020 17:53:30 +0200 Subject: [COFF] UUCP on macOS / *BSD In-Reply-To: References: Message-ID: <70723375-EF94-4F47-A7D1-54C958F85E9A@alchemistowl.org> On 29 Jun 2020, at 02:50, Grant Taylor via COFF wrote: > Does anyone have any experience with UUCP on macOS or *BSD systems that would be willing to help me figure something out? I run UUCP on OpenBSD for some very remote sites connected with satellite modems (using UUCP-over-IP, not pure UUCP, where the dial-up script initiates the UUCP exchange). UUCP was recently removed from the base OpenBSD distribution but is still available as a package. I honestly cannot see it work on macOS because I cannot even remotely imagine Apple having any interest whatsoever in ensuring that it works with the various changes they made to “standard Unix” (launchd, sandboxing, read-only /, etc.). Are you trying to configure dial-up UUCP or UUCP-over-IP with uucpd? Arrigo From gtaylor at tnetconsulting.net Tue Jun 30 02:42:45 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 29 Jun 2020 10:42:45 -0600 Subject: [COFF] UUCP on macOS / *BSD In-Reply-To: <70723375-EF94-4F47-A7D1-54C958F85E9A@alchemistowl.org> References: <70723375-EF94-4F47-A7D1-54C958F85E9A@alchemistowl.org> Message-ID: <8dbc09dd-07be-a7ab-082e-edc2e74f0d67@tnetconsulting.net> On 6/29/20 9:53 AM, Arrigo Triulzi via COFF wrote: > I run UUCP on OpenBSD for some very remote sites connected with > satellite modems (using UUCP-over-IP, not pure UUCP, where the dial-up > script initiates the UUCP exchange). UUCP was recently removed from > the base OpenBSD distribution but is still available as a package. Do you by chance recall what UUCP software was being used? Was it by chance Taylor UUCP? Or was it some other UUCP package in OpenBSD? > I honestly cannot see it work on macOS because I cannot even remotely > imagine Apple having any interest whatsoever in ensuring that it works > with the various changes they made to “standard Unix” (launchd, > sandboxing, read-only /, etc.). I'll be the first to admit that it was a very ... convoluted process to get it to work on macOS (X) Catalina 10.15.5. 1) Boot into recovery mode. 2) Log into my local account. 3) Disable System Integrity Protection. 4) Boot into normal mode. 5) Remount the root file system read-write: mount -uw / 6) Update /usr/share/uucp/* as necessary. 7) Boot into recovery mode. 8) Enable SIP. I did have to enable Set UID & GID on some of the UUCP binaries. - I don't know if this is a macOS thing that's broken or if it's a difference in how UUCP operates on BSD or something else I'm ignorant of. Currently, it seems like UUCP is largely working, save for the fact that users other than _uucp (yes, including the leading underscore) can't access the SSH key file that's used as part of the pipe transport. I should document what I'm doing, both as notes for my self (self serving) and for others (good of the community). > Are you trying to configure dial-up UUCP or UUCP-over-IP with uucpd? I'm trying to configure UUCP-over-SSH. It's probably closer to UUCP-over-modem than it is UUCP-over-IP (TCP). The ""modem pipe is the ssh command which remotely connects to the destination host (using keys to authenticate) and launching uucico through the SSH connection STDIO. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From clemc at ccc.com Tue Jun 30 03:20:42 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 29 Jun 2020 13:20:42 -0400 Subject: [COFF] UUCP on macOS / *BSD In-Reply-To: <8dbc09dd-07be-a7ab-082e-edc2e74f0d67@tnetconsulting.net> References: <70723375-EF94-4F47-A7D1-54C958F85E9A@alchemistowl.org> <8dbc09dd-07be-a7ab-082e-edc2e74f0d67@tnetconsulting.net> Message-ID: I can try to pull some info from long ago paged out memory. I havent had to run UUCP since the late 1990s. By the Stellar time, we were on the Internet and UUCP had pretty much become unnecessary for most folks. On Mon, Jun 29, 2020 at 12:42 PM Grant Taylor via COFF wrote: > Do you by chance recall what UUCP software was being used? Was it by > chance Taylor UUCP? Or was it some other UUCP package in OpenBSD? > BSD was originally based on V7 UUCP with some fixes. Eventually Honey-Dan-Ber came out in the very early 1980s and most of the commercial UNIX's licensed/relicensed/redistributed it. V7 and HDB were the versions that built the USENET. As Larry said, V7 definition needed a baby sister, HDB got to the point that it pretty much worked without having to watch it too much. The biggest issue was that disks were much smaller in those days and overflow of the spool area was not uncommon. Taylor UUCP was much later and was a mostly FOSS implementation of H-D-B. I never ran it. The original ORA UUCP manual (that Tim actually wrote the first draft) was always the definitive guide to running. > > > Are you trying to configure dial-up UUCP or UUCP-over-IP with uucpd? > > I'm trying to configure UUCP-over-SSH. It's probably closer to > UUCP-over-modem than it is UUCP-over-IP (TCP). The ""modem pipe is the > ssh command which remotely connects to the destination host (using keys > to authenticate) and launching uucico through the SSH connection STDIO. > What protocol is it running? Chesson's 'g' protocol (which was the default). How is the chatting being done? That's were most issues tended occur. Remember the expect(1) program was created by the folks at NIST modelling after Ber's version of chat for H-D-B. My guess is that something in macOS's way of running login might be doing something unexpected and confusing uucico. I might suggest try debugging with two computers talking over a serial link. Just add a USB to serial to each of your systems. Set up a login one link and get the other side to open the other. The hard part is Apple dorked the login scheme from traditional UNIX/so you'll need to make sure it does not try to do something too funny. Basically you need to be able to run cu (or the equiv) from one system to the other and login in a normal user. If you can do that and nothing is screwy, then try to login at user uucp and see if uucico is properly forked. Maybe the answer is pull an old getty/login pair off BSD and set up a daemon to fake it so that Apple login stuff is not in the way. But the trick is that once you make that work, you can then set up uucp the way it was expected to run. FWIW: ssh did not exist when UUCP transitioned to running on IP - so I suspect it was never really, debugged worked out. There was no need. Just so you know, a couple of UUCP of ethernet were done. I wrote the first one (the e protocol) for the Masscomp systems, which I gave back to Sam and Keith was in the BSD release. IIRC there were a couple of others that different people did also. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From arrigo at alchemistowl.org Tue Jun 30 03:22:32 2020 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Mon, 29 Jun 2020 19:22:32 +0200 Subject: [COFF] UUCP on macOS / *BSD In-Reply-To: <8dbc09dd-07be-a7ab-082e-edc2e74f0d67@tnetconsulting.net> References: <8dbc09dd-07be-a7ab-082e-edc2e74f0d67@tnetconsulting.net> Message-ID: <384AB182-420D-4014-9141-4B9A72ABD904@alchemistowl.org> On 29 Jun 2020, at 18:43, Grant Taylor via COFF wrote: > > On 6/29/20 9:53 AM, Arrigo Triulzi via COFF wrote: >> I run UUCP on OpenBSD for some very remote sites connected with satellite modems (using UUCP-over-IP, not pure UUCP, where the dial-up script initiates the UUCP exchange). UUCP was recently removed from the base OpenBSD distribution but is still available as a package. > > Do you by chance recall what UUCP software was being used? Was it by chance Taylor UUCP? Or was it some other UUCP package in OpenBSD? It is indeed Taylor UUCP. > I did have to enable Set UID & GID on some of the UUCP binaries. - I don't know if this is a macOS thing that's broken or if it's a difference in how UUCP operates on BSD or something else I'm ignorant of. Yes, UUCP binaries do have setuid set, even on OpenBSD. Indeed, in the interest of removing setuid binaries, UUCP was completely removed from base OpenBSD and moved to packages. > Currently, it seems like UUCP is largely working, save for the fact that users other than _uucp (yes, including the leading underscore) can't access the SSH key file that's used as part of the pipe transport. The key file won't normally work if permissions are more permissive than 0600 so that is not surprising. Is it doing tunnelling between two ports, i.e. using -L etc.? I'm assuming you are then using uucpd on the remote end listening on the appropriate, forwarded, port which would suggest that you don't need UUCP to setup the connection as long as it has access to the local forwarded port? > I should document what I'm doing, both as notes for my self (self serving) and for others (good of the community). Also for debugging purposes, i.e. showing us so that we can see the issues you discuss :) >> Are you trying to configure dial-up UUCP or UUCP-over-IP with uucpd? > > I'm trying to configure UUCP-over-SSH. It's probably closer to UUCP-over-modem than it is UUCP-over-IP (TCP). The ""modem pipe is the ssh command which remotely connects to the destination host (using keys to authenticate) and launching uucico through the SSH connection STDIO. Right, never did that in my life… I set things up when (open)SSH was v1.2 and port forwarding not quite there yet. Arrigo From gtaylor at tnetconsulting.net Tue Jun 30 06:06:04 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 29 Jun 2020 14:06:04 -0600 Subject: [COFF] UUCP on macOS / *BSD In-Reply-To: References: <70723375-EF94-4F47-A7D1-54C958F85E9A@alchemistowl.org> <8dbc09dd-07be-a7ab-082e-edc2e74f0d67@tnetconsulting.net> Message-ID: <7aff4a42-0109-2278-c573-7e29e878cd57@tnetconsulting.net> On 6/29/20 11:20 AM, Clem Cole wrote: > I can try to pull some info from long ago paged out memory. Some effort would be appreciated. But please don't dig too deeply or disturb too much accumulated dust. ;-) > I havent had to run UUCP since the late 1990s. By the Stellar time, > we were on the Internet and UUCP had pretty much become unnecessary > for most folks. TCP/IP and the Internet serve me quite well. But I've found that the background store-and-forward nature of UUCP is nice for some things. Particularly when one of the systems in the path is offline or not readily accessible. I recently moved a 4.7 GB DVD around between three systems just to see if I could. It worked quite well. It took ~2 minutes per hop. The email notification at the end was nice too. I was doing some reading of the Taylor UUCP manual last night and learned that uux can operate on files that are on other systems. uux sys1!diff sys2!file1 sys3!file2 Something like that. I've not had a need for that yet. But I do like the idea. > BSD was originally based on V7 UUCP with some fixes.   Eventually > Honey-Dan-Ber came out in the very early 1980s and most of the > commercial UNIX's licensed/relicensed/redistributed it. V7 and HDB were > the versions that built the USENET. #respect > As Larry said, V7 definition needed a baby sister, HDB got to the point > that it pretty much worked without having to watch it too much. Good to know. > The biggest issue was that disks were much smaller in those days and > overflow of the spool area was not uncommon. Ah. That makes sense. I would think that the byte count / size of the file would be checked before the transfer was started. But maybe that's the benefit of learning from 40 years of experience that others have had. I can also see how multiple inbound connections ~> copies could complicate things too. > Taylor UUCP was much later and was a mostly FOSS implementation of > H-D-B.   I never ran it. I know that Taylor UUCP supports a TCP mode. I don't know if HDB supported a TCP mode or not. I assume that the old V7 did not. > The original ORA UUCP manual (that Tim actually wrote the first draft) > was always the definitive guide to running. I'll look that up. I naively see the O'Reilly UUCP book as the definitive source often mentioned. As I type that I wonder if ORA is O'Reilly Associates. > What protocol is it running? "e" > Chesson's 'g' protocol (which was the default). I want ~> need to learn more about the protocols. > How is the chatting being done? That's were most issues tended occur. Chat isn't really happening. chat "" "" My understanding is that chat is needed to log into the remote system. Seeing as how I'm using SSH with key based authentication, there really isn't any typical log in process. The SSH connection is running uucico as the remote command. So it's really (local) uucico talking to SSH's STDIO which is (remotely) running uucico. > Remember the expect(1) program was created by the folks at NIST > modelling after Ber's version of chat for H-D-B. My guess is that > something in macOS's way of running login might be doing something > unexpected and confusing uucico. I'm trying to ""dial out from macOS into Linux. Saying "trying" is somewhat of a misnomer as it is working perfectly when I run uucico as the _uucp user. The only apparent problem is related to users other than the _uucp user prompting the call. I need to do some more investigating on this. I can initiate actions as my normal user; uucp, uuto, etc. and they properly queue actions. They also spur a call, which fails. If I subsequently spur a call as the _uucp user, things work perfectly fine. > I might suggest try debugging with two computers talking over a serial > link.   Just add a USB to serial to each of your systems.   Set up a > login one link and get the other side to open the other. I agree with your logic. However, I think that I'm past anything related to the UUCP chat. More specifically, I think my problem is related to the SSH ""serial (line alternative). > The hard part is Apple dorked the login scheme from traditional > UNIX/so you'll need to make sure it does not try to do something > too funny. ACK I have a handicap of of not knowing what's macOS issues vs what's simply a difference from the BSD family vs Linux what I'm used to. > Basically you need to be able to run cu (or the equiv) from one system > to the other and login in a normal user. cu targetSystemName seems to work. I get "Connected." followed by "Shere=targetSystemName". Note: I've got the remote system automatically launching uucico. This works perfectly fine when running uucico as the _uucp user. > If you can do that and nothing is screwy, then try to login at user > uucp and see if uucico is properly forked. Perhaps I should clarify somethings: - All of my systems are using the same configuration. - Think template with some values adjusted as necessary. - UUCP on all systems ssh out to to other systems as the host name. - hostA logs into hostB and hostC as the hostA user. - hostB logs into hostA and hostC as the hostB user. - hostC logs into hostA and hostB as the hostC user. - All systems have an account on the systems that they log into. - Random 63 character passwords that I no longer have. - SSH keys are used for all authentication. - SSH automatically launches uucico. - command: ssh targetSystemName /usr/sbin/uucico - authorized_keys: command="/usr/sbin/uucico" ... > Maybe the answer is pull an old getty/login pair off BSD and set up a > daemon to fake it so that Apple login stuff is not in the way.  But the > trick is that once you make that work, you can then set upuucp theway it > was expected to run. Given that the UUCP link works, seemingly perfectly fine, when run as the _uucp user, I think this is more a macOS (BSD?) issue than it is a UUCP link issue. > FWIW:  ssh did not exist when UUCP transitioned to running on IP - so I > suspect it was never really, debugged worked out.   There was no need. I've got multiple other systems running the same config and they are working perfectly fine. My issues came into being when I started trying to add a macOS system to the UUCP network. > Just so you know, a couple of UUCP of ethernet were done.  I wrote the > first one (the e protocol) for the Masscomp systems, which I gave back > to Sam and Keith was in the BSD release.   IIRC there were a couple of > others that different people did also. UUCP of Ethernet? Please elaborate. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Tue Jun 30 06:18:02 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 29 Jun 2020 14:18:02 -0600 Subject: [COFF] UUCP on macOS / *BSD In-Reply-To: <384AB182-420D-4014-9141-4B9A72ABD904@alchemistowl.org> References: <8dbc09dd-07be-a7ab-082e-edc2e74f0d67@tnetconsulting.net> <384AB182-420D-4014-9141-4B9A72ABD904@alchemistowl.org> Message-ID: <5059126e-23d2-0e65-11eb-f3a41be84356@tnetconsulting.net> On 6/29/20 11:22 AM, Arrigo Triulzi via COFF wrote: > It is indeed Taylor UUCP. Cool. Thank you for the confirmation. > Yes, UUCP binaries do have setuid set, even on OpenBSD. That clarifies setuid. Can the same be said about setgid? > Indeed, in the interest of removing setuid binaries, UUCP was > completely removed from base OpenBSD and moved to packages. That seems understandable, especially for OpenBSD. I think many distros are simply removing UUCP as an antiquated package. > The key file won't normally work if permissions are more permissive > than 0600 so that is not surprising. Agreed. I also tried it any way and got the expected error from OpenSSH saying that it was ignoring the key file with bad permissions. I was, still am, naively expecting that uucp / uuto / uux are run as normal users (not root and not the uucp user) to copy files to the uucp queue directory structure, and then something will cause the uucp user to initiate the outbound connection as the uucp user. I think this later part is where my understanding breaks down. > Is it doing tunnelling between two ports, i.e. using -L etc.? I'm > assuming you are then using uucpd on the remote end listening on the > appropriate, forwarded, port which would suggest that you don't need > UUCP to setup the connection as long as it has access to the local > forwarded port? No. sys: system targetHost call-login targetHost called-login targetHost port targetHost port: port targetHost type pipe command /usr/bin/ssh targetHost.fqdn /usr/sbin/uucico > Also for debugging purposes, i.e. showing us so that we can see the > issues you discuss :) What would you like me to show / share? > Right, never did that in my life… I set things up when (open)SSH > was v1.2 and port forwarding not quite there yet. ACK I've got this same type of configuration working quite well with multiple Linux systems. macOS mostly works. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Tue Jun 30 06:31:32 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 29 Jun 2020 14:31:32 -0600 Subject: [COFF] UUCP on macOS / *BSD In-Reply-To: <5059126e-23d2-0e65-11eb-f3a41be84356@tnetconsulting.net> References: <8dbc09dd-07be-a7ab-082e-edc2e74f0d67@tnetconsulting.net> <384AB182-420D-4014-9141-4B9A72ABD904@alchemistowl.org> <5059126e-23d2-0e65-11eb-f3a41be84356@tnetconsulting.net> Message-ID: <838270a9-c1a0-a3d0-0192-3b2f51f1608c@tnetconsulting.net> On 6/29/20 2:18 PM, Grant Taylor via COFF wrote: > sys: > system targetHost > call-login targetHost > called-login targetHost > port targetHost > > port: > port targetHost > type pipe > command /usr/bin/ssh targetHost.fqdn /usr/sbin/uucico I should probably include details about how SSH is configured: uucp user's ~/.ssh/config file: Host * User shortName # matches the output of uuname -l Calling system's ~/.ssh/authorized_keys file: command="/usr/sbin/uucico" ...typical contents... The uucp user can successfully ssh to the target system without being prompted for username or password. uucico starts automatically. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From clemc at ccc.com Tue Jun 30 06:59:06 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 29 Jun 2020 16:59:06 -0400 Subject: [COFF] UUCP on macOS / *BSD In-Reply-To: <7aff4a42-0109-2278-c573-7e29e878cd57@tnetconsulting.net> References: <70723375-EF94-4F47-A7D1-54C958F85E9A@alchemistowl.org> <8dbc09dd-07be-a7ab-082e-edc2e74f0d67@tnetconsulting.net> <7aff4a42-0109-2278-c573-7e29e878cd57@tnetconsulting.net> Message-ID: On Mon, Jun 29, 2020 at 4:06 PM Grant Taylor via COFF wrote: > > > I was doing some reading of the Taylor UUCP manual last night and > learned that uux can operate on files that are on other systems. > > uux sys1!diff sys2!file1 sys3!file2 > That just basic UUCP how Dan originally designed it. > > I would think that the byte count / size of the file would be checked > before the transfer was started. But maybe that's the benefit of > learning from 40 years of experience that others have had. > Yes and no. The problem was USENET (a.k.a. net.noise) had so little signal to noise ratio that one jack**s could send stuff that caused constipation > I know that Taylor UUCP supports a TCP mode. I don't know if HDB > supported a TCP mode or not. The basic package from AT&T did not, but different protocols were available as source. At the risk of taking Larry's ire, the key is that in practice people had the sources. So I passed on my original 'e' protocol, as did others. > I assume that the old V7 did not. > Right, but IIRC by the time of BSD 4.3 and later Sam or Keith had updated the UCB version so more than just g was in there. > > > The original ORA UUCP manual (that Tim actually wrote the first draft) > > was always the definitive guide to running. > > I'll look that up. > > I naively see the O'Reilly UUCP book as the definitive source often > mentioned. > > As I type that I wonder if ORA is O'Reilly Associates. > Yes -- Tim and I famously shared a card table as a desk at Masscomp. He was out contract tech writer. ORA was (is) his firm. He wrote a couple of manuals for us, plus one our second in house tech writer wrote the original Make manual. Tim proposed publishing some of the work he did for us (including Steve's Make) as the original 6 'UNIX in Nutshell' books[I still have them]. He did the X11 books for us and we (re)negotiated the deal. That was what got the ORA enterprise going. I also joke that ORA is the most successful and longest living part of Masscomp. > > > What protocol is it running? > > "e" > God lord another old hack lives!!! I'm not sure if I should be proud or ashamed. > > > Chesson's 'g' protocol (which was the default). > > I want ~> need to learn more about the protocols. > Talk to me offline. > > > How is the chatting being done? That's were most issues tended occur. > > Chat isn't really happening. > > chat "" "" > > My understanding is that chat is needed to log into the remote system. yes - it is now the uucico process is forked remotely. We can take this offline. > > Seeing as how I'm using SSH with key based authentication, there really > isn't any typical log in process. The SSH connection is running uucico > as the remote command. So it's really (local) uucico talking to SSH's > STDIO which is (remotely) running uucico. > Understand -- IIRC Perry Flinn used rsh/rexec originally (it was his hack one afternoon between our two machines). Once we got it working, I wrote the e protocol to make it more efficient. > I'm trying to ""dial out from macOS into Linux. > Good idea. Again, I might try to do this serial line to make the macOS was right before you tried to add things like ssh mix. > > Saying "trying" is somewhat of a misnomer as it is working perfectly > when I run uucico as the _uucp user. > uucico and the back end all runs as uucp/bin (or later uucp/uucp IICR -- I bet Tim's book tells you). IIRC the uucp and uux command needs to be setuid also because they will be working files in the spool directories. Look at the V7 root and usr file systems that Warren has. Duplicate >>exactly<< the ownership of directories, commands and backend there and make sure you have that working. As I said, I would do this on a serial line to start. If that works, then you know you have the base system working as expected. > > The only apparent problem is related to users other than the _uucp user > prompting the call. I need to do some more investigating on this. > > I can initiate actions as my normal user; uucp, uuto, etc. and they > properly queue actions. They also spur a call, which fails. If I > subsequently spur a call as the _uucp user, things work perfectly fine. > They needs to be make the setuid setting os V7 or BSD. > I agree with your logic. However, I think that I'm past anything > related to the UUCP chat. > It's more than just chat... you need to get the subsystem working - so set it up exactly as how it was expected and you will have fewer surprises. > > More specifically, I think my problem is related to the SSH ""serial > (line alternative). > Possible,m but it sounds like some of the commands/backend/databases are not consistent. > I have a handicap of of not knowing what's macOS issues vs what's simply > a difference from the BSD family vs Linux what I'm used to. > I would suspect most of it is Apple, but I don't know. They are not likely to have messed much with uucp. Taylor tried to match HDB and was targeted for later BSD systems [post the AT&T court case]. > I get "Connected." followed by "Shere=targetSystemName". > Excellent. > > Note: I've got the remote system automatically launching uucico. This > works perfectly fine when running uucico as the _uucp user. > uucico must run as UUCP --- the _uucp user is not traditional uucp - BTW. > > > If you can do that and nothing is screwy, then try to login at user > > uucp and see if uucico is properly forked. > > Perhaps I should clarify somethings: > > - SSH keys are used for all authentication. > - SSH automatically launches uucico. > Probably ok, but UUCP did not work that way. Your choice, but I would try to make it work as expected, described in the original V7 document and Tim's manual/book - the UUCP Administrator's guide. > - command: ssh targetSystemName /usr/sbin/uucico > - authorized_keys: command="/usr/sbin/uucico" ... > Can't help you. IICR uucico was traditionally in /usr/lib/uucp > > Given that the UUCP link works, seemingly perfectly fine, when run as > the _uucp user, I think this is more a macOS (BSD?) issue than it is a > UUCP link issue. > Be careful of seems to work. It means transfers are working once to kick start it. But are things being queued properly and is all the backup starting up right with the proper users. I don't think this is a BSDism as much as a macOS thing. > My issues came into being when I started trying to add a macOS system to > the UUCP network. > Fair enough -- it means the mac is not configured properly. But taking the configs from a Linux box is not a good idea here because between the Linux changed and the things Apple changed you're likely to have wrong configs. > > UUCP of Ethernet? Please elaborate. > > dyslexia-r-me UUCP >>over<< ethernet. Further adventures are probably better left offline. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtomek at ceti.pl Tue Jun 30 12:26:33 2020 From: rtomek at ceti.pl (Tomasz Rola) Date: Tue, 30 Jun 2020 04:26:33 +0200 Subject: [COFF] UUCP on macOS / *BSD In-Reply-To: <7aff4a42-0109-2278-c573-7e29e878cd57@tnetconsulting.net> References: <70723375-EF94-4F47-A7D1-54C958F85E9A@alchemistowl.org> <8dbc09dd-07be-a7ab-082e-edc2e74f0d67@tnetconsulting.net> <7aff4a42-0109-2278-c573-7e29e878cd57@tnetconsulting.net> Message-ID: <20200630022632.GA21942@tau1.ceti.pl> On Mon, Jun 29, 2020 at 02:06:04PM -0600, Grant Taylor via COFF wrote: > On 6/29/20 11:20 AM, Clem Cole wrote: > >I can try to pull some info from long ago paged out memory. > [...] > I'm trying to ""dial out from macOS into Linux. > > Saying "trying" is somewhat of a misnomer as it is working perfectly > when I run uucico as the _uucp user. > > The only apparent problem is related to users other than the _uucp > user prompting the call. I need to do some more investigating on > this. > > I can initiate actions as my normal user; uucp, uuto, etc. and they > properly queue actions. They also spur a call, which fails. If I > subsequently spur a call as the _uucp user, things work perfectly > fine. [...] So, assuming that I understood your problem - and given that I know close to nothing about uucp - and given that I know close to nothing about MacOS pecularities I wonder if your problem could be solved by setting up a small crontab entry for user _uucp, where a script would be called every minute and check, if there is previous instance of it running and if there are some jobs in the queue, and do the stuff when the answer were no and yes, respectively. Special user moving files over ssh, normal users putting files in the queue. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From gtaylor at tnetconsulting.net Tue Jun 30 13:19:20 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 29 Jun 2020 21:19:20 -0600 Subject: [COFF] UUCP on macOS / *BSD In-Reply-To: <20200630022632.GA21942@tau1.ceti.pl> References: <70723375-EF94-4F47-A7D1-54C958F85E9A@alchemistowl.org> <8dbc09dd-07be-a7ab-082e-edc2e74f0d67@tnetconsulting.net> <7aff4a42-0109-2278-c573-7e29e878cd57@tnetconsulting.net> <20200630022632.GA21942@tau1.ceti.pl> Message-ID: <76024752-a506-abf1-1990-0b66630bb7db@spamtrap.tnetconsulting.net> On 6/29/20 8:26 PM, Tomasz Rola wrote: > So, assuming that I understood your problem > - and given that I know close to nothing about uucp > - and given that I know close to nothing about MacOS pecularities > > I wonder if your problem could be solved by setting up a small crontab > entry for user _uucp, where a script would be called every minute > and check, if there is previous instance of it running and if there > are some jobs in the queue, and do the stuff when the answer were no > and yes, respectively. You're quite close to what I've seen on other systems. It would probably also work on the current problem system as a work around. But I don't think it will solve the underlying problem. There is an underlying utility that's part of the UUCP suite named "uucico" and it's job is to connect to itself and transfer files. It has a function where it will see if there is any work (UUCP terms) and if there is, do it. So I've frequently seen uucico run on an hourly cron job on a number of systems. I do believe that would work around the problem. I'm trying to understand what the problem is that is actually happening so that I can use things properly and not need to rely on the workaround. Incidentally, other Linux systems running the same software with the same config don't need the workaround. :-| > Special user moving files over ssh, normal users putting files in > the queue. There's some more nuance to it than that. But, sure, that's the gist of it. Subsystem that runs as a dedicated user moving files between systems, over SSH in this case. Normal users use other commands to ask said subsystem to do work on their behalf. Said subsystem includes creating and managing a queue structure, determining if / when to connect (call) a remote system, transferring files both ways, dealing with failures, and retrying. Oh, ya, said subsystem is an industry standard across most Unixes and some other platforms. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From rtomek at ceti.pl Tue Jun 30 13:26:48 2020 From: rtomek at ceti.pl (Tomasz Rola) Date: Tue, 30 Jun 2020 05:26:48 +0200 Subject: [COFF] UUCP on macOS / *BSD In-Reply-To: <76024752-a506-abf1-1990-0b66630bb7db@spamtrap.tnetconsulting.net> References: <70723375-EF94-4F47-A7D1-54C958F85E9A@alchemistowl.org> <8dbc09dd-07be-a7ab-082e-edc2e74f0d67@tnetconsulting.net> <7aff4a42-0109-2278-c573-7e29e878cd57@tnetconsulting.net> <20200630022632.GA21942@tau1.ceti.pl> <76024752-a506-abf1-1990-0b66630bb7db@spamtrap.tnetconsulting.net> Message-ID: <20200630032647.GB21942@tau1.ceti.pl> On Mon, Jun 29, 2020 at 09:19:20PM -0600, Grant Taylor via COFF wrote: [...] > Incidentally, other Linux systems running the same software with the > same config don't need the workaround. :-| [...] You might want to see if all copies of uucp on your many systems were compiled from the same source. In case of Debian, package maintainers sometimes add a bit from themselves, from what I have gathered. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From rtomek at ceti.pl Tue Jun 30 13:46:27 2020 From: rtomek at ceti.pl (Tomasz Rola) Date: Tue, 30 Jun 2020 05:46:27 +0200 Subject: [COFF] UUCP on macOS / *BSD In-Reply-To: <20200630032647.GB21942@tau1.ceti.pl> References: <70723375-EF94-4F47-A7D1-54C958F85E9A@alchemistowl.org> <8dbc09dd-07be-a7ab-082e-edc2e74f0d67@tnetconsulting.net> <7aff4a42-0109-2278-c573-7e29e878cd57@tnetconsulting.net> <20200630022632.GA21942@tau1.ceti.pl> <76024752-a506-abf1-1990-0b66630bb7db@spamtrap.tnetconsulting.net> <20200630032647.GB21942@tau1.ceti.pl> Message-ID: <20200630034627.GC21942@tau1.ceti.pl> On Tue, Jun 30, 2020 at 05:26:48AM +0200, Tomasz Rola wrote: > On Mon, Jun 29, 2020 at 09:19:20PM -0600, Grant Taylor via COFF wrote: > [...] > > Incidentally, other Linux systems running the same software with the > > same config don't need the workaround. :-| > [...] > > You might want to see if all copies of uucp on your many systems were > compiled from the same source. In case of Debian, package maintainers > sometimes add a bit from themselves, from what I have gathered. And BTW, looking how they did it on systems where things worked might give you a clue, too. For example, when you install a package, there might be a script setting thing up in a correct way. HTH -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From gtaylor at tnetconsulting.net Tue Jun 30 13:47:59 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 29 Jun 2020 21:47:59 -0600 Subject: [COFF] UUCP on macOS / *BSD In-Reply-To: <20200630032647.GB21942@tau1.ceti.pl> References: <70723375-EF94-4F47-A7D1-54C958F85E9A@alchemistowl.org> <8dbc09dd-07be-a7ab-082e-edc2e74f0d67@tnetconsulting.net> <7aff4a42-0109-2278-c573-7e29e878cd57@tnetconsulting.net> <20200630022632.GA21942@tau1.ceti.pl> <76024752-a506-abf1-1990-0b66630bb7db@spamtrap.tnetconsulting.net> <20200630032647.GB21942@tau1.ceti.pl> Message-ID: <18c61e52-de76-a2ff-a0bb-eab0c9b4a46c@spamtrap.tnetconsulting.net> On 6/29/20 9:26 PM, Tomasz Rola wrote: > You might want to see if all copies of uucp on your many systems were > compiled from the same source. In case of Debian, package maintainers > sometimes add a bit from themselves, from what I have gathered. I can almost guarantee that the copy on macOS, Ubuntu, and (multiple) Gentoo boxen are /not/ compiled from the same source code. But, that's one of the nice things about UUCP, it's a standard and things /should/ be interoperable. I think I'm tilting at something macOS specific. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Tue Jun 30 13:50:07 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 29 Jun 2020 21:50:07 -0600 Subject: [COFF] UUCP on macOS / *BSD In-Reply-To: <20200630034627.GC21942@tau1.ceti.pl> References: <70723375-EF94-4F47-A7D1-54C958F85E9A@alchemistowl.org> <8dbc09dd-07be-a7ab-082e-edc2e74f0d67@tnetconsulting.net> <7aff4a42-0109-2278-c573-7e29e878cd57@tnetconsulting.net> <20200630022632.GA21942@tau1.ceti.pl> <76024752-a506-abf1-1990-0b66630bb7db@spamtrap.tnetconsulting.net> <20200630032647.GB21942@tau1.ceti.pl> <20200630034627.GC21942@tau1.ceti.pl> Message-ID: <3c997004-f77c-1691-380e-4662375d46d8@spamtrap.tnetconsulting.net> On 6/29/20 9:46 PM, Tomasz Rola wrote: > And BTW, looking how they did it on systems where things worked might > give you a clue, too. For example, when you install a package, there > might be a script setting thing up in a correct way. Agreed. I have four systems in this current micro UUCP network, one Ubuntu and three Gentoo, all working happily with each other. The macOS system that I am working on adding to the mix is the cranky one. And even then, it's only cranky if you don't sweet talk it. If you do sweet talk it, it works like it should. Here, sweet talk means adding "-r" to uuto and uucp, then calling uucico as the UUCP user. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: