That's a fundamentally different approach quite useless for trying to protect against software that doesn't bother to make use of unveil, like pretty much everything on github and any commercial software.

You're conflating OpenBSD with a general-purpose OS. It's an opinionated OS meant for two purposes: a desktop for those who like the way that OpenBSD looks and feels, and a server for managing simple services like mail, static HTTP, and proxies. Someone using OpenBSD to build a public server should follow the handbook, which recommends the use of certain pre-built packages and ports. The OpenBSD ports team has put in a lot of effort to add privilege separation to these packages and ports. The main reason why OpenBSD developers adopted pledge and unveil was for the ease by which these tools can be incorporated into existing free software.

If OpenBSD doesn't have well documented support for a given service or package, you really shouldn't use it if you are concerned about its security footprint. If you're planning on running a public server hosting random software you download off of github, and you lack the ability to modify this software to follow the rules in the handbook, then OpenBSD isn't the OS for you. That's fine. There is a reason why there are many operating systems and many flavors of Linux. Pick one you like. Either way, configuring a system to be safe requires work. Furthermore, it requires the use of many tools, and not just filesystem lockdown, pledge/unveil, containers, seccomp, etc.

Barring hardware vulnerabilities, process isolation in BSD or Linux is pretty reasonable. Privilege separation and reducing the syscall footprint using pledge, seccomp, capsicum, etc., work with process isolation to provide reasonable defense in depth. This works as long as you can control the software being run, which is generally the case for simple mail, static HTTP, or proxy servers. This happens to be OpenBSD's bread and butter. But, different OSes can do similar things with different forms of configuration. OpenBSD chose pledge and unveil because it required the least developer involvement to port certain utilities to the OS. They didn't choose it so system admins could build custom policies on their own.

I highly doubt that you or any reasonably experienced adversary would have an easy time breaking a properly configured service on OpenBSD with privilege separation and pledge/unveil, nor a properly configured service on Linux with privilege separation and seccomp. At that point, it's Ford vs Chevy, or Mac vs PC. Use what you like.

Yeah... there is some unintentional irony in the name.

I guess that their investors and users thought that they were Case when they were really Armitage.

That's a rather broad brush that you're painting with. In your world, the only reason why people could POSSIBLY dislike Bitcoin is because they have FOMO? That's a rather convenient way to dismiss any viewpoint but your own.

Until PoW devolved to the point that it's actually having a major negative environmental impact, I couldn't care less about Bitcoin. It was yet another thing to separate fools from their money, but that didn't impact me. I can educate family and friends about the dangers of Ponzi schemes and the Greater Fool Principle. But, PoW does impact me. It impacts everyone. It's a lazy solution to a problem that wouldn't exist except in the very arbitrary world created by cryptocurrencies.

The worst part is that it isn't going away. Greenwashing attempts fail, because PoW rewards those who find the cheapest and dirtiest way of getting power. So, for every "green" mining rig operation we hear about, ten more operations open near coal plants.

The only reason why I'd love to see the value of BTC hit $0 is so that miners move on to some other get rich quick scheme. It has nothing to do with punishing HODLers.

I architected a form of wireless unlocking technology using BLE. This technology required the user to press a button as part of the authorization process. This certainly wasn't the only security feature in the technology meant to prevent this attack and other attacks, but the specifics are unimportant to the crux of this attack. Anyway, this is how the technology was tested and initially built. The button was designed specifically to prevent this relay attack. Unfortunately, the client decided to remove the button during the prototype phase to enable a "cool feature" (unlocking things with the device in the pocket), despite my warnings regarding this attack and others.

You can't always control how technology you build will be used, or how it will be perverted for marketing purposes. Eventually, a developer will be found who will accept a paycheck for breaking security for the sake of features, especially if they are given partial information.

For what it's worth, I still use this particular device. Just with some hardware and firmware modifications to bring back the button. The technology itself is good. With a button, it's safer than a physical key, which can be duplicated by anyone with a smart phone and 3D printer. Hopefully, the publicity of this attack will ensure that this client as well as other manufacturers will consider the full authorization picture. The fix is relatively easy, especially for those using a smart phone as their device: pull it out and press a button to authorize the action.

