Code rot and why I picked OpenBSD
homing-on-code.blogspot.com
homing-on-code.blogspot.com
But I just can't switch to OpenBSD as a daily driver yet. The big ones for me are battery life and responsiveness. Unfortunately compared to Debian I get almost 2 fewer hours on a single charge, and using OpenBSD's power management functions makes my i7 thinkpad sluggish and laggy. Noticeably longer delays when starting applications and whatnot.
I'm sure OpenBSD is a great desktop/server OS but IMHO it's just not there yet for laptops, which is surprising/disappointing to me because I'd always heard the OpenBSD guys dogfood their stuff heavily.
And yes, it just feels solid, much the same way Slackware does but even more so. It's not the perfect "Desktop OS", dogfooding or not, but it's good enough if you're focused on using it to get work done and leaving the entertainment stuff for Linux/Windows/OS X.
And you should submit your dmesg and any info you have about your battery and PM issues to the OpenBSD devs. They really do listen and try to fix issues like that!
See also: Richard Stallman's attempt to troll the OpenBSD mailing list[0] after having been called out[1] about a misunderstanding of the OpenBSD ports tree (and its existence as an index of software that can be built or installed on OpenBSD, free or otherwise).
[0]: http://marc.info/?l=openbsd-misc&m=119730630513821&w=2 [1]: http://marc.info/?l=openbsd-misc&m=119725673616073&w=2
No we're not. Stop talking kak.
Another thing to consider is that bug reports are only valid for the virtual environment; sometimes things that happen there simply don't happen on bare metal. I always test Haiku OS on any new hardware I get so if I come across something wonky, I can submit it to the devs for more testing. In a VM, that's pointless (but then Haiku is a hobby, not a job, so maybe not relevant to this discussion).
All that said, if all you need is a terminal and a web browser to be productive, a VM is a solid choice for getting things done efficiently.
A little digging brings a 9/2014 comparison of virtualization software that notes VirtualBox as a distant third on performance benchmarks (http://www.tekrevue.com/parallels-10-fusion-7-virtualbox-ben...) and an Ubuntu thread noting that its performance under VirtualBox leaves much to be desired (http://discourse.ubuntu.com/t/virtualbox-or-vmware-for-linux...).
[1] Scroll down to the graph at http://mitchellh.com/comparing-filesystem-performance-in-vir... to get an idea of how bad this is.
Are you sure you understood the documentation? Most upgrades are done in ten minutes, and it's mostly an automated process (the package updates are limited by your bandwidth of course). Every once in a while something on the system is changed or removed, and the upgrade guide tells you how to deal with that -- unlike on many other systems, where you upgrade and then find out things have changed and broken and you have no idea what needs to be fixed.
To me this looks more "manual" than FreeBSD's freebsd-update. Additionally, if there's no tool like pkg then upgrading all the user land packages will be quite an undertaking. A typical desktop/development environment may have about a thousand of them installed. On FreeBSD, I can do pkg upgrade, and it will take care of all dependencies pretty much automatically. Is there something similar available on OpenBSD?
After that you're into the "final steps" territory. Which means running sysmerge to merge changes in config files. It's not called openbsd-update, but freebsd-update requires you to do the same thing.
Typically the only "manual" part is removing some files and users no longer needed by the new release. Now 5.6 has lots of these files, but it's not really representative -- most releases have a much shorter list of file removals. In any case, there are very good reasons for the system not to do this automatically for you. And, in any case, if you know you haven't done anything unusual so as to depend on these files, you can get away with copy pasting these instructions.
At this point you update your packages with pkg_add -u. Just as you would have to on freebsd...
No, you're not done. You've merely dropped a new OS onto an old OS. It's now an exercise to the user to figure out how to remove all the files leftover from the old OpenBSD release. Leaving older libraries around is dangerous as programs could link against them long after they've been retired potentially exposing you to vulnerabilities that you didn't think you were exposed to anymore.
The correct way to upgrade OpenBSD is to do a clean install. Hopefully someday they'll support a tool like "freebsd-update" which handles all of this for the user.
If you're using the official OpenBSD packages, they would be linked to the correct libraries for that release, so there's no need to worry about linking to the wrong libraries. If you're compiling your own packages, you should be aware of anything you've done with any libraries that would require you pay any particular attention necessary to files being removed. Otherwise, it's not anything you would need be concerned about as a user.
Where do you get the idea that a clean install is the correct way to upgrade? Considering how conservative OpenBSD is, it would not provide an upgrade process if it wasn't something that was very well supported.
But you're right, removing files documented.
No it's not. The upgrade guides for each release literally tell you exactly which files should be cleaned up, which packages are now part of base, which parts of base are now packages, etc. OpenBSD has a good reputation for having complete and thorough documentation on every last detail of its operation, and system upgrades are no exception.
In practice, it takes very little time to upgrade an OpenBSD machine. As calrogman pointed out pkg_add -u is quite nice.
Is FreeBSD easier. Mostly, but I just went through a lot of manual crap because of a change in gnome and a php module causing a crash. I use a mix of FreeBSD, OpenBSD, Red Hat, and Windows servers at work.
But in practice, upgrading OpenBSD is basically:
1) Download and boot the bsd.rd for the new version.
2) Select [U]pgrade when prompted.
3) Mostly just accept defaults on the rest of the prompts. Do read carefully however.
After rebooting, run sysmerge(8). This has actually gotten even easier recently as you no longer need to point it to etc.tgz and xetc.tgz for that release.
If you have any packages installed, run pkg_add -u. If anything goes wonky, you might need to run pkg_check to clean up dependencies.
If you have compiled anything else from source you will need to remake/reinstall that also.
It's definitely more "hands on" than Windows, Mac OS, or most Linux distros. But really not bad.
It's actually not that hard. Even with the 5.4->5.5 upgrade (which broke binary compatibility on my PowerBook), I just needed to fire up the install disk, pick "upgrade" instead of "install", press Enter/Return a few times, and reboot (after which you run "sysmerge" to get your configuration files in order, then tweak $PKG_PATH and run a quick "pkg_add -u" in most cases (in mine, I had to save a list of all installed packages, uninstall everything, then reinstall from that list, but that was only slightly more tedious), similar to FreeBSD from what I understand).
It's only "hard" if you're trying to upgrade without booting into the install kernel first; not being recommended aside, even this isn't particularly difficult if you follow the upgrade guides, though perhaps it's a bit tedious, and just involves doing manually what the installer does for you automatically.
> Also, FreeBSD has pkg, which is a neat binary package manager - which is important on a desktop/laptop - and it looks like OpenBSD still uses the old, manual pkg_add way.
A pkg_add command is still involved, but it doesn't seem to be much different from most package managers; it still downloads binaries, checks dependencies, and does all the other nifty things that most modern package managers do. It ain't zypper or nix, but it does its job well enough.
Granted, I don't have all that much experience with pkg, so perhaps pkg_add is indeed primitive in comparison (it's certainly pretty spartan, to say the least). It's a step up from dealing with the ports tree directly, though, so there's that :)
> Maybe I'll try it on the third laptop, curiosity grows bigger every day for sure.
You definitely should.
AND
"... OpenSSL code base, counting how much resources are needed to plumb it into shape, how the original maintainers - let's not go there. Let's say 'didn't do a great job'. ..."
Does anyone see the disconnect here?
The point I wanted to make was the bank code base described in the article reads like it's insecure (no mention of it being exploited). The article then describes using Unix variants at home, [0] though not which one. I assume Linux. Usable, permissive and open, Linux has always been inherently insecure. Then the article goes on to describe finding of OpenBSD, post Heartbleed.
The question I asked myself: "How does a smart capable person as yourself, miss security being the heart of the operating system and programming while working on core bank systems?" Is this atypical? That's the crux I've what struck me. The dis-joint between the description of what represents a secure, large code base and the personal move to OpenBSD.
From what I understand OpenBSD, a bastard child of 386BSD [1] was a deliberate move to build a secure and audited and most importantly free operating system. This is such a contrast to the cruft described in the article. Maybe that's the point of the article, a growing awareness that fast a moving code-base left unchecked, comes at a cost. It has to change and it can be done.
[0] I fully endorse this btw. A linux user since '95, I love how I could use lots of different hardware with it. Linux is also fast. Fast to use, fast to install software. Fast. Secure it is not. I got sick of trying to secure my boxes and started using OpenBSD. Read about my pathetic attempts to install it on old hardware <http://monkey.org/openbsd/archive/misc/0310/msg01026.html>
[1] P57, Tovalds & Diamond, 'Just for Fun', "One BSD derivation in particular is worth mentioning. I was the 386BSD project by Bill Jolitz based on the BSD code-base, distributed over the Internet. It was later to fragment and become the freely available BSD favors-NetBSD, FreeBSD, and OpenBSD".
I'll try to put some more light and perspective into how my previous work place 'ticked' and how I intended to outline my passage to OpenBSD in the article.
My previous workplace was a large corporation. I were literally on the clock accounting for every 0.25h of work I did. You were not allowed to touch a single line of code unless you had billed hours against that task (contract with a client, bug report from a client). This literally meant that doing comprehensive code reviews or reworking a particularly nasty part of the code was not possible. There was a 'process' for doing code reviews but it was so bureaucratic that going through the paper work you had to submit after one took 0.5h-2h but the time you had for a code review was counted as a percentage of the time it took someone to produce or alter the code. So if you reviewed a change that took 1h - you had 10 minutes to do the code review and all the alloted paperwork.
I don't want to speak about the quality of the code base in detail due to obvious reasons but I can assure you that people working on it are really experienced and know what they are doing. Most of the problems and the humongous technical debt is years of corporate culture. Did I mention that the banking system I worked on was born around 15 years ago?
During my 7 years at that job. I had the chance to refactor code once. In my first 3 months of working there since I was not yet on the 'clock'. When I was at my leaving period I was given a free hand and was took off the clock again. This allowed me to really look at the code, analyze potential problems and actually react on them. People that are still working on it don't have that privilege on a daily basis.
The stab at Linux was actually accidental :) I use Linux personally since late 90s. What I mostly pointed out was some of my bad hardware choices in the passage and how OpenBSD drives me more into actually diving into the code contrasted to all the years I solely used Linux.
You are correct that my 'evolution' towards tighter, smaller and correct implementations drew me towards OpenBSD. I think I had that feeling for a long time but hopefully you understand that it's not always in the hands of the programmer himself to call the shots and do things right. What I really loved though was auditing and removing a ton of cruft in one code base while OpenBSD did the same with LibreSSL :)
Hope this answers your question.
"... I were literally on the clock accounting for every 0.25h of work I did. ..."
That is a revelation. Please follow with more articles like this.
I like to think the development of software as something akin to making music. If startups are Punk, big business is Pop. Manufactured Pop. It makes a lot of money and does the job, but at it's core the product sounds crap and devoid of time for creativity.
There was one guy who was a natural at playing guitar, a born player. He started in school and went on to be a top session player for a commercial company in the UK. It got to the point where he would turn up and be handed a folder of music and would have to play it on the spot, no practice, just play.
At that point he realised he was just a highly skilled session player, churning out muzac. He quit. That man was Jimmy Page who went on to play in Led Zeppelin.
Understanding how these musicians/programmers make the choices and tradeoffs to create, be it commercial muzac or punk rock, hearing about this trade-craft is good value.
Reliable and cheap, even more so if you take 10 minutes to google for a discount coupon.
Operating systems get deployed from an image, and typically expand the own partitions to fill up the disk... OpenBSD can't do this, which makes things pretty tricky.
As for VPS providers, I've heard good things about 1984[0], though I haven't used them myself (yet; I'll probably do this pretty soon). I've also used EDIS[1] without any particular problems. Both provide OpenBSD as OS options.
[0]: https://www.1984.is/ (in Icelandic, but there's a drop-down to set the language to English). [1]: http://www.edis.at/en/home/
Is there a LWN style product covering OpenBSD (possibly with free/net as well?)
I also watch tedu's blog (http://www.tedunangst.com/flak/) and the OpenBSD tag on lobsters.
For general news, undeadly is in my rss feeds. I also like the BSD Now and bsdtalk podcasts. BSD Now is from two folks from PC-BSD and FreeBSD, but covers the other BSDs as well.
OpenBSD Misc is here http://marc.info/?l=openbsd-misc&r=1&w=2
Long story short, and against my better judgement i stayed, for a 50% raise and a promotion.
If you don't take a stand, what's the point of your life?
In OpenBSD you are encouraged to run current.
What they actually say[1] is:
The name -stable refers ONLY to the API and
operations of OpenBSD not changing, not the
overall reliability of the system. In fact,
if things go as desired, the -current flavor
of OpenBSD, on its way to becoming the next
-release, will be an improvement in reliability,
security and overall quality over the previous
-release and -stable.
What is implied is that sometimes things don't go as desired; -current sometimes has issues. They are almost always quickly fixed, but if you depend on as near as possible certainty that an update won't break anything, you should run -stable.If OpenBSD states that something is configured then it works and will remain working flawlessly or will only get better over time.
Not guaranteed. I remember somewhere in the 4.x series my NIC driver was removed from the release build. I updated, and suddenly had no network access. My fault for not reading the release notes, but they don't always support old/obscure hardware forever. More recently, support for some older Microsoft VPN protocols was removed. It was because they were insecure, but this changed the way I had to interoperate with one of my client's internal networks.
OpenBSD appealed to me as a Linux user for the same reasons why Linux appealed to me as a Windows user. I was tired of bugginess, and just wanted things to work. Unfortunately, I still have the same obstacles migrating to it from Linux as I had migrating to Linux from Windows - namely, hardware support and gaming - that keep it from being my dream OS; however, it's still the OS I like to use when I need to get real work done (just as GNU/Linux was the OS I liked to use when I needed to get work done, back when I was still a Linux/Windows dual-booter so many years ago).
Even with those shortcomings, my PowerBook G4 is currently my favorite machine. There are some kinks, to be sure (power management is non-op, so I can't put the laptop to sleep), but with OpenBSD and WindowMaker, it's pretty rock-solid despite its age.
The nice thing about OpenBSD is that the devs aren't afraid of breaking backwards-compatibility if needed. They've already solved the 2038 problem as of 5.5, for example; with Linux's policies on backwards-compatibility, that'll be a nightmare to fix on 32-bit Linux systems (and even other BSDs, if I understand correctly). To me, that's awesome; I'll take a minor flag day to clean-reinstall my servers now over a major flag day to hack together some kind of band-aid "fix" later any day, and it's nice to know that, should I setup a server right now, it won't spontaneously vomit all over itself in 20 years or so due to it suddenly thinking it's 1970 again.
Lesson 1 sources on the hdd
This might sound simple but in a long time I didn't feel so connected to my OS. Having the sources for every piece of software I use around made things really different. How? I'm actually looking at them
I've taken to keeping a ~/code on my machines after experiencing the same thing with a BSD. It has been life-altering to be able to search implementation details with a simple :grep in my editor. I typically keep a copy of OpenBSD sources, along with major libraries for my current target OS and my dev toolchain (clojure/python(pypy)/clang) around to reference due to this. OpenBSD sources are kept around because it's cleaner to reference when I'm simply studying how something might be accomplished (as opposed to loading up glibc or the linux kernel if I need an implementation detail).The OpenBSD motto is "shut up and hack". Look at the work that is being done recently with libressl, openssh, the new httpd, signify, static PIE, xorg privilege separation etc. etc.
They're letting the code do the talking.
Heartbleed provoked substantial discussion as well as the LibreSSL project.
As I recall those allegations prompted the OpenBSD to team do a full code audit of the IPSEC stack and, while they did find a few bugs, the conclusion was that there was no backdoor and that the bugs they found were not intentional. I think it's really hard to respond these sorts of allegations and I'm not sure we could honestly expect more than that.
I'm really not trying to insinuate that OpenBSD is compromised or untrustworthy. I guess I'm just musing that, even though I've used OpenBSD for ages & ages and I do try to keep up with things in the OpenBSD world, I just don't grok the OpenBSD community... and that makes me feel uneasy sometimes.
(JFTR, I run OpenBSD in production, trust it greatly, and never believed the allegations of FBI/NSA/etc. "tampering".)
3 months? That sounds excessive. How much would your employer have been required to give you if they decided to let you go?
If they were the ones ending the contract then I also would have to stay for 3 months (getting paid for it).
I would get no money if we would both agree to let me go on the first day. They didn't want me to leave and I was not in a hurry to go on the first day. So I stayed for the whole period and tried to do my best both for my co-workers and my employer.
It's a business-critical system so as a professional, I wanted to ensure my replacement's (and my former team's) success.
I left on very good terms.