- COFF - www.tuhs.org

how was TCF different or similar to Mosix

by Clem Cole

On Fri, Apr 2, 2021 at 1:50 PM Theodore Ts'o <tytso(a)mit.edu> wrote: > Out of curiousity, how was TCF different or similar to Mosix? > Many similar ideas. TCF was basically the commercial implementation of the Locus, which Jerry and students built at UCLA (one 11/70s original). I want to say the Locus papers are in some early SOSPs. MOSIX was its own Unix-like OS, as was Locus [and some of this was in Sprite too BTW]. TCF was a huge number of rewrites to BSD and was UNIX. The local/remote restructuring was ad-hoc. By the time Roman and I lead TNF, we had created a formal VPROC layer as an analog to the VFS layer (more in a minute). TNC was to be the gut of Intel's Paragon using OSF/1 as base OS. The basic idea of all of them is that the cluster is looks like a single protection domain with nodes contributing resources. A Larry says a ps is cluster-wide. TCF had the idea of features that each node provides (ISA, floating-point unit, AP, *etc*..) so if a process needed specific resources, it would only run on a node that had those resources. But it also meant that processes could be migrated from a node that had the same resources. One of the coolest demos I ever saw was we took a new unconfigured PS/2 at a trade show and connected the ethernet to it on the trade show network, and put in a boot floppy. We dialed back into a system at an LCC, and filled in some security things, details like the IP address of the new system and soon it booted and joined the cluster. It immediately started to add services to the cluster, we walked away, and (overnight) the system had set up the hard disk and started caching locally things that were needed for speed. Later I was editing a file and from another screen migrated the process around the cluster while the editing was active. The problem with VPROC (like VFS) is it takes surgery all over the kernel. In fact, for Linux 2.x kernel the OpenSSI <https://sourceforge.net/projects/ssic-linux/> folks did all the kernel work to virtualize the concept of process, which sadly never got picked up as the kernel.org folks did not like it (a real shame IMO). BTW, one of the neat side effects of a layer like VPROC is things like checkpoint/restart are free -- you are just migrating a process to the storage instead of an active processor. Anyway, Mosix has a lot of the same types of ideas. I have much less experience with it directly.

4 years, 2 months

2
1
0 0

