TUHS

tuhs@tuhs.org

34 participants
6419 discussions

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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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