> segaloco via TUHS writes:
>> I think that's a good point that scripting problems may be
>> a symptom of the nature of the tools being used in them.
> I think that you're hinting at something different.
> To the best of my recollection, scripting languages were originally
> intended and used for the automation of repetitive personal tasks;
> making it easier for users who found themselves typing the same
> stuff over and over again.
Indeed!
> Somewhere along the line people forgot
> how to use a compiler and began writing large systems in a variety
> of roughly equivalent but incompatible interpreted languages. Can
> one even boot linux without having several different incompatible
> versions of Python installed today? So I don't think that it's the
> nature of the tools; I think that it's people choosing the wrong
> tools for the problems that they're trying to solve.
> Jon
The forgotten compilers were typically used to supply glue
to paste major tools together. The nature of that glue---often
simple data reformatting--inspired tools like sed and awk.
Each use of a tool became a process that saved many minutes
of work that would in a scriptless world be guided by hand,
boringly and unreliably.
Yet glue processes typically did only microseconds of
"real" work. In the name of efficiency, the operations began
to be incorporated directly into the shell. The first
inklings of this can be seen in "echo" and various forms
of variable-substitution making their way into the v7
shell. The phenomenon proliferated into putting what were
typically canned sed one-liners (but not sed itself) into
the shell.
Lots of specializations crowded out universality. A side
effect was an explosion of knowledge required to write
or understand code. Such is the tragedy of "forgetting
compilers".
Doug
Someone dumped a bunch of Unix/Plan 9/FORTRAN/FOCAL documents on github:
https://github.com/kenmartin-unix/UnixDocs
I haven't looked at them closely to see what may be there, but this
may interest some TUHS readers.
- Dan C.
I'd love to get my hands on a 3B2 someday, this'll be cool if I can get it going but that'd be a much more robust machine.
I'm starting to suspect if there isn't any sort of boot ROM that spits out commentary on the UART and that doesn't get flexed until UNIX is up, I may not be able to get very far. I referred to http://bitsavers.trailing-edge.com/pdf/att/3b1/999-809-010IS_UNIX_PC_Remote… for the serial settings and it appears:
9600 baud, 1 stop bit, no parity, 8 data bits
And the relevant pins
Pin 1 - GND
Pin 2 - RX
Pin 3 - TX
Pin 4 - RTS
Pin 5 - CTS
Pin 6 - DSR
Pin 7 - GND
Pin 8 - DCD
Pin 20 - DTR
So I've plugged my USB-TTY GND/RX/TX into the relevant pins and setup the necessary tty settings. The manual then suggests if running null modem mode to short pin 4 to 5 and then pins 6, 8, and 20 together, presumably omitting any need for modem signalling from the remote machine, doing basic serial RX/TX. Unfortunately even with all of this bypassing I get nothing out of the RS-232 port. What I don't know is if I could even expect something or if this is unlikely to bear fruit whether the hardware works or not. In any case, if I do get this thing running I'll have a writeup for folks afterwards. If not, then hopefully I can figure out something useful to do with this thing rather than junking it.
- Matt G.
------- Original Message -------
On Tuesday, January 3rd, 2023 at 3:53 PM, rob(a)atvetsystems.com <rob(a)atvetsystems.com> wrote:
> Hello Matt,
>
> I’ve got one of these in my garage. I bought it about twenty years ago as a working system but when I got it home I noticed that the hard disk wasn’t connected but at some point I’d like to get it and my 3b2/300 working.
>
> Regards, Rob.
>
>> On 3 Jan 2023, at 23:27, segaloco via TUHS <tuhs(a)tuhs.org> wrote:
>>
>> And here are some pictures of the guts.
>>
>> https://imgur.com/a/E1ioxZl
>>
>> Various bits inside date this to late 1985. The good news is it at least turns on, but that's about as far as I've gotten with it. The display never turns on, nor do I hear any sounds indicating it tries to start the CRT. The fans kick on and there it stays until I turn it off. I plugged in a USB-TTY to pins 2, 3, and 7 (RX/TX/GND) and listened at 9600 baud 8 bit 1 stop no parity and got nothing. Swapped the RX/TX, still nothing. Of course, that's all predicated on the assumption there's something there to even interact with. I have little faith that whatever UNIX install was on this is extant. Additionally, it didn't come with a keyboard, so if there was some futzing with key combos that would trigger some sort of UART over those lines, I can't do that. I wonder if there are some contacts inside I can just poll for activity with this serial connector, not sure how safe that is...
>>
>> Anywho, the CPU has a bit of corrosion on the surface, not sure how that bodes for the innards, but this is in kinda rough shape either way. I hope I can salvage it but if not, I'm going to at least do some study on the CRT particulars and see if I can extract and keep the monitor from it, been wanting a smaller CRT to have around for a while.
>>
>> - Matt G.
>> ------- Original Message -------
>> On Tuesday, January 3rd, 2023 at 12:20 PM, segaloco via TUHS <tuhs(a)tuhs.org> wrote:
>>
>>> Good day everyone, just starting a thread for yet another project I'll be tinkering on over time. Picked up a (presumably broken/untested) 7300 off eBay to at the very least tear down and get some good pictures of and, with some luck, perhaps get working again.
>>>
>>> https://imgur.com/a/CExzebl
>>>
>>> Here are some pictures of the exterior for starters. I'll update this thread when I've got pictures of the guts and also with any info I can glean regarding whether this might be salvageable. The rust on the back is pretty nasty but I've seen older/worse start up just fine.
>>>
>>> - Matt G.
Good day everyone, just starting a thread for yet another project I'll be tinkering on over time. Picked up a (presumably broken/untested) 7300 off eBay to at the very least tear down and get some good pictures of and, with some luck, perhaps get working again.
https://imgur.com/a/CExzebl
Here are some pictures of the exterior for starters. I'll update this thread when I've got pictures of the guts and also with any info I can glean regarding whether this might be salvageable. The rust on the back is pretty nasty but I've seen older/worse start up just fine.
- Matt G.
Does anyone have the original troff of this document? It was written
by Bill Shannon at Sun, documenting the C style conventions for SunOS.
A PDF rendering is here:
https://www.cis.upenn.edu/~lee/06cse480/data/cstyle.ms.pdf
Thanks!
- Dan C.
The /bin/sh stuff made me think of an interview question I had for engineers,
that a surprisingly few could pass:
"Tell me about something you wrote that was entirely you, the docs, the
tests, the source, the installer, everything. It doesn't have to be a
big thing, but it has to have been successfully used by at least 10
people who had no contact with you (other than to say thanks)."
Most people fail this. I think the people who pass might look
positively on the v7 sh stuff. But who knows?
As mentioned in the first post on SysIII porting, I was surprised to see how much code was needed to initialise modern hardware and to load an OS. Of course, modern devices are much more capable than the ones of 40 years ago, so maybe my surprise is misplaced. It did raise an interest in the history of Unix system configuration though.
It would seem that 5th Edition already contained a configuration program that generated a few system tables and the ‘low.s’ file with interrupt vectors and alike. Although it steadily grew in sophistication, the approach appears still the same in SysIII. I suppose this is all in line with common practice of the era, with OS’s typically having a ’system generation kit' to combine the pre-linked OS kernel with device drivers and system tables.
SysIII also introduces the "var struct" and the “v” kernel variable that summarises some of the system configuration. I’m not sure whether it has roots in earlier Unix systems, it does not seem to originate from Research. I’m not sure what the point of this ‘v’ kernel variable was. Does anybody remember?
One could argue that one of the drivers of the success of CP/M in the 1970’s was due to its clear separation between the boot rom, BIOS and BDOS components. As far as I am aware, Unix prior to 1985 did never attempt to separate the device drivers from the other kernel code. I am not very familiar with early Xenix, it could be that Microsoft had both the skill and the interest to separate Xenix in a standard binary (i.e. BDOS part) and a device driver binary (i.e. BIOS part). Maybe the differences in MMU for the machines of the early 80’s were such that a standard binary could not be done anyway and separating out the device drivers would serve no purpose. Once the PC became dominant, maybe the point became moot for MS.
It would seem that the next step for Unix in the area of boot, config and device drivers came with Sun’s OpenBoot in 1988 or so. This also appears to be the first appearance of device trees to describe the hardware to the bios and the kernel. Moreover, it would seem to me that OpenBoot is a spiritual ancestor of the modern Risc-V SBI specification. Maybe by 1988 the IO hardware had become sufficiently complex and/or diverse to warrant a break from tradition?
Was there any other notable Unix work on better organising the boot process and the device drivers prior to OpenBoot?
> "Originally the idea of adding command line editing to ksh was
> rejected in the hope that line editing would move into the terminal
> driver." [2]
> I have always wondered, what such a central terminal driver driven
> history/line-editing would have felt like.
You can get a feel for it in Rob's "sam" editor, which works that way.
Doug
at the risk of making a fool of myself - there are several people far better qualified here, however…
my memory is that the plan9 linker could be easily rebuilt to use malloc and free in the traditional style, reducing its memory footprint - though making it much slower.
-Steve
Adam Thorton wrote:
> I mean all I really want for Christmas is a 64-bit v7 with TCP/IP support, a screen editor, and SMP support.
>
> The third one is a solved problem. The second one would not be that hard to adapt, say, uIP 0.9, to v7. That first one would require some work with C type sizes, but getting larger is easier than the reverse. It's that last one.
>
> Having said that...maybe what I really want is 64-bit 4.3 BSD?
>
> I mean, just a Unix, without all the cruft of a modern Linux, but which can actually take advantage of the resources of a modern machine. I don't care about a desktop, or even a graphical environment, I don't care about all the strange syscalls that are there to support particular databases, I don't care much about being a virtualization host.
Luther Johnson wrote:
> I'm in the process of building a system like that for myself, but
> perhaps a little smaller - mine will be based on an embedded
> microprocessor I've developed (so much work still yet to do ! at least a
> year out).
Earlier this year I ported VAX System III to Risc-V, to a simple Allwinner D1 based SBC. This is RV64GC. Just ported to the console terminal.
It turned out that porting Sys III to 64 bit was surprisingly easy, most of the kernel and user land appears to be 64 bit clean. It helps that I am using a LLP64 compiler, though. Apart from networking Sys III also feels surprisingly modern (for an ancient Unix) - its should get more attention than it does. The hardest work was in porting the VAX memory code to Risc-V page tables (and to a lesser extent, updating libc for the different FP formats).
The code is currently in an ugly state (with debug stuff in commented-out blocks, a mix of ansi and K&R styles, an incoherent kludgy build system, etc.) and the shame stopped me from putting it out on gitlab until I found enough time to clean this up. As there seems to be some interest now, I’ll put it up anyway in the next week or so. There you go Adam, half your wish comes true.
The kernel is about 60KB and most binaries are quite close in size to the VAX equivalents.
My next goals for it are to re-implement the Reiser demand paging (I think I have a good enough view of how that worked, but the proof of the pudding will be in the eating), and to add TCP/IP networking, probably the BBN stack. Making it work on RV32 and exploring early SMP work is also on my interest list.
===
David Arnold wrote:
> I think xv6 does SMP? (param.h says NCPU = 8, at least).
>
> You’d need to add a network stack and a userland, but there are options for those …
For the above, making xv6 work on the D1 board was my first stepping stone, to proof the tool chain and to get the basics right (hardware init, low-level I/O, etc.).
As an educational tool, I am sure that xv6 hits all the right spots, and it certainly does SMP (the D1 is single hart, so I have not tried that myself). I like it a lot in that context. However, as a simple Unix it is useless: from a user-land view it is less capable than LSX. At minimum it needs fixes to make the file system less constrained.
In my view, for SMP Keith Kelleman’s work for Sys-V is probably a better place to start.
