Switching customers from Linux to BSD because boring is good

One of Stefano Marinelli's NetBSD boxes sat quietly serving for a decade, because everyone forgot about it. This is how Unix is meant to be. After this year's Open Source Summit in Vienna, the Reg FOSS desk travelled to Dublin for the 2024 EuroBSDCon. One of the talks at the event was from the man who built that NetBSD server …

[may_i]

I love FreeBSD for its reliability

My TrueNAS server runs FreeBSD and behaves just like a proper UNIX server. It just does what it's supposed to do, year after year after year.

That iXSystems have now spurned FreeBSD for Linux so that people can overload their reliable storage systems with loads of plug in and VM add-ons is probably one of the most monumentally stupid decisions I've seen.

TrueNAS Scale? Just say no.

[collinsl]

Re: I love FreeBSD for its reliability

Nas4Free/XigmaNAS FTW!

[Graham Perrin]

Rationality

> stupid

You haven't seen the true rationale.

[collinsl]

Re: Rationality

Pray tell?

[bombastic bob]

Re: I love FreeBSD for its reliability

Long time FBSD user here, since early 2000's (version 4.7)

From article: One of Stefano Marinelli's NetBSD boxes sat quietly serving for a decade, because everyone forgot about it. This is how Unix is meant to be.

UPSIDES for FBSD: you can easily build everything from source! I typically do.

DOWNSIDE: building my system from source takes > a week and "up"graded ports sometimes no longer workl (but I get to fix them)

Also the devs are pretty good at accepting submissions but have VERY high standards. I've submitted a few things in the past, latest being SPI-related for RPi boards.

Icon, because FreeBSD

[_andrew]

Re: I love FreeBSD for its reliability

I've been rebuilding from source for longer than I remember: can probably count the number of cold-reinstalls since the PatchKit on the fingers of one hand.

I manage a portmaster run (to upgrade installed ports) and a buildworld/buildkernel every week and it usually only takes a couple of hours. Sometimes a bit longer if some system or database has aged out and the upgrade doesn't go smoothly, but that's rare. My "file server" is an 8-core Zen1 system at the moment though: dimensioned according to the compile times, rather than how much CPU is needed for samba, apache and mysql or whatever. I wouldn't be able to do this on a raspberry pi I think.

I do like the sense of security that knowing that I have the source code to everything that is running on the system, and that I can work at fixing anything that breaks. That's the key beauty of FreeBSD I think: there's nothing mysterious or magical. Does what it's told.

[andy 103]

Super reliable

In the mid 2000s I was asked by a local hair salon if I could build them a booking system.

They'd been given numerous demos off the shelf solutions but they were either overly complex, too pricey, or had bugs. When I went in to discuss the project one of their main requirements was along the lines of "the booking computer must never go down". They didn't need anything that was internet facing, just something they could use within the shop.

I realised that all of the systems they'd had demonstrated worked on Windows and several of them were crappy web apps that only worked in Internet Explorer.

In the end the solution I used was to build them a custom web app and install it on a NetBSD box. At the time their public website didn't take bookings although they said they might want to do that in future.

The entire solution ran for years to the point where I'd almost forgotten about it. It never once went down. About 7 or 8 years went by and they asked if I could adapt the system to take bookings from a website. It was relatively simple to make a connection from the NetBSD box to an endpoint that sent booking data to the system I'd built including cancellations and rescheduling.

They still use the system to this day and as far as I know have never experienced any form of OS error or application problem. Some of the hardware was upgraded over time and moving all of the installation across was one of the easiest, least painful jobs ever.

[mark l 2]

"Even on a home/gamer-level box. Something you can throw together in under 48 hours, which then lasts a decade."

For a server were you want things to be slow moving an reliable BSD is a good choice for something that you want to run for many years, but BSD as a gamer system?

[andy 103]

but BSD as a gamer system?

I don't think the suggestion is using BSD as an OS for a gaming set up.

If you read the externally linked article Marinelli says

> I suggested the client invest in Enterprise-grade hardware. However, they insisted on using a server they already had, assembled by a local vendor with “gaming-quality” parts.

[Clausewitz4.0]

"I don't think the suggestion is using BSD as an OS for a gaming set up."

I believe they are referring to more dangerous "games". Like Elbrus processors powering Russian weapons or VxWorks software powering USA weapons.

[Liam Proven]

[Author here]

> Like Elbrus processors powering Russian weapons or VxWorks software powering USA weapons.

Nope. I meant that Marinelli's box that ran for 12Y was built from leftover gamer-level bits, that's all.

I mean you may well be right but I was not even hinting at speculating about xBSD in defence kit. I don't know, and TBH, I don't want to know.

The most cheerful interpretation I could imagine was using it to build some super-secure encrypted laptop that can't even run exploits targeting Linux.

[Clausewitz4.0]

Ok, my bad.

[Anonymous Coward]

I've real your posts, you are always bad.

[bombastic bob]

Gamer-quality hardware

I usually get gamer-quality stuff. I run FreeBSD on them, "daily drivers" for dev work including running windows in a VM on occasion. Hard drives get replaced (easy for FBSD systems) but everything else generally keeps on going for DECADES.

My "server" and intarweb gateway is a really old Core Duo box (E-bay special) that I replaced the power supply twice in, added RAM, and new hard drive twice. Still working.

HD usually goes 3-4 years before ZFS starts detecting errors on scrub...

[Liam Proven]

[Author here]

> but BSD as a gamer system?

As @andy 103 says, no, that is not what I meant or said.

As per Stefano Marinelli's presentation, the NetBSD box he set up in under 48h that ran for 12Y with an over 9Y uptime was not built on server-grade kit, it was built from gamer components that the customer already had available.

That's what the reference to gamer-grade kit meant.

[MJI]

CELL OS

ORBIS OS

[Nameless Dread]

Coming shortly

Writing this in GhostBSD (FreeDSB-based). Sussing it out before switching from MX Linux (and from Miint and fromr Windows before that).

Just got to get to grips with Fish and then it's migration time.

Thanks to Liam for the articles.

[werdsmith]

When I first started out, I used to look at the Unix machines in the server room with the same kind of awe and fear I felt when I looked at the humming transformers in an electricity sub-station.

Now it has moderated somewhat but it still feels like the BSD variants are grown up serious stuff, and the linuxes are the toys and playthings.

[andy 103]

it still feels like the BSD variants are grown up serious stuff, and the linuxes are the toys and playthings.

Yes and no.

If you read the post I made earlier I used NetBSD about 20 years ago to deploy an application largely on the premise that it was a super reliable OS. The application and use-case of what I'd deployed was relatively basic. It was being used in a hairdressers although NetBSD could clearly be used for more demanding applications.

