No. This hate of coddling just makes the ptsd worse. It's easy to sit in judgement, but hard to fix. Why aren't people dinging the employers for not proactively offering this training? Why are we letting them off so easily?
A few nits: He worked at CSRG which produced BSD, Berkeley Software Distribution. It wasn't the BSD movement, but the efforts to rewrite Unix to get rid of AT&T IP was started at CSRG after 4.3BSD was released, and Mike did a lot of work there. 2BSD did run on the PDP-11s, and 2.11BSD was the best release to run on larger PDP-11s. 3B2s never had BSD support: it was pure System Vr2 and later from AT&T (with a BSD networking stack ported later). Lately he had also been contributing a lot to FreeBSD and was going to be release engineer for our next release 13.4.
Unless you were at Krik McKusick's house, you never saw 4.5BSD
Kirk, author of UFS and manager of CSRG for a time, has a listing on his bookshelf that's labeled "4.5BSD." However, it really really is a snapshot between 4BSD and what would become 4.1BSD. CSRG's follow on release to 4BSD was going to be 5BSD and this listing was half way to that. AT&T asked them not to do that (after this listing was produced and labeled), so they went with 4.1BSD for reasons to extensive to go into here. I'm sure Kirk keeps it as a conversation piece
CSRG, the computer group at Berkeley enhanced AT&T's 7th Edition Unix under contract to DARPA to make it faster and add networking. They distributed the results as the Berkeley Software Distribution. Mike was the release engineer for several of these releases, first on the PDP-11 (for 2.9BSD) and later for 4.3BSD, the interim releases and 4.4BSD. Most recently, he'd accepted the role of being release engineer for the next FreeBSD release (13.4) and was also active in improving Raspberry Pi5 support as well as all the low level moving parts of getting FreeBSD running on the M1 and friends. His whole career is too long to mention here.
He was an absolute joy. I always loved seeing him at different conferences, most recently at BSDcan 2024 just last week. I talked with him about a number of things, had dinner with him and hung out with him for a while at the after social party. I'm still in shock that he's gone.
As for wayland, you can run wayland on FreeBSD. Or X11. Or both with xwayland. FreeBSD runs the Linux drm drivers which helps a lot, as does mesa and vulkan integration.
As for systemd, meh. We've dealt with it in mostly ad-hoc ways to date. It's mostly a system administration problem, not a deeply embedded into programs problem for the most part.
Forgive my ironic chuckle at x11 is dying, though. I've heard FreeBSD is dying since the 90s. I'll believe it when I see it... though recent X release rates do tend to give me pause...
My daughter had to have a window laptop instead of a mac laptop once she discovered that macos had dropped 32-bit binary support. Without it, you couldn't play classic games, and that was it.
> The first Unix distributions I used, you had to build the OS yourself, hand compiling in, or out different options. I built a bunch of DNS servers, FTP servers, SMTP servers... sync sync reboot
The first unix distributions, back at Bell Labs, were tapes that you booted. These tapes had programs to initialize the disk, copy files from the tape that were disk images to the disk and/or restore other partitions from tar or its predecessors. These date back to V1 on the system which had you set the system console switches to a certain magic value to do the install. You didn't have to recompile anything, though you often did recompile the kernel to tune it to your system rather than run a generic version (most tapes had a generic version, and several copies of that with different major/minor numbers plugged into it so that different disks could be root). BSD improved this a bit by having a RAM disk that you'd copy to the swap partition and run out of that to do the initialization (fewer stand alone programs to run).
The first Linux distributions were not nearly this nice. You had a boot floppy that you could use for format the hard disk and a few other floppies that had other programs on them that you'd basically tar off (though early on the concept of floppy sets arose that was basically a multi-volume tar file under a different name). It took a couple of years before the CD isos appeared which made it a lot easier and the install process to get going....
So things have come a long way since then, but we're not longer installing this stuff on 4-8MB 386DX computers with 50-100MB hard drives either...
Once upon a time, AT&T said that if I read their proprietary sources to learn how Unix worked, my brain had been infected and I couldn't pass along that knowledge. That position lost in court. It sounds a bit like what FSF is saying here: Read GPL code, then the code you produce must be GPL'd.
Except both these points are wrong.
It's like the rules of the road. We don't have people crashing into each other because there's rules about when and where to drive. Nobody is suggesting because they have disappeared into the woodwork of society that they aren't important and play an important role.
There's also a bit of a logical fallacy in the 'one was bad, therefore all are bad'. And this last round, there was no strife: we learned the lesson of reuse and reused one that worked.
So you could draw the conclusions in this thread, but they would be wrong because they rest on logical fallacies.
Nice theory. The reality is that hasn't happened.
I helped draft the 2018 CoC (but disliked how it was adopted). I helped get the replacement adopted (LLVM or golang, I didn't care: both were so much better). I'd like to share my personal views.
The takeaway is simple. The 2018 CoC was adopted w/o input from the community. It was poorly drafted and some of the worst examples were held up to ridicule. It also appeared when people were itching for a culture war fight, so a lot of outsiders dog-piled on it. Worse than that, though, was that it was also a poor document to help field complaints of bad behavior and help people interact in a more respectful way. It also had bad reporting mechanisms that encouraged abuse. It was a poor fit for the community that wants aspiration, not prescription. While it was a mistake to adopted what was effectively the rough draft of the drafting committee w/o the review we thought it would get (in general engineers suck at drafting high quality CoCs), it was an even bigger mistake to try to adopt it by fiat w/o a community discussion. So whoever said it can't be viewed as anything but a failure: you are right on that point...
The 2020 LLVM adoption is a much better fit. The reporting issues were also fixed. It provides better guidance on behavior that has been found to promote collaboration. It gives much better guidance for dealing with friction between community members. There have been fewer formal complaints, though it is still early. And the best thing: so far there haven't been the wide-ranging flame wars over its content we had with the last one. The project has been more focused on technical arguments and working to get FreeBSD 13.0 out the door.
The real takeaway here is that a bad CoC can drain the energy out of people. No doubt about that. A good CoC disappears into the woodwork. It's better to admit failure with a bad one and move on than to stubbornly enforce it at all costs. Also, engineers have a poor track record of drafting high quality CoCs: let others that have been successful do it and just use theirs was another take-a-way. Community engagement is also key, because that leads to community buy-in (a lesson learned from the 2018 experience). The CoC should reflect the community's values and aspirations. The more it does, the more buy-in you'll get which is key to it's success. I'm sure that in some years, the community's standards and values will have evolved enough to warrant revisiting things like this CoC, but for now it's at least a decent fit.
Lately, it seems to be working... The project has put its energy into adopting git (I know, a bit late), moving to asciidoc for its handbooks and docs, moving to OpenZFS as our ZFS upstream and getting the FreeBSD 13.0 release ready (due next month). It kinda surprised me to see this come up at all since things have been so quiet on the CoC front lately...
Anyway, I'm sure this won't please everybody. I'm sure some will disagree with me. But I think my perspective on the project's experience might be of interest.
Warner
I stopped contributing to the Linux kernel in like 1995 because the environment even then was too toxic. With the same sort of 'apologist' rhetoric that we hear today. In the 20 years I've been contributing to FreeBSD, I've still yet to accumulate as much toxin as was present in the 12 months or so I tried contributing minor things to Linux.
Also, it is the name of a Nazi gun more commonly known as the Luger...
First, it's not clear a contract was established. And even if it was, unilateral changes generally are unenforceable. And even if it were there when the attempted purchase was attempted, this is an unconscionable contract clause, against public policy (1st amendment, etc) and should be thrown out.
This person's best bet is to dispute the credit reports, counter sue for whatever they can think of to recover legal fees.
If it were me, I'd just send them a letter telling them to go F themselves and I'll see you in court. Bring it. My lawyer, however, would likely wish that I not do that.
The WHOLE is 6. You see 5 from the whole. That means one is missing from the five to make a while.
This method of thinking through the problem is taught in the classroom instruction that goes along with it.
Nobody said computers were going to be polite.
