TUHS

tuhs@tuhs.org

29 participants
6557 discussions

Start a nNew thread

Re: Unix witticisms

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy > Annnnnnnd, that's the thread, noone can top that! "EMACS - Editor too big" Noel

7 years, 10 months

Please .. no DKIM chatter here

by Warren Toomey

Hi all. First up, it's TUHS so please no DKIM/email chatter here. Only a few of you are involved and it's not relevant to Unix history. Grant Taylor and Tom Ivar Helbekkmo having been working behind the scenes to find a good solution. We are hoping to a) merge the two lists back together, b) reinstate [TUHS] and non-mangled From: lines, and c) keep most MTAs happy in the process. With some luck, all of this will be resolved. So, let's get back to the discussion of old Unix systems :) Thanks, Warren

7 years, 10 months

Mangled and non-mangled TUHS mail lists

by Warren Toomey

All, there are now two variants of the TUHS mailing list. E-mail sent to tuhs(a)tuhs.org will propagate to both of them. The main TUHS list now: - doesn't strip incoming DKIM headers - doesn't alter the From: line - doesn't alter the Subject: line and hopefully will keep most mail systems happy. The alternative, "mangled", TUHS list: - strips incoming DKIM headers - alters the From: line - alters the Subject: line to say [TUHS] - puts in DKIM headers once this is done and hopefully will keep most mail systems happy but in a different way. You can choose to belong to either list, just send me an e-mail if you want to be switched to the other one. But be patient to start with as there will probably be quite a few wanting to change. Cheers, Warren

7 years, 10 months

And now ... Weirdnix?

by Warren Toomey

And now, we bring the RMS/Gnu thread to a close :-) To kick a more relevant thread off, what was the "weirdest" Unix system you used & why? Could be an emulation like Eunice, could be the hardware e.g NULL was not zero, NUXI byte ordering etc. Cheers, Warren -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

7 years, 10 months

NUMA, Sequent NUMA-Q, etc

by Kevin Bowling

NUMA is something that's been on my mind a lot lately. Partially in seeding beastie ideas into Larry McVoy's brain. I asked Paul McKenney for some history on what went down at Sequent since that's before my time. He sent me this, which I think the group will enjoy: http://www2.rdrop.com/users/paulmck/techreports/stingcacm3.1999.08.04a.pdf It looks pretty nice. Not sure anyone's come as close as Irix to solving and productizing "easy" NUMA but that's the one I have the most hands on experience with. They can affine, place, migrate, and even replicate many types of resources including vnodes. I'm actually surprised all that code seems to have been spiked and it doesn't seem like either Sequent née IBM nor SGI brought forward any of their architecture to Linux. Paul did RCU which is a tour de force, but the Linux topology and MM code looks like the product of sustaining engineers instead of architectural decree. Maybe the SCO lawsuit snubbed all of that? HP has an out of date competitive analysis that's worth a look http://h20566.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=5060289&docLoc…. I don't have enough seat time with Tru64 but maybe they had some good ideas. As open source, I do like Illumos' locality groups. I can't make much sense of Linux on this, too much seems to be in arch/ vs a first class concept like locality groups. Regards, Kevin

7 years, 10 months

Re: Favorite UNIX

by jnc＠mercury.lcs.mit.edu

> From: Don Hopkins > Solaris: so bad I left the company. Why was Solaris so much worse than SunOS? I guess the Sun management didn't understand that was the case? Or were they so hot for the AT+T linkup that they were willing to live with it? Noel

7 years, 10 months

Re: [TUHS] SunOS to Solaris - why?

by Larry McVoy

