Fancy a quick tour of DragonFly BSD 6.4? Dragonfly BSD 6.4 is here, with various updates and new features, including a better hypervisor, improved support for AMD GPUs, and more. Dragonfly supports the Lumina desktop from the defunct PC-BSD project, but it's quite rudimentary. Dragonfly supports the Lumina desktop from the defunct PC-BSD project, but it's quite …
When I was learning about this stuff at Dennis Publishing in the mid-1990s, Mr Betteridge, or "Penfold" as we called him, was on a sister title. I know him, and his law, well. :-)
I come up with the words, but I don't usually write the headlines. As such, I deny everything.
"(I have often wondered why sometimes the headlines are a few degrees out of phase with the article.)"
FYI It's pretty standard in the news business, I believe, for headlines, subheads, and the like *not* to be written by the article's author. That was certainly the case at the magazine I worked at in the 90s.
It's not just an El Reg thing.
> FYI It's pretty standard in the news business..., for headlines, subheads, and the like *not* to be written by the article's author. That was certainly the case .....in the 90s. .... It's not just an El Reg thing.
It was that way when I learned newspapering at my mother's knee. Late 1960s. At the end of the linotype era, early photo-type and hot-wax layout. Mom roughed-out the final layout and declared the headlines. Often to fit the space on the page. Or not to have two too-similar headlines in the same day, or same page. Stories arrived with short 1 or 2 word tags so editors and writers could say "Where's the dam story?" or "Here's the dam story!" or "Put the dam story on page 13!". The Continued On Page 46 might be "Dam", but for the top of the story she'd write something interesting like "Ruckus at Dam Meeting". Yes, if a writer had 'a great idea' it could be penciled on the copy or proposed verbally over the desk. But it was Mom's job.
This seemed to be how she was taught circa 1951. And journalism in 1951 was already mature and stodgy.
BTW: in hot-wax layout the titles and the articles were separate slips of treated paper. I know, because I was with her final-checking the layouts before they were shot onto film for making the plates. I noted that this article went with that headline and that with this. Pointed it out and there was a minor crisis of peeling the heads off, hotting-up the wax dispenser, waxing and carefully checking alignment (at this point she let the professional layer do the fussywork).
"... early photo-type and hot-wax layout"
I caught the very end of that era at the job I was referring to above. When I joined the company in 1991, it was all typeset galleys and manual paste-up as you describe, although ads (the ones our graphic designers created as a service, as opposed to camera-ready artwork sent by clients) were imageset in their final form. By the time I left in 1998, the (new) imagesetter was cranking out camera-ready pages; paste-up was a thing of the past. And only a couple of years later, the pages went to direct to plate (the details of which I'm far from clear on since, as noted, I wasn't there).
A sad postscript: the pandemic did in their existence as a print publication entirely. They're now web-only -- and much diminished in terms of content from when I worked there.
For those following along: the "treated paper", in our case, was exposed and developed photographic paper. It was produced by a device called an "imagesetter", which I've described elsewhere.
The "hot wax" was the adhesive used to stick said paper to the final page form -- it was surprisingly sticky wax, and felt so to the touch. Why wax instead of regular glue? It was certainly faster -- the piece of paper you wanted to stick down zipped through the waxer in a fraction of a second as I recall, as opposed to many seconds faffing about with a glue stick or whatever. What I don't know is whether wax also produced a superior result -- cleaner or more securely fastened or whatever. Oh, one thing: as PRR says, you could peel something off and reposition it if you needed to.
(Being in IT, I never did any of this back-end stuff myself, but just watched other people doing it. My involvement was more at the front end: supporting the desktop-publishing and illustration software whose output was sent to that imagesetter, and care and feeding of the device itself.)
"Stories arrived with short 1 or 2 word tags..."
Our word for that was the slug. An article's slug served as the base filename for the story and its various bits on the file server -- main body copy, headlines, images, etc. "Slug" is an old newspaper term. As far as I can tell, this usage is a specialized sense meaning "a bit of type that's off to the side, not intended to appear on the final page", the more general sense being "any chunk of type metal". To elaborate on Wikipedia's definition, a story's slug is an ID that is (a) unique within the issue -- but can be reused from issue to issue (and in our case often was, for recurring features) -- and (b) meaningful to humans -- not e.g., just a number, but something descriptive.
Interestingly, "slug" has come across into web publishing, still meaning, essentially, a human-meaningful unique ID for an article. That'd be the dragonfly_bsd_6_4 piece of this comment thread's URL, which was inherited from Liam's original article.
...Many of the articles seem to mention install issues, sometimes specifically related to installing in VirtualBox, sometimes hardware related, which might also be VirtualBox related. I'd have thought a review of an OS that details the tribulations of installation really ought to be tested on real, relatively generic hardware, not adding a software layer in which may have it's own issue.
I do agree with your point, but I imagine there are constraints on time, space, maybe power sockets (ahem)... Using VMs allows multiple concurrent trials without needing a bigger, hotter office! And probably the hope of reviewing the OS proper, without needing to review the installation process in depth.
Regardless, reading the article sent me back 25 years to the days of installing Slackware, *twitch*! The problems encountered in the article all sound very familiar! Except:
Re: package management: So, before you do that first upgrade, make a backup copy of the... config file...
What's all that about then? Package manager deletes own config, WAI or bug feature? (I briefly checked the linked guide, couldn't see anything specific.)
Generally speaking, you are more likely to have success installing obscure operating systems in a virtual machine than on bare metal. The developers will probably be doing most of their work in a virtual machine, and most of the users will be trying it out in one.
For anything other than Linux and FreeBSD, give Hyper-V a miss, it is probably not going to work; but QEMU, VirtualBox and VMWare are good choices.
My general decision tree goes something like:
[1] Give the OS an overall attempt in the simplest, quickest, easiest environment -- which is a VM. IMHO the easiest-to-use FOSS hypervisor, whatever Red Hat may think, is VirtualBox, which is easier, more complete and more flexible than GNOME Boxes, or KVM + VMM.
(It is not a very useful trial to attempt a company's OS only in its own hypervisor: that is the combination I would expect to be most thoroughly tested and to work best.)
[2] If it works well on that, then try it on hardware. If possible, try it on a complex existing configuration, because getting a machine to itself is easier for almost any OS. For instance, it is more instructive to try a laptop than a desktop; it's more instructive to try a complex machine, e.g. with a discrete GPU, or worse still switchable GPUs.
So, in this instance, I could not get Dragonfly working as a desktop in a VM, so it didn't make it to step 2.
The other BSDs worked very well as desktop OS in VMs, but I could not coax them into installing onto a complex multiboot scenario alongside existing installations of Linux _and_ Windows.
(This also defeated some Linuxes, including Deepin, ChromeOS Flex, Alpine, and Pop OS. Ubuntu Kylin was especially hard work although I did get it working.)
I've only got FreeBSD running happily on its own dedicated SSD on a machine where there is only one other OS and that too has its own dedicated SSD.
OpenBSD and NetBSD looked to be too limiting for me to dedicate a machine to them, so they didn't get that far.
I'm not saying this is an ideal scenario. I'd love to have a testing lab with multiple laptop, desktop and server boxes, with a few different CPU architectures, that I could dedicate to this, but sadly, I just don't have the space for that at present.
This post has been deleted by its author
@Liam_Proven
Why? Take a look at this:
- Link: https://distrowatch.com/
So......there are 100 distributions listed on the right hand side of the page.......yup.......100.
.....and of that 100, 8 distributions have more than 1000 HPD (hits per day).
To get to the point......some of us want ONE distribution so we can get on with our lives! In my own case, my choice is Fedora 37.
......but 100 distributions!!!!! 8 popular distributions!!!! Please!!!! Just give me a break!!!!!
Nobody is forcing you to try them all. There is nothing to take a break from.
If you are happy with what you've got, then good: stay with it.
Dragonfly BSD isn't one of them. It isn't a distribution. It isn't Linux at all, and it doesn't contain any Linux code in its kernel or core parts.
It is its own independent OS, related to FreeBSD but with nearly 20 years of separate development going in different directions and trying to find efficient ways to exploit modern high-end PC hardware.
Some people are not so happy with Linux as you. Some want something else. Choice is good, and the more wide the choice, the more different some alternatives are, the better that is.
I'd go as far as saying Fedora is its own thing and the fact that it has a Linux kernel is almost incidental. I still use Linux for my desktop, Mint in my case having become tired of RH many years ago (and the main problem with it is thanks to RH's influence) so I'd agree that choice is good. Dragonfly is interesting and one to keep an eye on, not least as I use FreeBSD for my server anyway, having made the switch at the same time as I was looking for RH alternatives.
I think choice is especially important after Oracle and HP's mishandling of Solaris and VMS respectively, to use just two examples; I'd hate the world of personal computing to be reduced down to just Windows and Fedora (and MacOS, Apple having always been its own alternative reality...)
"Such are the joys of trying out experimental operating systems, but unfortunately, the pressure of online publishing deadlines meant that our step-by-step process of learning by trying it and breaking things had to end."
Perhaps a pipeline approach? Spend a couple of weeks and do three or four systems in parallel so some hours can be allocated to each.
I preferred *csh for a long time as My First Unix™ was Ultrix on a Vax where csh was standard, but ended up going down the sh/bash route because of problems I encountered scripting csh which seemed oddly finicky with whitespace. Well, that and My First Job involved SVR3 whose only BSDism/other feeling of modernity was vi: no csh for me, just sh and eventually ksh after I badgered my manager about it (it required actual money to be parted with back then), so by the time csh was back on the scene when Linux arrived a few years later I'd already become set in my ways. Er, at the ripe old age of 24...
I also used to use csh and tcsh a lot on proprietary unices and Linux, but eventually switched to Bash, because (A) almost all scripts one encounters use sh-style syntax, so better get familiar with it, and (C) Bash is the default what you get in Linux installations.
But in some ways the csh-style syntax is more user-friendly. Initially the rules where sh (or bash or ksh) expects a newline or semicolon in control structures were clear as mud to me. Csh is more like a normal programming language.
I've been a tcsh user (and compiler of it!) for many many many years now, but even so I've finally given up on (t)csh for scripting and just moved on to bash, which finally has the CLI experience that (t)csh had over the bourne shell side of things. I've still got a soft spot for tcsh, but I cant' say I'm using it nearly as much any more. But $WORK has a long long long long history if all the setup scripts in tcsh, so there it stays the default shell for users.
[Author here]
> you may find "set -o emacs" helps
I thoroughly dislike Emacs, and while I am marginally more familiar with Vi and Vim, I detest the entire Vi family.
All of them are hideous 1970s abominations which should have been modernized, or deleted and forgotten forever, decades ago.
Back in the 1980s I mastered dozens of different text editors, with totally different UIs. WordStar, RPED, Edlin, WordPerfect, loads of them.
I think it was a *wonderful* development when all of them were swept away by the tide of UI standardisation that followed the Mac HIG, and subsequently, Windows and IBM CUA.
There are standard for menu bars, hotkeys, control keys and so on, and there have been for over 30 years now. Any editor that doesn't follow them can die in a fire.
And no, Emacs' `cua-mode` is not enough. I want to see every dialog box, every line of the manual, rewritten. I do not have a "meta" key. Nobody has a meta key and nobody has had a Meta key since Lisp machines died out some 40 years ago. Even the Amiga and the ST had Ctrl, Alt, cursor keys and so on.
The IBM extended keyboard layout is the standard and has been since 1984.
CUA is the standard editing UI. Adopt it, accept it, move on.
All my keyboards have Home, End, PgUp and PgDn, Ins and Del. Left a word is Ctrl+Left. Right a word is Ctrl+Right. Start of doc is Ctrl+Home. End of doc is Ctrl+End.
If those are not part of an editor's core UI, I refuse to even try to learn it. Life is too short.
An excellent rant. I hope you feel better for writing it!! I feel better for reading it :-)
But RPED? I only ever saw that on Amstrad PC1512/1640 MS-DOS disks. A quick'n'dirty, nice simple editor :-)
Because it was so small and fast to load, I copied and used that for config.sys/autoexec.bat editing on every system and MSDOS version after that, especially anything that had to be booted from floppy :-)
Nowadays, it's whatever the default editor on FreeBSD is when you type "edit", or if on some version of Linux, nano. Anything more complex than editing a simple config file or simple script gets done in a "proper" modern GUI editor.
:-)
> But RPED? I only ever saw that on Amstrad PC1512/1640 MS-DOS disks.
In the days of EDLIN, "Roland Perry's EDitor" was just a better alternative.
But it wasn't limited to DOS. RPED also came preloaded on Amstrad CP/M Plus, that is, the CP/M 3.0 boot disks that came with every Amstrad PCW and, although I never had them myself, I believe also on floppy-drive-equipped Amstrad CPC and Spectrum +3 machines.
While on DOS Plus or MS-DOS 3.x, RPED was merely better than Edlin, on CP/M it was your only option. There was no bundled text editor in CP/M (AFAICR!) and so if you needed a .SUB file or a startup profile, it was RPED or nothing.
There were many alternatives out there, but you had to buy floppies with them on -- 3" disks, of course, while old CP/M machines used 8" and later ones 5¼" ones. Nothing else ran CP/M and used 3" disks, so no American shareware library could help you. Most of us didn't have a modem and so couldn't download anything, and in any case, the PCW didn't have a serial port as standard.
It was a different world back then. Then, in the 1990s and 2000s, everything came with an editor and they all used the same UI, from TextEdit on Mac OS X to Notepad on Windows to Kate or Gedit or any other Linux desktop's editor.
But still the Vi and Emacs people plow their lonely furrows of horrible (one could even say VILE) user interfaces from before this stuff was standardised. "Vim is editing at the speed of thought" my backside: I don't think in modes and I don't want an editor that has modes either.
Emacs *could* be modernised, but they'd probably have to fire Richard Stallman first.
Fire him again, I mean.
Dragonfly was forked at FreeBSD 4.x because Matt Dillon didn't agree with the way FreeBSD was doing SMP from 5.X onwards.
I've never actually heard any feedback on who was "right" on this issue. Putting aside everything else, like hammer, etc. who nailed the SMP problem?
I worked in a NetBSD shop around the time of the Dragonfly split and through the years I've heard many variations of the argument (sometimes in raised voices) about which approach works best. Consensus seemed to be they both are and since Net and Dragonfly (mostly) peacefully coexist I don't believe there is a "right" or "wrong" approach. As Liam said above, choice is good.
[Author here]
> who nailed the SMP problem?
The problem is that it's hard to define and measure.
Nowadays, according to benchmarking exercises, for large systems with a lot of CPUs or cores, Dragonfly is faster.
Caveat #1: OTOH, it is still a work in progress, and a lot of stuff isn't finished yet. Hammer2 is not yet usable across a cluster, for instance. It's possible that if it were, it would big a big help in performance.
So, from what I've read, Dragonfly beats FreeBSD _on very large systems_. NetBSD is allegedly far behind but this is not its main goal or a primary area of research.
Caveat #2: However, there's more R&D work in Linux and Linux does better at this stuff.
So Linux > Dragonfly > FreeBSD > NetBSD.
Caveat #3: most people don't have lots and lots of CPU cores and this stuff doesn't really apply to the desktop, where single-threaded performance is most important.
So Linux would probably win.
Caveat #4: ... along with filesystem performance and things, where ZFS wins. ZFS on Linux has unavoidable drawbacks, due to licensing issues. (E.g. the Linux cache and ZFS cache are separate.) Advantage, FreeBSD.
Caveat #5: Back in the day, Solaris scaled way better than Linux. I suspect on very large systems, it still might. If someone made enough money to throw at OpenSolaris, I reckon it could still win on large systems.
So... it's complicated. Depends which part of the market you're interested in, and there are no very clear winners and losers.
Heretical view: me, personally, I'd like to see the various BSDs settle their differences and recombine.
It will be interesting to see how much NetBSD has caught up performance wise whe version 10.0 is released. At the moment it's a beta release, but debugging options are still enabled in the official builds which currently slow it down.
At one point, it's performance got a massive boost when the threading implementation was rewritten. This was around 2010 if memory serves, and there was also considerable work on the SMP side of things that the simpler threading design made easier. For certain workloads (PostgreSQL for example), it outperformed Linux for a while.
Thanks Liam. It does seems a shame that Matts solution hadn't been used inside FreeBSD, and the combined resources put to better use.
I'm close on giving up on the FreeBSD organisation (not FreeBSD itself) - I've numerous bug fixes, and code enhancements lying around. I have logged some of them, yet no-one bothers even looking at them, yet alone doing anything about them, so there really isn't much point. There are only so many times you can update a bug report, or prod a mailing list until you become considered a spammer.
BSD was around well before 1992.
I remember hearing a couple of comments about when UNIX v6 was installed on the PDP-11 on the fifth floor of Evans Hall at UC Bezerkeley. One was: "If Bell Labs hadn't invented the transistor, the phone company would still be using vacuum tubes." Another was in respect to C "an abomination in the eyes of the Lord".
Luckily (or perhaps unluckily) for the computer world, the group developing what became BSD adopted pretty much the same software license and Pederson did with SPICE, you were pretty much free to do hat you want as long as mention was given to the Regents of the University of California.
From Britannica.
He [Bill Joy] responded in 1977 by creating Berkeley Software Distribution (BSD)...
Which supports the BSD article on the irrefutable (*cough*) Wikipedia!
"If Bell Labs hadn't invented the transistor..."
Poor Lilienfeld :(
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
