For BSD Unix, It's Sayonara (1992)(tech-insider.org)
tech-insider.org
For BSD Unix, It's Sayonara (1992)
https://www.tech-insider.org/unix/research/1992/0622.html
85 comments
The article is about BSD Unix which had a final release in June of 1995. So BSD is sayonara!
Long live FreeBSD, OpenBSD and NetBSD, the stepchild(s) of BSD.
Long live FreeBSD, OpenBSD and NetBSD, the stepchild(s) of BSD.
Nevertheless, it shows an interesting crossroads moment in the BSD history and uncertainty of it's future.
> There are still options to secure BSD code, with one company, Berkeley Software Design (Falls Church, Va.), a company employing former Berkeley programmer Mike Karels, planning to offer a commercial version of Unix for SPARC systems based on the 4.4BSD code but free of AT&T source licensing requirements. It currently offers BSD/386, a version of Unix for 386 machines based on the Berkeley NET2 release.
(commented from a laptop running FreeBSD 14.0-CURRENT;)
> There are still options to secure BSD code, with one company, Berkeley Software Design (Falls Church, Va.), a company employing former Berkeley programmer Mike Karels, planning to offer a commercial version of Unix for SPARC systems based on the 4.4BSD code but free of AT&T source licensing requirements. It currently offers BSD/386, a version of Unix for 386 machines based on the Berkeley NET2 release.
(commented from a laptop running FreeBSD 14.0-CURRENT;)
BSDi actually helped FreeBSD develop SMP support. FreeBSD's "SMPng", the basis for the SMP facilities in the kernel today, was started roughly 23 years ago, with the help of BSDi engineers, as well as donations of code.
References: https://man.freebsd.org/cgi/man.cgi?smp
https://www.usenix.org/legacy/event/usenix01/freenix01/full_...
https://people.freebsd.org/~peter/smp.html
https://www.krsaborio.net/unix-scalability/research/2000/09....
References: https://man.freebsd.org/cgi/man.cgi?smp
https://www.usenix.org/legacy/event/usenix01/freenix01/full_...
https://people.freebsd.org/~peter/smp.html
https://www.krsaborio.net/unix-scalability/research/2000/09....
Ah, I was looking at the history of BSDi (nee Berkeley Software Design). Turns out BSD/OS was killed off by Wind River in 2003? I didn't realize it had lasted so long. Nor did I realize BSD/OS had such strong market share in '95.
(commented from a laptop building an osx -> dragonfly cross compiler)
(commented from a laptop building an osx -> dragonfly cross compiler)
First shop I worked at in 1998 was hosting dozens of websites using all BSDi —-it was the first thing I really managed as a sysadmin. Such a pleasure to run! Everything very sanely laid out, it was easy to compile the extra tools we needed, the serial consoles were trivial to set up without extra boards, and provided the hardware was good it was stable as hell. The only downside was the lack of certain tools: we had a single Sun box for running Oracle and ColdFusion, for instance. I was sad when we were bought and the new owners converted everything to other platforms.
Seems like today, given the proclivity of open-source/non-platform-locked tooling, someone would be looking at making that a viable solution for boutique design-plus-hosting. But maybe those days are gone.
Seems like today, given the proclivity of open-source/non-platform-locked tooling, someone would be looking at making that a viable solution for boutique design-plus-hosting. But maybe those days are gone.
Does it still have that classic Berkeley smell?
"It was a matter of their taking it in and peeing on it until it smelled like Berkeley."
"It was a matter of their taking it in and peeing on it until it smelled like Berkeley."
Don't forget Darwin, the step-grandchild of BSD. It might not be as free as FreeBSD, OpenBSD, and NetBSD, but it'd be hard to argue it's not as important.
Mac is certified to be unix, so it's more like the only legitimate heir.
That's a cool series, thanks for sharing!
I didn't grow up during this era, so it was facinating to stumble upon a news article on the (lack of continued) funding for BSD - something I'd never really thought about.
I didn't grow up during this era, so it was facinating to stumble upon a news article on the (lack of continued) funding for BSD - something I'd never really thought about.
"The University of Colorado's Nemeth, regarded as an expert on Unix security and perhaps best known for having co-authored the Unix System Administration Handbook, said last week that she would like to have her university conduct some of the operating system research that Berkeley is now abandoning."
RIP Prof. Nemeth.
Tragically lost at sea sailing across the Tasman in Winter in a "vintage" 1928 schooner.
"Evi Nemeth had previously used the services of Bob McDavitt for weather forecasts and passage planning during her voyage on her yacht Wonderland. There was no such request for services made to Bob McDavitt from the Nina before she sailed from Opua. Bob McDavitt is a well-known and respected meteorologist who retired in 2012 from the NZ Met office where he had responsibility for marine and aviation weather forecasting. Now as a consultant he provides services to cruising yachts, providing weather forecasts and voyage forecasts. (www.metbob.com.)"
https://nzsar.govt.nz/assets/Downloadable-Files/Nina-Indepen...
https://www.sail-world.com/-123872/ (AUS --> NZ)
RIP Prof. Nemeth.
Tragically lost at sea sailing across the Tasman in Winter in a "vintage" 1928 schooner.
"Evi Nemeth had previously used the services of Bob McDavitt for weather forecasts and passage planning during her voyage on her yacht Wonderland. There was no such request for services made to Bob McDavitt from the Nina before she sailed from Opua. Bob McDavitt is a well-known and respected meteorologist who retired in 2012 from the NZ Met office where he had responsibility for marine and aviation weather forecasting. Now as a consultant he provides services to cruising yachts, providing weather forecasts and voyage forecasts. (www.metbob.com.)"
https://nzsar.govt.nz/assets/Downloadable-Files/Nina-Indepen...
https://www.sail-world.com/-123872/ (AUS --> NZ)
Correction: Apparently Met uses June 1 as 1st day of winter but it's officially the solstice. One could argue it was not yet winter.
https://www.stuff.co.nz/national/113038178/when-does-winter-...
https://www.stuff.co.nz/national/113038178/when-does-winter-...
I recommend her book to everyone, get a hard copy!
It’s neat to start reading and immediately run into professor Evi Nemeth being quoted. I TA”d for her a few year later, and it was axiomatic in her labs that BSD Unix was the only true Unix, that slowaris was a abomination and ATM was the worst network protocol ever devised.
We eventually got her onto this new Linux thing..
We eventually got her onto this new Linux thing..
> ATM was the worst network protocol ever devised
Having 53 byte payloads is something only a committee could love.
Having 53 byte payloads is something only a committee could love.
ATM cells have 48 byte payloads.
Supposedly that was because different groups involved in the standardisation process wanted either 32 or 64 byte payloads.
Supposedly that was because different groups involved in the standardisation process wanted either 32 or 64 byte payloads.
Supposedly it was the largest size the French contingent to the standards committee would accept. They wanted a very small sample size to reduce the need for echo cancellation in their network.
That's definitely a "split the baby down the middle" kind of solution.
More like a "fuck all you guys, I'm going home" kind of solution, if you ask me.
I think there's a similar story for the HDTV 16:9 aspect ratio.
conveniently about the size of a typical ip+tcp header
yeah. 53 bytes was the total packet size, not the payload size. But oh hey! lets pick a large prime number for the number of bytes that a payload could be transmitted in. Lets also pick a small prime number of bytes so we can't do byte boundaries.
Needless to say, I am glad that TCP/IP won. Moving on.
Needless to say, I am glad that TCP/IP won. Moving on.
First, ATM is OSI Layer 2, where PDUs are not called "packets", they are called "frames". ATM calls these frames "cells", so a cell is 53 octets (which literally means 8 bits, because guess what, not all bytes are that size.) ATM also covers Layer 1 (where PDUs are called "bits" or "symbols") and Layer 3 (where IP starts).
Second, TCP/IP is Layer 3 and up, which means it runs on ATM just fine, like it runs on ISDN, Ethernet, Token Ring, PPP, and the various ITU standards for modems.
ATM is commonly used in DSL implementations, so it also "won" as far as DSL has penetrated as a broadband technology.
Second, TCP/IP is Layer 3 and up, which means it runs on ATM just fine, like it runs on ISDN, Ethernet, Token Ring, PPP, and the various ITU standards for modems.
ATM is commonly used in DSL implementations, so it also "won" as far as DSL has penetrated as a broadband technology.
[deleted]
At least some telco types absolutely wanted to use ATM for everything. The idea was that instead of the completely anarchy of letting anyone connect to anyone else, you'd use ATM to build up sane, billable virtual circuits between endpoints. Basically, your computer would "call" a server, and Ma Bell would helpfully bill you for the connection and for the amount of data you passed. When you were done, you'd disconnect. I mean, it'd worked for years for voice, so why not data?
Fortunately, that insanity lost.
Fortunately, that insanity lost.
> Fortunately, that insanity lost.
It lost to ad-supported websites, affiliate links, third-party cookies, tracking and fingerprinting?
Also, ATM was an integral part of SONET/SDH PSTN backbones for decades, so unbeknownst to the consumer, we were using ATM "for everything".
It lost to ad-supported websites, affiliate links, third-party cookies, tracking and fingerprinting?
Also, ATM was an integral part of SONET/SDH PSTN backbones for decades, so unbeknownst to the consumer, we were using ATM "for everything".
There was talk (I was in the room) of using it, or a successor, as the transport of the Internet.
Imagine replacing IP with ATM, and paying a telco every time you created a virtual circuit for the things we use TCP for today. That was the grand vision.
See https://www.wired.com/1996/10/atm-3/ for the debate at the time.
Imagine replacing IP with ATM, and paying a telco every time you created a virtual circuit for the things we use TCP for today. That was the grand vision.
See https://www.wired.com/1996/10/atm-3/ for the debate at the time.
What you're implying is that transport providers would've charged more than the market can bear, as compared to the flat-fee typical of ISPs in these United States. It's interesting to note that in other parts of the world, such as the ones which used ISDN, Internet usage has been metered, albeit not per-server-connection.
You're also implying that there's something special about the technical design and implementation of ATM that enables monetization based on per-connection events. Well, let me introduce you to TCP, which sets up virtual connections... circuits... at the transport/session layer. There is no technical reason that ISPs (many also happen to be telcos) couldn't charge on a per-TCP-session level in the same way as ATM's SVCs weren't used.
What I'm saying is that the consumers have been monetized anyway, via data mining, engagement, and tracking, and while it's not cash coming out of our pockets, it's still us trading something of value for access to those resources. In fact, the consumer has resources so valuable, that there are whole classes of malware like coinminers, who literally capitalize on them, and there are parallel benign apps which do the same, only with consent.
Perhaps if the telcos had been willing to charge per-VC, our attention and PII would still be monetized, and they'd get us coming and going. Perhaps it's a false dichotomy. I don't know.
You're also implying that there's something special about the technical design and implementation of ATM that enables monetization based on per-connection events. Well, let me introduce you to TCP, which sets up virtual connections... circuits... at the transport/session layer. There is no technical reason that ISPs (many also happen to be telcos) couldn't charge on a per-TCP-session level in the same way as ATM's SVCs weren't used.
What I'm saying is that the consumers have been monetized anyway, via data mining, engagement, and tracking, and while it's not cash coming out of our pockets, it's still us trading something of value for access to those resources. In fact, the consumer has resources so valuable, that there are whole classes of malware like coinminers, who literally capitalize on them, and there are parallel benign apps which do the same, only with consent.
Perhaps if the telcos had been willing to charge per-VC, our attention and PII would still be monetized, and they'd get us coming and going. Perhaps it's a false dichotomy. I don't know.
Um. Is joke? Loads of cloud provider have billing related to the amount of data shipped. Freaking Route53 bills almost per query.
No. They wanted to bill per connection. You know how you use to be charged to call another phone? The telcos wanted that connection-level billing for data.
For a meteorology focused response I don’t think the use of meteorological summer is too surprising. https://www.ncei.noaa.gov/news/meteorological-versus-astrono...
Still better than 193 bit frames
I assume that’s a T1 dig? It worked quite well for the intended purpose - carrying voice traffic.
So did 53 byte frames, which was due to voice-specific requirements.
Could it fit better? Sure. It was after all a compromise so equipment was interoperable.
The 53 byte ATM cell was a compromise for a particular community of voice networks. And the overhead and small cell size never really worked "well" -- there are a bunch of reasons why Ethernet and IP won out, and low average overhead and the ability by the late 90s to scale switching and routing gear up to gigabit speeds and beyond were two big reasons.
ATM collapsed under its own weight.
ATM collapsed under its own weight.
I always attended her talks at Usenix. I'm still sad about her loss.
I recognize her as one of the authors of the Unix System Adminstrator's Handbook.
Re: ATM: https://books.google.ca/books?id=uAblPu1lpqIC&pg=PA130
Re: ATM: https://books.google.ca/books?id=uAblPu1lpqIC&pg=PA130
[deleted]
I don't know what it is about the BSD's. I just keep getting drawn to them, and I don't even use them personally or professionally.
I think it's because they are complete operating systems with their own user-land and complete documentation. Plus the fact that BSD users get excited about little things like when an extra command line switch or a new filesystem flag. All this meticulous attention to detail...
I think it's because they are complete operating systems with their own user-land and complete documentation. Plus the fact that BSD users get excited about little things like when an extra command line switch or a new filesystem flag. All this meticulous attention to detail...
Same. I always look for a reason to run FreeBSD for jails and ZFS but I just can't. Questionable compatibility and the lack of OCI containers (which are an easy way out if you don't want to spend time setting up a jail on your home server in your free time) always ruins it.
I could run a VM for Linux but i could also only run Linux and not deal with that...
I could run a VM for Linux but i could also only run Linux and not deal with that...
This is me as well, im excited to know there is a whole solution in one. Ive run them here and there to experiment, but for my needs i still use Debian. I feel Debian gives me some of the BSD vibe, but i still enjoy reading about all the new features the BSDs bring each release. Hope one day they catch up to what my linux box does, so i can enjoy it more.
Slack and Debian (mostly Debian) were my favorite Linux experience, and indeed Unix experience, until I landed on NetBSD.
Try Chimera
I had switched all my customers from CentOS 6 to FreeBSD many years ago, before systemd was introduced into RHEL. They have been running solidly for almost 9 years now, all on various DELL PowerEdge rack mounted servers.
Back in the day "they" said: what one BSD admin can do in a week, 10 Windows admins could do in a month. (Or something like that).
Yea it’s strange that right now we have four direct derivatives (OpenBSD, FreeBSD ,NetBSD and DragonflyBSD) and an combination of OSF Mach 4 and FreeBSD which has Billions of users (macOS ,iOS)
Given Apple’s market share, BSD is actually extremely popular!
In other stuff too.. PlayStation 3 through 5, but those are closed systems.
So is Apple. Some here might see this as a lesson in licensing I guess.
Specially when we check what they have contributed to upstream.
Yea open sourcing APFS drivers would be something actually useful
It's not over till Netcraft confirms it.
Throwback to my slashdot sig:
To misquote Churchill, never has an operating system (FreeBSD) used by so many been administered by so few. - NetCraft
So basically it's an anti-Kubernetes?
The whole copypasta, frequently posted to slashdot back in the day:
It is official; Netcraft now confirms: BSD is dying
One more crippling bombshell hit the already beleaguered BSD community when IDC confirmed that BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming close on the heels of a recent Netcraft survey which plainly states that BSD has lost more market share, this news serves to reinforce what we've known all along. BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin to predict BSD's future. The hand writing is on the wall: BSD faces a bleak future. In fact there won't be any future at all for BSD because BSD is dying. Things are looking very bad for BSD. As many of us are already aware, BSD continues to lose market share. Red ink flows like a river of blood.
FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the BSD market. Therefore there are (7000+1400+700)4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that BSD has steadily declined in market share. BSD is very sick and its long term survival prospects are very dim. If BSD is to survive at all it will be among OS dilettante dabblers. BSD continues to decay. Nothing short of a cockeyed miracle could save BSD from its fate at this point in time. For all practical purposes, BSD is dead.
Fact: BSD is dying
It is official; Netcraft now confirms: BSD is dying
One more crippling bombshell hit the already beleaguered BSD community when IDC confirmed that BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming close on the heels of a recent Netcraft survey which plainly states that BSD has lost more market share, this news serves to reinforce what we've known all along. BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin to predict BSD's future. The hand writing is on the wall: BSD faces a bleak future. In fact there won't be any future at all for BSD because BSD is dying. Things are looking very bad for BSD. As many of us are already aware, BSD continues to lose market share. Red ink flows like a river of blood.
FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the BSD market. Therefore there are (7000+1400+700)4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that BSD has steadily declined in market share. BSD is very sick and its long term survival prospects are very dim. If BSD is to survive at all it will be among OS dilettante dabblers. BSD continues to decay. Nothing short of a cockeyed miracle could save BSD from its fate at this point in time. For all practical purposes, BSD is dead.
Fact: BSD is dying
Whatever happened to the old Netcraft site where I type in a url and it’d tell you what OS, webhost, webserver, etc it ran.
Netcraft seems all corporate now.
Netcraft seems all corporate now.
It's still there, although it too got rebranded: https://sitereport.netcraft.com
I personally used https://builtwith.com/, gave nice reports back in the day.
Security checklists.
Ahem… Darwin. Because of Darwin (iOS) and its derivatives, BSD probably powers 10-20% or more of all daily user hours logged on the planet.
"The Design and Implementation of the 4.4BSD Operating System" is a classic: https://www.amazon.com/Implementation-Operating-paperback-Ad...
Don't forget the newer, updated versions, the last release just a few years ago.
There is just one updated version, and 2014 was more than just a few years.
https://www.amazon.de/-/en/Marshall-Kirk-McKusick/dp/0321968...
https://www.amazon.de/-/en/Marshall-Kirk-McKusick/dp/0321968...
No, there are two: https://www.amazon.com/Design-Implementation-FreeBSD-Operati...
Have you bothered to check the release year before replying?
Your link is to the newest one. Mine is to the one before that. The original post is about the very first issue. You claimed there are only two editions. My link proves there were more. Understand?
Then better mention that properly, and while I stand corrected on the number of editions, 9 years is still a bit more than a few years, which by English grammar rules means 3 on average.
I started uni in 1990 and went from a kid in his basement banging away on a PC clone with Turbo Pascal 5.x to a place with this thing called "usenet" on a "VAX" running "BSD" off of tapes and the map of the "Internet" could just about fit on a whiteboard. I sponged off the sysadmins all I could learning about renoe, tahoe and all things in between. I had no cognizance at the time that the death of this amazing world was getting thought off just when i thought it was the greatest stuff in the universe. I read the demon book cover to cover when I had no idea what most of it meant. BSD, whether alive or "dead" will always hold a special place in my mind. It's only with the long road since those days that I can appreciate the tone of this article. Thanks OP for posting it here.
Funny. This reminded me of the old saying "Two of the most famous products to come out of Berkeley are BSD and LSD." Turns out, as a tech person, I'm (very) tangentially involved with BSD and my landlord was pretty deeply involved with LSD decades ago. ;)
As long as we can still run BSD on our VAXen, I'm happy.
http://vlc.zia.io/
http://vlc.zia.io/
[deleted]
FWIW, Klara has a good series on the history of FreeBSD:
https://klarasystems.com/articles/history-of-freebsd-unix-an...
https://klarasystems.com/articles/history-of-freebsd-part-2-...
https://klarasystems.com/articles/history-of-freebsd-part-3-...
https://klarasystems.com/articles/history-of-freebsd-part-4-...