As I've said elsewhere, Sun was out of money. AT&T bought $200m of Sun stock at 35% over market but Sun had to dump SunOS and got to SVR4. I don't know if Scooter knew what he was dumping or not, I suspect not but all those late nights when he came over to egg us kernel geeks on, maybe he did know. I don't think he had a choice. On Sun, Oct 01, 2017 at 12:59:42PM -0400, Arthur Krewat via TUHSmangle wrote: > From Sun's point of view, what was the REAL reason to move from SunOS to > Solaris? > > I don't think I've read anything anywhere as to a real technical reason. Was > it just some stuffed-shirt's "great idea"? > > Or was it really a standards-based or other reality-based reason? > > As of SunOS 4.1.4, it seemed ready to go whole-hog into SMP, so that wasn't > the sole reason. > > thanks! > art k. > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

7 years, 10 months

Re: Favorite Unix?

by Lawrence Stewart

I’m an HPC guy. The only good OS is one that is not executing any instructions except mine. No daemons, no interrupts, nothing. Load my code, give me all physical memory, give me direct access to the interconnect and then get out of the way. If I want anything, I will let you know, but don’t wait up. When I put on an educator’s hat I still have a soft spot for V6 and V7. Those were my first exposure to Unix and the Unix Way. One could actually learn style by reading code and writing device drivers. These days kernels (Linux at least) are too complicated and too cluttered up with ifdefs to learn much. The real recent innovations like RCU and queuing locks and NUMA affinity are buried pretty deep, and actual reliable file systems like ZFS and BTRFS are just too complicated for mortals. As a user, what I really want are reliability, the commands and utilities, and stable APIs. I don’t like a lot of things about Posix, but it is at least a little stable and a little portable. For myself, I use MacOS and Debian Linux, and open, close, read, write. -Larry

7 years, 10 months

Re: Favorite UNIX

by Michael Parson

On Sun, 1 Oct 2017, arnold(a)skeeve.com wrote: > Date: Sun, 01 Oct 2017 09:13:28 -0600 > Michael Parson <mparson(a)bl.org> wrote: > >> On 2017-09-30 12:53, Ian Zimmerman wrote: >>> On 2017-09-30 10:40, Michael Parson wrote: >>> >>>> I've recently found instructions for installing SunOS 4.1.3 under >>>> qemu-sparc that I want to try as well. >>> >>> Can you share a pointer to those with us? >> >> Sure: >> >> https://en.wikibooks.org/wiki/QEMU/SunOS_4.1.4 >> >> Oops, 4.1.4, not .3. :) > > So then the next question is where can one find install media (or > image thereof...) I bought a boxed copy of 'Solaris 1.1.2' off e-bay many moon ago, though I've been told it can be found with the google search term of 'winworldpc'. -- Michael Parson Pflugerville, TX KF5LGQ

7 years, 10 months

Re: Favorite UNIX

by Will Senn

On Sep 28, 2017 11:02 PM, "Kevin Bowling" <kevin.bowling(a)kev009.com> wrote: What is your favorite UNIX. Three possible categories, choose one or more: 1) Free 2) Forced to use a commercial platform. I guess that could include macOS and z/OS with some vivid imagination, maybe even NT. 3) Historical 1. FreeBSD. It's super stable and tends to be logical. The documentation is great once you get over the learning curve. Debian is a close second for the same reasons. Mint with KDE Plasma 5 is beautiful and user friendly. 2. I used Sun OS with a CDE-like interface back in the day and that was ok. Mac OS X 10.5-10.12 are great. 3. I enjoy the research versions of unix and other OSes that are available for the SimH PDP 11 emulator. Will

7 years, 10 months

Re: [TUHS] Line Terminators in Text Files [

by Clem Cole

On Sun, Sep 3, 2017 at 11:08 AM, Warner Losh <imp(a)bsdimp.com> wrote: > > > On Sat, Sep 2, 2017 at 8:54 PM, Dave Horsfall <dave(a)horsfall.org> wrote: > >> On Sat, 2 Sep 2017, Nemo wrote: >> >> Hhhmmm... This begs the historical question: When did LF replace CR/LF >>> in UNIX? >>> >> >> Unix has always used NL as the terminator :-) > > > <CR><LF> was the line terminator in DEC operating systems that grew up > around the same time as Unix. CP/M and MS-DOS inherited that from them > since those systems were developed, in part, using cross compilers running > on DEC gear with DEC OSes. Unix came from the Multics world where LF was > used as the line terminator... Thankfully, neither CP/M nor MS-DOS picked > up DEC's RMS... > > Warner > The fun story on that Warner is after years of dogged defense of RMS, when C was written for VMS, Cutler had to add Stream I/O. The moment is was released, much (?most?) of customer base (including a lot of internal folks like the compiler runtime and DB folks) switched to using it. It was so much easier. I never heard Dave back down, but it I used to smile when I saw the statistics.

