- COFF - www.tuhs.org

Will someone please explain the history and usage of gpasswd / newgrp / sg?

by Grant Taylor

Hi, Will someone please explain the history and usage of gpasswd / newgrp / sg? I've run across them again recently while reading old Unix texts. I've been aware of them for years, but I've never actually used them for anything beyond kicking the tires. So I figured that I'd inquire of the hive mind that is TUHS / COFF. When was the concept of group passwords introduced? What was the problem that group passwords were the solution for? How common was the use of group passwords? I ran into one comment indicating that they used newgrp to work around a limitation in the number of (secondary) groups in relation to an NFS implementation. Specifically that the implementation of NFS they were using didn't support more than 16 groups. So they would switch their primary group to work around this limit. Does anyone have any interesting stories related to group passwords / gpasswd / newgrp / sg? -- Grant. . . . unix || die

3 years, 7 months

4
4
0 0

Double posting

by jnc＠mercury.lcs.mit.edu

Can people **please** send posts to one of these two lists, only? Having to go through and delete every other post (yeah, I know, I could relete _all_ messages to either list, since they are archived, but old habits are hard to break) is _really_ annoying. OK, I can see sending an _initial_ query to both lists, to get it to as wide a circle as possible: _but_ BCC at least one of them, to prevent lazy people just hitting 'reply all' and thereby sanding out multiple copies of their reply. Thank you. Noel

3 years, 7 months

6
7
0 0

Re: [COFF] [TUHS] Will someone please explain the history and usage of gpasswd / newgrp / sg?

by Clem Cole

3BSD has the V7 scheme, the new kernel code where there is a group list in the process is not introduced until later/ ᐧ On Mon, Nov 15, 2021 at 1:46 PM Henry Bent <henry.r.bent(a)gmail.com> wrote: > On Mon, 15 Nov 2021 at 13:31, Clem Cole <clemc(a)ccc.com> wrote: > >> Grant, >> >> Mashey and crew basically did most of the original group work as part of >> PWB. If you look at the Sixth Edition sources and the PWB 1.0 stuff, that >> is one of the places you will find differences. With Seventh Edition (or I >> believe as part of the UNIX/TS work that Ken picked up), the Mashey group >> changes went back into the Research stream. With one of the predecessors to >> 4.2BSD (it may have 4.1A or 4.1B but frankly I have forgotten) Joy >> introduced the group scheme we all use today. >> >> > Looking at the TUHS archives, unless I'm missing something, 3BSD has > groups that appear to be in the modern format: > > % ls -l /bsd/3bsd/etc/group > -r--r--r-- 1 root root 44 1980-01-02 22:08 /bsd/3bsd/etc/group > % cat /bsd/3bsd/etc/group > staff:*:10:bill,ozalp > grad:*:20: > prof:*:30: > % find . -name 'chgrp*' | xargs ls -l > -r-xr-xr-x 1 root root 6960 Dec 30 1979 ./usr/bin/chgrp > -r--r--r-- 1 root root 26 Feb 12 1979 ./usr/man/man1/chgrp.1 > -r--r--r-- 1 root root 754 Feb 12 1979 ./usr/src/cmd/chgrp.c > > -Henry >

3 years, 7 months

2
2
0 0

Vaxen, my children, just don't belong some places

by Dave Horsfall