It's all predicated by fear. These con artists are very good at catching people off-balance. They make it clear that something bad will happen to their loved one if they go to the police. In newer versions of the con, they are warned that even hanging up the phone is enough for them to do whatever it is they are going to do.

This con works by keeping the pressure high and making it clear that the only way out is to do whatever the person on the other line says. If their victim pushes back, they will get the "kidnap" victim to scream followed by harsh words by the "kidnapper". This tends to take the fight out of most. Under such pressure, many people become compliant. My mother probably would have as well, if not for their slip-up.

It's a brutally effective con. There is always an easy "out": go to the bank, get the money, and either wire it or use it to buy gift cards. This works with someone's moral calculus. Money can be replaced. A loved one cannot be replaced. Since they are kept on the line and pressured to leave the house immediately, it's unlikely that they will discover that this is a con until it's too late. After that, victims are often too embarrassed to admit that they were fooled. Even if they do call the FBI or local law enforcement after the fact, these con artists clean up their tracks.

The best that we can do is to educate family and friends about these sorts of calls so that they are prepared when they get one.

She called me at work, frantic, because she was told that I was being held at gunpoint because of my alleged gambling debts. They even had someone sobbing and whispering, claiming to be me. The scammers had managed to compile enough public information to make the extortion attempt seem plausible. Thankfully, my doppelganger used a word, "momma", which I'd never use. That gave her enough suspicion to call me.

I drove to her place, and waited for the scammers to call back. I managed to get her to say enough of the "right" things to get a callback number, which we gave to the sheriff. It was a burner phone number, and it was deactivated by the end of the day. But, it was worth a shot. They did whatever forensics they do, but the trail was pretty cold. These scammers aren't dumb. Virtual or not, there's a hefty prison sentence involved if they are caught.

Thankfully, she was wise enough to be suspicious and to call me the moment things didn't add up. Since then, I've trained my parents and my grandparents on how to spot cons and how to just terminate communication and contact someone they trust the moment something doesn't feel right. If they try to keep you on the phone, pull up SMS, Messenger, etc. Whatever you do, don't keep secrets from loved ones, even if someone has convinced you that you've done something wrong.

It's not perfect -- if it were possible to avoid scams and cons we'd be taught how to do so in school. But, familiarity helps to reduce the likelihood that they will become victims. Every time I hear of a new type of scam or con, I run through it with them.

There is a 10% to 20% performance hit over Linux / FreeBSD. But, the OpenBSD developers have worked hard to tighten this. With each release, it gets faster relative to other distros. The developers have purposefully disabled many features by default that can enhance performance, such as SMP. These can be turned back on if you are willing to accept the risks. For instance, with SMP, there are still potential branch prediction risks (e.g. similar to Spectre / Meltdown). The OpenBSD developers focus on creating a safe and predictable system first, leaving the trade-offs of performance tuning to the user.

Personally, I just buy faster hardware. I can run Linux and *BSD VMs on my OpenBSD desktop via either vmm / vmd (built into OpenBSD since 5.9) or qemu. I prefer the design considerations taken into account by the OpenBSD developers. To me, they seem more mature, cohesive, and complementary than in other OSes. Would Linux or FreeBSD be faster to run as a host? Absolutely. But, I find OpenBSD to be easier to configure and overall, easier to administrate.

Respectfully, you're about a decade out of date with your Systrace reference. It was replaced by pledge and unveil, both of which accomplish many of the same things, but in a way that is easier to configure. SELinux has many features that OpenBSD does not with pledge and unveil, but from a practical standpoint, both pledge and unveil are much easier to use.

I write services that run on Linux, FreeBSD, OpenBSD, NetBSD, seL4, etc. There are frameworks on each that can be used to lock things down. In practice, both pledge and unveil under OpenBSD are quite useful.

I think that any CoC is going to need to be adapted over time. I'll cherry pick a few points based on my perspective. Note that the language in the CoC isn't mine and I'm not about to claim either expertise or agreement with it, other than to say that it largely boils down to "don't be a dick".