Re: [COFF] [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM

by Theodore Ts'o

On Fri, Apr 02, 2021 at 09:11:47AM -0700, Larry McVoy wrote: > > Long before Linus released Linux into the wild in 1990 for the >>386<< much > > less any other ISA, IBM had been shipping as a product AIX/370 (and AIX/PS2 > > for the 386); which we developed at Locus for them. The user-space was > > mostly System V, the kernel was based on BSD (4.1 originally) pluis a great > > deal of customization, including of course the Locus OS work, which IBM > > called TCF - the transparent computing facility. It was very cool you > > could cluster 370s and PS/2 and from >>any<< node run a program of either > > ISA. It has been well discussed in this forum, previously. > > It's really a shame that TCF didn't get more widespread usage/traction. > That's exactly what BitMover wanted to do, I wanted to scale small cheap > SMPs in a cluster with a TCF layer on it. I gave some talks about it, > it obviously went nowhere but might have if we had TCF as a starting > point. TCF was cool. (Moving this to COFF...) Out of curiousity, how was TCF different or similar to Mosix? - Ted

4 years, 2 months

2
1
0 0

Was [TUHS] tabs vs spaces - entab, detab

by John P. Linderman

The tab/detab horse was still twitching, so I decided to beat it a little more. Doug's claim that tabs saving space was an urban legend didn't ring true, but betting again Doug is a good way to get poor quick. So I tossed together a perl script (version run through col -x is at the end of this note) to measure savings. A simpler script just counted tabs, distinguishing leading tabs, which I expected to be very common, from embedded tabs, which I expected to be rare. In retrospect, embedded tabs are common in (my) C code, separating structure types from the element names and trailing comments. As Norman pointed out, genuine tabs often preserve line to line alignment in the presence of small changes. So the fancier script distinguishes between leading tabs and embedded tabs for various possible tab stops. Small tab stops keep heavily indented code lines short, large tab stops can save more space when tabbing past leading blanks. My coding style uses "set-width" of 4, which vi turns into spaces or tabs, with "standard" tabs every 8 columns. My code therefore benefits most with tabstops every 4 columns. A lot of code is indented 4 spaces, which saves 3 bytes when replaced by a tab, but there is no saving with tabstops at 8. Here's the output when run on itself (before it was detabbed) and on a largish C program: /home/jpl/bin/tabsave.pl /home/jpl/bin/tabsave.pl rsort.c /home/jpl/bin/tabsave.pl, size 1876 2: Leading 202, Embedded 3, Total 205 4: Leading 303, Embedded 4, Total 307 8: Leading 238, Embedded 5, Total 243 rsort.c, size 209597 2: Leading 13186, Embedded 4219, Total 17405 4: Leading 19776, Embedded 5990, Total 25766 8: Leading 16506, Embedded 6800, Total 23306 The bytes saved by using tabs compared to the (detabbed) original size are not chump change, with 2, 4 or 8 column tabstops. On ordinary text, savings are totally unimpressive, usually 0. Your savings may vary. I think the horse is now officially deceased. -- jpl === #!/usr/bin/perl -w use strict; my @Tab_stops = ( 2, 4, 8 ); sub check_stop { my ($line, $stop_at) = @_; my $pos = length($line); my ($leading, $embedded) = (0,0); while ($pos >= $stop_at) { $pos -= ($pos % $stop_at); # Get to previous tab stop my $blanks = 0; while ((--$pos >= 0) && (substr($line, $pos, 1) eq ' ')) { ++$blanks; } if ($blanks > 1) { my $full = int($blanks/$stop_at); my $partial = $blanks - $full * $stop_at; my $savings = (--$partial > 0) ? $partial : 0; $savings += $full * ($stop_at - 1); if ($pos < 0) { $leading += $savings; } else { $embedded += $savings; } } } return ($leading, $embedded); } sub dofile { my $file = shift; my $command = "col -x < $file"; my $notabsfh; unless (open($notabsfh, "-|", $command)) { printf STDERR ("Open failed on '$command': $!"); return; } my $size = 0; my ($leading, $embedded) = (0,0); my @savings; for (my $i = 0; $i < @Tab_stops; ++$i) { $savings[$i] = [0,0]; } while (my $line = <$notabsfh>) { my $n = length($line); $size += $n; $line =~ s/(\s*)$//; for (my $i = 0; $i < @Tab_stops; ++$i) { my @l_e = check_stop($line, $Tab_stops[$i]); for (my $j = 0; $j < @l_e; ++$j) { $savings[$i][$j] += $l_e[$j]; } } } print("$file, size $size\n"); for (my $i = 0; $i < @Tab_stops; ++$i) { print(" $Tab_stops[$i]: "); my $l = $savings[$i][0]; my $e = $savings[$i][1]; my $t = $l + $e; print("Leading $l, Embedded $e, Total $t\n"); } print("\n"); } sub main { for my $file (@ARGV) { dofile($file); } } main();

4 years, 3 months

2
3
0 0

Re: [COFF] [TUHS] Pondering the hosts file

by Bakul Shah

On Mar 11, 2021, at 10:08 AM, Warner Losh <imp(a)bsdimp.com> wrote: > > On Thu, Mar 11, 2021 at 10:40 AM Bakul Shah <bakul(a)iitbombay.org> wrote: >> From https://www.freebsd.org/cgi/man.cgi?hosts(5) >> For each host a single line should be present with the following information: >> Internet address >> official host name >> aliases >> HISTORY >> The hosts file format appeared in 4.2BSD. > > While this is true wrt the history of FreeBSD/Unix, I'm almost positive that BSD didn't invent it. I'm pretty sure it was picked up from the existing host file that was published by sri-nic.arpa before DNS. A different and more verbose format. See RFCs 810 & 952. Possibly because it had to serve more purposes? > Warner > >>> On Mar 11, 2021, at 9:14 AM, Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> wrote: >>> Hi, >>> >>> I'm not sure where this message best fits; TUHS, COFF, or Internet History, so please forgive me if this list is not the best location. >>> >>> I'm discussing the hosts file with someone and was wondering if there's any historical documentation around it's format and what should and should not be entered in the file. >>> >>> I've read the current man page on Gentoo Linux, but suspect that it's far from authoritative. I'm hoping that someone can point me to something more authoritative to the hosts file's format, guidelines around entering data, and how it's supposed to function. >>> >>> A couple of sticking points in the other discussion revolve around how many entries a host is supposed to have in the hosts file and any ramifications for having a host appear as an alias on multiple lines / entries. To whit, how correct / incorrect is the following: >>> >>> 192.0.2.1 host.example.net host >>> 127.0.0.1 localhost host.example.net host >>> >>> >>> >>> -- >>> Grant. . . . >>> unix || die >> _______________________________________________ >> COFF mailing list >> COFF(a)minnie.tuhs.org >> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff

4 years, 3 months

1
0
0 0

Pondering the hosts file

by Grant Taylor

Hi, I'm not sure where this message best fits; TUHS, COFF, or Internet History, so please forgive me if this list is not the best location. I'm discussing the hosts file with someone and was wondering if there's any historical documentation around it's format and what should and should not be entered in the file. I've read the current man page on Gentoo Linux, but suspect that it's far from authoritative. I'm hoping that someone can point me to something more authoritative to the hosts file's format, guidelines around entering data, and how it's supposed to function. A couple of sticking points in the other discussion revolve around how many entries a host is supposed to have in the hosts file and any ramifications for having a host appear as an alias on multiple lines / entries. To whit, how correct / incorrect is the following: 192.0.2.1 host.example.net host 127.0.0.1 localhost host.example.net host -- Grant. . . . unix || die

4 years, 3 months

8
13
0 0

Ancient Pi [Was: Re: [TUHS] tabs vs spaces - entab, detab]

by Nemo Nusquam

4 years, 3 months

1
0
0 0

Quote from Wilkes

by Nemo Nusquam

I am currently reading "Memoirs of a Computer Pioneer" by Maurice Wilkes, MIT press. The following text from p. 145 may amuse readers. [p. 145] By June 1949 people had begun to realize that it was not so easy to get a program right as had at one time appeared. I well remember then this realization first came on me with full force. The EDSAC was on the top floor of the building and the tape-punching and editing equipment one floor below [...]. I was trying to get working my first non-trivial program, which was one for the numerical integration of Airy's differential equation. It was on one of my journeys between the EDSAC room and the punching equipment that "hesitating at the angles of stairs" the realization came over me with full force that a good part of the remainder of my life was going to spent in finding errors in my own programs. N.

4 years, 3 months

2
1
0 0

Re: [COFF] [TUHS] cut, paste, join, etc.

by Peter Jeremy

=> COFF since it's left Unix history behind. On 2021-Feb-16 21:08:15 -0700, Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> wrote: >I like SQLite and Berkeley DB in that they don't require a full RDBMS >running. Instead, an application can load what it needs and access the >DB itself. I also like SQLite and use it quite a lot. It is a full RDBMS, it just runs inside the client instead of being a separate backend server. (BDB is a straight key:value store). >I don't remember how many files SQLite uses to store a DB. One file. I often ship SQLite DB files between systems for various reasons and agree that the "one file" is much easier that a typical RDBMS. -- Peter Jeremy

4 years, 3 months

3
2
0 0

Re: [COFF] [TUHS] cut, paste, join, etc. (Grant Taylor)

by Rudi Blom

I've been maintaining a customer's application which uses C-ISAM as database interface on SCOUNIX, TRU64 and HP-UX. Simple and above all in 'C' ! As wiki says "IBM still recommends the use of the Informix Standard Engine for embedded applications" https://en.wikipedia.org/wiki/IBM_Informix_C-ISAM Mind you, the page hasn't seen significant changes since 2006 :-) Of course not having C-ISAM as a shared library can make executables a bit big unless included in a custom made shared library which I never really tried on SCOUNIX, but did on the newer UNIXes. A diskette used on SCOUNIX for certain offline salvage actions just isn't 'spacious' enough. Cheers, uncle rubl . >From: Grant Taylor <gtaylor(a)tnetconsulting.net> >To: coff(a)minnie.tuhs.org >Cc: >Bcc: >Date: Sat, 20 Feb 2021 10:23:35 -0700 >Subject: Re: [COFF] [TUHS] cut, paste, join, etc. >On 2/18/21 12:32 AM, Peter Jeremy via COFF wrote: >>I also like SQLite and use it quite a lot. It is a full RDBMS, it just runs inside the client >>instead of being a separate backend server. (BDB is a straight key:value store). > >Fair enough. > >I was referring to an external and independent daemon with it's own needs for care & >feeding. >. >>One file. I often ship SQLite DB files between systems for various reasons and agree >>that the "one file" is much easier that a typical RDBMS. > >*nod* > >-- >Grant. . . . >unix || die -- The more I learn the better I understand I know nothing.

4 years, 3 months

1
0
0 0

Fwd: [TUHS] nothing to do with unix, everything to do with history

by Dan Cross

The COFF folks may have a bead on this if no one on TUHS does. ---------- Forwarded message --------- From: ron minnich <rminnich(a)gmail.com> Date: Wed, Feb 10, 2021, 9:33 AM Subject: [TUHS] nothing to do with unix, everything to do with history To: TUHS main list <tuhs(a)minnie.tuhs.org> There's so much experience here, I thought someone might know: "Our goal is to develop an emulator for the Burroughs B6700 system. We need help to find a complete release of MCP software for the Burroughs B6700. If you have old magnetic tapes (magtapes) in any format, or computer printer listings of software or micro-fiche, micro-film, punched-card decks for any Burroughs B6000 or Burroughs B7000 systems we would like to hear from you. Email nw(a)retroComputingTasmania.com"

4 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

COFF