If I was to be tasked with the same project today - and didn't know anything about NetBSD or have that past experience - my guess is I'd deploy to AWS/Azure/Google Cloud on some Linux based VM. I'd be willing to bet it wouldn't be as reliable over the years; but suggesting Linux is a toy nowadays ignores how many production web servers it's powering. Some of which are used for very serious applications.

[Snake]

I'll agree

"I'd be willing to bet it wouldn't be as reliable over the years; but suggesting Linux is a toy nowadays ignores how many production web servers it's powering. Some of which are used for very serious applications."

I agree, Linux has proven itself a solid server OS. I think the "toy" is issue when people have decided to package Linux to make hundreds of versions of the server OS for desktop use. 'New Linux distro of the week' is tiring.

[Anonymous Coward]

Re: I'll agree

Yes, it's not so much "Linux is a toy", more "it's often used and packaged like a toy"

[Anonymous Coward]

Re: I'll agree

Indeed. And it's used and packaged like a toy because it's for overgrown toddlers who lack adult supervision. How else can someone explain why the output from ls on a Linux box looks like there's been an explosion in a paint factory?

[druck]

Re: I'll agree

Every use of colour is carefully chosen to signify a different property of the file, and is extremely useful to identify things quickly.

But that's all lost on you in your dull flat monochrome Windows world, isn't it.

[Anonymous Coward]

Lost on who?

Clearly, fundamental design principles of Unix are lost on you.

In Unix every file is just a byte stream so applications don't (need to) care where they read from or write to. In Linux, ls breaks that because the application changes its behaviour depending on where its output goes. This is wrong. And spectacularly stupid.

If the output goes to a tty, you might get pretty colours - assuming that output target emulates an X terminal window or whatever. If it's some other device, it might or might not show the same colours. And if that output goes to a file or pipe, the result will be different again. Producing inconsistent output like this by design leads to the mindlessness that produced systemd. Instead of doing just one job and doing it well (listing a directory), ls on Linux randomly generates paintball patterns based on where it thinks the output is going. Which is obviously far more important than printing the actual directory entries without gratuitous, unnecessary noise.

Next, files in Unix do not have properties. They're just byte streams. IIUC they're supposed to be just byte streams in Linux-land too.

Saying the colours are "carefully chosen" is utter bullshit. Chosen by who BTW? Psychedelic ls output doesn't help if you're colour blind. In fact it's probably a hindrance. You're also supposed to identify things quickly - I assume you mean files - by their actual names, not what colour they get displayed in. Of course I realise Linux victims usually need extra help here because directory file names tend to get an unnecessary .d suffix appended to them.

[yetanotheraoc]

Re: Lost on who?

Lost on _whom_?

Chosen by _whom_ BTW?

Goofy. :)

I find the colors slightly distracting at worst. You can turn them off if you wish. And thanks for the tip about .d suffix, I might find a use for that in future.

[ovation1357]

Re: Lost on who?

I'm not entirely sure one jump straight from colourised output from "ls" to the monolithic beast of "systemd"

Colours used in ls are optional but enabled by default in modern distros using bash or other modern shells. In fact, ls itself does not use colour by default but distributions/shells come with default aliases such as 'ls=ls --color=auto'. Such built-in aliases may not be to everybody's taste but they can easily be changed to suit individual preferences.

Personally, I find it helpful but those who dislike it can disable it, and in the case colour-related visual impairments, the colours are fully customisable ('dircolors' and the LS_COLORS variable), so I'm sure there will continue to be a user choice between no colours or alternative colour schemes.

I hate to point out that FreeBSD offers 'ls -G' for colourised listings when using a compatible terminal, which can be set up as an alias to make it the default.

I'm also reasonably sure I used colourised ls output on Solaris back in the day.

There are many things to dislike about the state and direction of the Linux ecosystem but does 'ls' including optional support for colour terminals deserve a place on that list?

[Doctor Syntax]

Re: I'll agree

I think the "toy" thing is mostly thrown about by Windows* users who've never quite grasped that it's grown a bit since it was a student project. In fact, as a desktop or laptop OS based on something like Debian or, for preference, Devuan it's a reliable, rich daily driver. Given that much of the application S/W is also available for the BSDs I'd expect that a BSD system would do just as well.

In reality the Linux world divides into several areas. One is the reliable, slow moving, just what you'd want for server or daily driver. Another is the embedded, anything from Android to your router or allegedly smart TV. A third is the experimental, possibly bleeding edge pushing the OS envelope area. The latter I wouldn't want to use either as a server or a desktop for doing work. There's some overlap, of course - ChromeOS would be an example Also ideas that mature in the third category will make their way into the others but if you think the third category is what desktop Linux is all about you're missing the point.

* Now that's something I really regard as - maybe not a toy but something I wouldn't dream of using for serious work.

[JakeSays]

Re: I'll agree

Considering that Linux runs on more devices than any other OS, I would say it is more than just a reliable server OS.

[werdsmith]

Yes and Yes.

How I feel about it is down to me.

[mmccul]

Lack of commercial support is a problem

For any system I run today, I need the ability to run certain tooling, such as an EDR (yes, including on servers). Unfortunately, support for the *BSDs is quite lacking. Yes, there are longstanding feature requests to add support, but the movement has been away from the BSDs, not toward them.

[Anonymous Coward]

Re: Lack of commercial support is a problem

https://heimdalsecurity.com/blog/open-source-edr-tools/

[mmccul]

Re: Lack of commercial support is a problem

And then it lists a whole bunch of tools that even the sales people don't claim are EDR like ossec, snort, Tenable vuln scanner, etc.

Having dealt with Heimdal Security before, I'm especially cynical about them.

[Anonymous Coward]

Re: Lack of commercial support is a problem

Fair enough. It's obviously a subject you know more about that I do. I had previously heard FreeBSD was well covered. A shame to learn otherwise.

[Greg 11]

Re: Lack of commercial support is a problem

there's a port for Wazuh also: https://www.freshports.org/security/wazuh-agent

[bombastic bob]

Re: Lack of commercial support is a problem

FreeBSD has a Linux compatibility layer (Currently with CentOS 7 userland lib binaries). I think CentOS 7 is still being supported for software (though it went EOL in June).

Maybe that helps?

[Greg 11]

Small correction

Great article!! 1 teensy correction:

"At the same event, we met one of the developers working on modernizing FreeBSD's laptop support, as we recently reported now aided by STF funding."

The funding to modernize laptop support is not from STF, but rather Quantum Leap Research and the FreeBSD Foundation

[ptribble]

Applies to illumos too

You could pretty much replace FreeBSD with illumos and exactly the same applies - boring and invisible is good. Stability at both the system and interface level is paramount.

