spauldo

I don't have much to disagree with there, only that any survey answer is the difference between complex things is going to be simplified. I'm thumb typing here and no one's paying me to write a book.

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.

Well it 40 below and I don't give a...

FreeBSD is a heavier, more capable system, suitable for large servers. It's got its own virtualization platform (bhyve), an LXC-ish container system (jails), native ZFS, dtrace, Linux emulation, and a bunch more. It makes for a decent workstation and has pretty decent hardware support.

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.

I had the opposite food experience in the EU, but I'll admit my experience is mostly Spain.

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 seem to remember Iceland was looking hard into hydrogen for their fishing fleets. They have to import Diesel fuel but they've got geothermal running out of their ears.

I haven't checked to see how that went, but it sounded like the perfect test case for hydrogen's viability.

I pay DigitalOcean $6/mo for a VM that started out as just that - a bare repo and ssh. If it was available at the time, I'd probably have paid $10 for the same if I didn't have to set up and administer the thing. I lost interest in administrating web servers in the early Apache 2.0 days so a private "mini-githib" would be tempting.

(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.)

Only certain types of contractors, and likely only in the short term.

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.

The carriage return and linefeed combo are the commands to move to the next line of a teletype. Other commands might (in theory) be used for this purpose on other devices. These are implementation details.

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.

The American suburbs are full of houses with attached garages, so I'm hardly alone in this.

He's got that Venezuelan woman's Nobel too, doesn't he?

Unless you travel a lot and live in hotels for months at a time, like I do. Granted, that's not horribly common but there are still legitimate reasons to want an ICE.

I would. Why wouldn't I? I park my car in an attached garage. If I had an EV or PHEV, I'd walk right past the charger on my way to the door into the house. I don't like standing around at the gas station waiting on the tank to fill. Seems like a no-brainer to me.

I actually wanted a PHEV, since my car is mostly used for local driving but I also drive hundreds of miles for work trips. Unfortunately I couldn't find one I liked.

Whether he believed in it or not, he passed rigorous physical tests for the Navy and NASA. They don't let just any slob be a fighter pilot, much less a test pilot or astronaut. If you don't have good cardiovascular fitness, you can't handle high G-forces or maintain good judgement while sleep deprived (those jets didn't fly themselves while the pilot napped like modern ones do).

Maybe he was just naturally fit. Some people are. But he was undoubtedly fit.

There were effectively no free compilers in the 80s. If you had an expensive UNIX workstation it might come with one, but everyone in the micro world had to pay. Or they wrote in Assembly or a BASIC interpreter.

Granted, some were pretty cheap, at least by the early 90s.

I dunno, given the reputation we Americans have as tourists, it'd be nice to point out good ol' Alex and say, "hey, it could be worse!"

Everybody smoked back then. Besides, until you get older your health is much more affected by your lifestyle than whether or not you smoke.

Most astronauts were chosen from a decent sized pool of military pilots. Pilots are some of the most expensive assets the military has (moreso than the planes they fly) and they have to be physically fit. People wanting to become astronauts are subjected to rigorous physical testing.

No, they're not Olympic athletes but they're considerably more fit than the average American.

They'd lose a whole lot of users if they killed Java edition, since the modded community is so large. They'd quickly find one of the Minecraft clones reaching feature parity. And there's no good reason for it - it's not like Java is a threat anymore.

We already have to trust that none of the people involved in the official images are foreign (or even domestic) intelligence agents, so it's not that different.

I don't recall the Bible saying much about who to vote for, given that democracy wasn't much of a thing in the ancient middle east.

I haven't used Linux as a gateway in years, so I can only compare pf to iptables. The two biggest differences are the way the rules are applied and the logging.

pf rules work a little backwards compared to iptables. A packet traverses the entire ruleset and the last rule to match wins. You can short-circuit this with a "quick" directive. It takes a bit of getting used to coming from iptables.

The logging on pf doesn't integrate with syslog automatically like iptables does. You're expected to set up a logging system for your particular use case. There are several ways to do it, and for production you'd be doing it regardless, but for honelab setups it's an extra thing you need to worry about.

I prefer pf, but I don't recommend it to people new to firewalls.

You're confusing two different things.

For most C and C++ software, you use the system packaging which uses libraries that (usually) have stable ABIs. If your program uses one of those problematic libraries, you might need to recompile your program when you update the library, but most of the time there's no problem.

