The Bible tells us how to pick godly leaders. It also gives many examples of those doing right and wrong. For both, leaders exist today with similar worldviews. So, it's directly applicable.
Thomas Jefferson took inspiration for our system from Jethro's advice to Moses:
Which character traits in the baove passages do you think lead to good leaders? Which do you reject as wicked? I think, and have seen, that they all lead to good outcomes.
You and I commit sins, too. Should everything we've ever said be disregarded?
If you are sharing opinions, you can't possibly believe that. If you expect people to listen to and weigh your comments, we should consider his as well. Especially since they were part of building a great, adaptable system that we are benefiting from now.
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.
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.
Ok - it sounds like you’re right, but I think despite your clarification I remain confused. Isn’t the linked post all about how those two things always have a mingling at the boundary? Like, suppose I want to develop and distribute a c++ user-space application in a cross platform way. I want to manage all my dependencies at the language level, and then there’s some collection of system libraries that I may or may not decide to rely on. How do I manage and communicate that surface area in a cross platform and scalable way? And what does this feel like for a developer - do you just run tests for every supported platform in a separate docker container?
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.
> you should prefer copyleft licenses over non-copyleft licenses,
For most, but not all, software. Stallman did famously argue for libvorbis, which you may know as the ogg codec used mostly by games and spotify, to be licensed under BSD instead of the (L)GPL.
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.
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.
Except when it doesn't. I can't upgrade my Intel graphics drivers to any newer version than what came with the laptop or else my laptop will silently die while asleep. Internet is full of similar reports from other laptop and graphics manufacturers and none have any solutions that work. The only thing that reliably worked is to restore the original driver version. Doesn't matter if I use the WHQL version(s) or something else.
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).
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.
No, we wouldn't. Linux climbed its way up to overtake proprietary UNIX despite being less capable, which it very much was at the time.
Linux came around at the right time when the Internet was going public and regular people had access to hardware that could run a decent UNIX. People latched onto it because it was free and an interesting project. The free BSDs were just late enough to the party that they missed out on the momentum.
All the proprietary UNIX vendors (other than SCO) relied on expensive proprietary hardware sales. Intel ate their lunch while they were too busy stabbing each other in the back to notice. Linux killed SCO because SCO was, quite frankly, overpriced crap.
None of this had anything to do with the license, other that the fact you could use it for free. It was all about hardware availability, the rise of the Internet, the wave of new IT people who had experienced Linux at home, and the fact that Linux on Intel was good enough to replace those pricy proprietary machines.
Now, you wanna talk Apple, there's where your code "theft" kicks in. But that's a whole different thing.
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.
reply