(As a big difference, illumos doesn't have any Sovereign Tech Funds backing it.)

[Arthur the cat]

Differences

… yet that doesn't mean that all the same programs and commands are there. They are not. FreeBSD is not a some odd, different cousin of Linux: it is very different OS

I'm a long term FreeBSD user with a couple of Linux boxes and get caught out on commands occasionally, but it's no big deal because I'll remember it's ip rather than ifconfig (or whatever) pretty much as I hit return. The OS that makes me incandescent with rage is Mac OS - sort of Unix, but very definitely isn't. /etc/hosts? Sure, you can create one for a quick fix but it will be ignored. Want to mount NSF disks in the same place as all the other boxes? Nope, they must go under /Volumes. Lots and lots of niggling little differences that totally bugger up Unix admin, because Mac OS is for "creatives" and they don't understand need to worry their pretty little heads about such things.

[Liam Proven]

Re: Differences

[Author here]

> Lots and lots of niggling little differences that totally bugger up Unix admin

I have been reading comments like this since I was running Mac OS X 10.0 "Cheetah" on a heavily-hacked PowerMac 7600 via XPostFacto.

Yes, it is based on some Unix code. Yes, it passes compatibility testing. It is a UNIX™.

But no, it is not like any other Unix, and if you try to treat it like one, you will have a bad time. It's a hybrid OS with a Unix-derived userland that enabled NeXT and Apple to get to market with a multitasking GUI OS years earlier than just about anyone else.

It predates Windows NT, Linux, FreeBSD/NetBSD/OpenBSD, and was demonstrated in public the same month that OS/2 1.1 was released, the first version of OS/2 with a GUI. (And a fairly ugly GUI it was, especially compared to the beauty of NeXTstep.)

The *only* other GUI OS that is still maintained from the same codebase that survives that is contemporary with what's now called macOS is RISC OS. Windows has been replaced with a rewrite. OS/2 was replaced with a rewrite. All modern FOSS Unixes date from the decade after NeXTstep.

It's _old_. And it's a pure play GUI workstation OS. Its creators cheerfully tore up the rule book and ripped out all the existing plumbing meant for workstations.

The result has been a product with sales in the billions: iOS and all other Apple OSes are based on OS X. I think it is fair and accurate to say that sales of the Apple OS family exceed _all_ sales of *all other proprietary and licensed Unix of any form PUT TOGETHER.* That's every proprietary/commercial Unix, counting seats not CPUs, and I strongly suspect all sales of all commercially licensed Linux (SLE, RHEL etc.) put together, don't even make a dent in the comparison... and Apple is 1 box = 1 user.

(And yes, I am also counting the weird things that passed Unix certification like z/OS and OpenVMS. And by seat for them too, not by processor, which boosts their numbers by at least an order of magnitude.)

Few Macs run anything except macOS, just a tiny rounding error, and macOS runs on nothing but Macs, except for a tiny rounding error.

No, it is not like other Unixes.

And the most important way? Unlike other Unixes, it's commercially successful.

[two00lbwaster]

Re: Differences

It's like Windows in its own way, it has had very individual choices go into. It's funny that Linux has generally ended up choosing to more closely mimic Windows rather than MacOS's patterns. I wonder why that is? I have some thoughts on the matter.

[bombastic bob]

Re: Differences

Micros~1 has had their grubby little fingers in projects like Gnome and (pretty sure) FreeDesktop. I *HATE* what they did to it, especially ADWaita and the 2D FLATSO-ness they have helped FOIST upon Linux. Even Mozilla integrates that look now... fortunately you can theme Mate to use 'TraditionalOk' and derivatives

(and don't even get me started on Wayland...)

[Doctor Syntax]

Re: Differences

I take it "seats" doesn't include all the users of world-facing web servers.

[Liam Proven]

Re: Differences

> I take it "seats" doesn't include all the users of world-facing web servers.

Several possible answers here. :-)

* Do they have accounts on the server? Are they licensed users? If not, then no, it doesn't.

* How much of the WWW was served from proprietary UNIX after its first few years, do you think?

The Web and FOSS xNix have grown hand-in-hand. Proprietary UNIX wasn't much involved since its invention -- on NeXTstep, of course.

[Anonymous Coward]

Re: Differences

"But no, it is not like any other Unix, and if you try to treat it like one, you will have a bad time. It's a hybrid OS with a Unix-derived userland that enabled NeXT and Apple to get to market with a multitasking GUI OS years earlier than just about anyone else."

Indeed NeXTSTEP was unique in its day: kernel based on Mach kernel, Display Postscript for UI, out-of-the-box TCP/IP and Appletalk and Novell networking, Objective C as its main language...

I used to work at a NeXTSTEP reseller (and as well as running a Linux-based ISP) in the early 1990s. I still have a NeXT-formatted MO-cartridge lying around here somewhere.

[Graham Perrin]

FreeBSD predates Mac OS X

Nit (sorry): Mac OS X did not predate FreeBSD.

FreeBSD originated in 1993.

https://freebsdfoundation.org/freebsd/timeline/

https://freebsdfoundation.org/wp-content/uploads/2023/06/FreeBSD_timeline.pdf

https://en.wikipedia.org/wiki/MacOS_version_history#Releases

[Liam Proven]

Re: FreeBSD predates Mac OS X

> FreeBSD originated in 1993.

Hi, Graham!

FreeBSD arrived 5 years after NeXTstep was first shown publicly.

NeXTstep was first publicly demonstrated, as version 0.8, in 1988.

https://www.youtube.com/watch?v=92NNyd3m79I

NeXTstep 1.0 was released in 1989.

https://betawiki.net/wiki/NeXTStep_1.0

NeXTstep got to version 3.3 (1995) and was in the process of being replaced by version 4, renamed OPENSTEP, when Apple acquired the company in 1997, and it was renamed Mac OS X. OPENSTEP 4.2 (1997) was the final release.

https://betawiki.net/wiki/OPENSTEP_4.2

Rhapsody, later sold in limited numbers as Mac OS X Server, was effectively NeXTstep 5.

NeXTstep → OPENSTEP → Rhapsody → Mac OS X Server → Mac OS X → OS X → macOS.

The branding changes but the OS is the same.

I stand by it. The first commercial released version of the OS that is now called macOS predates Windows 3.0 by a year, Linux by two years, 32-bit OS/2 by three years, and FreeBSD/NetBSD/Windows NT by 4 years.

[Arthur the cat]

Re: FreeBSD predates Mac OS X

Well, if we're getting into the greybeard(*) techie equivalent of the four Yorkshiremen sketch :-)

FreeBSD is just a name, the original code was simply BSD (with some code stripped out for legal reasons IIRC) ported to IBM PCs, and BSD's initial release was 1978. And BSD was derived from version 6 Bell Labs Unix, the initial C version of which (V4) was released in 1973(**). [I feel I should be using "begat" here for some reason.]

The *BSDs are the Carrier Strike Group of Theseus.

And all Unix alikes, whether they're adaptations of the original or merely influenced by it, ultimately owe their existence to Multics, which was Alien Technology compared to the other commercial OSes of the time.

(*) Mine is greyerwhiter than Liam's.

(**) And strictly speaking, that original Unix code was proprietary.

[ovation1357]

Re: FreeBSD predates Mac OS X

Luxury!

And if you try and tell the young folks of today...

[Handy Plough]

Re: FreeBSD predates Mac OS X

Then NeXT/OpenSTEP/Mac OS X/macOS are essentially *the same* as they stem from the same branch of Unix.

[_andrew]

Re: FreeBSD predates Mac OS X

And FreeBSD itself has a history that traces back through PatchKit on top of 386BSD (Jolitz/Dr Dobbs) and thence to the Net/2 tapes and 4.3RENO repo-edited/patched with 4.4 after the AT&T case.

To be fair, 386BSD was '92, which still doesn't predate the NEXT demos, but you could have read about the latter on Usenet from a SunOS system based on 4.2 or an Ultrix box running 4.3 and felt very much the same, and I'm pretty sure that I did.

[Liam Proven]

Re: FreeBSD predates Mac OS X

> FreeBSD is just a name, the original code was simply BSD

It was, but I think it's important to distinguish the projects, with names and communities of contributors and codebases of their own, from their ancestors.

BSD -> 386BSD (and lots of others) -> NetBSD _and_ FreeBSD

It's not a line. It's a tree, with many branches, and the key points are that certain branches are in the open air, and continued and still do, while most of the others sprouted within the walls of companies and when the companies collapsed those branches died.

NetBSD is not the same OS as FreeBSD. They have different commands and different abilities. The packaging and updating commands and so on are more different than 2 related Linux distros. FreeBSD is deeply integrated with ZFS, but it's an optional extra on NetBSD and it doesn't exist on OpenBSD.

All of them have influence from GNU and each other, and from the dead commercial ones now too.

It's disingenuous to airily proclaim "oh well they're all just BSD really!"

I'm a white Brit. Maybe you, "Arthur the cat", are a white Brit too. Or a white American or other Anglophone. If so, we're probably related. We're probably descended from Charlemagne. We're family! We're as good as brothers. Pop us an SMS with your bank details and PIN, will you? I could use a couple of spare grand. I mean, by your argument, we're the same person really...

[Arthur the cat]

Re: FreeBSD predates Mac OS X

It's disingenuous to airily proclaim "oh well they're all just BSD really!"

I refer my learned colleague to the four Yorkshiremen reference earlier.

We're probably descended from Charlemagne.

And quite possibly Attila too. I'll claim Felis silvestris silvestris as well.

I mean, by your argument, we're the same person really...

I wondered where the intrusive thoughts were coming from. Do you really do that with rhubarb? Doesn't it make your eyes water?

[Graham Perrin]

Re: FreeBSD predates Mac OS X

Sorry, some misunderstanding:

"… I was running Mac OS X 10.0 …

"It predates Windows NT, Linux, FreeBSD/NetBSD/OpenBSD, … (And a fairly ugly GUI it was, especially compared to the beauty of NeXTstep.)"

I took the "It" to mean Mac OS X, not NeXTstep.

[Liam Proven]

Re: FreeBSD predates Mac OS X

> I took the "It" to mean Mac OS X, not NeXTstep.

That's the point. *It is the same OS.*

If FreeBSD 14.1 is the same OS as FreeBSD 1.0 was in 1993, then macOS 15.01 Sequoia is the same OS as NeXTstep 0.8 in 1988.

[Ian Johnston]

I had a HP print server which ran without needing any attention at all for over twenty years, during which period it only rebooted because of power cuts, once every couple of years or so. I presume it had some sort of OS, thought it wasn't terribly full-featured.

[Anonymous Coward]

Rule of thumb is:

If you want naff "modern" features, home desktop and games, stick with Linux.

But if you want a good operating system, give BSD a shot.

[Doctor Syntax]

What's "naff" or "not good" about a reliable working desktop for everyday work?

One irony about how little you've thought about this is that, depending on what's in the ports and hardware support you could build equivalent desktops on either Linux or BSD. Why would one be "naff" and the other "a good operating system"?

Another is that if you need, for whatever reason, a platform to run a commercial RDBMS from the old days when the big commercial Unices ruled the roost you'll be able to use Linux because I don't know that there are BSD ports. In that situation which is the "good operating system" and which is "naff"?

[JakeSays]

Good operating system for what? The definition of good is completely use case dependent.

[Anonymous Coward]

No security updates

Nine years of uptime isn't possible unless you don't apply security updates. The kernel and server daemons he was running (which included externally accessible Apache and PHP, SSH, internal dhcpcd, etc.) have all had security updates since NetBSD 5.1 was originally released in 2010.

You could put pretty much any operating system on reliable hardware and run it for decades without any updates, but I'm not sure you'd want to.

[Tim99]

Re: No security updates

You certainly is possible, just don't connect it to anything else...

[Jonathan Richards 1]

Re: No security updates

Well, I upvoted that post before I saw the joke icon. You keep the upbovote, but IMHO it's not a joke, at all. A server connected solely to clients on an internal network, as here, is pretty damn secure. If you don't need any new functionality introduced by updates, then updates are nugatory. Finite state machine just goes on changing between one of its finite states and the next one ...

[toejam++]

Re: No security updates

Not to mention that you can always upgrade the user-land without rebooting the kernel. And you can go a number of years before the included libraries start to impede your ability to upgrade packages.

[bombastic bob]

Re: No security updates

FBSD's "build from source" let's you apply direct patches to the source, then re-compile and restart affected daemons. I do this locally so I do not have to update EVERYTHING to apply a single patch, depending. Or you can use binary packages if you want.

build from source is integrated into the ports system. No need for "-dev" version insanity.

[Anonymous Coward]

Re: No security updates

> A server connected solely to clients on an internal network, as here, is pretty damn secure.

The linked blog post says the server was running Apache and PHP connected to the external network.

Aside from that detail, your claim that servers are secure if they're only on an internal network is fundamentally incorrect. All it is takes to get access to the network is one compromised laptop that gets connected to that network. Or even a compromised WiFi key. Back in 2010, cracking WPA keys using software like Aircrack was trivial.

The bottom line is that server security should not depend on network security. This is such a fundamental security point that encryption expert Bruce Schneider famously runs all of his home networks unencrypted with open WiFi APs to show that security must be within and between devices. You should never trust the network.

[halfstackdev]

Re: No security updates

You can upgrade and patch jails individually without needing to reboot the base system

[Clausewitz4.0]

Re: No security updates

Back in the University days, I had a firewall and dhcpd running for about 2 years. UPS on it. Slackware if I remember well. Only SSH, iptables, ebtables, dhcpd.

[ChrisElvidge]

Re: No security updates

For a reliable Linux server, I would go with Slackware, too.

IIRC, I ran Slackware (no GUI) servers from about v3 in the late 90s.

[David Haworth 1]

Don't forget 386BSD!

The statement that *BSD predates Linux is questionable.

When I first started dabbling with Unixy OSes on my home PC, I installed a copy of 386BSD. That was in the early '90s. IIRC, it was before Linux appeared on the scene - or before Linux appeared as a "product" to buy.

The main problem with 386BSD was getting the X server to work with the graphics card in my PC. I eventually gave up and replaced 386BSD with one of the first iterations of Slackware, and I've had Linux on the desktop ever since. But perhaps I should consider using *BSD on my servers. Diversity is always good, and servers don't need graphics.

[Handy Plough]

Re: Don't forget 386BSD!

The Berkeley Software Distribution go back to the 1970’s! It literally predates Linux by over a decade. What we have today are in essence forks of the original BSD. Nearly all the BSDs and commercial UNIX OSs (including Darwin) can trace direct lineage in some way back to the Unix of Ritchie and Thompson.

[JakeSays]

Re: Don't forget 386BSD!

Indeed! 1BSD was released in 1977.

[Liam Proven]

Re: Don't forget 386BSD!

[Author here]

> IIRC, it was before Linux appeared on the scene

I am afraid you recall wrongly.

386BSD 0.1 -- July 1992:

https://groups.google.com/g/comp.unix.bsd/c/zA8Jl89HSRo/m/DqMzaUUZ7wYJ

Linux 0.97 followed days later:

https://github.com/oldlinux-web/oldlinux-files/blob/master/Linux-0.97/docs/CHANGES-0.97

In other words Linux had moved beyond the early experimental 0.0x releases and was counting down to 1.0.

I wasn't using Linux then. I was aware of it and was tracking the project but frankly it was when kernel 2.0 appeared in 1996 that I felt it was useful and usable.

https://lkml.iu.edu/hypermail/linux/kernel/9606.1/0056.html

[Jamie Jones]

Re: Don't forget 386BSD!

[ Commenter here ]

Liam, not directly related to this thread, but I must say that it's really great that you always read and liase with the comments on all your articles.

[Liam Proven]

Re: Don't forget 386BSD!

> Liam, not directly related to this thread, but I must say that it's really great that you always read and liase with the comments on all your articles.

Why, thank you!

I do try to. Once they spill over onto a few pages, though, usually I am too busy with the article after the article after next or something...

That's my story and I'm sticking to it. ;-)