Overall, I think that the CoC is meant more for repeat abusers. The penalties are designed to ratchet up over time. So, if you innocently say something that hurts someone else, I don't think they are going to permban you. They would likely reach out to you first, give you a talking-to and possibly a warning, and move on from there. If you are a repeat offender, then they will likely start giving you temporary bans and more severe penalties, depending of course on the severity of the abuse. The CoC is meant to be something that people can point to when behavior is called out as unacceptable. It is the "why" and not the cudgel itself. Can it be abused? Certainly. That's why it is a code that must be judiciously enforced by community maintainers, and not a book of laws.

The "outing" rule is specifically designed to allow others to "out" known offenders. So, for instance, if that guy who makes women (or other men) feel uncomfortable due to aggressive sexual advances is going to attend BSDCon, then it's okay for community members to "out" him by providing information to event coordinators about said person. "Outing" in this context specifically means providing pertinent personal details that can help to protect others. For instance, the alleged actions of a certain hacker named after a toy whistle at certain hacker conventions were "outed" in order to ensure that boys and young men were kept safe. That convention had adopted a similar CoC used to similar effect.

I think the dead names thing really just comes down to not being a dick about someone's gender. If someone used to be known as "Tom" and is now known as "Samantha", it's a dick move to continue to refer to that person as "Tom".

The "hugs" thing is likely an issue of context and was used as an example. I've seen degrading comments made to women on mailing lists when someone indicates an action that they would like to perform to the woman, and then later plays it off as an innocent joke or misunderstanding. The reason why it's uncool is because it degrades her in front of peers. If she calls it out, then she gets labeled as "uptight". By making it part of the CoC, at least in theory, it's possible to get someone else to pull that person aside and demand a public apology.

I think that private conversation should be considered "off the record" in most contexts. When people share private conversations with others -- unless these conversations are abusive -- it is tacky. I think the CoC draws this line specifically to ensure that abuse can be forwarded, but that this doesn't open the flood gates for folks to just make all private conversations public. Sure, private and public statements are contradictory all of the time. That's politics, and any community is going to be full of politics. But, it's dirty pool to out those private communications, unless someone is harassing someone else. I'm pretty sure that is what this clause is about.

The "knowingly making harmful claims about a person" is meant as a check on the outing rule. If Bob is a sexual predator, and I out him for it, then I had better have proof. Otherwise, Bob may in fact be someone I'm just trying to smear, and that would be uncool. Likewise, let's face it, false accusations do occur. Sometimes, retaliatory accusations are made to one's accusers. There needs to be a fair balance between taking accusations at face value and ensuring that malicious parties can be dealt with. I don't think that any CoC can thread this needle, as it is highly context-sensitive, but I think the point here is to point out that this isn't a he said / she said free-for-all.

Again, I'm just an outsider looking in. I've seen similar CoCs adopted by similar communities. I think there is a well reasoned argument behind this CoC, but I will agree that the language needs to be softened without losing meaning or power. Most of that really just comes down to picking language that people don't find as offensive or confusing. Building a fair and respectable CoC is hard work, and I commend the FreeBSD community for putting this one together. I think that in time, it can be made even better and more inclusive to both the people it is trying to protect and the people it is trying to keep in the community.

If I don't agree with the CoC of a community, I simply do not participate in that community. If a new CoC is adopted that has language with which I disagree, I'll first ask questions to clarify, following the principle of charity and keeping an open mind. If, after seeking clarification, I am still concerned, I'll move on. There is nothing to be gained by attempting to fight this stuff. This is the FreeBSD Foundation's walled garden. Either we accept their terms or we do not. But, bracketing the language, I really don't see anything in the guidelines that raises any red flags to me.

I'll turn the question back on you. Which specific clauses in the CoC do you find unreasonable? Let's not talk about language, because we can likely both agree that the language is extreme. Are there specific rules in that CoC that go too far?

Sure, this code of conduct is a bit ham-handed and written from a radical perspective that is at odds with the relatively conservative past of the project, but if we ignore the language of the conduct and focus instead on its meaning, it basically boils down to not being a dick. I think most people are likely upset because the language screams SJW, but this does not make the code wrong.

This is a sign of the times. The newer generation coming into these projects was raised with these values. Us "old timers" -- and by that I mean us who are over thirty -- were part of a different generation of OSS and Internet culture. This new culture may seem alien to us, but it's not that bad. Focus on building things and maybe try to be a bit more sensitive when critiquing others, and you'll be just fine.