For your company's custom mission critical application where you need total control of the dependencies, then yes you need to manage it yourself.

That's when you rewrite your codebase in the SPARK dialect of Ada and play innocent when your management questions you about it.

True, there are exceptions. Stallman thought strategically. Having a free-but-non-copyleft licensed reference implementation is necessary if you are trying to wrest dominance from an established but proprietary standard.

But I'm willing to bet that he'd have pushed for GPL if he wasn't trying to topple MP3.

The FSF has written extensively on why (in their opinion) you should prefer copyleft licenses over non-copyleft licenses, but they don't require a license to be copyleft in order to be considered free. It's worth spending a bit of time on their site to understand their point of view. Just be careful not to drink too much of the Kool-Aid or you'll become one of those annoying people who never shut up about the GPL on forums.

It's not the development model at fault here. It's the simple fact that Windows makes up nearly the entire user base for PCs. Companies make sure their hardware works with Windows, but many don't bother with Linux because it's such a tiny percentage of their sales.

Yeah, V8 is the shape of the engine - 8 cylinders in two rows offset at an acute angle (i. e. V-shaped). Likewise a V6 has the same number of cylinders as an inline 6 but performs very differently. There's a handful of different engine shapes - I'm fond of the rotary engines used in early aircraft. Traditionally, the name of an engine was just the year, the manufacturer, and the displacement (like 1965 Ford 352). You often leave off the year and even the manufacturer if it's not required by context.

The Ford 351 is a bit special because there were two different engines made by Ford in the same time period with the same displacement, so they tacked on the city they were manufactured in (Windsor or Cleveland).

Especially since, IIRC, it actually predates C.

A Linux-based system would be identical to a Windows-based system as far as operator experience goes. They interact with HMI software and only see the OS underneath when Windows pops up silly notifications and errors.

Windows owns the industrial space for historical reasons, mostly to do with OPC being Windows-only and software for doing maintenance on field devices originally running on DOS. It quickly became a chicken-and-egg situation - everyone wrote their software for Windows because everyone else wrote their software for Windows. SCO owned a decent chunk of the field before that, but we know how that worked out.

We're seeing some change now that OPC is being phased out. Ignition now has feature parity between Linux and Windows (barring OPC, of course). Windows won't go away any time soon (if ever), but you can now have a fully functioning SCADA system with no Windows at all.

Yeah, I was there too.

The three companies you list are horrible examples. IBM is kind of a UNIX vendor, sort of, but not like Sun or DEC. They sell solutions, and the solutions that use AIX don't overlap with what Linux was capable of in 1998. I'd argue that, given their complete disregard for Tru-64 and pretty much all things DEC, Compaq was never a UNIX vendor - they just inherited a bunch of legacy systems they needed to support. They certainly didn't push for new Tru-64 based systems. Oracle wasn't a UNIX vendor at all and wouldn't become one for quite some time.

BSD sockets are also a bad example. They were the reference implementation, paid for by DARPA. The entire purpose of BSD sockets was to be copied into other operating systems. You'll notice that Linux copied them as well.

IBM and Compaq invested in Linux because they wanted something that ran on their lower-end server hardware and could handle web traffic. Oracle invested in Linux because they wanted to be the backend to all these new websites that were cropping up.

IBM, Oracle, and Compaq didn't give a rat's ass about the operating system code - they wanted the platform. If Linux had never happened and FreeBSD became the new hot thing all the online hackers were talking about, the result would have been exactly the same. They'd have poured money into the projects rather than trying to make their own thing because that's the financially sensible thing to do. The UNIX wars were over, and proprietary software lost.

Meanwhile, the last major UNIX vendor - Sun Microsystems - was giving away its own source code under the CDDL. FreeBSD ended up adopting a lot of it. That's the complete opposite effect from what you're talking about.

Sun got involved in the GNOME project and even deprecated their own CDE desktop in favor of it. Was it because it was GPL? No. It was because they saw that all the new desktop software was coming out of the Linux community, who didn't have access to CDE. Even if GNOME had been BSD licensed they would still have switched to it, because they were still trying to keep the workstation market alive at that point and CDE was quickly becoming irrelevant.

As far as I can see, the only companies interested in taking operating system code were the network appliance vendors and Apple. It only worked for them because they didn't care about compatibility.