[thames]

Seems to work for the basics

I have been using FreeBSD and OpenBSD as test targets along with all the major Linux distros and Windows for quite a few years now running in VMs on an automated testing system. At first I used Virtualbox, but have lately switched over to KVM. The test method involved starting the VM, loading the packages over SSH, compiling the source, running the unit tests and benchmarks, and then downloading the results. I have this all automated.

For the most part running FreeBSD was more or less like running Linux, with two exceptions. One was the standard shell wasn't Bash, and so didn't have Bash extensions. This meant that any shell scripts which needed to run on the target (managing installation and tests and things like that) needed to not have any Bash extensions in them. If you google for answers about how to do any shell scripting, virtually all the answers you get assume that you are using Bash. This means that you need to really know your shell scripting quite well in order to stick to the older (and less convenient) syntax supported in BSD. It's doable, but it's something that you need to take the extra effort over.

The other major difference was the C compiler. Straightforward vanilla C does not support many modern CPU features, which means that you either need to write those bits in assembly language or use extensions (or not use those CPU features). For the most part LLVM supports GCC extensions, but in some places that support is still lacking. I write fallback vanilla code anyway, so it does compile with LLVM, but the program does take a significant performance hit in doing so. This will only affect some types of applications, so you need to benchmark this yourself to see if it affects you.