7 years, 10 months

Favorite UNIX

by Kevin Bowling

What is your favorite UNIX. Three possible categories, choose one or more: 1) Free 2) Forced to use a commercial platform. I guess that could include macOS and z/OS with some vivid imagination, maybe even NT. 3) Historical Me: 1) FreeBSD - I find it to generally be the least annoying desktop and laptop experience with admittedly careful selection of hardware to ensure compatibility. It's ideal to me for commercial appliances and servers due to the license, tight coupling of kernel and base, and features like ZFS, jails, and pluggable TCP stacks. Linux distros lost their luster for me once systemd was integrated into Debian, and that kind of culture seems to be prevailing up and down the stack in a way that I'd prefer to be an outside observer of Linux and not dependent on it for now. 2) AIX - I often see people disparage AIX but I like it. I learned a lot in my teens about C, build systems, compilers, and lots of libraries trying to port random software to it for auto-didactic reasons. It definitely doesn't feel like any other UNIX. It probably supports high core count and NUMA better than any other system except Linux, it had advanced virtualization with LPARs and containers with WPARs before most and hot patchable kernel, fully pagable kernel, lots of rigorous kernel engineering there that didn't get a lot of fanfare. SMIT is kind of cool as a TUI and spits out commands that you can learn through repetition and use at the CLI or scripting. I think it probably peaked in the early 2000s, but the memory management, volume management, and file systems all seemed pretty forward thinking up until then. I don't think SMP performance was a strong suite until it was pretty much a relegated niche though. 3) IRIX - it just screams '90s cool like an acrylic sweater. Soft real time, immense graphics support, pro audio and video features, lots of interesting commercial software, NUMA, supercomputers. I enjoy tinkering on this still, but a lot of that is due to the neat hardware. Regards, Kevin

7 years, 10 months

Re: [TUHS] UNIX of choice these days?

by Norman Wilson

Warner Losh: It's an abundance of caution thing. This code had security problems in the past, we're not 100% sure that we've killed all the issues, though we believe we have. ==== And if there isn't anyone who's actively interested in the code, willing to dig in to clean it up and make security issues less likely, deal with multiprocessing matters, and so on, that's a perfectly reasonable stance. I think it's an unfortunate result, and I wonder how much of it comes from a cultural view that sysctl >> /proc. (Recall how Ken and Dennis originally resisted Doug's push for pipelines and filters, because--as Dennis once put it in a talk--it just wasn't the way programs worked?) But as someone who is sometimes credited with removing more code than he wrote while working on the latter-day Research kernel, it's hard for me to argue with the principle. A lot of the code I tossed out was complicated stuff that was barely used if used at all, and that nobody was willing to step up to volunteer to maintain. Norman Wilson Toronto ON

7 years, 10 months

UNIX of choice these days?

by Arthur Krewat

What's your UNIX of choice to do normal "real" things these days? Home file server (NAS), business stuff, develop code, whatever. Mine is Solaris 11.3 at this point. Oracle has provided almost all the "normal" utilities that are used by Linux folk, and it runs on Intel hardware rather well. My main storage is a raidz2 of 24TB and I get 1.2GB/sec to a bunch of 3TB 512-byte-sector SAS drives. It serves my vmware farm with iSCSI at 10gbe using COMSTAR, which also houses a bunch of Solaris 11 guests that perform various chores. It also houses some Linux and Windows guests for prototyping/testing. It's also my Samba server, servicing a few Windows workstations. This is all in my home office where I do all my personal/professional work. What do you all use for day-to-day development and general playing around with new stuff? AAK

