OpenBSD continues to fascinate me. It's impressive that a small team can produce such a coherent operating system and so many add-ons, like httpd, relayd, OpenSSH, pf and various networking tools.
Ignoring the things that happen when we add a desktop environment, everything in the base operating system just feels like it was designed to work together and with a clear guiding principle. Even the documentation is remarkable. It's rare that I can't simply rely on the man pages to figure out how something works.
The main feature for me in this release though is an updated network driver which seems to fix an issue I had where traffic would just pause for a few seconds.
Question. As i read can one use intel AC wireless with OpenBSD now?
Having a x250 and try'd FreeBSD13 some days ago, wireless speed was horrible (2.5 MB/s). It's a bit disappointing that FreeBSD just cant bring that to work...at least n would be acceptable.
I don’t have anything new enough to support AC so I honestly don’t know. Also the most heavy use I have for wireless is streaming and that’s plenty fast on my 6 year old NUC.
>Implemented a new 802.11n Tx rate adaptation algorithm ("RA") for iwm(4), iwn(4), and athn(4). Fixed association problems with the ipw(4) and iwi(4) drivers.
>Fixed automatic selection of the 11a/b/g/n/ac operating mode when the interface is running as an access point.
>Also, difficult to get into OpenBSD develooment when you already know git but not CSV.
That's your smallest problem if you wanna go into openbsd development, trust me if cvs is a burden for you, writing clean and correct code will be even harder....it's a version control system...should not be too hard to learn.
It may be something you already understand, but just to be clear to everyone, this preliminary support. It's a work in progress. You can't boot and run OpenBSD 6.9 on an M1 Mac Mini.
Like clockwork. I first started using the system in 6.4, so each release is a reminder to me of how quickly time has passed. Looking forward to a painless upgrade of my two servers and continued improvement of the project!
Goodness me, thank you for pointing this out. The songs are back as of 6.8 and I thought they finally kicked the bucket after 6.2. Below is a link for the 6.9 release song, it is – as you say – really nice:
Yeah, the most time consuming thing for me is if a PostreSQL upgrade is required on the machine. Other than that, sysupgrade, package upgrades, and a quick reboot seem to be the norm.
Yep, been using it since 4.8. Just upgraded my servers this weekend. Aside from my NAS, which has its own peculiar issues, everything went smoothly. sysupgrade, let it reboot, automatically updates, reboots again back to a working system. pkg_add -u to get the latest versions of installed packages, and that's it. Didn't even have to look at any sysmerge'd conf files this time.
OpenBSD finally got installed because I had a corner case where Linux cannot rein in the misbehaving systemd.
This corner case is where I must block all network access with and by systemd.
systemd DHCP is still immature in dealing with Juniper DHCP server (used by Verizon FiOS) so I stayed with ISC DHCP server.
Further more, despite disabling DHCP in systemd, this systemd continued to spew network packets (think aggregate link and bridging).
Since I want no part of systemd accessing the network, I found that there is no way to QUIET that systemd despite its own config effort.
Not even Linux firewall can block this PID 1 (systemd).
Coupled that with recent but devastating CVE vulnerability of systemd, I’ve since moved to Denuvan distro, which uses SysV init as well as Debian APT repositories.
Initial pre-production review shows that this OpenBSD OS remains the only one OS that can block by PID.
So, I am sold.
No more effort to super-hardening of Linux. No more.
I just wait for the day when systemd implement's THE standard filesystem with a backup program a backup-status-webpage just viewable with their systemd-fork of webkit and presented with a webserver running with pid 1 (can even be used as a bootloader)...like that genius idea...journald.
It's a stupid binary format..you have to convert it internally to a syslog'ish format which is clear-text readable even by humans and utilities like more...linux nih sickness once again, reinvent the wheel but this time we make it square.
I've experienced some dangers of thinking too much in that direction. Enjoy your anxiety filled life.
Edits because that was too snarky:
To elaborate, my own experience is that someone stuck in this mindset will spend too much energy and stress assessing people. The assessments will be wrong some percentage of the time. Probably often. A lot of times you'll be an asshole without merit. But a very stressed out asshole, too.
If you maintain an open mind about the "very bad" people, maybe occasionally you will trust people you should not, but also, sometimes those people will surprisingly impress you. And you may be much less stressed.
Id did say nothing about prejudice, there are bad people you can't deny that. But have a open mind and never think that you are right, and the others are wrong but try to understand other mindsets is a good thing. However there are bad peoples around who give a grandiose sh* about you try to be nice, you can ask Pol Pot or Idi Amin maybe sometimes...about being nice.
I just said that there are really bad peoples around, and nothing about prejudice or hiding from society.
The line has to be drawn somewhere. The default install with default settings is a reasonable enough one. Consider that Linux distros and Windows frequently have remote exploits in their default-install/default-state systems. One can enable services and misconfigure a base system to have remote exploits (is enabling telnet and not having a root password a fault of OpenBSD, or the admin?).
Once you start installing software from ports (as you're likely to do to use it as a desktop), are you going to blame the OpenBSD guys for the quality of software outside of their control? I hope not. :)
>are you going to blame the OpenBSD guys for the quality of software outside of their control?
Of course not, that's my point. In order to make an OpenBSD system usable for more than a rudimentary firewall, you need to step beyond the security claims that OpenBSD makes.
So the "only two holes" track record doesn't really mean much if you're installing software from ports, which nearly everyone does.
I would not conflate the tag line about remote holes in the default install with the security features OpenBSD provides [1]. Of which both base and ports benefit from, not to mention the patches for things like Chrome and Firefox to make use of pledge(2) and unveil(2).
The alternative would be for all OSes to run services X,Y and Z even if you install it in order to host service W. Also, you would then be "happy" to get remote rooted on your W service box, when attackers found an exploit in Y, just so that the box was not "empty" of services?
Even if you meant to run service X or Z, it would still be "better" to have the exploitable Y running by default, just so the system wasn't bare or so that they could not have that line on the webpage?
If you don't want to get exploited by default when you put your box on the internet, and these people have a method to get you there AND others tried running all fancy services exposed and did get hacked within minutes after putting such a box on the internet, would you still say "not exposing your box immediately" is a bad idea? Is it cheating somehow to not participate in the race to the bottom?
I run a lot of OpenBSD servers using either only base (httpd + pf + relayd) or base + software I write with minimal dependencies. The security in base is excellent for that. I don't have a desktop environment on my servers. It is easy to upgrade these, and I get very good security & configuration. So, for my use case, having "no remote holes in the default install" is exactly what I want and need. YMMV.
I hope they rewrote the pf rule syntax yet again so I get to go around rewriting every ruleset for every pf firewall I’ve deployed and all the books and documentation on pf can be obsolete. /s
Has anyone ever tried to propose a "universal" firewall syntax. Like an "intermediate representation" that can then be translated into the syntax for any version of any firewall software. Obviously it would not work as a 1:1 translation for every rule. There are things that one program can do that another cannot. Even something pre-pf like ipf still has some yet-to-be duplicated functionality. However there are many commonalities between all these programs.
Ignoring the things that happen when we add a desktop environment, everything in the base operating system just feels like it was designed to work together and with a clear guiding principle. Even the documentation is remarkable. It's rare that I can't simply rely on the man pages to figure out how something works.
The main feature for me in this release though is an updated network driver which seems to fix an issue I had where traffic would just pause for a few seconds.