Even when compiled without extensions in both cases, LLVM used to produce drastically slower code than GCC (and slower than Microsoft C). However, over the years LLVM performance has gradually improved to the point where it's now not far behind GCC and the Microsoft compiler now produces the slowest code of the three on average. What I have learned though is that different compilers have different strengths and weaknesses, so you need to benchmark your own specific application rather than depending on generalizations (I'm mainly doing numeric computations).

Using OpenBSD was a lot like using FreeBSD, but starting with version 7.3 it would no longer install in Virtualbox. Instead I had to install 7.2 and upgrade from there. After I switched to KVM I can't get it to install regardless of what version I try. Version 7.6 just came out so I will be giving it a try, but I'm not holding out a lot of hope. Apparently this is a very well known problem and there are various blog posts around the Internet claiming to offer various devious ways of hacking around it. If I get some time I will try some of them, but none look simple. If you plan on running BSD in a VM, you may need to try various types to find one that works for you.

The main reason that I use BSD is to be able to do testing on a different platform and compiler while still remaining similar enough to Linux to make the additional effort minimal. Testing in different environments (and with different compilers) helps turn up bugs that would otherwise perhaps not surface in a testing environment. When I first starting adding different environments it turned up all sorts of bugs which I would not otherwise have found. This was a fairly common practice in the late 20th century - it's not that one compiler is "better" than another at finding bugs. It's just sufficient that they are different. If you are writing software for Linux and do any automated testing it's worth adding at least one of the BSDs to your list of testing VMs even if you don't foresee much of a market there in terms of number of users.

[two00lbwaster]

Re: Seems to work for the basics

Not to mention all those bash scripts that start #!/bin/bash instead of #!/usr/bin/env bash -

Having wrote a lot of scripts to target multiple types of OS, starting any such search with POSIX tends to help. I know that some people symlink /bin/bash to the location of their bash install specifically because of that above issue.

[Anonymous Coward]

Re: Seems to work for the basics

"Not to mention all those bash scripts that start #!/bin/bash instead of #!/usr/bin/env bash"

WTF? Non-portable shell scripts?

[elip]

Re: Seems to work for the basics

Huh? I've been running various OpenBSD versions on various KVM versions for years, both in KVM-based clouds, as well as a guest on my own private plain-old CentOS 7.9 server as daily driver at work. What issue are you seeing with installing recent OpenBSD versions on KVM?

[thames]

Re: Seems to work for the basics

The installation stops at the point where it asks whether to install, upgrade, autoinstall, or shell. I have just now tried this with OpenBSD 7.6 (the install screen is still lookng at me). It appears to simply not be accepting any keyboard input. This would seem to imply that I can't fiddle with the boot options from the console either.

I'm using Virtual Machine Manager 4.1.0 on Ubuntu 24.04, installing from the ISO (install76.iso amd64), and accepted the standard defaults.