I don't think this is the death knell for FreeBSD. Inclusiveness is a good thing. I'm glad they are trying to engage millennials. If enforcing a Code of Conduct that, despite the virtue signaling language, really boils down to "don't be a dick to people" ensures that this project can attract young people, then I'm glad to see it ratified.

Change can be good, but we have to be open minded to that change.

I've decided to build my own "dumb" phone. There are several 3G modules on the market that can be integrated into a simple hardware design. A few even support Hayes style AT commands to operate, providing both voice and data links.

There are a limited number of features I need in such a device. Beyond voice and text, I do want the ability to synchronize local data with a remote data store, such as productivity data, e-mail, and GPS information. However, I find most "smart phone" apps at this point to be little more than over-glorified bloatware that is prone to crashing and that often treats security and privacy as afterthoughts. I'd rather carefully curate the functionality I allow on my mobile device, and the hurdle of having to write firmware to perform these operations suits me just fine.

I don't disagree with your assessment. However, if your assessment is valid, then a functional language is still going to be quite foreign to someone who has only been taught object-oriented programming. I agree that we can go deep down the rabbit hole with OOP as well. The minimal interface that has been extracted from the science behind OOP and introduced to programmers in general is a mere shadow of the works of folks like Barbara Liskov.

FP has yet to have this generational winnowing. It is still fresh and academic. We can build people up to understand this, or we can pull these concepts down to their most basic versions that are still useful. I suspect that both will have to happen before the industry can meet in the middle with FP. We are seeing this happen already as mainstream languages are adopting bits and pieces of functional concepts. I think it's more likely that we will see functional applications of OOP, such as in languages like Scala, than OOP superseded by FP. That's okay. There are already plenty of examples of non-mutable objects with copy-on-write semantics. We are seeing functions treated more and more like first-class objects. There are examples of the FP-as-style movement taking off.

I believe that we should teach higher math in high school and even as a requirement for engineering or information systems disciplines. Currently, most universities top out bachelor degree seeking students specializing in these disciplines to calculus, differential equations, and linear algebra if they are lucky. It would be nice to see abstract algebra and some category theory taught as well. When I advise people genuinely interested in pursuing software development as a career, I strongly recommend that they minor in mathematics so they can have the opportunity to take these more advanced classes.

That being said, there's nothing that prevents people from studying this for self-improvement. Learning either or both OOP and FP will fundamentally change the way that one organizes software. I'd love to see high school kids exposed to these concepts and the mathematics behind them. Then again, I'd also love to see high school kids taught how to build their own CPUs from 74-series logic ICs. Understanding the theory of computation at an intuitive level will do incalculable good for most of these kids through the rest of their careers. If I were to teach a class to high school level students, it would be along this line. I can guarantee that they will never look at a computer, embedded device, or "smart" device the same way again.

Functional programming languages like Haskell, ML, and Gallina can be very beautiful. The problem is that they have a steep learning curve that has less to do with the syntax of the language and more to do with the semantics. If one is well versed in category theory or has spent a significant amount of time working with functor spaces, monoids, and monads, then it's much easier to understand a non-trivial application written in Haskell than the equivalent object hierarchy in an object-oriented language. The up-front cost is greater in terms of study and learning the semantics, but the end result is significantly more powerful.

I love functional programming. I went from C++ to Haskell and C as my go-to languages for personal projects. However, in my professional work, I tend to factor long-term language popularity into my decisions. So, I'm more inclined to use languages like Java, C#, Go, Python, and Ruby when I'm paid to write software. I have to consider the total cost of ownership in my professional work, and part of that cost is finding people to maintain it years from now.

I think that FP has an elegance that makes it a worthy model, and I hope that some day, FP becomes more popular than OOP. But, I'm old enough to understand that technical superiority rarely wins out to popularity. Popularity matters. This sort of calculus is one of the reasons why FP has not gained much traction despite all of the buzz.

Most static analysis tools look for bugs and potentially buggy behavior. They must rely on limited pattern matching and data flow analysis. They can't find all bugs. See: The Halting Problem.