[ Warning: you need to be an OF to understand the references ] I don't think I've ever posted this here... And trust me, an IBM 3090 was really big iron in those days. I don't recall the author, but I found it on the 'net. ----- VAXen, my children, just don't belong some places. In my business, I am frequently called by small sites and startups having VAX problems. So when a friend of mine in an Extremely Large Financial Institution (ELFI) called me one day to ask for help, I was intrigued because this outfit is a really major VAX user - they have several large herds of VAXen - and plenty of sharp VAXherds to take care of them. So I went to see what sort of an ELFI mess they had gotten into. It seems they had shoved a small 750 with two RA60s running a single application, PC style, into a data center with two IBM 3090s and just about all the rest of the disk drives in the world. The computer room was so big it had three street addresses. The operators had only IBM experience and, to quote my friend, they were having "a little trouble adjusting to the VAX", were a bit hostile towards it and probably needed some help with system management. Hmmm, hostility... Sigh. Well, I thought it was pretty ridiculous for an outfit with all that VAX muscle elsewhere to isolate a dinky old 750 in their Big Blue Country, and said so bluntly. But my friend patiently explained that although small, it was an "extremely sensitive and confidential application." It seems that the 750 had originally been properly clustered with the rest of a herd and in the care of one of their best VAXherds. But the trouble started when the Chief User went to visit his computer and its VAXherd. He came away visibly disturbed and immediately complained to the ELFI's Director of Data Processing that, "There are some very strange people in there with the computers." Now since this user person was the Comptroller of this Extremely Large Financial Institution, the 750 had been promptly hustled over to the IBM data center which the Comptroller said, "was a more suitable place." The people there wore shirts and ties and didn't wear head bands or cowboy hats. So my friend introduced me to the Comptroller, who turned out to be five feet tall, 85 and a former gnome of Zurich. He had a young apprentice gnome who was about 65. The two gnomes interviewed me in whispers for about an hour before they decided my modes of dress and speech were suitable for managing their system and I got the assignment. There was some confusion, understandably, when I explained that I would immediately establish a procedure for nightly backups. The senior gnome seemed to think I was going to put the computer in reverse, but the apprentice's son had an IBM PC and he quickly whispered that "backup" meant making a copy of a program borrowed from a friend and why was I doing that? Sigh. I was shortly introduced to the manager of the IBM data center, who greeted me with joy and anything but hostility. And the operators really weren't hostile - it just seemed that way. It's like the driver of a Mack 18 wheeler, with a condo behind the cab, who was doing 75 when he ran over a moped doing its best to get away at 45. He explained sadly, "I really warn't mad at mopeds but to keep from runnin' over that'n, I'da had to slow down or change lanes!" Now the only operation they had figured out how to do on the 750 was reboot it. This was their universal cure for any and all problems. After all it works on a PC, why not a VAX? Was there a difference? Sigh. But I smiled and said, "No sweat, I'll train you. The first command you learn is HELP" and proceeded to type it in on the console terminal. So the data center manager, the shift supervisor and the eight day-operators watched the LA100 buzz out the usual introductory text. When it finished they turned to me with expectant faces and I said in an avuncular manner, "This is your most important command!" The shift supervisor stepped forward and studied the text for about a minute. He then turned with a very puzzled expression on his face and asked, "What do you use it for?" Sigh. Well, I tried everything. I trained and I put the doc set on shelves by the 750 and I wrote a special 40 page doc set and then a four page doc set. I designed all kinds of command files to make complex operations into simple foreign commands and I taped a list of these simplified commands to the top of the VAX. The most successful move was adding my home phone number. The cheat sheets taped on the top of the CPU cabinet needed continual maintenance, however. It seems the VAX was in the quietest part of the data center, over behind the scratch tape racks. The operators ate lunch on the CPU cabinet and the sheets quickly became coated with pizza drippings, etc. But still the most used solution to hangups was a reboot and I gradually got things organized so that during the day when the gnomes were using the system, the operators didn't have to touch it. This smoothed things out a lot. Meanwhile, the data center was getting new TV security cameras, a halon gas fire extinguisher system and an immortal power source. The data center manager apologized because the VAX had not been foreseen in the plan and so could not be connected to immortal power. The VAX and I felt a little rejected but I made sure that booting on power recovery was working right. At least it would get going again quickly when power came back. Anyway, as a consolation prize, the data center manager said he would have one of the security cameras adjusted to cover the VAX. I thought to myself, "Great, now we can have 24 hour video tapes of the operators eating Chinese takeout on the CPU." I resolved to get a piece of plastic to cover the cheat sheets. One day, the apprentice gnome called to whisper that the senior was going to give an extremely important demonstration. Now I must explain that what the 750 was really doing was holding our National Debt. The Reagan administration had decided to privatize it and had quietly put it out for bid. My Extreme Large Financial Institution had won the bid for it and was, as ELFIs are wont to do, making an absolute bundle on the float. On Monday the Comptroller was going to demonstrate to the board of directors how he could move a trillion dollars from Switzerland to the Bahamas. The apprentice whispered, "Would you please look in on our computer? I'm sure everything will be fine, sir, but we will feel better if you are present. I'm sure you understand?" I did. Monday morning, I got there about five hours before the scheduled demo to check things over. Everything was cool. I was chatting with the shift supervisor and about to go upstairs to the Comptroller's office. Suddenly there was a power failure. The emergency lighting came on and the immortal power system took over the load of the IBM 3090s. They continued smoothly, but of course the VAX, still on city power, died. Everyone smiled and the dead 750 was no big deal because it was 7 AM and gnomes don't work before 10 AM. I began worrying about whether I could beg some immortal power from the data center manager in case this was a long outage. Immortal power in this system comes from storage batteries for the first five minutes of an outage. Promptly at one minute into the outage we hear the gas turbine powered generator in the sub-basement under us automatically start up getting ready to take the load on the fifth minute. We all beam at each other. At two minutes into the outage we hear the whine of the backup gas turbine generator starting. The 3090s and all those disk drives are doing just fine. Business as usual. The VAX is dead as a door nail but what the hell. At precisely five minutes into the outage, just as the gas turbine is taking the load, city power comes back on and the immortal power source commits suicide. Actually it was a double murder and suicide because it took both 3090s with it. So now the whole data center was dead, sort of. The fire alarm system had its own battery backup and was still alive. The lead acid storage batteries of the immortal power system had been discharging at a furious rate keeping all those big blue boxes running and there was a significant amount of sulfuric acid vapor. Nothing actually caught fire but the smoke detectors were convinced it had. The fire alarm klaxon went off and the siren warning of imminent halon gas release was screaming. We started to panic but the data center manager shouted over the din, "Don't worry, the halon system failed its acceptance test last week. It's disabled and nothing will happen." He was half right, the primary halon system indeed failed to discharge. But the secondary halon system observed that the primary had conked and instantly did its duty, which was to deal with Dire Disasters. It had twice the capacity and six times the discharge rate. Now the ear splitting gas discharge under the raised floor was so massive and fast, it blew about half of the floor tiles up out of their framework. It came up through the floor into a communications rack and blew the cover panels off, decking an operator. Looking out across that vast computer room, we could see the air shimmering as the halon mixed with it. We stampeded for exits to the dying whine of 175 IBM disks. As I was escaping I glanced back at the VAX, on city power, and noticed the usual flickering of the unit select light on its system disk indicating it was happily rebooting. Twelve firemen with air tanks and axes invaded. There were frantic phone calls to the local IBM Field Service office because both the live and backup 3090s were down. About twenty minutes later, seventeen IBM CEs arrived with dozens of boxes and, so help me, a barrel. It seems they knew what to expect when an immortal power source commits murder. In the midst of absolute pandemonium, I crept off to the gnome office and logged on. After extensive checking it was clear that everything was just fine with the VAX and I began to calm down. I called the data center manager's office to tell him the good news. His secretary answered with, "He isn't expected to be available for some time. May I take a message?" I left a slightly smug note to the effect that, unlike some other computers, the VAX was intact and functioning normally. Several hours later, the gnome was whispering his way into a demonstration of how to flick a trillion dollars from country 2 to country 5. He was just coming to the tricky part, where the money had been withdrawn from Switzerland but not yet deposited in the Bahamas. He was proceeding very slowly and the directors were spellbound. I decided I had better check up on the data center. \Most of the floor tiles were back in place. IBM had resurrected one of the 3090s and was running tests. What looked like a bucket brigade was working on the other one. The communication rack was still naked and a fireman was standing guard over the immortal power corpse. Life was returning to normal, but the Big Blue Country crew was still pretty shaky. Smiling proudly, I headed back toward the triumphant VAX behind the tape racks where one of the operators was eating a plump jelly bun on the 750 CPU. He saw me coming, turned pale and screamed to the shift supervisor, "Oh my God, we forgot about the VAX!" Then, before I could open my mouth, he rebooted it. It was Monday, 19-Oct-1987. VAXen, my children, just don't belong some places. -- Dave