I have just recently started using KVM. I have a new automated testing system and used the opportunity to switch from Virtualbox, having used the latter for many years (because the testing scripts were designed to work with its peculiarities.

OpenBSD would not install in VirtualBox from version 7.3 onwards. I can't recall the details, but my note that I have with the ISOs simply says that it would not install. However, version 7.2 would install, so I was able to simply install 7.2 and sys upgrade from there without any problems. However that option doesn't work with KVM.

If you have any suggestions I would be happy to hear about them. I plan on working on this problem today and If I have any success today I will make another post on this thread.

[Anonymous Coward]

Re: Seems to work for the basics

Your post reeks of "FreeBSD does it wrong. Linux does it right"

If you're going to play that game, it's actually closer to the other way around. It's Linux systems that have deviated from the norm.

But I'm not going down that route. Just look at the practicalities.

bash is an abomination of a shell. One of my main bugbears is Linux bashism scripts that easily could have been written properly.

Bash has it's place - if you really want to use its features, have it as your own personal interactive shell. Making it the core root shell is ridiculous.

There is a good reason why sh is the defacto shell on Unix systems. Oh, and it hasn't stagnated. The official shell is being updated.

[thames]

Re: Seems to work for the basics

It might help to actually read a post before you hit the reply button. The standard shell for /bin/sh in Ubuntu and Debian is Dash - Debian Almquist Shell, which is a POSIX standard shell.

The standard interactive shell is Bash (/bin/bash). If your shell script just asks for /bin/sh you get Dash, not Bash. If you open a terminal to interact with or your script asks for /bin/bash you get Bash. The majority of Linux distros are Debian derivatives, so most of them do the same. I can't speak for Red Hat or Suse derivatives on this.

However if you google for answers to questions about shell scripting nearly all the answers you get will be for people assuming you are using Bash, even if they do not explicitly say so. Therefore if you decide to use pretty much any BSD you need to know your shell scripting well enough to distinguish between standard shell syntax and Bash extensions.

The Bash extensions are very nice to have, but they are Bash specific and don't work in Dash, let alone any of the BSD shells. This is something that anyone trying out BSD needs to be aware of. Therefore don't copy-paste shell scripts from the Internet without having a good look over them for Bash specific extensions.

[two00lbwaster]

I like FreeBSD and admin'ed a couple of hundred boxes running it for a good few years. These days Kubernetes is such a strong solution to solving the problems around hosting Web applications that they would have to break into that ecosystem to get people doing that kind of thing to bring it back into consideration.

Its funny, because jails have the ability to act like docker containers, zfs datasets, snap-shotting and exporting snapshots could stand in for the layering format for those containers so a lot of the same kind of tooling is there to support that same approach (you could even make it dockerfile compatible).

On Proxmox it would be nice that there would be an equivalent for BSDs, though, once you have decoupled and modularised something so that it can support different hypervisors and package manager solutions it would probably mean that you could add support for most of the NIXes. Given that Proxmox is pretty tied to Debian it's unlikely to be that. The problem is getting enough people interested in it.

I can hold out hope that something like Redox OS will take off and is the future, I'm still young enough that it could happen :D

[Liam Proven]

[Author here]

> On Proxmox it would be nice that there would be an equivalent for BSDs, though,

https://clonos.convectix.com/

It's not ready yet but it's coming.

[Blackjack]

The point is, ladies and gentleman, that boring -- for lack of a better word -- is good.

Boring is right.

Boring works.

Boring is reliable, boring is not unexpected, boring gets the job done!

Boring, in all of its forms, has marked the upward surge of mankind. Because when things get boring, when there is no surprises it usually means you are doing things right.

And boring -- you mark my words -- will not only save you time and money, but also that of others.

So you say BSD is boring? I say that is an advantage.

Thank you very much.

[Philo T Farnsworth]

Ignoring a system is good?

I ran FreeBSD on several systems over the years and am a fan, albeit a lapsed one, having moved to Ubuntu for most of my work now.

I like "boring" when it comes to operating systems too, but I'm not sure that a box "quietly serving for a decade, because everyone forgot about it" is necessarily a good thing or whether "This is how Unix is meant to be."

An ignored box eventually becomes an insecure box, as vulnerabilities are uncovered, and if it's not managed because someone forgot its existence doesn't seem to me be an approach to security that should be lauded.

I don't necessarily need or want all the latest "shiny-shiny" but still, keeping a system up to date with patches strikes me as a good thing.

Perhaps I'm missing something here.

[Yankee Doodle Doofus]

Re: Ignoring a system is good?

< "Perhaps I'm missing something here."

I don't think it is implied, and certainly not directly stated, that going a decade without updates is desirable. The point of that anecdote is the stability of the OS.

[bazza]

Re: Ignoring a system is good?

I think that the real answer is, as ever, it depends.

Coming from a background of high performance compute, Linux is where it's at. The CPU manufacturers contribute to make sure Linux works well on their chips, and Linux itself has focused on "performance". Throw in PREEMPT_RT too (now firmly adopted into Linux properly) and you have a handy RTOS too (well, RT enough for a lot of applications). GLIBC is also a major component of Linux's performance, with it's performance-orientated memory allocator.

Other operating systems possibly lag somewhat in taking advantage of newer CPUs (though I admit that that is an entirely subjective view. The performance of, say, FreeBSD surely isn't that bad; Sony use it on their Playstation line, and that's not a product where gross inefficiency in the OS would be acceptable). But even then it depends; if there's a single task to run with little by way of needing the OS, then it's largely down to the compiler for the application.

I have noticed some notable reliability differences. One example is GNU Radio. The version I was using ran absolutely fine on Linux, no apparent problems. However, the exact same code built on GhostBSD hit segmentation faults running a particular graph. Clearly there was a memory fault somewhere in there that wasn't showing symptoms (so far as I could see) on Linux, where as GhostBSD's more defensive allocator worked as intended.

[Doctor Syntax]

Re: Ignoring a system is good?

"Perhaps I'm missing something here."

The fact that in this particular case it wasn't - gasp of astonishment - connected to the internet. So all the updates, and the little surprises such as something you were depending on has been deprecated, are irrelevant.

[Liam Proven]

Re: Ignoring a system is good?

> Perhaps I'm missing something here.

From this and several other comments in other places, I am guessing people did not watch the talk or read the blog post.

The customer changed their firewall so the box became internal-only. Having not heard from them in years, Marinelli changed his VPN appliance and that severed the remote-management connection he'd had, so it was not contactable from the outside world even by its sysadmin any more.

[Anonymous Coward]

Re: Ignoring a system is good?

I read the blog post. He says he set up the server in 2010 running external websites and external VPN. He "lost touch" with the client around 2013. In 2015 the VPN access stopped working. In 2021, the customer contacted him, and he found the server's last reboot was in 2012. The external web sites were still active but apparently no longer accessible from the internet ("wisely kept hidden" as he says, implying that he knew the web sites were no longer secure).

It does sound like there was a window of several years where the server was connected to the internet and running web sites without anyone being responsible for its security.

[PyLETS]

Why not use both ?

Sure I'd consider BSD for a server application which needs to run on a virtual machine for years without hassle, so long as it didn't have too many dependencies I had to compile and fix the source code for. That's where the package system which keeps the convoy of supported applications compatible with each other together, and that comes with the OS, is crucial to whether or not it's the right tool for the job.

Before good package systems, a lot could be achieved by compiling stuff from source code, but nowadays that can all too easily result in dependency hell and a lot of bug fixing.

Just about any OS and it's supported software packages will come to end of security supported life at some point where your choice is to let the application you've built on it continue until someone breaks it, or to rebuild it on something newer which does have security support. Using the OS's self upgrade mechanism doesn't always upgrade all the application dependencies - sometimes these are left installed and running but lose security support themselves.

There's also probably greater differences between different Linux flavours including embedded versions running on matchbox sized routers with tiny amounts of memory, than between server versions of Linux and BSD.

[stefano79]

I Solve Problems

Hello, I'm Stefano Marinelli, and I'm both surprised and delighted to see this article about my talk and my experience. Thank you, Liam!

The article perfectly captures my point of view: the passion for technology always leads to exploring new avenues, and that is the fuel to keep moving forward. The *BSD systems innovate without upheaval, ensuring enviable stability and continuity. They are tools that allow for calm and consistent work. I see that OpenBSD wasn't mentioned (which I referenced several times in my talk), and it's a pity as it exemplifies how doing things right from the start leads to long-term results (for example, RegreSSHion was effectively prevented back in 2001).

But this will encourage more people to read the original article. :-)