7 years, 10 months

Re: [TUHS] [Groff] pic.ps

by Doug McIlroy

>> The Fedora system I have access to lacks /usr/share/doc/groff > Fedora defaults to loading only the package "groff-base" so that man pages can be displayed. To actually use groff for any other purpose, the packages "groff", "groff-doc", "groff-perl", and "groff-X11" have to be installed. Annoying, but there it is. That explains all. Thanks. doug

7 years, 10 months

Re: [TUHS] UNIX of choice these days?

by Derek Fawcus

On Thu, Sep 28, 2017 at 06:44:20PM +0100, Derek Fawcus wrote: > On Thu, Sep 28, 2017 at 08:34:28AM -0400, Chet Ramey wrote: > > Yes, that changed in 2007 based on bug reports you filed while working at Cisco. > > So fd 255 is my fault? :-) Or not - given that macOS, using an older bash already used 255: $ set|fgrep VERSION BASH_VERSION='3.2.57(1)-release' $ lsof -p $$|fgrep CHR bash 6843 derek 0u CHR 16,10 0t554677 701 /dev/ttys010 bash 6843 derek 1u CHR 16,10 0t554677 701 /dev/ttys010 bash 6843 derek 2u CHR 16,10 0t554677 701 /dev/ttys010 bash 6843 derek 255u CHR 16,10 0t554677 701 /dev/ttys010 DF

7 years, 10 months

Re: [TUHS] RFS was: Re: UNIX of choice these days?

by David

> > It's important to note, when talking about NFS, that there was Sun's NFS > and everyone else's NFS. Sun ran their entire company on NFS. /usr/dist > was where all the software that was not part of SunOS lived, it was an > NFS mounted volume (that was replicated to each subnet). It was heavily > used as were a lot of other things. The automounter at Sun just worked, > wanted to see your buddies stuff? You just cd-ed to it and it worked. > > Much like mmap, NFS did not export well to other companies. When I went > to SGI I actually had a principle engineer (like Suns distinguished > engineer) tell me "nobody trusts NFS, use rcp if you care about your > data". What. The. Fuck. At Sun, NFS just worked. All the time. > The idea that it would not work was unthinkable and if it ever did > not work it got fixed right away. > > Other companies, it was a checkbox thing, it sorta worked. That was > an eye opener for me. mmap was the same way, Sun got it right and > other companies sort of did. > I remember the days of NFS Connect-a-thons where all the different vendors would get together and see if they all interoperated. It was interesting to see who worked and who didn’t. And all the hacking to fix your implementation to talk to vendor X while not breaking it working with vendor Y. Good times indeed. David

7 years, 10 months

Re: [TUHS] RFS was: Re: UNIX of choice these days?

by jnc＠mercury.lcs.mit.edu

> From: Theodore Ts'o > when a file was truncated and then rewritten, and "truncate this file" > packet got reordered and got received after the "here's the new 4k of > contents of the file", Hilar[i]ty Enused. This sounds _exactly_ like a bad bug found in the RVD protocol (Remote Virtual Disk - a simple block device emulator). Disks kept suffering bit rot (damage to the inodes, IIRC). After much suffering, and pain trying to debug it (lots of disk writes, how do you figure out the one that's the problem), it was finally found (IIRC, it wasn't something thinking about it, they actually caught it). Turned out (I'm pretty sure my memory of the bug is correct), if you had two writes of the same block in quick sucession, and the second was lost, if the first one's ack was delayed Just Enough... They had an unused 'hint' (I think) field in the protocol, and so they recycled that to be a sequence number, so they could tell ack's apart. Noel

7 years, 10 months

Re: [TUHS] UNIX of choice these days?

by Norman Wilson