3 years, 8 months

3
2
0 0

TOPS-10 question

by Adam Thornton

So I have a very vanilla TOPS-10 system running. The console is being spammed with: [DAEMON: %AVAIL.A77 already used, can't rename AVAIL.SYS] Somewhere, evidently, there's a directory of files that are backups of AVAIL.SYS, and it needs cleaning out. How do I find that directory? Adam

3 years, 8 months

2
1
0 0

Charles Moore's Birthday

by Nemo Nusquam

Dave, No message about Charles Moore? N. -------- Forwarded Message -------- Subject: Re: Chuck;'s Birthday Date: Thu, 09 Sep 2021 10:37:29 -0700 From: Paul Rubin <no.email(a)nospam.invalid> Newsgroups: comp.lang.forth Jurgen Pitaske <jpitaske(a)gmail.com> writes: > It is Chuck Moore's 83rd birthday today. > You might want to send some greetings, > here a link to his facebook - or you might have his email address > .https://www.facebook.com/charleshavicemoore Happy 83rd birthday Chuck! Or perhaps I should say: 83 birthday Chuck happy

3 years, 9 months

1
0
0 0

Re: [COFF] What does your "cal" show? (fwd)

by Dave Horsfall

> Ah, leap seconds. I work for an observatory. Some things are in TAI > and some are in UTC. At least now I know what to look for when > something is 37 seconds off. Isn't about that the transit of the Moon or something? -- Dave

3 years, 9 months

3
2
0 0

What does your "cal" show?

by Dave Horsfall

In 1752 we switched to the Gregorian calendar, with the peasants revolting (as if they weren't already) because they thought they'd lost 11 days of their lives. What does "cal 9 1752" show on your boxes? -- Dave

3 years, 9 months

10
14
0 0

Re: [COFF] What does your "cal" show?

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > What does "cal 9 1752" show on your boxes? Given that the source: https://minnie.tuhs.org//cgi-bin/utree.pl?file=V6/usr/source/s1/cal.c has been in C since at least V6, I'd be rather surprised if on other machines it did anything other than what those of us who were paying attention read in the documentation: https://minnie.tuhs.org//cgi-bin/utree.pl?file=V6/usr/man/man6/cal.6 back then: "Try September 1752." Get off my lawn. Noel PS: Said documentation already notes that it won't work in most counries: "The calendar produced is that for England and her colonies." For more fun with calendates, check out the Japanese Lunar-Solar Calendar: http://www.chiappa.net/~jnc/prints/calendar.html

3 years, 10 months

1
0
0 0

1992 Gates, Dell, Joy, Dyson photo

by Charles H Sauer

Maybe not old enough for this list, but some might enjoy https://specials-images.forbesimg.com/imageserve/61001c736e3fe79457907f91/F… Caption: TECH TITANS WITH BABY FACES: (From left) At the 1992 PC Forum in Arizona, Bill Gates talks with a 27-year-old Dell and Sun Microsystems cofounder Bill Joy, while Prediction Company’s Doyne Farmer chats up influential tech newsletter editor and conference organizer Esther Dyson. ‎ Found in https://www.forbes.com/sites/antoinegara/2021/08/03/deal-of-the-century-how… -- voice: +1.512.784.7526 e-mail: sauer(a)technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer

3 years, 11 months

3
2
0 0

70s Matlab source

by Wesley Parish

I'm wondering, is it still floating around somewhere? Thanks Wesley Parish

3 years, 11 months

2
2
0 0

In these COVID times...

by Dave Horsfall

I wonder how many bods rememeber: "Nothing sucks like a VAX!"? -- Dave

3 years, 11 months

2
1
0 0

Re: [COFF] In these COVID times

by Rudi Blom

That rang a Bell with VAX as IBM-killer :-) Even if it's on an MS site it's still a nice article. https://news.microsoft.com/features/the-engineers-engineer-computer-industr… Take care and stay healthy, uncle rubl >From: Dave Horsfall <dave(a)horsfall.org> >To: Computer Old Farts Followers <coff(a)tuhs.org> >Cc: >Bcc: >Date: Mon, 26 Jul 2021 11:54:44 +1000 (EST) >Subject: [COFF] In these COVID times... >I wonder how many bods rememeber: "Nothing sucks like a VAX!"? > >-- Dave -- The more I learn the better I understand I know nothing.

3 years, 11 months

1
0
0 0

Re: [COFF] [TUHS] 386BSD released

by Clem Cole

Thank you, Doug. On Wed, Jul 14, 2021 at 10:22 PM Douglas McIlroy < douglas.mcilroy(a)dartmouth.edu> wrote: > The open source movement was a revival of the old days of SHARE and other > user groups. > Amen, my basic point, although I was also trying to pointing at that these user groups got started b*ecause the vendors gave the sources to their products out.* We SHARED patches and features. DECUS started out the same way. For instance, many/most PDP-10 OS's used the DEC compilers and often even found a way to run TOPS-10 binaries by emulating the UUOs. The IBM/360 world worked pretty much the same way. My own experience was that the compilers (e.g WATFIV-FTNG-ALGOLW-PL/1) and language interpreters (APL-Snolbol) for the TSS and MTS had been 'ported' from the IBM-supplied OS [my own first job was doing just that]. The same story was true for the PDP-8 with DOS-8/TSS-8 and the like. By the time of the PDP-11, while some of the DEC source code was available (such as the Fortran-IV for RT-11/RSX), since it took at PDP-10/BLISS to support it, DEC had it its protection - so moving it/stealing it - would have been harder. By the time of the VAX, DEC was charging a lot of money of SW and it was actually a revenue stream, so they keep a lot more locked up and had started to do the same with PDP-10 world. So, the available/unavailable source issue came when things started to get closed up, which really started with the rise of the SW industry and making revenue with the use of your SW. OEMs and IVSs started to be a lot less willing to reveal what they thought was their 'special sauce.' Some/many end-users started to balk. RMS just took it to a new level - just look at how he reacted to Symbolics being closed source :-) The question that used to come up (and still does not an extent) is how are the engineers and teams of people that developed the SW going to be paid/renumerated for their work? The RMS/GNU answer had been service revenue [and living like a student in a rent-controlled APT in Central Sq]. What has happened for most of the biggest FOSS projects, the salaries are paid for firms like my own that pay developers to work on the SW and most FOSS projects die when the developer/maintainer is unable to continue (if not just gets bored). In fact, [I can not say I personally know this - but have read internal memos that make the claim], Intel pays for more Linux developers and now LLVM developers than any firm. What's interesting is that Intel does not really directly sell its HW product to end-users. We sell to others than use our chips to make their products. We have finally moved to the support model for the compilers (I've personally been fighting that battle for 15 years). So back to my basic point ... while giving the *behavior* a name, the *idea *of "Open Source" is really not anything new. While it may be new in their lifetime/experience, it is frankly at minimum a sad, if not outright disingenuous, statement for the people to try to imply otherwise because they are unwilling to look back into history and understand, much less accept it as a fact. Trying to rewrite history is just not pretty to witness. And I am pleased to see that a few folks (like Larry) that have lived a little both times have tried to pass the torch with more complete history. Clem. ᐧ

3 years, 11 months

10
23
0 0

Re: [COFF] [TUHS] head/sed/tail (was The Unix shell: a 50-year view)

by John Cowan

[-TUHS] [+COFF] On Fri, Jul 16, 2021 at 4:06 AM Lars Brinkhoff <lars(a)nocrew.org> wrote: On ITS it only ever stored characters as full 36-bit words! So sizeof > char == 1 == sizeof int. This is allowed per the C standard. (Maybe it > was updated somewhere else, I dunno.) > The ZETA-C compiler ran on the Symbolics Lisp Machine and translated C into Zetalisp; since everything was a Lisp object, from the C perspective all elementary types had sizeof == 1 also. The modern Vacietis compiler to Common Lisp uses the same design for its data, though it does not share any code. C pointers are represented by CL closures.

3 years, 11 months

1
0
0 0

Re: [COFF] [TUHS] head/sed/tail (was The Unix shell: a 50-year view)

by Lars Brinkhoff

Moved to the COFF list. > Yes, WAITS is what I was thinking of. As I mentioned in my previous > mail, it feels like the SAIL timesharing systems get mentioned briefly > in a lot of accounts of historical computing, sometimes with mention > that they had some sort of (relatively) advanced video terminals, but > no in-depth descriptions of the actual hardware/software environment. I agree WAITS gets very little attention, particularly in relation to the great number of things pioneered at SAIL. I'm involved making emulators for some of the hardware. SAIL started out with a couple PDP-1 timesharing systems with vector displays from Philco. But that's almost a pre historical era. The PDP-6/10 started with another vector system from III. It could support up to 12 displays, but only ever had 6. A raster display system was added in the early 70s. It must have been one of the very first bitmapped display systems. It came from the Data Disc company and used disk for storage. It was dual ported: the computer could write data, and the displays could read. 64 displays were supported. The III and DD displays used the SAIL keyboard which introduced the META key. The Data Disc displays and SAIL keyboard heavily influenced Tom Knight at MIT to make a similar system for their AI lab PDP-10 running ITS.

3 years, 11 months

1
0
0 0

Re: [COFF] [TUHS] 386BSD released

by Michael Kjörling

On 14 Jul 2021 22:21 -0400, from douglas.mcilroy(a)dartmouth.edu (Douglas McIlroy): > IBM provided source code for the Fortran II compiler. More recently than that, for the original IBM PC anyone could get (I believe) the complete schematics, detailed technical information, and a commented ROM BIOS source code listing just by purchasing their Technical Reference for, what, $50 or thereabouts? It certainly wasn't open source according to the Open Source Definition, but it certainly was _available_ to anyone who wanted a copy. What kind of company does that today, in a similar market segment? -- Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”

3 years, 11 months

2
1
0 0

quick question

by Jesse Davidson

Hi Stephen, I noticed you shared an article from KiCAD.org when you talked about PCB design software tools, here: https://minnie.tuhs.org/Blog/2019_06_18_cscvon8_lessons_learned.html I thought that the article from KiCAD.org is actually pretty good, but we recently published an article that goes much deeper and talks about the ten best PCB design software tools in 2021. PCB design software is the operating program used by a computer that helps electronic engineers design printed circuit board (PCB) layouts. This design tool helps users to collaborate on various projects, access libraries of components created before, know the accuracy of their circuit schematic design, and more. The article talks about the best PCB design software tools available in the market today and provides answers to the following questions: - What is PCB design software and why do you need it? - What is the evaluation criteria for PCB design software? - What are the key features to look for when choosing PCB design tools? - What are other recommended PCB design software tools? We quote 30 different sources in the article -- it's quite authoritative. Here's the article, if you're interested: https://www.wellpcb.com/special/pcb-design-software.html Would you consider sharing our article with your readers by linking to it? Anyone who is looking for the right PCB design software to use might find this very useful. Please let me know if you have any questions and thank you for your time. Cheers, -Jesse -- Jesse Davidson, Editor 5 Ross Rd Durham, NH 03824 BTW, if you didn't like getting this email, please reply with something like "please don't email me anymore", and I'll make sure that we don't.

3 years, 11 months

1
0
0 0

Re: [COFF] [TUHS] 386BSD released

by Clem Cole

Sigh ... Warren I am going to ask for your indulgence once here on TUHS as I try to get any *new* discussion moved to COFF, but I guess it's time to renew this history as enough people have joined the list since the last time this was all discussed ... I'll do this once -- please take any other discussion off this list. It has been argued too many times. Many of the actors in this drama are part of the list. Sadly we have lost a few, sometimes because of the silliness of the argument/trying to give people credit or not/person preferences, etc. If you want to comment, please go back and read both the TUHS and COFF archives and I suspect your point may have already been made. *If you really do have something new, please move to COFF.* On Wed, Jul 14, 2021 at 4:21 AM Angus Robinson <angus(a)fairhaven.za.net> wrote: > Looking at a few online sources, Linus actually said when "386BSD came > out, Linux was already in a usable state, that I never really thought about > switching. If 386BSD had been available when I started on Linux, Linux > would probably never had happened". > A number of us, such as Larry and I have discussed this a bunch both online and in person. What would become 386BSD was actually available as early as 1988, but you needed to know the public FTP address of where to get it at UCB (which the UCB licensees had access to that FTP server). Bostic was still working on what would become the 'NET' release, but this tarball offered a bootable system and did have things in it that later AT&T would require UCB to remove. In fact, this system would have X10 ported to it and was a reasonably complete 'distro' in today's terms. By formal definition, the tarball and the rest of UNIX from Research is and always has been, '*Open Source*' in the sources were available. *But they were licensed*. This was fairly typical of much early software BTW. The binary nature only came about with the minicomputers. The tarball in question was fairly easy to find in the wild but to use the sources as a system, you technically needed an AT&T license. An practically you needed access to a BSD box to rebuild them, which took a license - although by then SunOS was probably close enough - although I do not know anyone that tried it. The sources in the tarball were not '*Free and Open Source*' -- which becomes the crux of the issue. [Sadly the OSS folks have confused this over the years and that important detail is lost]. Many people, such as myself, when the AT&T suite began got worried and started hacking on Linux at that point as the not nearly as mature but sort of works version without networking or graphics had appeared [386BSD had both and a real installer - more in a minute] FWIW: Linus could have had access to the BSD for a 386 tarball if we had asked in the right place. But as he has said later in time, he wanted to write his own OS and did not both ask the right folks at his University, or try to get permission. Although he has said he access to Sun3 and has said that was his impetus for his work. This is an important point that Larry reminds us of, many institutions kept the sources locked away like his U of Wis. Other places were like liberal about access. IIRC Larry sometimes refers to it as the "UNIX Club." In my own case, I was running what would become 386BSD on my Wyse 32:16 box at home and on an NCR 386 based system in Clemson as I was consulting for them at the time. I also helped Bill with the PC/AT disk driver[WD1003 and later WD7000/SCSI controllers], as I had access to the docs from WD which Bill did not. I think I still have a photocopy of them. What basically happened is as BSDi forked and that begets a number of things, from hurt feelings to a famous law suite. A number of us, thought the latter was about copyright (we were wrong it was about trade secret). We were worried that the AT&T copyright would cause UNIX for an inexpensive processor to disappear. We >>thought<< (incorrectly) that the copyright that Linux was using, the GPL, would save us. Turns out >>legally<< it would not have, if AT&T had won, at least in the USA and most NATO Allies - the trade secret applied to all implementations of Ken, Dennis, and the rest of the BTL folk's ideas. All of the Unix-like systems were in violation at this point. BSDi/UCB was where AT&T started. The problem is that while the court found that AT&T did create and own the >>ideas<< (note ideas are not the source code implementation of the ideas), they could not call the UNIX 'IP', trade secrets since the AT&T people published them all both academically in books like Maury Bach's, much less they had been forced by the 1956 consent decree to make the license available, they had taught an industry. BTW: It's not just software, the transistor 'gets out' of AT&T under the same type of rules. In reality, like PGP, since there was lots of UNIX-based IP in other places, it hard to see in practice how AT&T could have enforced the trade secret. But again -- remember Charlie Brown (AT&T CEO) wants to go after IBM, thinking the big money in computers in the mainframe. So they did believe that they could exert pressure on UNIX-like systems for the higher end, and they might have been able to enforce that.

3 years, 11 months

4
4
0 0

Re: [COFF] [TUHS] [tuhs] The Unix shell: a 50-year view

by Andrew Warkentin

On 06/07/2021, Larry McVoy <lm(a)mcvoy.com> wrote: > > http://lkml.iu.edu/hypermail/linux/kernel/0106.2/0405.html > > I wasn't completely right 20 years ago but I was close. I'm tired, > if you want to know where I'm wrong, ask and I'll tell you how I > tried to get Linus to fix it. > > In general, Rob was on point. He usually is. > I've never been a fan of clone(). It always strikes me as something that seems like an elegant simplification at first, but the practical realization (on Linux that is) requires several rather ugly library-level hacks to make it work right for typical use cases. UX/RT will use the "processes are containers for threads" model rather than rfork()/clone() since that's the model the seL4 kernel basically uses (in a very generalized form with address spaces , capability spaces, and threads being separate objects and each thread being associated with a capability space and address space), and it would also be slightly easier to create the helper threads that will be required in certain parts of the IPC transport layer. The base process creation primitive (efork(), for "empty/eviscerated fork") will create a completely blank non-runnable child process with no memory mappings or file descriptors, and return a context FD that the parent can use to manipulate the state of the child with normal APIs, including copying FDs and memory mappings. To actually start the child the parent will perform an exec*() within the child context (either a regular exec*() to make the child run a different program, or a new eexec() function that takes an entry point rather than a command line to run the process with whatever memory mappings were set up), after which point the parent will no longer be able to manipulate the child's state. This will eliminate the overhead of fork() for spawning processes running other programs, but will still allow for a library-level fork() implementation that has comparable overhead to traditional implementations. Also, it will do what Plan 9 never did and make the process/memory APIs file-oriented (I still don't get why Plan 9 went with a rather limited anonymous memory API rather than using memory-mapped files for everything). Also, we're straying a bit from historical Unix here and should have probably moved to COFF several messages ago.

3 years, 12 months

1
0
0 0

Re: [COFF] Happy birthday, Alan Turing!

by Rudi Blom

>From yesterday: "New British 50 pound note with WW2 codebreaker Turing enters circulation" https://news.yahoo.com/british-50-pound-note-ww2-231442699.html -- The more I learn the better I understand I know nothing.

4 years

1
0
0 0

Happy birthday, Alan Turing!

by Dave Horsfall

On this day in 1912. Were it not for him, you would not be reading this message; he was the father of Computer Science. -- Dave

4 years

1
0
0 0

Early Programming Books

by Paul Birkel

I know of two early computer (in the stored program sense) programming books. 1951: Preparation of Programs for an Electronic Digital Computer (Wilkes, Wheeler, & Gill) 1957: Digital Computer Programming (McCracken) What others were published prior to the McCracken text? Excluded are lecture compendia and symposia proceedings, such as: 1946: Moore School Lectures 1947: Proceedings of a Symposium on Large-Scale Digital Calculating Machinery 1951: Proceedings of a Second Symposium on Large-Scale Digital Calculating Machinery 1953: Faster Than Thought, A Symposium On Digital Computing Machines These were principally about designs for, and experience with, new hardware. I'm curious about texts specifically focused on the act of programming. Were there others prior to McCracken? paul

4 years

1
0
0 0

70 years of commercial computing

by Greg 'groggy' Lehey

Seen in my calendar yesterday: Jun 15 UNIVAC I delivered to the Census Bureau, 1951 70 years! And Unix has been around for nearly 52 of those years. Amusingly, though, the next entry is: Jun 16 First publicized programming error at Census Bureau, 1951 Which suggests that they were able to install the machine and getting it running in only one day. Greg -- Sent from my desktop computer. Finger grog(a)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.php

4 years

4
3
0 0

Re: [COFF] 70 years of commercial computing (Greg 'groggy' Lehey)

by Rudi Blom

>From wiki "The first Univac was accepted by the United States Census Bureau on March 31, 1951, and was dedicated on June 14 that year.[3][4] " https://en.wikipedia.org/wiki/UNIVAC_I -- The more I learn the better I understand I know nothing.

4 years

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

COFF