Thanks again, Liam, for this good article!

[Doctor Syntax]

Re: I Solve Problems

And thank you, Stefano, for the interesting article on the 9-year server. I agree with your philosophy about clients who appreciate stability. Apart from anything else they do keep coming back because they'll want something more as business requirements change and you also get more clients from the best form of advertising - word of mouth.

[Liam Proven]

Re: I Solve Problems

> Thanks again, Liam, for this good article!

Oh, excellent. I am very glad you liked it. :-)

[Frank Leonhardt]

Linux older than BSD?

I think you mean the Linux kernel has been officially FOSS a bit longer than BSD ;-)

Berkley Unix dates from 1978 IIRC, although you could argue that was just a fork of Version 5.

The first Linux kernel didn't show up until the 1990s, and was just a kernel to begin with.

When it came to setting up a public Internet hosting company in the early 1990s, BSD was the obvious choice when moving from Solaris. Why use the new knock-off when you could now have the real thing for free?

[bazza]

Re: Linux older than BSD?

Linux was just a kernel, with a GNU userland added on top.

That could be changing; there's a project in play to re-implement the core utilities in Rust.

[John Brown (no body)]

Re: Linux older than BSD?

"there's a project in play to re-implement the core utilities in Rust."

Why? Shirley SystemD will do all that long before that project completes!!

[Anonymous Coward]

Re: Linux older than BSD?

And if Pottering decides a memory-safe language is needed for it, he will write his own.. System-Bust !

[Graham Perrin]

Stop calling me Shirley.

> Shirley SystemD will do all that …

[Anonymous Coward]

Re: Linux older than BSD?

"Linux was just a kernel, with a GNU userland added on top.

That could be changing; there's a project in play to re-implement the core utilities in Rust."

I've heard there's something called Busybox that could be used instead of a GNU userland, Liam even mentioned it last week: https://www.theregister.com/2024/10/04/busybox_137/

.......oh, hang on a minute, Alpine Linux has been using Busybox instead of GNU userland for quite a few years now (and there are other Linux distros also doing similarly).

[bombastic bob]

Re: Linux older than BSD?

Right, Linksys wifi routers back in 2005 used busybox. It makes for a very tiny userland. In short, it hosts all of the utilities in one application, and symlinks for ls, mv, rm, etc. point to the busybox binary. it uses argv[0] to determine what functionality you get. It loads really fast, and is tiny compared to separate utilities. Good for getting a Linux 2.x image into a 4M ROM for a ~100Mhz MIPS or ARM system.

[toejam++]

Re: Linux older than BSD?

1977: First fork of 1BSD from Unix v6.

1983: Release of SunOS 1.0, the first stand-alone OS based on BSD (pre-1.0 was based on Unix v7)

1991: Initial release of Linux kernel.

1992: Initial release of 386BSD, the first free stand-alone OS based on BSD

1993: Initial releases of NetBSD and FreeBSD

[Liam Proven]

Re: Linux older than BSD?

> Linux older than BSD?

No. Again, no: older than NetBSD, which is the oldest of the *FOSS* BSD projects that originated on x86, and also older than its direct ancestor, 386BSD.

When I wrote that FreeBSD was the oldest of the modern living BSD family, we got angry comments and emails that NetBSD was older. It is, by 6 months.

Same year, different month.

Apparently, this really matters to some people.

If 6 months is our base unit of time here:

Well, then, Linux is three times older than NetBSD (one year and eight months), and it as much older than 386BSD as NetBSD is older than FreeBSD.

[Henry Wertz 1]

It's good

I'm a Linux user myself but have a friend who is way into NetBSD,. Indeed it's true. the BSDs have weak support for newer GPUs, Mesa3D, etc, but would be fantastic for a server.

[Manveru]

Give me Docker

Give me Docker on BSD and I'll go back. And no, jails don't do the job as no one publishes scripts for nailse, only Dockerfiles.

[karlkarl]

Re: Give me Docker

Docker is basically "Linux containers on Linux or run Linux on non-Linux platforms using a VM". You can do that on BSD just like any non-Linux platform.

Windows - Hyper-V backed WSL

macOS - Xhyve (fork of Bhyve)

FreeBSD - Bhyve

OpenBSD - VMM

That said, I find FreeBSD's Jails superior to Linux containers. Much more consistent and clean. You should give them a try.

[Liam Proven]

Re: Give me Docker

> Docker is basically "Linux containers on Linux or run Linux on non-Linux platforms using a VM". You can do that on BSD just like any non-Linux platform.

Sure, we know that. You're missing the point though -- although I think there is a bigger overarching point that you do make successfully.

Docker is a layer in a stack now. It's not just a tool any more.

I recently wrote about Virter:

https://www.theregister.com/2024/09/20/virter_simpler_test_vms/

Its creators say it's "docker for VMs" with the point that it's both got a Docker-like syntax and also composition of VM images that works like composing Docker templates.

