Your argument is similar to parents who say that kids should always finish their food because people are starving in China. One has little to do with the other. I'm betting there's a named logical fallacy here but I can't identify it.
I think the answer is pretty clear. Put a flag pole or antenna mast up next to your house, install a good outdoor WiFi AP on top of it, connect it to your DSL service (however terrible it may be), and shut off encryption so your neighbors can connect to and use it at will. Get together with other techies in your town, and convince them to do the same. Suddenly, a good number of those poor rural people are connected to the internet, at a price they can afford.
It's clear the economics aren't there to make a business out of it, and you apparently don't have the chops for it, anyhow, so setting up a few open APs around town will probably provide the most benefit, with the least cost and effort on your part.
Right now there are only three or four architectures that delivers some punch, x86, ARM, Sparc and Itanium. But the last is only alive due to HP and Sparc is kept alive by Oracle so far.
Among those you missed are Power / PowerPC and MIPS.
MIPS is very-much alive, thanks to China. They're actively developing home-grown MIPS CPUs, and paying license fees to MIPS as well. MIPS CPUs have always had higher DMIPS/MHz than ARM CPUs, and generally compete with PowerPC in the embedded space for anything needing a good bit of performance.
Cheap MIPS chips in China mean lots of inexpensive products are coming out with MIPS CPUs in them, such as the Alpha 400 and the Novo7
POWER will be around for a good long time... IBM isn't willing to let their own platform and cash-cow go away, and they've sunk enough money into it to keep it highly competitive. PowerPC will likely be around a good long time as well... Freescale has quite a focus on their PowerPC chips, and their performance is damn respectable.
SPARC has a bigger customer base than Oracle. Hitachi will probably keep making them no matter what. They've made supercomputers out of them, and they can scale down to embedded applications quite easily.
Itanium is an interesting case... Everybody but HP who jumped onto Intel's 64-bit CPU has died a painful death (see: SGI). Their proprietary systems all require Itanium CPUs, with no sign of HP-UX, Tru64, OpenVMS, etc., being ported to any other architecture. This even though Intel deperately wants to kill off the architecture. HP has killed off all their proprietary CPU lines, and ported their software to Itantium with immense effort, so I don't see where they can go from here. ARM sure doesn't have the horsepower for high-end servers, and switching to x64 would eat their proprietary hardware margins, and probably make them a joke... SPARC and POWER seem like the only possible options, sort of resurrecting DEC's Alpha CPUs. It would be incredibly ironic.
They want to build a fully BSD-licensed OS from the ground up, with zero dependence on GPL-licensed stuff.
Not really true. Everyone was pretty comfortable living along-side GPLv2-licensed software for many, many years. But NOT the new GPLv3. Organizations all over the place are running away, screaming, from anything using that extra-restrictive and incompatible license. The FSF, developing the GPLv3 license, has done more to promote BSD/MITX licensed software than anyone else could have ever hoped to.
Some companies just keep their older, GPLv2 licensed software as long as they can, but in compilers in particular, age and lack of development is a liability, so they eventually have to go out and look for more liberally licensed projects that will make a reasonable replacement. Hence LLVM has seen a flood of development effort.
Secondly, with the change from gcc-2.x to gcc-3.x and now 4.x, compile times have climbed significantly, in favor of optimization. Even if you turn off all the options you can, you're talking about a substantially longer build time. Not an issue for your final compile for public consumption, but during development, where folks want to quickly compile an test, it's a real nuisance, which numerous develops have been complaining about.
Apple, FreeBSD and many others went for LLVM. OpenBSD went for PCC instead.
At some point, the only solution to "bad people" is killing them. Assad has shown a willingness to mass-murder his own people in order to retain his grip on power in the region, and has shown unwilling to comply with any negotiated agreements.
What magical solution do you have which turns bad people good, and stops the killing, without just plain killing off those doing the killing? Or do you think we should just let them go on killing off the protesters, until there are no protesters left, and no more need for killing?
The extreme pasifist approach doesn't easement of Hitlet cemented his power in Germany, and led to WWII nd 16 million dead jews. I bet they wish they had a few weapons back then.
Your particular pascifist mindset, held by the UN, just so happens to have caused thousands of deaths in the Srebrenica massacre among others... Trying too hard to solve your problems without weapons just results in your own death, as the other side isn't quite so "enlightened" and decides it's easier just to kill you first.
I would be immensely interested in high-speed last mile because:
Two customers of the same ISP could transfer files at ridiculous speeds. Bittorrent and other P2P services would automatically take advantage of this, upon seeing one peer with insane bandwidth. The technically inclined would make good use of this, storing backups off-site once ample last-mile bandwidth is there.
Edge-network caching services like Akami would now mean many popular websites will be super-fast, not just slightly lower latency...
Payment card companies can only push around the little guys. If Paypay is anything but incompetent, they have lawyers OBSESSING over those PCI-DSS requirements, and ensuring they meet them TO THE LETTER, with the minimum of effort. "Compensating controls" appear in the regs an awful lot, so you have a blank check to make-up your own pretend security methods. I know I worked for companies who did the same.
Laptop style keys, but nice and BIG and lined-up properly. No crazy laptop crap like moving the PGUP/Dn keys around, and requiring the use of a Fn key.
Yes, velomobiles suck... until they're motorized. Then they can get higher speeds and longer distances than EVs, at much lower prices. And no, they don't have to be lacking in cargo space... they currently ARE because the current crop is designed for human-powered racing, not general purpose use. There's no reason you can't have a 4-seater that goes 70MPH for 300+ miles, at a fraction the cost of a Nissan Leaf or Tesla.
And whatever you happen to think about that, doesn't matter. Don't like it? Too bad! Cars ARE GETTING LIGHTER, and will continue to do so. Electric Velomobiles are the logical extreme of consumer cars, just as motorized bicycles are the logical extreme of motorcycles. Consumer products will end up somewhere in-between, as gas prices go up, and battery tech remains expensive. Lowering the weight of vehichles is the quickest, easiest, and cheapest fix.
Many current automobiles would have been unthinkable in the 60s, yet they're on the roads, today. If gas prices shot through the roof, due to natural disaster or war, I'd be the first one out in my garage welding two mountain-bikes together, fabricating a fiberglass frame, and hooking it up to a starter motor and car batteries, or a lawn-mower/dirt-bike engine, rather than be unable to reasonably travel.
You don't have to go buy a velomobile, but you should get ready for a future where cars look more and more like them, due to physical realities and economics of expensive oil.
Due to "A Christmas Story" being rather inoffensive, it is played during the holidays with almost as much frequency as "It's a Wonderful Life" once was... Ovaltine decoder rings played a major role in the story, and more people are likely familar with them from the movie, than from first hand experience. And I explect a large percentage of/.ers have seen the film at least once.
You don't need to go nuts to get a home that'll survive massive destruction.
Wood-framed homes are plenty strong to survive massive destruction. The failures happen where the various frame pieces join together, hence the Hurriquake nail designed just for this purpose: https://en.wikipedia.org/wiki/HurriQuake
Secondly, I've seen the aftermath, and heard from residents, and you get a pretty clear map of what works and what doesn't... The houses destroyed are the ones that didn't have steel shutters... all the the surviving houses have steel shutters on them. Those big pieces of plywood you see people attaching just aren't nearly strong enough (without extra framing), and your home is long gone the instance the envelope is compromised.
Build your home with hurriquake nails, and have steel shutters installed, and your home will handle immense forces, without needing massive design compromises that make the resale value about zero.
I live in Las Vegas. Nothing is within 265 miles of here:
So go buy a Chevy Volt and be quiet while the adults are talking. I know, it's horrible that not all cars are made to fit YOU personally, but it happens.
RedHat built their company on making Linux expensive through support contracts, though only 1/10th as expensive as purely proprietary software alternatives... With "supported" linux, there's room for both saving the company big, big money, while still spending enough that there's room for slightly smaller kickbacks to continue flowing.
If RedHat could push into the corporate firewall space (using PF, NOT IPTABLES), at the expense of current "hardware" firewall vendors in the corporate world, I'd be eternally grateful, and would happily pay the RH tax, never mentioning unsupported alternatives.
mksh is much smaller than BASH while having almost all the bash features, and being better in several cases... The big one is commands too long to fit on a single line; bash wraps to two lines, and goes utterly ape-shit when you start editing that multi-line command. Mksh, meanwhile, maintains a single-line, and never has such problems.
No, I'd generally recomend FreeBSD, once you're past the whole not being able to comprehend Unix system complexity, and other bits of the process. I was only pointing out the positives, since that's what the GP asked for.
The downsides include fewer ports, that are less customizable and often out of date, much poorer hardware support, worse performance, etc. It still has the whole "simplicity and elegance" thing in the base system, but plenty of drawbacks once you get past that.
Still great for a firewall/router and other minimal systems, but even I avoid it.
My recomendation for FreeBSD (or Linux) users is to install mksh and make it the default shell for everyone... Smaller
Actually I'm against stuff that is poorly architected in the first place. "Change" that doesn't improve anything, or causes as many problems as it fixes, is usually called "waste", and indeed that's the situation far too often on Linux...
Linux ACPI s3/suspend has worked on most of the system I've run across for several years now, including the system I'm typing on, where I use it extensively. There's bugs, which don't get the priority they should, but in any case, you should expect OpenBSD will have to labor for another decade just to reach parity with the Linux ACPI support of TODAY... Not an exciting prospect.
Missing suspend/resume was one of several major reasons I switched from several years of OpenBSD usage, to FreeBSD, and then several more years later, from FreeBSD to Linux, though I'm really not sure if I gained much in that last step...
Re:OBSD firewalls vs others - what's the diff?
on
OpenBSD 5.2 Released
·
· Score: 2
Aren't Juniper's OS BSD based?
Yes, Juniper runs a FreeBSD kernel, but that's about the only similarity. You certainly don't have a full-fledged computer, or a working userland you can access. You get the kernel booting-up their proprietary CLI interface, with their own configuration and command syntax. In fact Cisco's IOS was based on BSD as well, back in the day, but it's diverged substantially at this point, as Juniper's OS probably will if they survive for as many decades as Cisco has.
All BSDs, from what I understand, use PF, and so even if an OS uses something like FreeBSD or NetBSD instead of OpenBSD as its base, whatever it used for the IP filtering would be based on PF, wouldn't it? Or are there IPTables versions on BSD as well?
The FreeBSD firewall used-to be IPFW, and I assume that's still more-or-less the default option. You can see IPTABLES is there, as is PF.
PF is an option on FreeBSD, but it tends to be either missing a few features, or otherwise just lagging behind what's available on OpenBSD, where it is developed.
Also, how is OpenBSD better than other FreeBSD based distros,
Honestly, I don't care... With OpenBSD versus Cisco ASAs / Netscreens, or Linux firewalls, or low-end ARM-based "routers", there was a huge gap between the options that I tried to explain. But comparing OpenBSD vs FreeBSD, you're really splitting hairs. And in the end, it doesn't matter, because the corporate world will continue to insist on using expensive trash like ASAs which has been severely hobbled to fit Cisco's traditional model. Some day I'm sure I'll see it come crashing down, like every other industry that lived on arbitrary restrictions. I'd be perfectly happy using PF (or even the ancient IPF) on FreeBSD or OpenBSD or even PF on Linux if it ever gets fully (sup-)ported, to avoid more hours on proprietary crippled hardware devices. But if given the choice between an ASA and a Linux system running IPTables, I'd struggle with it, and probably shoot myself at the depressing prospect of working with either one for serious work...
"Just two weeks after it challenged the public to come up with a better technological way to stop incessant robocalling, the Federal Trade Commission pulled the plug on five mass calling companies it said were allegedly responsible for millions of illegal pre-recorded calls from 'Rachel' and others from 'Cardholder Services.'
I don't think the timing is a coincidence... I think a few months ago, a high-ranking FTC official was trying to figure out how to track and take down these companies, and took his work home with him. Having forgot to lock his home office's door, his 5 year-old daughter walked in, caught a glimpse of the topic, got a quick explanation, and recounted some playground incident that was vaguely similar that she figured out how to handle, and bluntly asked her daddy why he didn't just do something similar... which he and everyone else at the FTC had never thought-of, and which is now proving incredibly successful in practice.
Instead of a website, maybe they need a souped-up magic 8-ball on their desks?
Think about all the complexity of GRUB. Think about all the issues that the initrd causes. Think about the loading and unloading of kernel modules, whether for different hardware support or just kernel features (eg. bonding NICs), and issues that arise from switching between kernel versions or whatnot. Think about the often cryptic syntax of modules.conf. Think about the complexity of SysV and looking through those hundreds of little scripts to find the problem you're looking for. Think of chkconfig and "services".
Now imagine it all going away.
That's right... OpenBSD doesn't use or need any of it. The whole system is super-simple and extremely clean. For those who've used FreeBSD and been impressed with how much nicer and simpler it is than Linux, you should know FreeBSD is only half-way to being as simple as OpenBSD.
I used-to LOVE the simplicity of it. Back when removable hard drives were as close to mobile computing as most of us got, I'd have my OpenBSD system all setup, and I could just up and boot it from ANY SYSTEM, with no reconfiguration, and no problems. Windows users were absolutely astonished, and Linux users were aghast at the lack of boot-time kernel panic or other system hangs.
It's absolutely the best way to start learning Unix... With init/startup scripts a child can understand, and configure, and a clean, straight-forward user-land, rather than one cluttered with 20 different shells like any Linux distro.
And I've just started scratching the surface... Think of an OS where the developers have kept the same sound systems for decades, and have kept the same file system for decades, with just a few rare updates that kept it among the all-around best-performing. Think of an OS where the scheduler doesn't keep changing and getting more tweaks, but works the same from version to version for many years in-between. Think of an OS that you can just install and really count on it being as stable as a rock, and incredibly bug-free foundation. Imagine not having to keep up with the constant changes made to better suit some random person's idea of what minor feature is worth completely upending decades of good design, legacy and stability (eg: KMS, Wayland, etc.). Think of an OS that doesn't have to go through contortions and change after change to its design to suit the design constraints of the latest mainframe IBM is developing.
Think of an OS that is simple, elegant, solid, and just plain works.
Slashdot Mirror
Couldn't find it? Here ya go:
http://yourlogicalfallacyis.com/appeal-to-emotion
I think the answer is pretty clear. Put a flag pole or antenna mast up next to your house, install a good outdoor WiFi AP on top of it, connect it to your DSL service (however terrible it may be), and shut off encryption so your neighbors can connect to and use it at will. Get together with other techies in your town, and convince them to do the same. Suddenly, a good number of those poor rural people are connected to the internet, at a price they can afford.
It's clear the economics aren't there to make a business out of it, and you apparently don't have the chops for it, anyhow, so setting up a few open APs around town will probably provide the most benefit, with the least cost and effort on your part.
Among those you missed are Power / PowerPC and
MIPS.
MIPS is very-much alive, thanks to China. They're actively developing home-grown MIPS CPUs, and paying license fees to MIPS as well. MIPS CPUs have always had higher DMIPS/MHz than ARM CPUs, and generally compete with PowerPC in the embedded space for anything needing a good bit of performance.
Cheap MIPS chips in China mean lots of inexpensive products are coming out with MIPS CPUs in them, such as the Alpha 400 and the Novo7
http://www.geeks.com/details.asp?invtid=ALPHA-400
http://www.mobile.slashdot.org/story/11/12/06/0359235/sub-100-android-40-tablet-coming-soon
POWER will be around for a good long time... IBM isn't willing to let their own platform and cash-cow go away, and they've sunk enough money into it to keep it highly competitive. PowerPC will likely be around a good long time as well... Freescale has quite a focus on their PowerPC chips, and their performance is damn respectable.
SPARC has a bigger customer base than Oracle. Hitachi will probably keep making them no matter what. They've made supercomputers out of them, and they can scale down to embedded applications quite easily.
Itanium is an interesting case... Everybody but HP who jumped onto Intel's 64-bit CPU has died a painful death (see: SGI). Their proprietary systems all require Itanium CPUs, with no sign of HP-UX, Tru64, OpenVMS, etc., being ported to any other architecture. This even though Intel deperately wants to kill off the architecture. HP has killed off all their proprietary CPU lines, and ported their software to Itantium with immense effort, so I don't see where they can go from here. ARM sure doesn't have the horsepower for high-end servers, and switching to x64 would eat their proprietary hardware margins, and probably make them a joke... SPARC and POWER seem like the only possible options, sort of resurrecting DEC's Alpha CPUs. It would be incredibly ironic.
Not really true. Everyone was pretty comfortable living along-side GPLv2-licensed software for many, many years. But NOT the new GPLv3. Organizations all over the place are running away, screaming, from anything using that extra-restrictive and incompatible license. The FSF, developing the GPLv3 license, has done more to promote BSD/MITX licensed software than anyone else could have ever hoped to.
Some companies just keep their older, GPLv2 licensed software as long as they can, but in compilers in particular, age and lack of development is a liability, so they eventually have to go out and look for more liberally licensed projects that will make a reasonable replacement. Hence LLVM has seen a flood of development effort.
Secondly, with the change from gcc-2.x to gcc-3.x and now 4.x, compile times have climbed significantly, in favor of optimization. Even if you turn off all the options you can, you're talking about a substantially longer build time. Not an issue for your final compile for public consumption, but during development, where folks want to quickly compile an test, it's a real nuisance, which numerous develops have been complaining about.
Apple, FreeBSD and many others went for LLVM. OpenBSD went for PCC instead.
At some point, the only solution to "bad people" is killing them. Assad has shown a willingness to mass-murder his own people in order to retain his grip on power in the region, and has shown unwilling to comply with any negotiated agreements.
What magical solution do you have which turns bad people good, and stops the killing, without just plain killing off those doing the killing? Or do you think we should just let them go on killing off the protesters, until there are no protesters left, and no more need for killing?
The extreme pasifist approach doesn't easement of Hitlet cemented his power in Germany, and led to WWII nd 16 million dead jews. I bet they wish they had a few weapons back then.
Your particular pascifist mindset, held by the UN, just so happens to have caused thousands of deaths in the Srebrenica massacre among others... Trying too hard to solve your problems without weapons just results in your own death, as the other side isn't quite so "enlightened" and decides it's easier just to kill you first.
I would be immensely interested in high-speed last mile because:
Two customers of the same ISP could transfer files at ridiculous speeds. Bittorrent and other P2P services would automatically take advantage of this, upon seeing one peer with insane bandwidth. The technically inclined would make good use of this, storing backups off-site once ample last-mile bandwidth is there.
Edge-network caching services like Akami would now mean many popular websites will be super-fast, not just slightly lower latency...
Payment card companies can only push around the little guys. If Paypay is anything but incompetent, they have lawyers OBSESSING over those PCI-DSS requirements, and ensuring they meet them TO THE LETTER, with the minimum of effort. "Compensating controls" appear in the regs an awful lot, so you have a blank check to make-up your own pretend security methods. I know I worked for companies who did the same.
Laptop keyboards don't have-to suck. Go look at http://typematrix.com/
Laptop style keys, but nice and BIG and lined-up properly. No crazy laptop crap like moving the PGUP/Dn keys around, and requiring the use of a Fn key.
The comments here are so terribly uninformed.
Yes, velomobiles suck... until they're motorized. Then they can get higher speeds and longer distances than EVs, at much lower prices. And no, they don't have to be lacking in cargo space... they currently ARE because the current crop is designed for human-powered racing, not general purpose use. There's no reason you can't have a 4-seater that goes 70MPH for 300+ miles, at a fraction the cost of a Nissan Leaf or Tesla.
And whatever you happen to think about that, doesn't matter. Don't like it? Too bad! Cars ARE GETTING LIGHTER, and will continue to do so. Electric Velomobiles are the logical extreme of consumer cars, just as motorized bicycles are the logical extreme of motorcycles. Consumer products will end up somewhere in-between, as gas prices go up, and battery tech remains expensive. Lowering the weight of vehichles is the quickest, easiest, and cheapest fix.
Many current automobiles would have been unthinkable in the 60s, yet they're on the roads, today. If gas prices shot through the roof, due to natural disaster or war, I'd be the first one out in my garage welding two mountain-bikes together, fabricating a fiberglass frame, and hooking it up to a starter motor and car batteries, or a lawn-mower/dirt-bike engine, rather than be unable to reasonably travel.
You don't have to go buy a velomobile, but you should get ready for a future where cars look more and more like them, due to physical realities and economics of expensive oil.
So when is GM being taken to court for the same type of fraud?
https://en.wikipedia.org/wiki/Chevrolet_Equinox#Debate_about_EPA_fuel_economy_ratings
I'd be happy to pay more for extra arm and leg room, but not the billionaire tax for first-class fare. Business-class is often not available.
Due to "A Christmas Story" being rather inoffensive, it is played during the holidays with almost as much frequency as "It's a Wonderful Life" once was... Ovaltine decoder rings played a major role in the story, and more people are likely familar with them from the movie, than from first hand experience. And I explect a large percentage of /.ers have seen the film at least once.
You don't need to go nuts to get a home that'll survive massive destruction.
Wood-framed homes are plenty strong to survive massive destruction. The failures happen where the various frame pieces join together, hence the Hurriquake nail designed just for this purpose: https://en.wikipedia.org/wiki/HurriQuake
Secondly, I've seen the aftermath, and heard from residents, and you get a pretty clear map of what works and what doesn't... The houses destroyed are the ones that didn't have steel shutters... all the the surviving houses have steel shutters on them. Those big pieces of plywood you see people attaching just aren't nearly strong enough (without extra framing), and your home is long gone the instance the envelope is compromised.
Build your home with hurriquake nails, and have steel shutters installed, and your home will handle immense forces, without needing massive design compromises that make the resale value about zero.
So go buy a Chevy Volt and be quiet while the adults are talking. I know, it's horrible that not all cars are made to fit YOU personally, but it happens.
In any EV or hybrid car the regular brakes will last an EXTREMELY long time thanks to "dynamic braking", as the motor handles almost all braking.
I don't think I've added any brake fluid to my car in the 20 years it's been around. Sure, it's there, but I wouldn't think to mention it in any car.
And he already mentioned "rotating tires" which is pretty close to mentioning (eventual) tire replacement.
RedHat built their company on making Linux expensive through support contracts, though only 1/10th as expensive as purely proprietary software alternatives... With "supported" linux, there's room for both saving the company big, big money, while still spending enough that there's room for slightly smaller kickbacks to continue flowing.
If RedHat could push into the corporate firewall space (using PF, NOT IPTABLES), at the expense of current "hardware" firewall vendors in the corporate world, I'd be eternally grateful, and would happily pay the RH tax, never mentioning unsupported alternatives.
mksh is much smaller than BASH while having almost all the bash features, and being better in several cases... The big one is commands too long to fit on a single line; bash wraps to two lines, and goes utterly ape-shit when you start editing that multi-line command. Mksh, meanwhile, maintains a single-line, and never has such problems.
No, I'd generally recomend FreeBSD, once you're past the whole not being able to comprehend Unix system complexity, and other bits of the process. I was only pointing out the positives, since that's what the GP asked for.
The downsides include fewer ports, that are less customizable and often out of date, much poorer hardware support, worse performance, etc. It still has the whole "simplicity and elegance" thing in the base system, but plenty of drawbacks once you get past that.
Still great for a firewall/router and other minimal systems, but even I avoid it.
My recomendation for FreeBSD (or Linux) users is to install mksh and make it the default shell for everyone... Smaller
Thanks for the info, I did indeed mis-recall the story, perhaps because S3 was one of the things I switched to FreeBSD for, several years ago.
Actually I'm against stuff that is poorly architected in the first place. "Change" that doesn't improve anything, or causes as many problems as it fixes, is usually called "waste", and indeed that's the situation far too often on Linux...
Ext2 (Write) support was absolutely piss-poor the last time I tried it (a couple years ago), and unsuitable for writing backups to.
In generally, it's all UFS with softupdates, or tar.
Linux ACPI s3/suspend has worked on most of the system I've run across for several years now, including the system I'm typing on, where I use it extensively. There's bugs, which don't get the priority they should, but in any case, you should expect OpenBSD will have to labor for another decade just to reach parity with the Linux ACPI support of TODAY... Not an exciting prospect.
Missing suspend/resume was one of several major reasons I switched from several years of OpenBSD usage, to FreeBSD, and then several more years later, from FreeBSD to Linux, though I'm really not sure if I gained much in that last step...
Yes, Juniper runs a FreeBSD kernel, but that's about the only similarity. You certainly don't have a full-fledged computer, or a working userland you can access. You get the kernel booting-up their proprietary CLI interface, with their own configuration and command syntax. In fact Cisco's IOS was based on BSD as well, back in the day, but it's diverged substantially at this point, as Juniper's OS probably will if they survive for as many decades as Cisco has.
http://www.freebsd.org/doc/handbook/firewalls.html
The FreeBSD firewall used-to be IPFW, and I assume that's still more-or-less the default option. You can see IPTABLES is there, as is PF.
PF is an option on FreeBSD, but it tends to be either missing a few features, or otherwise just lagging behind what's available on OpenBSD, where it is developed.
Honestly, I don't care... With OpenBSD versus Cisco ASAs / Netscreens, or Linux firewalls, or low-end ARM-based "routers", there was a huge gap between the options that I tried to explain. But comparing OpenBSD vs FreeBSD, you're really splitting hairs. And in the end, it doesn't matter, because the corporate world will continue to insist on using expensive trash like ASAs which has been severely hobbled to fit Cisco's traditional model. Some day I'm sure I'll see it come crashing down, like every other industry that lived on arbitrary restrictions. I'd be perfectly happy using PF (or even the ancient IPF) on FreeBSD or OpenBSD or even PF on Linux if it ever gets fully (sup-)ported, to avoid more hours on proprietary crippled hardware devices. But if given the choice between an ASA and a Linux system running IPTables, I'd struggle with it, and probably shoot myself at the depressing prospect of working with either one for serious work...
I don't think the timing is a coincidence... I think a few months ago, a high-ranking FTC official was trying to figure out how to track and take down these companies, and took his work home with him. Having forgot to lock his home office's door, his 5 year-old daughter walked in, caught a glimpse of the topic, got a quick explanation, and recounted some playground incident that was vaguely similar that she figured out how to handle, and bluntly asked her daddy why he didn't just do something similar... which he and everyone else at the FTC had never thought-of, and which is now proving incredibly successful in practice.
Instead of a website, maybe they need a souped-up magic 8-ball on their desks?
Think about all the complexity of GRUB. Think about all the issues that the initrd causes. Think about the loading and unloading of kernel modules, whether for different hardware support or just kernel features (eg. bonding NICs), and issues that arise from switching between kernel versions or whatnot. Think about the often cryptic syntax of modules.conf. Think about the complexity of SysV and looking through those hundreds of little scripts to find the problem you're looking for. Think of chkconfig and "services".
Now imagine it all going away.
That's right... OpenBSD doesn't use or need any of it. The whole system is super-simple and extremely clean. For those who've used FreeBSD and been impressed with how much nicer and simpler it is than Linux, you should know FreeBSD is only half-way to being as simple as OpenBSD.
I used-to LOVE the simplicity of it. Back when removable hard drives were as close to mobile computing as most of us got, I'd have my OpenBSD system all setup, and I could just up and boot it from ANY SYSTEM, with no reconfiguration, and no problems. Windows users were absolutely astonished, and Linux users were aghast at the lack of boot-time kernel panic or other system hangs.
It's absolutely the best way to start learning Unix... With init/startup scripts a child can understand, and configure, and a clean, straight-forward user-land, rather than one cluttered with 20 different shells like any Linux distro.
And I've just started scratching the surface... Think of an OS where the developers have kept the same sound systems for decades, and have kept the same file system for decades, with just a few rare updates that kept it among the all-around best-performing. Think of an OS where the scheduler doesn't keep changing and getting more tweaks, but works the same from version to version for many years in-between. Think of an OS that you can just install and really count on it being as stable as a rock, and incredibly bug-free foundation. Imagine not having to keep up with the constant changes made to better suit some random person's idea of what minor feature is worth completely upending decades of good design, legacy and stability (eg: KMS, Wayland, etc.). Think of an OS that doesn't have to go through contortions and change after change to its design to suit the design constraints of the latest mainframe IBM is developing.
Think of an OS that is simple, elegant, solid, and just plain works.