Larry McVoy: > +1 on what Ron said. I don't get the rationale for going back to ptrace. > Anyone know what it is? Is there a perf issue? Kurt H Maier: The usual rationale presented is that someone can exhaust the fd table and then you can't get anything done. Instead of fixing that problem, the popular approach is to add more syscalls, like with getrandom(2). ==== Funny that that rationale isn't extended to its logical conclusion: get rid of open and creat. Then nobody needs to worry about running out of file descriptors ever! I too am saddened to see such a retrograde step, but perhaps I'm biased. When I arrived in 1127, the kernel had /proc but still had ptrace as well. Why? Because no one was brave enough to wade into sdb and adb. After a couple of years, I felt brave enough, so I did it. Once the revised sdb and adb had propagated to all our systems, I removed the syscall. I celebrated by physically removing ptrace(2) from the Eighth Edition manual in the UNIX room: the manual entry comprised two facing pages, which I glued together. I can sympathize with FreeBSD excuse someone cited elsewhere, that nobody used the code so it should go--I'm always in favour of improving programs by chopping sutff out--but I think the decision here was backwards. The proper answer would have been to teach ps et al to use /proc, not to invent a new complex of system calls. I dislike how Linux has tossed information about processes and other system-related data into the same namespace (and now that there is /sys as well as /proc, I wonder whether it's time to divorce them, or even to move /proc into /sys/proc), but the general direction of moving things into the file system makes sense. I have some qualms about adding more and more code to the kernel that just does string processing (making the kernel bigger and more complicated, and widening the attack surface for bad guys), though; maybe most of that stuff belongs not in the OS proper but in a user-mode program that reads /dev/mem and presents as a file system. Norman Wilson Toronto ON

7 years, 10 months