Lots of people are using Docker tools and Docker commands to create, develop, test, and deploy server stacks _without actually having any Docker itself anywhere in the whole stack_.

Docker is a standard for images, it's a standard for repositories holding them, it's a standard for commands and scripts to pull those images, combine them, and instantiate them, and it's also, almost entirely separately, a standard for deploying, running, and managing them.

All without using Docker itself. Docker itself as a daemon-based container runtime is a bit outmoded and old fashioned.

You can use Podman to develop them, containerd or something to run and test them, CRIO to host them, all without ever having Docker itself anywhere.

Whether {some other containerisation tool} is better or worse is irrelevant, I'm afraid. It's not really about the strengths of the original implementation any more. Now it's the standard format, and nobody cares if your alternative standard is better or worse.

https://xkcd.com/927/

Now another and totally different argument would be: Should FreeBSD adopt Docker syntax for its jail-management commands? Yes, this would make them more familiar and accessible for new migrants from Linux, but OTOH, unless FreeBSD *also* implemented template-based Jail image handling, and a compatible system of repositories, then there's no point -- and I do not see that happening.

[karlkarl]

Re: Give me Docker

I guess a more succinct statement would have been:

If you specifically want Linux. You can only use Linux (or VM).

Docker *is* Linux.

Its like complaining that Linux isn't Windows. Likewise FreeBSD will *never* be Docker/Linux.

[Liam Proven]

Re: Give me Docker

> Docker *is* Linux.

Not so.

Docker runs natively on Windows and you can use Docker commands to run Windows containers on Windows server using Docker.

https://learn.microsoft.com/en-us/virtualization/windowscontainers/quick-start/run-your-first-container

[Anonymous Coward]

Re: Give me Docker

"Docker runs natively on Windows and you can use Docker commands to run Windows containers on Windows server using Docker."

To be accurate/pedantic, Docker makes use of Linux kernel features (namespaces and cgroups) and so Docker can be run "natively" on Windows as Windows (WSL) is *emulating* (in some fashion) those Linux kernel features (i.e. Windows is pretending to be Linux).

As Windows is emulating Linux features I think it is debatable whether that means Docker is running "natively" on Windows...

NOTE: I'm referring to "classic" Docker containers rather than "Docker Windows containers" - I've never looked into what exactly Windows containers are. I assume karkkarl was likewise referring to Docker containers in the same fashion.

[halfstackdev]

BSD - Dangerous and Unsafe !

The OP must be mistaken. It’s simply not possible for BSD to have significant uptimes

BSD is doesn’t use the latest memory safe language technology

Dangerous and Unsafe !

Even the kernel code in BSD doesn’t appear to use an npm like package manager to automatically pull in the hundreds of dependencies that must be needed to write even a basic for loop

Dangerous and Unsafe !

The guys writing and maintaining all this unsafe code don’t even use the the latest AI tools to generate half the code … and they are probably not even using an electron powered graphical code editor provided by big tech either. They are probably using vi - without so much as syntax highlighting.

Dangerous and Unsafe !

By rights, BSD must be unsafe and highly unstable. Just booting it up would be enough to catch covid from the experience, let alone experience any uptime at all

Don’t go near BSD unless you are wearing at least 3 layers of government approved masks

Much better to wait a few more weeks until a better operating system is delivered - one written from scratch in a proper memory safe language

[Doctor Syntax]

Re: BSD - Dangerous and Unsafe !

A downvote? Must be from someone who didn't notice the Whoosh sound.

Nice one!

[Anonymous Coward]

Re: BSD - Dangerous and Unsafe !

"They are probably using vi - without so much as syntax highlighting."

Who do these BSD fuckers think they are? They're not using the Rust ports of libsystemd in the packages that must be used to commit their source code to github. Dangerous and Unsafe !

[bombastic bob]

Re: BSD - Dangerous and Unsafe !

Don't tell anyone but I use pluma on a GUI screen with the syntax highlighter plugin and convert hard tabs to spaces and set tab width to TWO. And I indent using "Allman" style!

But before I submit contributed code I convert it to the "kernel normal format" standard using the built-in 'indent' utility

indent infile outfile -nce -di8 -i8 -lp

(see icon - dodging tomatoes and other flying objects from the Ent-like BSD guru devs) (but because of them it is a stable OS)

[Paul Floyd]

I've been using FreeBSD as my main OS at home for FOSS development for the past 4 or 5 years.

No real issues (unlike Fedora which has given me countless issues with either kernel panics at boot or borked Nvidia drivers).

[Anonymous Coward]

FreeBSD is meant to be stable. Fedora is Red Hat/IBM's distro for unpaid guinea pigs/beta testers/tech previewers.

[Anonymous Coward]

Who thought of it first?

Quote: "Clients are often influenced by hype."

From Eric Laithwaite and Meredith Thring (How to Invent), the hype cycle - spoken by third parties - goes like this:

(1) It will never work!

(2) It might work.....but it will never be any use to anyone!

(3) I thought of it first!

[ThoughtCrime]

Btw, Linux is NOT a type of Unix. It's just intended to look like one.

[Liam Proven]

> Linux is NOT a type of Unix

Wrong.

I covered this at length here:

https://www.theregister.com/2023/01/17/unix_is_dead/

[ThoughtCrime]

The mere fact that a system has nine years of uptime is hardly significant. I had a Linux system that had been up eight years last time i could see it. It was owned by a non-profit, that I don't work for anymore, and they have since abandoned the domain--it may well still be up. Of course, if it is, it's 11 years behind on security upgrades.

[naive]

Linux and BSD offers everyone a great choice for creating solutions

Linux and BSD make up a perfect couple for creating solutions.

Linux is mainstream, takes less specialized knowledge to maintain. It also runs most apps like databases out of the box.

I use both, NetBSD for dedicated appliance like tasks where security is essential. Anyone doubting this should check the CVE databases of MITRE.

It is still fun to create a VM using 256MB memory and 16GB to build a NetBSD based appliance and watch windows people faint.

Linux is with google support easier to maintain for casual Unix specialists compared to NetBSD.

Anyone who got tired of chasing ones tail with trying to find the endpoint of Linux script generated configuration files will feel like being in heaven when seeing the elegant simplicity of NetBSD.

If NetBSD is Unix, then Linux can not be called Unix due to exponential bloat and complexity.

[Tridac]

Have been running FreeBSD for years now, both on X86 and Sparc. I put it in the same class as Solaris, in terms of functionality and reliability, with uptimes of years. ZFS an install option. Very professional and makes Linux, with it's systemd trainwreck and other bloatware, look like amateur hour. Also run it on a public ntp server, with current uptime of over three years, though the systems are all on a 4 hour backup ups. Can get a basic setup done in around 20 minutes, with a handful of package installs to get a desktop. It just works, and the internals handbooks are excellent. .