OpenBSD 6.3 released(marc.info) |
OpenBSD 6.3 released(marc.info) |
> o Support the sun4v hypervisor interrupt cookie API, adding support for SPARC T7-1/2/4 machines.
Who is running OpenBSD on a big expensive SPARC T7 and why? I'm genuinely curious as to what possible use cases there are which make this a desirable combination.
https://www.tedunangst.com/flak/post/OpenBSD-on-a-Sun-T5120 (Not expired, Ted runs his own CA)
https://www.openbsd.org/sparc64.html
"The other architectures that OpenBSD supports have benefited because some kinds of bugs are exposed more often by the 64-bit big endian nature of UltraSPARC."
"SPARC64 is a favorite of this developer because it's some Alice in Wonderland stuff where up is down and left is right compared to other architectures. So it exposes a number of bugs that others don't."
Becoming a new SPARC user is becoming more tempting to me now.
indicates:
static const struct pci_matchid bwfm_pci_devices[] = {
{ PCI_VENDOR_BROADCOM, PCI_PRODUCT_BROADCOM_BCM43602 },
{ PCI_VENDOR_BROADCOM, PCI_PRODUCT_BROADCOM_BCM4350 },
};
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/pci...
as:
vendor BROADCOM 0x14e4 Broadcom
product BROADCOM BCM4350 0x43a3 BCM4350
product BROADCOM BCM43602 0x43ba BCM43602
Looking forward to checking out the new execpromises in pledge. I use pledge in all my C stuff and have added it to a few other apps. Thanks OpenBSD devs!
Of all the priviledge dropping mechanisms I have encountered, pledge seemed the most comprehensible.
Interesting that they just changed the interface from `int pledge(const char * promises, const char * paths[]);` to `int pledge(const char * promises, const char * execpromises);`. I guess that is the power they have by being a BSD and integrated system, they do not worry about userland compatibility.
"BUGS. The path whitelist feature is not available at this time."
So the second argument was previously unused, and thus could be repurposed without hurting backwards compatability.
Can someone help explain what the "routing domain" is?
EDIT: Nevermind: https://marc.info/?l=openbsd-cvs&m=152256582629837&w=2
- Those running network infrastructure (router, firewall, VPN gateway, mail server, etc.)
- Those who want a simple Unix desktop with no gimmicks and low hassle
- Hardcore Unix geeks who don't like the other flavors for $REASONS
In a more general or vague sense, OpenBSD is often appealing to people who care more about cohesiveness and correctness than about the sheer magnitude of performance and features. If you've ever thought that you might prefer to have an indefinitely supported version of Windows 7 because Windows 10 seems to be crawling with gratuitous changes, bugs, and dubious "features", the appeal is a bit like the Unix equivalent of that.
This! When you are using OpenBSD, and wonder how a particular piece of the kernel works, you just open the source code, read it, and you can usually have a good idea of the inner workings with some days studying it. Trying to do the same thing with linux, you would need months to grasp any idea of how it works. Linux is developed by thousands of people all around the world at the same time. OpenBSD on the other hand is developed by a few power developers, which gives the code a unique consistency and readability.
I noticed this first hand in while submitting a patch for my macbook's touchpad to FreeBSD's wsp driver and then comparing to OpenBSD's driver... The approaches between FreeBSD's and OpenBSD's driver couldn't be more opposite: FreeBSD's is big, explicitly listing each hardware revision/model (hence the reason I had to go in there and add mine), OpenBSD's very minimal, implicitly inferring all hardware revision options so users don't have to add each and every one, it's also very neat and tidy which I think is an underrated quality in source.
Admittedly this is only one file from one small number of devs, far from the whole of FreeBSD, but the contrast matches much of what i've heard of OpenBSD's approach: minimise cruft and bad code, if it's shit and not easy to re-write then delete it, better to be minimal than buggy and insecure.
Full Disclosure: My comment may well be outdated since I moved away from FreeBSD for my desktop 2 years ago, I have nothing against it, I just needed (other) working drivers.
Also, installation was quite fast if you knew what you were doing.
I'm weird, dunno if others agree ~
I stopped using OpenBSD when I tried installing it on my newer Core 2 Duo desktop in ~2008, but the OS would not boot, and I was told on IRC by OpenBSD developers that the hardware was too new for OpenBSD.
FWIW, now I use Arch Linux. I guess I'm in the target demographic.
I used these [0][1] repos as a starting point, I wrote a few helpers to update dynamic dns and a DNS ad blocklist for unbound. This replaced a pfSense install and I'm happy with it so far.
[0] https://github.com/elad/openbsd-apu2 [1] https://github.com/northox/openbsd-apu2
What I love about OpenBSD is the documentation. If An openbsd manpage describes it then it will work like that.
The only bummer is it’s a bit of a niche. I’m sure the majority of Linux distros dwarf its development team in warm bodies.
>Do we really want an internet where the use of encryption requires authorization?
No, it doesn't require, it provides identification and that's a huge benefit. We are all far better by having it as a standard. Just configure Let's Encrypt and stop annoying your readers.
I don't hack on the internals or build my own ports, I just use it. It stays out of my way and I like that.