647 karma · joined May 20, 2020
Motif did have a reputation for being a total drag to develop with, though. It's based on Xt. So is Athena, so if you've ever written an Xaw app it's pretty similar.
Sun used a lot of open parts, but they had absolute control over the platform. Everything in your solution came from Sun or a Sun partner. Fujitsu doing weird stuff with Japanese mainframes was an interesting fact but irrelevant to 99% of Sun's user base.
Intel/AMD combined with EFI or IBM-compatible BIOS? You can get that from anybody. An HP server is basically interchangeable with a Dell.
Sun was proprietary in the same way Apple is.
The system is broken. No one with the power to fix it has any incentive to do so. Might as well get what you can.
Normally I'm not a huge fan of privatization but the way it's done here works great. The fees are set by the state and the agency gets a percentage, so if an area is underserved someone just opens another one.
FreeBSD has a Linux compatibility feature that lets you run native Linux binaries. I've never used it so I can't say how good it is, though - all the stuff I use runs fine natively.
The major BSDs have decent package management and sizeable repositories, with the option to build software (and customize compile-time options) using the ports or pkgsrc systems. You can also rebuild and customize the kernel and base system (aka "make world") but that's strictly optional these days.
I seem to remember there was some GNOME stuff that had a hard systemd dependency and wouldn't run on the BSDs. That was a while back though and I don't run GNOME so I don't know whatever happened there or what the status is.
These things are walled gardens. You never see the operating system. You can only change their behavior using the vendor's software. They generally run a single program (that you write using the vendor's software) on a fixed scan cycle. They read the inputs, run your program, write the outputs, then repeat.
While you're giving up the nearly infinite possibilities that an SBC gives you, the benefits more than make up for the lack of flexibility. They run (and have parts and support available) for decades. Modules are easy to diagnose and replace. An electrician who isn't a programmer can follow ladder logic and troubleshoot problems. Integrators can quickly come up to speed and understand your code.
There's a reason companies will pay tens or even hundreds of thousands of dollars for these things.
If that's an old GE 90-30 (a common FANUC system), it's time to replace it. You're currently in that period when the CPU has reached end of life but the modules are still supported and the vendor has an easy upgrade path. Emerson owns the brand now, and can sell you a new unit that'll run your old program with minimal changes. You can call them and get a list of integrators in your area. It'll be pricey, but you won't need to do it again for another quarter century.
But I don't see anything wrong with OpenBSD saying they focus on security when it's well documented that they do, in fact, focus heavily on security.
One of the two professors (Dr. Sussman) that give the lectures in this series is a co-creator of Scheme.
I will defend my "heaviness" argument, though. Sure, you can run OpenBSD on large hardware, but it's not going to be able to take advantage of it like FreeBSD can. Which makes sense if you think about it - FreeBSD optimizes for heavy workloads. Conversely, if you set up minimal installs, OpenBSD will be smaller. Again, that makes sense, since OpenBSD focuses on security over features (plus the only truly secure code is the code that doesn't exist). There's a lot of overlap in the middle, of course.
I wouldn't use OpenBSD for a NAS, and I wouldn't use FreeBSD for a diskless firewall. Not because they can't do those things - they just each have their strengths and weaknesses.
NetBSD is small and simple. It's a lot like an old-school UNIX. It makes a decent platform for small services. I run bind and dhcpd on a NetBSD machine. The source code is very pleasant to read. It uses the pkgsrc software repository. It's my preferred platform for writing POSIX code.
OpenBSD still carries much of the general feel of NetBSD and can fill a similar niche on a network, but the security focus stands out in their documentation, subprojects (OpenSSH, LibreSSL, OpenNTPD, etc.), APIs (see pledge(8)), and policies. It makes for a great firewall. I'd say it also requires the most know-how.
All of them have excellent documentation (especially compared to Linux distros) and the base system is developed alongside the kernel, giving you a very consistent experience compared to Linux distros where everything is developed in isolation. If you write C, it's worth keeping a BSD system around just for the manpages and to make sure you're not letting Linuxisms creep into your codebase.
In the US there's usually a good variety of food from all different cultures available. When I spent two months in Spain, I got really, really tired of the same three seasonings the Spanish put on everything. I craved Mexican food like crazy the whole time.
Spanish food is great, don't get me wrong - I wish we had it here in the sticks where I live - but I'm used to a bit more variety.
I haven't checked to see how that went, but it sounded like the perfect test case for hydrogen's viability.
(I use that VM as my primary public nameserver now and I don't really need a web front end for git so I'll be keeping my current setup. But if it had been available back then, I'd probably have gone for it.)
Military contractors do well when the military has widespread support from the voters. Congresscritters will happily approve tax dollars going to the military industrial complex when their constituents view the US as the global protector of democracy. Wars like this one that aren't popular and make us look like thugs open the floor up to anti-military candidates. So yeah, the companies building missiles do well while the war is on, but the people like me who automate military fuel farms see budget cuts and projects cancelled.
Text inside a computer doesn't need any of that just to signal a newline. UNIX chose to use a single line feed character as a line separator because there was no good reason to use two. MacOS chose a single carriage return for similar reasons. Anything going out to a printer or teletype would run through a device driver that would turn the newline character into whatever the device expects.
Windows copied DOS which copied CP/M which was a very basic program loader for 8-bit machines and didn't really have "drivers" like we think of them today. I'm guessing here, but I imagine they chose the teletype combo because that's what most serial printers understood and printing was a major use case for those machines. That was probably the right choice for CP/M, but I can't imagine Microsoft would choose it if they were developing Windows from scratch today.