Re: [TUHS] APPLIX-L On this day... (Rosetta Stone, Einstein's equation, first Model T, first passenger train)

by Dave Horsfall

On Wed, 27 Sep 2017, Roland Turner wrote: > * Simply attaching the entire message as a message/rfc822 part is an > appealing approach, but very few mail clients would do anything > intelligent with it. My MUA of choice, Alpine, certainly does, and it's hardly uncommon. I tried Elm once, and immediately went straight back to Pine (as it was known then); never bothered with Mutt. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 10 months

TUHS: munged From header for DKIM

by Warren Toomey

All, I've set up a mirror TUHS list which munges the From: line to keep mail systems like Gmail happy. I've migrated some of you over to this new list: those whose subscriptions were disabled due to excessive bounces. I'm hoping that this will a) fix most of the bounce problems and b) keep those who don't want address munging happy. If I've moved you and you want to be put back on the non-munged list, let me know. Fingers crossed that this is a good solution, Warren

7 years, 10 months

Excessive bouncing ... argh!

by Warren Toomey

All, overnight the mail list blocked about 60 people because of excessive bouncing. It was probably because the list has been busy, and the bounce threshold for the (mostly gmail) addresses was exceeded. I've manually re-enabled them all. I have installed the script that strips DKIM and ARC header lines before the list software processes the inbound e-mails. We will see if that helps. Apologies, Warren

7 years, 10 months

Another mail list idea

by Warren Toomey

All, I just had a whole bumch of gmail addresses disabled on the TUHS list because of DKIM. I had an idea. I'll create a second list which munges the From: line. E-mail to tuhs(a)tuhs.org will go to both lists. I'll move the gmail people over to the munging list. This is just a test e-mail to see if the munging list works. I'm the only one on it. If it seems to work, I'll move the gmail folk over. Cheers, Warren

7 years, 11 months

Re: [TUHS] Sockets and the true UNIX

by Norman Wilson

Clem Cole: It was never designed for it. dmr designed Streams to replace the tty handler. I never understood why the Summit guys insisted on forcing networking into it. ====== You've mistaken. The point of the stream I/O setup with stackable line disciplines, rather than the old single line-discipline switch, was specifically to support networking as well as tty processing. Serial-device drivers in V7 used a single line-discipline driver, used variously for canonical-tty handling and for network protocols. The standard system as used outside the labs had only one line discipline configured, with standard tty handling (see usr/sys/conf/c.c). There were driver source files for what I think were internal-use-only networks (dev/pk[12].c, perhaps), but I don't think they were used outside AT&T. The problem Dennis wanted to solve was that tty handling and network protocol handling interfered with one another; you couldn't ask the kernel to do both, because there was only one line discipline at a time. Hence the stackable modules. It was possible to duplicate tty handling (probably by placing calls to the regular tty line discipline's innards) within the network-protocol code, but that was messy. It also ran into trouble when people wanted to use the C shell, which expected its own special `new tty' line discipline, so the network code would have to know which tty driver to call. It made more sense to stack the modules instead, so the tty code was there only if it was needed, and different tty drivers could exist without the network code knowing or caring. When I arrived at the Labs in 1984, the streams code was in use daily by most of us in 1127. The terminals on our desks were plugged into serial ports on Datakit (like what we call a terminal server now). I would turn on my terminal in the morning, tell the prompt which system I wanted to connect to, and so far as I could tell I had a direct serial connection. But in the remote host, my shell talked to an instance of the tty line module, which exchanged data with a Datakit protocol module, which exchanged data with the low-level Datakit driver. If I switched to the C shell (I didn't but some did), csh would pop off the tty module and push on the newtty module, and the network code was none the wiser. Later there was a TCP/IP that used the stream mechanism. The first version was shoehorned in by Robert T Morris, who worked as a summer intern for us; it was later cleaned up considerably by Paul Glick. It's more complicated because of all the multiplexers involved (Ethernet packets split up by protocol number; IP packets divided by their own protocol number; TCP packets into sessions), but it worked. I still use it at home. Its major flaw is that details of the original stream implementation make it messy to handle windows of more than 4096 bytes; there are also some quirks involving data left in the pipe when a connection closes, something Dennis's code doesn't handle well. The much-messier STREAMS that came out of the official System V people had fixes for some of that, but at the cost of quite a bit more complexity; it could probably be done rather better. At one point I wanted to have a go at it, but I've never had the time, and now I doubt I ever will. One demonstration of virtue, though: although Datakit was the workhorse network in Research when I was there (and despite the common bias against virtual circuits it worked pretty well; the major drawback was that although the underlying Datakit fabric could run at multiple megabits per second, we never had a host interface that could reliably run at even a single megabit), we did once arrange to run TCP/IP over a Datakit connection. It was very simple in concept: make a Datakit connection (so the Datakit protocol module is present); push an IP instance onto that stream; and off you go. I did something similar in my home V10 world when quickly writing my own implementation of PPP from the specs many years ago. The core of that code is still in use in my home-written PPPoE code. PPP and PPPoE are all outside the kernel; the user-mode program reads and writes the serial device (PPP) or an Ethernet instance that returns just the desired protocol types (PPPoE), does the PPP processing, and reads and writes IP packets to a (full-duplex stream) pipe on the other end of which is pushed the IP module. All this is very different from the socket(2) way of thinking, and it has its vices, but it also has its virtues. Norman Wilson Toronto ON

7 years, 11 months

Re: [TUHS] Unix of choice these days?

by Doug McIlroy

>> "Bah. That's just some goof-ball research toy." > I feel like the same thing was said about Unix at some point very early in it's history. Amusingly the IT department of AT&T felt that way and commissioned a Harvard prof, no less, to write a report about why VMS was the way to go on Vaxen. The hired gun (so much for academic integrity) addressed the subject almost entirely with meta arguments: (1) VMS was written by OS professionals; Unix was a lab experiment. (2) One could count on support from DEC, not from Research. (So much for USG; as far as i know the author never asked anyone in] Bell Labs about anything.) (3) And the real killer: VMS was clearly far advanced, witness its shelf of manuals vs the thin Unix volumes that fit in one's briefcase. Lee McMahon had particular fun with this one in a rebuttal that unleashed the full power of his Jesuit training in analytic debate. Doug

7 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS