OpenBSD 5.5 Released

ConstantineM (965345) writes "Just as per the schedule, OpenBSD 5.5 was released today, May 1, 2014. The theme of the 5.5 release is Wrap in Time, which represents a significant achievement of changing time_t to int64_t on all platforms, as well as ensuring that all of the 8k+ OpenBSD ports still continue to build and work properly, thus doing all the heavy lifting and paving the way for all other operating systems to make the transition to 64-bit time an easier task down the line. Signed releases and packages and the new signify utility are another big selling point of 5.5, as well as OpenSSH 6.6, which includes lots of DJB crypto like chacha20-poly1305, plus lots of other goodies."

Comments

YAY for BSD

[CheshireDragon]

Even though I've never used it...

Re:YAY for BSD

[Anonymous Coward]

This article will get like 2 comments while another about lesbian programmers in space with get 200 billion comments.

I won't say anymore because ....

Never mind ,,,

Re:YAY for BSD

[Anonymous Coward]

Fire up a VM and try it out, OpenBSD is a really nice OS to work with IMO.

Re:YAY for BSD

[Anonymous Coward]

Next time the article should say: Lesbians install the new OpenBSD version.

Re:YAY for BSD

[i kan reed]

Yep, that's pretty much what 99.7% of people can contribute to this discussion(maybe 95% of slashdotters specifically, but still).

You can kinda go "Yay open source operating system that creates a bit of systemic competitive pressure to keep updating other open source operating systems through some really bizarre application of economics towards a system built around entirely free exchange"

It gets real abstract.

Re:YAY for BSD

[Anonymous Coward]

Even though I've never used it...

And there you go with the problem with it. OpenBSD has no holes in the install as long as you don't mess with the config and actually turn on a service and as long as you upgrade to each new version which can't (practically) be done automatically. It's almost unusable to a normal user.

Still; I'm going to install it today and all of you should send the project some money 'cos lots of the important security software such as OpenSSH comes from OpenBSD.

Re: YAY for BSD

[the_humeister]

If not for the lack of ZFS, I would use OpenBSD. Instead my fileserver is running FreeBSD 10.

Re:YAY for BSD

[QuietLagoon]

And there you go with the problem with it. OpenBSD has no holes in the install...

Regardless of how you use an operating system, if the OS foundation is not secure, then anything you put on top of it cannot be secure.

At least OpenBSD provides the secure foundation upon which you can build what you'd like. The security of what you build on top of OpenBSD is your responsibility.

Re:YAY for BSD

[Kremmy]

There's a little bit of header, a little bit of license, BSD...

It's the silent protagonist in the technological world - they build and refine the technology that seeps into all other operating systems.
The code is licensed so liberally that Stallman's arguments literally boil down to "everyone can use it so it's not free".
If you dig into the credits portion of almost any software, it's there.
We all use BSD.

Re:YAY for BSD

[wonkey_monkey]

It gets real abstract.

Well, which is it?

Re:YAY for BSD

[Anonymous Coward]

Stallman has never called the BSD license non-free. You're either delusional or a liar.
All free software licenses are wonderful for us users. Copyleft ones are also wonderful for free software as a whole.

Re: YAY for BSD

[Anonymous Coward]

How to update Open BSD: insert CD, boot CD, select update. Wait a few minutes. Upgrade ports. Wait a few minutes. You are done.

No CD? Copy base files to machine through SSH. Install files. Reboot. Upgrade ports. Wait a few minutes. You are done.

Any other questions?

Re: YAY for BSD

[unixisc]

Which file system do they use?

Re: YAY for BSD

[Anonymous Coward]

You got it. I've updated remote (read: "in other countries") OpenBSD machines for over a decade. There is still the anxiety of waiting for the system to boot, but I don't recall ever having it blow up on me.

Re:YAY for BSD

[CODiNE]

The former latter.

Re:YAY for BSD

[metrix007]

Yeah, no. Heartbleed showed how meaningless theire claims of a secure default install are in this day and age.

It used to mean something against Windows Servers and Linux Distros that had everything enabled by default, but not so much these days.

All these years, and they hadn't even audited openssl, a key core component of the default install.

Re: YAY for BSD

[rubycodez]

openbsd has the Unix FFS (up to about 1TB volume size) and FFS2 (up to 8 zettabytes volume size)

Re:YAY for BSD

[Anonymous Coward]

The code is licensed so liberally that Stallman's arguments literally boil down to "everyone can use it so it's not free".

Given that Stallman's main organisation, the Free Software Foundation, almost actively supports the BSD license, declaring it a Free Software License compatible with the GPL, I wonder what it is that drives you to say such a thing. A feeling that since the truth normally supports Richard, it's worth spreading almost any lie in the hope of discrediting him?

Re:YAY for BSD

[rubycodez]

it is a joke, you're funny

you could have made a backup copy of fstab before dicking with it. or followed the excellent OpenBSD documentation and made backup root partition.

Re:YAY for BSD

[rubycodez]

you sure? your printer doesn't have have controller running BSD? or network appliance?

Re:YAY for BSD

[Arker]

"The code is licensed so liberally that Stallman's arguments literally boil down to "everyone can use it so it's not free"."

Stallman has always acknowledged it as Free and continues to do so.

Dont be a troll.

Re:YAY for BSD

[Anonymous Coward]

http://www.openbsd.org/cgi-bin/man.cgi?query=ed&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

Maybe you didn't have so much as a smartphone or a wiki kindle, but you can find all of the manual pages online.

I don't even use OpenBSD, but I use this in similar situations.

Re:YAY for BSD

[Dan Ost]

I was under the impression that OpenBSD did not enable heartbeats by default and, as such, was not vulnerable to Heartbleed by default.

Am I wrong?

Re:YAY for BSD

[Kremmy]

That is EXACTLY what he is saying given his comments regarding LLVM.
Referring to this post in particular.
His stance is a demonization of liberally licensed code, to a very unfortunate degree.
I am absolutely not trolling when I say that man has given up freedom for ideology.

Re: YAY for BSD

[unixisc]

So FFS2 - how does it compare w/ ZFS, aside from license (which I'm assuming here is ISC, right?)

Re:YAY for BSD

[davester666]

OMG. Lesbians are recommending the use of OpenBSD. I have just got to install it, just to be like lesbians.

Re:YAY for BSD

[Anonymous Coward]

OpenBSD have software in place that wouldn't allow the Heartbleed bug to work in the first place. As soon as a Heartbleed event occurred, the OpenSSL software would immediately terminate in OpenBSD.

Re: YAY for BSD

[TheRaven64]

FFS2 is basically the original Berkeley FFS (also known as UFS, but there are at least half a dozen incompatible filesystems called UFS, so that just gets confusing) with some extensions. It basically just increases the size of various fields in the inode data structure so that various limits are much larger. I'm not familiar with the OpenBSD implementation, but on FreeBSD it also supports soft updates (where metadata and data writes are sequenced so that the filesystem is aways consistent, although fsck may be required to clean up) and journalling. Aside from that, it's a fairly conventional inode-based FS. If you want snapshots, FreeBSD provides them at the block layer via GEOM (I don't know what the OpenBSD equivalent is).

In contrast, ZFS rearranges all of the layering. At the lowest level, you have a set of physical devices that are combined into a single virtual device. On top of this is a layer that's responsible for storing objects and providing a transactional copy-on-right interface to the underlying storage. On top of this, you layer something that looks like a POSIX filesystem, or something that looks like a block device (or, in theory, something that looks like an SQL database or whatever).

For the user, this means that a load of things are easy with ZFS that are hard with UFS:

• Creating snapshots with ZFS is a O(1) operation.
• Creating new filesystems with ZFS is about has hard as creating directories.
• Filesystems all have block-level checksums, can have multiple copies of files (if they're used for important stuff) on a single volume.
• Compression and deduplication can be enabled on a per-filesystem basis. With UFS, there's no deduplication (although it would be possible to write a block-level dedup implementation for GEOM), and compression is handled at the block device layer.
• You can delegate the rights to create and modify filesystem properties into jails safely with ZFS (not relevant to OpenBSD, as it lacks jails).

Re:YAY for BSD

[TheRaven64]

Not true. It would have done if OpenSSL hadn't used a custom allocator, but the use of the custom allocator bypassed the policy in OpenBSD's malloc() that aggressively returns unused pages to the OS and causes this kind of fault. And why does OpenSSL have this custom allocator? Because without it people complain that malloc() implementations like the one in OpenBSD are too slow...

Re: YAY for BSD

[Anonymous Coward]

Lorelei Lee approves your message.

Re: YAY for BSD

[Anonymous Coward]

Can you explain the mental process behind the number 99.7 ? I love people that use 99.9+% ( as a regex). It makes sense because it's kinda convergent. But what are those 0.3% ?

Re:YAY for BSD

[Arker]

"That is EXACTLY what he is saying given his comments regarding LLVM.
Referring to this post in particular."

I suggest you re-read his post. If your opinion has not corrected by then, you might need to seek remedial help in Reading or English. "EXACTLY" and "not at all" are not synonyms, and this is actually not at all what he is saying in that post.

Re:YAY for BSD

[metrix007]

Honestly I'm not sure. If heartbleeds are not enabled that's great.

It still lessons their claim since they missed a vulnerability from 2011 in the base install. No doubt there are others.

Re:YAY for BSD

[Anonymous Coward]

From RMS:

In the free software movement, we campaign for the freedom of the
users of computing. The values of free software are fundamentally
different from the values of open source, which make "better code" the
ultimate goal. ...
The Clang and LLVM developers reach different conclusions from ours
because they do not share our values and goals. They object to the
measures we have taken to defend freedom because they see the
inconvenience of them and do not recognize (or don't care about) the
need for them. I would guess they describe their work as "open
source" and do not talk about freedom.

Sounds like he is questioning how "Free" that code really is. What is the correct interpretation of his comment that BSD devs basically avoid talking about freedom if it doesn't mean it isn't truly free?

Why don't you enlighten (I mean, "correct") us as to what he is saying?

Re:YAY for BSD

[Arker]

Q. Where in that does he say the BSD license is not Free?

A. Nowhere.

"What is the correct interpretation of his comment that BSD devs basically avoid talking about freedom if it doesn't mean it isn't truly free?"

That despite being Free they do not share the values and goals of copyleft, do not recognise or care about the need for copyleft.

Free Software: https://www.gnu.org/philosophy/free-sw.html

Copyleft: https://www.gnu.org/copyleft/

List of Free Software Licenses: https://www.gnu.org/licenses/license-list.html

All of these licenses are recognised as Free. Yet there are still differences between them, and reasons to prefer one over another.

Free software is the superset, copyleft is the subset. Which is to say all copyleft software is Free, but not all Free software is copyleft.

The Free Software foundation exists to promote Free Software. It also promotes copyleft specifically (in most but not all circumstances) because that type of Free Software not only means Freedom for users today, but helps to ensure that future users will still have Freedom tomorrow.

LLVM is Free, but it's not copyleft. And if you care about Freedom down the line, not just your Freedom here today but the future of it in 5 or 10 or 20 years, that could be very significant. That's why he's worried.

Re: YAY for BSD

[rubycodez]

OpenBSD does have soft updates which are optionally enabled at mount time. It also has software RAID 0 or 1, and 1 allows more than two volumes to be mirrored, kind of like a hot spare that doesn't need rebuild time.

So it's not as full featured as ZFS, though compared to most linux filesystems the FFS and FFS2 are extremely robust at surviving unexpected power failure.

Re:YAY for BSD

[Anonymous Coward]

LLVM is kind of a special case and required a special comment from him.

GCC is effectively dead and LLVM killed it. It will take years and years for it to die completely, but in 10 years people will talk about GCC the way they talk about Trisquel Linux now. This "Open Compiler Initiative" stuff going on now isn't happening because the GCC folks had a change of heart; it's happening because they are about to become irrelevant and they know it.

The GPL is important. It's a safe harbor that everybody can always retreat back to because of that protective license, but the switch to GPLv3 moved a lot of moneyed interest to "what's the next best thing?" There's always been a low level of discussion about moving projects like OpenBSD away from gcc to something BSD licensed (pcc came up some). Now llvm and clang have given people that path. FreeBSD has clang as the default compiler. Others will follow. BSPs for various embedded boards will eventually move to clang/llvm and there'll be no turning back.

Re:YAY for BSD

[Kremmy]

I don't consider this a special case. As you've just said, people have been trying to replace GCC for ages. There are a lot of motivations for that, many of which coming down to a distaste for the GPL. There have been hard criticisms for a long time. I've personally run into some of the stranger code malformation issues affecting certain versions while compiling my own code. I think they may have been bit by the same hubris that affects the rest of the software organizations, which leads us to crap like Metro and Unity. I'm really pleased with LLVM shaking up this particular tree - it REALLY needed it, monopolies are bad for EVERYONE and GCC had been the free compiler monopoly for how long?

Re:YAY for BSD

[Anonymous Coward]

I see it as a special case because it seems like GCC is taking LLVM very seriously.

> GCC had been the free compiler monopoly for how long?

Since the days of EGCS at least or maybe the XEmacs/Emacs debacle--a long time at any rate.

> I'm really pleased with LLVM shaking up this particular tree - it REALLY needed it,

I see things like VMKit and HSAIL and I'm looking forward to seeing what else comes out of LLVM.

Re: YAY for BSD

[evilviper]

Creating snapshots with ZFS is a O(1) operation.

That doesn't relate to any of the (layering) changes you listed. That's a simple byproduct of ZFS being a copy-on-write (CoW) file system, unlike most other popular file systems. But there are other CoW file systems out there, which similarly have O(1) snapshots.

Re:YAY for BSD

[evilviper]

...until you put a typo in /etc/fstab when you're not used to plain old vi, and get to discover the joys of learning ed. Without a man page because that was in /usr too.

Some reason you can't just manually run "mount" from the command-line to mount the /usr partition, and get vi and man pages back?

And is there some reason you couldn't just visit the website to access the man pages?

http://www.openbsd.org/cgi-bin...

Re:YAY for BSD

[evilviper]

No, the manual is on the file system, and they're far better than the crap documentation you get from Linux or other Unixes. It just also happens to be available, in a convenient location on the web.

*Ahem*

[Anonymous Coward]

oblig

Re:*Ahem*

[ledow]

Except we're not on 64-bit.

The full announcement tells you that a load of things had to be converted to unsigned 32-bit because that's all you could do.

And they can conceivably affect things in your children's lifetimes (if not before, with long date calculations like mortgages etc.).

Fact is, however, that system support for 64-bit time only means your taskbar clock will go up that far. It means nothing in terms of your application actually supporting and calculating things correctly once we get anywhere near 2038.

Conceivably, those places offering 30-year mortgages etc. were handling those dates several years ago. They involve a lot of money so likely they are okay.

But whether your we get everything like your phone, satnav, car, embedded devices etc. all onto full 64-bit time OS and 64-bit time applications BEFORE they're predicted-end-of-life would go through 2038 - that's a different question entirely.

Re:*Ahem*

[fnj]

Making time_t an int64_t instead of an int32_t has absolutely NOTHING to do with whether the architecture is 32 or 64 bits. An application that does time manipulations NOT using time_t is a stupid, broken application.

Missing libReSSL, as expected

[Anonymous Coward]

Before anyone asks, no, this new version of OpenBSD (version 5.5) does not include libReSSL yet.
That's not how OpenBSD operates. Neat announcements made even a month before an OpenBSD release do not usually appear in the very next OpenBSD release. There are cutoffs/deadlines, and the OpenBSD group is far more interesting in ensuring reliability than flashy new code that is only partially ready.
If you check the libReSSL.org website, libReSSL is planning to be included in OpenBSD 5.6, which I expect will be released on November 1, 2014. The OpenBSD group has a solid track record of making their official releases publicly available by the expected date.
To see an overview on what did get included in this version (like signed packages), see the release notes (which is pointed to by the first hyperlink of this Slashdot news story).

Next release...

[msauve]

The next release is scheduled for a few years prior to Sunday, 4 December 292,277,026,596.

Re:Next release...

[Anonymous Coward]

The next release is scheduled for a few years prior to Sunday, 4 December 292,277,026,596.

Will that be Sunday morning or Sunday afternoon?

Re:Next release...

[proxie]

ha! I was just checking.. 5.4 - November 2013 5.3 - May 2013 5.2 - November 2012 5.1 - May 2012 5.0 - November 2012 4.9 - May 2011 Its' actually consistent, just really prolonged compared to other *nix distros... dethrone a tyrant and might actually get things done sooner :)

Re: Next release...

[Anonymous Coward]

Yes they release every 6 months. What's your point?

Re:Next release...

[unixisc]

I was gonna ask - which year would people have to look out for now?

Re:Next release...

[fnj]

[time between releases is] just really prolonged compared to other *nix distros

Horse shit. It's exactly the same timing as Ubuntu and Fedora and much qicker than Debian and Redhat Enterprise.

Re: *BSD is dying

[ConstantineM]

http://meta.unix.stackexchange...

Damn OpenBSD

[Anonymous Coward]

They do this just when I'm halfway done building my year 2038 bunker.

Re:Damn OpenBSD

[jones_supa]

You should call yourself lucky. I just made the finishing touches to my Y2K survival basement.

Re:Damn OpenBSD

[Anonymous Coward]

At least you're ready for Y3K.

Re:Damn OpenBSD

[TheRaven64]

Pretty much all 64-bit systems have used 64-bit time_t forever, so the Y2038 problem is only an issue if people are still using 32-bit platforms in 24 years. Given that even ARM is now 64-bit, that seems quite unlikely (none of those old mainframes that were a problem for Y2K have this problem and most databases use 64-bit time values because people care about dates further in the past than can be expressed with a 32-bit UNIX time_t). Of course, Google has just released a new Java implementation for Android that does a load of void* to int32_t casts all over the place and is going to be almost a total rewrite to port to a 64-bit architecture, so you can't always trust big software companies not to be complete idiots...

Re:Why not try it?

[i kan reed]

Why do we not like scripts? Honest question.

Re:Why not try it?

[Anonymous Coward]

Just don't use Ubuntu, which emphasize on graphical experience. There are distributions which are intended for the kind of folks who want to change their IPs on the command line. Try arch or gentoo.

Re:Why not try it?

[Anonymous Coward]

How do you even change the ip address from the command line?

"ip addr add $IP_NUM dev $IP_DEV"

Or, if you like, you can use ifconfig, even though that's obsolete.

They'll collect your nerd card on the way out, troll.

English?

[Anonymous Coward]

"Just as per the schedule"? Really?

Re:Why not try it?

[Jakeula]

What an odd measure of the quality of an OS. Like changing your IP from the command line is something that speaks to how well Linux has been developed. And you can change your IP from the command line. ifconfig does this just fine, even if its not the preferred method. you can also do something like this: sudo ip addr add xxx.xxx.xxx.xxx
but I guess I just fed a troll, so jokes on me.

USB Installer!

[Dimwit]

There's a USB installation image for i386 and amd64! Finally! Dear lord, it's been years. That's as big a deal as the time_t thing for me.

Re:USB Installer!

[Anonymous Coward]

It still won't boot on my 2011 imac, so it's worth fuck-all to me.

Re:USB Installer!

[Anonymous Coward]

A more flexible way to create an OpenBSD flash installer:
http://blog.breeno.net/2014/02/creating-flexible-openbsd-usb-installer.html

Re:USB Installer!

[Anonymous Coward]

If your comment was about booting USB installation media on an iMac:
I don't know enough about iMacs to have understood your comment. More clarity would be appreciated.

If your comment was about OpenBSD:

I'm sorry, but posting here does not satisfy the official OpenBSD bug reporting process. (Particularly, the last hyperlink on that page.)
In particular, this post (comment #46891655) seems very much like a violation of the first paragraph under OpenBSD FAQ 2: section on bugs.
Well, look on the bright side. At least you were intelligent enough, or just plain lazy enough, to post as Anonymous Coward. Hmm, given the other behavior I've observed, I suspect the latter.

Re:USB Installer!

[Anonymous Coward]

That's

That's = an abbreviation for "That is", a present-tense phrase.
'Tis true, 'tis true. At the time that it was written. Although, I'm rather certain that those priorities will change in less than a quarter century (unless you're an old-timer who kicks the bucket, jumping off this mortal coil before that quarter century is up).

Actually, this time_t update has happened surprisingly late. I've heard that such time bugs can cause problems as soon as 30 years in advance (which would have been about 6 years ago) in financial software that handles 30 year mortgages. Granted, maybe 30 years is a bit longer of a stretch than what most people tend to think about. However, as time continued to advance, more and more people would experience more and more problems that are more noticeable. The problems would not all start to manifest after the magical second on January 19th of 2038.

NetBSD time_t

[Anonymous Coward]

I use OpenBSD almost exclusively, but in all fairness NetBSD was the first to move to a 64-bit time_t on all its platforms.

Also, there's no chance that Linux would ever make such a jump. They'll invent something complex and annoying to maintain backward compatibility with all the proprietary crapware. OpenBSD and NetBSD can do it because they're not afraid to make everybody recompile their software.

(For people who don't understand the issue: on NetBSD and OpenBSD time_t is now 64-bits, even on 32-bit platforms. So the 2038 problem is non-existent going forward, even for 32-bit software.)

Re:NetBSD time_t

[unixisc]

I think you got it the other way around - it's Linux that's unafraid to break backwards compatibility, while the BSDs are pretty religious about that point

Re:NetBSD time_t

[rubycodez]

but this openbsd release is a "flag day" release, meaning it *will* break old binaries, they need to be recompiled.

Re:NetBSD time_t

[Anonymous Coward]

I disagree. Look at multiarch support in Linux. There is little reason to support 32-bit binaries on 64-bit architectures, _especially_ for FOSS software. Yet modern Linux systems have a convoluted library system to support this. The BSDs, on the other hand, took the route of simplicity. 64-bit is 64-bit, 32-bit is 32-bit, and ne'er the twain shall meet (at least for x86).

I think you're confusing API and ABI backwards compatibility. Linux aims for long-term backwards compatibility for both ABI and API, but commercial vendors will cynically tell you that they suck at both. BSDs, however, generally only aim for API compatibility. They don't care about long-term ABI compatibility--just recompile your crapware for the new point release, already. That means they have more time and energy to focus on a consistent and sane API implementation.

Re:NetBSD time_t

[AndroSyn]

I disagree. Look at multiarch support in Linux. There is little reason to support 32-bit binaries on 64-bit architectures, _especially_ for FOSS software.

Not all platforms are as brain damaged as the x86. On SPARC64 type systems, you'll find that most all software is run in 32bit mode, as the ABI still allows you full register access. Most software doesn't need to access more than 4GB of memory anyways.

Also there is a lot of non-FOSS software that is only available as Linux x86 32bit executables, keeping that 32 ABI compatiblity sure is useful as well on a 64bit system.

It's not entirely unthinkable to run a 64bit kernel on X86-64 and run entirely a 32bit userspace, in fact, it might run a little bit faster as a lot of the software would have a smaller cache footprint, yet the kernel would still support large amounts of physical memory without PAE tricks.

Just because *YOU* think is convoluted and not useful, doesn't mean it doesn't make sense to someone else.

       

Re:NetBSD time_t

[TheRaven64]

On x86, you can (now) use the x32 ABI to get the same effect. The problem comes when you need to run one or two 64-bit binaries. Now they are pulling in a different libc and so on and the extra i-cache churn from multiple copies of the same library can quickly offset the reduced d-cache churn from smaller pointers (main memory usage is largely irrelevant: it's rarely a bottleneck and the average 5-10% saving from reduced pointer size is in the noise).

Re:Why not try it?

[jones_supa]

They break easily and are slow to interpret.

Re:Why not try it?

[Anonymous Coward]

There's nothing wrong with scripts as such. It's much better to have scripts than have all the configuration and system actions hidden in binaries and controlled from some binary formatted hirearchical database like the Windows registry. However the number and types of scripts in the average Linux install can be pretty overwhelming. There is a kind of deep lack of clarity about some Linux distro's boot process. This makes them much more flexible and easy when everything's working but it can be confusing. People don't tend to like confusing.

Not quite

[ArchieBunker]

Wasn't that easy on my BeagleBone Black board http://derekmolloy.ie/set-ip-a...

How anyone is supposed to figure that out is beyond me. Is a script calling ifconfig too good for you people?

Re:Not quite

[Anonymous Coward]

Get used to this, with systemd and everything udev (including the kernel) and dbus, it's config files all the way down.

Re:Not quite

[Anonymous Coward]

*binary* config files if you let the systemd guys get their way.

Re:Why not try it?

[ArchieBunker]

Its not one script anymore. Its one script hundreds of lines long that calls other scripts to finally accomplish something you could do with seconds and ifconfig. Don't get me started with the mess systemd is.

You are correct

[Anonymous Coward]

Running NetBSD on a 64 bit Alpha really showed how broken a lot of software was.

Re:You are correct

[Anonymous Coward]

It used to be that running *anything* on an Alpha apart from VMS* showed how broken a lot of software was.

* Runing VMS just showed how broken VMS was.

Re:You are correct

[Anonymous Coward]

The OS itself was rock solid. I had the box running for close to a decade. The problem was trying to compile poorly written software. Still hard to believe that VMS is still supported on Itanium. I'd love to get some numbers on their user base.

Re:You are correct

[TheRaven64]

Especially anything that used threads. Going from a strongly ordered x86, where basically anything is sequentially consistent for free, to the extremely weakly ordered Alpha, where things are only visible between threads with explicit barriers breaks a lot of stuff where people only tested on x86. ARM has a similar problem.

So how does it perform?

[Anonymous Coward]

I have used OpenBSD a number of times over the years but when I have tried to use it as a high performance server it falls on its face. Has it gotten any better?

Re:So how does it perform?

[Anonymous Coward]

OpenBSD is not meant to be the fastest or most scalable OS in the world -- just the safest. The right tool for the job. You use OpenBSD as a firewall in front of your high performance server, which can then run whatever OS you choose. I wouldn't trust anything else. More specifically, the bare bones, well documented, best practice coded, continuously audited, secure by default approach means you can deploy an OpenBSD firewall router with minimal effort and minimal worry. Save the worry and effort for the potentially less secure OS's that are running behind the firewall.

Re:So how does it perform?

[Anonymous Coward]

Nothing like putting a superfluous firewall in front of a web application server which would only have port 80 open anyhow (or maybe port 22, too, but that's the least of your worries).

I agree that for high performance you're stuck with Linux. But slapping an OpenBSD firewall in front of your Linux application server doesn't magically make it any safer. Port 80 is still open, which for most intrusions is the only port that matters. And who seriously blocks outgoing connections? Your server must be doing something mighty boring to not need to make requests over the Internet. And good luck coordinating with the developers the precise IP addresses they'll be contacting.

For truly critical infrastructure, just use OpenBSD. Most critical services can be spread across multiple boxes.

Re:So how does it perform?

[Anonymous Coward]

There is no point in even using OpenBSD in that case. Your apps are still running on whatever high performance insecure backend you need. OpenBSD adds nothing.

Re:So how does it perform?

[Anonymous Coward]

But isn't the point of a firewall to keep the web server isolated from the rest of the network? If the web server gets hacked, you still have the firewall isolating the intrusion from the internal network.

Can I relax now?

[NMBob]

Does this mean I don't have to worry about Tuesday January 19, 2038 at 03:14:07 UTC anymore? What's the new date/time when things will crash and burn?

Re:Can I relax now?

[Jurily]

Using a signed 64-bit value introduces a new wraparound date that is over twenty times greater than the estimated age of the universe: approximately 292 billion years from now, at 15:30:08 on Sunday, 4 December 292,277,026,596.

Re:Can I relax now?

[NMBob]

Yeah, but isn't it going to take like 10^500 (or is it 10^800?) years for all of the baryons to fizzle out? Rats. More code to write.

Everyone forgot the most important bit!

[ConstantineM]

5.5 base signify pubkey: RWRGy8gxk9N9314J0gh9U02lA7s8i6ITajJiNgxQOndvXvM5ZPX+nQ9h
5.5 fw signify pubkey: RWTdVOhdk5qyNktv0iGV6OpaVfogGxTYc1bbkaUhFlExmclYvpJR/opO
5.5 pkg signify pubkey: RWQQC1M9dhm/tja/ktitJs/QVI1kGTQr7W7jtUmdZ4uTp+4yZJ6RRHb5

Heartbleed not fixed in 5.5 by default

[cmdrbuzz]

Just an FYI, heartbleed is not fixed in 5.5 without extra (source) patches.

See http://www.openbsd.org/errata5...

  002: SECURITY FIX: April 8, 2014 All architectures
Missing bounds checking in OpenSSL's implementation of the TLS/DTLS heartbeat extension (RFC6520) which can result in a leak of memory contents.
A source code patch exists which remedies this problem.

Re:Heartbleed not fixed in 5.5 by default

[Anonymous Coward]

Can't you just do apt-get upgrade or whatever the equivalent OpenBSD alternative is?

Re:Heartbleed not fixed in 5.5 by default

[rubycodez]

patching openbsd is usually this dance:

1. wget or whatever to download the patch
2. best practice, use "signify" to check signature
3. cd /usr/src and apply patch with patch -p0 my_patch.txt
4. make obj; make; make install

Re:Heartbleed not fixed in 5.5 by default

[rubycodez]

oh, slashdot filter knocked out the < sign; nice going for a supposed geek tech forum eh?

Re:Heartbleed not fixed in 5.5 by default

[Anonymous Coward]

This is how you patch OpenBSD these days:
1. openup
2. profit

Shock and horror, no "???" step.
Seriously, that is how easy it is.
stable.mtier.org look it up.

Re:Heartbleed not fixed in 5.5 by default

[machine321]

A third party has created an auto-update app.

https://stable.mtier.org/

Re:Heartbleed not fixed in 5.5 by default

[Anonymous Coward]

WTF, version 5.5 has been released yesterday but it doesn't include patches from march and requires you to compile suff on a production host from day 1? how is this possible?

Re:Heartbleed not fixed in 5.5 by default

[Anonymous Coward]

If the default install were affected, the release might have been delayed to fix the issue. However, Heartbleed and other errata only affect certain services which must be manually enabled by the user/admin, so one is assumed to be competent enough to patch one's shit before deploying.

Re:Heartbleed not fixed in 5.5 by default

[iggymanz]

some caveats, that only does i386 and amd64. the package manager in openbsd automatically updates packages anyway, as for the openbsd binaries despite what that mtier.org says it's very simple and fast to update, in less than four minutes I had applied all outstanding patches to a system I brought up today.

Re:Heartbleed not fixed in 5.5 by default

[iggymanz]

by "automatic" I mean you type in pkg_add -u and it then updates all packages that have updates

I wonder whether DJB will be trying it out

[ConstantineM]

I just tweeted him to ask if he'll be switching back to OpenBSD now. :-)

https://twitter.com/Mcnst/stat...

(DJB is known as @hashbreaker on Twitter.)

Re:Why not try it?

[i kan reed]

Break easy compared to machine code in some specific way?

Scheduled Release Dates... yes, really

[Anonymous Coward]

Yes, really. Here I provide you a summary of some regular release dates:

Gnome - March (version number increases by .2)
Ubuntu - towards end of April (LTS if this is an even-numbered year)
OpenBSD - May 1st (or, historically and occasionally, May 19th)
GNOME - September (version number increases by .2)
Ubuntu - towards end of October (hence why version numbers end with "10", it is the 10th month)
OpenBSD - November 1st

Firefox: New release every whenever-they-feel-like-it not-very-long
Debian: New release every whenever-they-feel-like-it yes-very-long

I'm sure there are other projects with regular schedules... I'd appreciate any reply comments about other major projects with known regular release dates.

Some notes related to Ubuntu:
Ubuntu has a history of releasing very 6 months. Mark Shuttleworth of Canonical (who releases Ubuntu) has expressed desire to synchronize with other projects:
Mark Shuttleworth: The Art of Release
More recently, he may have drunk some of Mozilla's Kool Aid, though
Mark Shuttleworth: Let's Go Faster...
discusses possibly turning Ubuntu into a "rolling release" cycle.

Anyway, getting back to OpenBSD, Theo seems quite dedicated to releasing the software when it is expected, and describes it as a result of their carefully controlled development process. (Even before their semi-annual release schedule, they had an annual release on December 1st. So, when they did change their schedule to release on November 1st, they were ahead of their old schedule.) So, they have demonstrated that they are carefully able to release on time. Slashdot Article on OpenBSD release process, Discussion on OpenBSD release cycle. Development is also discussed in the video at BSDNow.tv: Doing It de Raadt Way (which interviews de Raadt starting about 8min7sec into the show).

So, they stick to their schedule well. But why a semi-annual schedule? In Kernel Trap interview with Theo, Theo says, "We have a six month cycle for many reasons. First off, and most important to me personally, it is just the right length so that I do not kill myself."

OpenBSD + TrueCrypt MP3 Player / Ripper

[Anonymous Coward]

Give me an MP3 player which has the following features:

1. OpenBSD
2. TrueCrypt - choice of encrypting all of device with 1st run and in settings
3. Rip from any device - an extension to the device (like the front part of ST:TNG ship's dish which separates for example) which allows CDs to be inserted and ripped on the fly without a computer connection, and the ability to plug into any electronic device which has the ability to contain audio files, scan for, and rip any audio files - all with the option to convert them to a format of your choosing
4. Complete support of as many audio/image/video codecs as possible.
5. Nothing about the device should be proprietary, neither hardware or software.

Before you say, "Why would you want to use a device with the MP3 format?" As #4 points out, and you should really know unless you're trolling, if you look at all of the MP3 players currently for sale, most support many audio, image (JPG and more) and sometimes several video formats.....

Re:OpenBSD + TrueCrypt MP3 Player / Ripper

[Anonymous Coward]

I'm not sure about your other points, but an OpenBSD installation can be fully encrypted from the get-go with softraid(4). TrueCrypt is not in the ports tree as far as I can tell.

Re:Why not try it?

[metrix007]

You use the same tools the scripts use. Ifconfig.

Choose a better distro and things wont be so obfuscated.

Re:Why not try it?

[just_another_sean]

/sbin/ifconfig

It's not just for listing!

Re:Why not try it?

[jones_supa]

Not in any specific way. For example when a called subprogram returns an unexpected result, or a result in an unexpected format. Also when the script interpreter is upgraded, it might break something. Heck, sometimes the problem is caused by something silly like a space in a file name.

Re:Why not try it?

[i kan reed]

That is to say: it's software.

/. IS a geek tech forum

[ConstantineM]

patch -p0 < 005_openssl.patch.sig

Signed packages!

[aNonnyMouseCowered]

No, the biggest thing for me is the signed packages. For a security-focused distribution, the lack of signed packages seemed quite ironic.

Wayland

[unixisc]

Does OBSD include support for Wayland in 5.5? Is it stated for a future version, or have they decided to stay w/ X11?

Re:Wayland

[iggymanz]

no it doesn't, just X

so far wayland has less features than X, but who knows about the future

Re:Why not try it?

[jones_supa]

Not really. Machine code is more robust and, as I said, faster. There might still be other good reasons to use scripts, I'm not denying that. They are easier to maintain, for example.

Re:Why not try it?

[Anonymous Coward]

Good thing we have systemd to bring all of that Windows goodness to Linux.

OpenBSD breaking old binaries

[Anonymous Coward]

Granted, this release does break things a bit further than most, as mentioned by post about time_t incompatibility. For example, the password database may need to be updated (by running a new version of pwd_mkdb , as mentioned by a forum post: updating past 5.4 current flag day). So, that database is a binary update that is required.

It is also true that this is a case of the operating system requiring that binary executable files to be re-compiled. However, breaking compatibility with older executable files is actually something that is pretty much always happening between OpenBSD releases. So that's not at all unusual.

Let me explain a bit about OpenBSD compatibility between versions: The operating system and pre-built ports are generally filled with dependencies of libraries, and seemingly little to no tolerance for different versions. This means that most binary executables will be designed for a specific version of the OS. Using binary executables for any other version of the OS will break things terribly.

The end of OpenBSD FAQ 5: section on OpenBSD Flavors states, “It is important to understand that OpenBSD is an Operating System, intended to be taken as a whole, not a kernel with a bunch of utilities stuck on.” The kernel and other software is meant to match. http://www.openbsd.org/faq/faq15.html#NoFun (gotta just love the name of that hyperlink anchor) is about "using a system and ports tree which are not in sync." In other words, if the "system" (e.g., the kernel) and the "ports tree" (i.e., "other software") are different versions, then you're likely doomed. Upgrading software to the "-stable" branch is generally an exception, meaning that it is okay as long as you're still within the same version number. Upgrading to a new -release involves upgrading to a new version number, and that's when hopelessness starts to seep in. Upgrading to the "snapshots" release, involving "-current" source code, is also likely to cause some incompatibilities. (Possibly not. But the likelihood increases over time, especially as soon as something common like libc ends up getting an updated version number.) The only intended and recommended way to deal with these problems is to just avoid them altogether, by upgrading absolutely everything (operating system and all the software) at once, which keeps things in sync.

This does get discussed further at ][CyberPillar][: updating OpenBSD via binaries in the subsection titled "Code sync requirement (and ramifications of this requirement)", which describes this issue more and provides additional hyperlinks.

This is why every single "port"/"package" (third party software) needs to be updated (for the easiest experience) with every applied OpenBSD version upgrade (in order to have the easiest experience). There is no "let's upgrade one piece of software today, and then upgrade another piece of software next week". It's an all-or-nothin' deal.

Did you read about the latest feature added by some piece of software? Sure, you can download a pre-built binary executable file from the "snapshots" release to try out that new software. If the software runs, great. If there's a problem with needing another library, then there's another solution using pre-built binary executables. Simply make sure to upgrade your entire friggin' operating system to the "-current" (a.k.a. unstable/testing branch), and all other software, all at the same time. That should avoid version compatibility issues.

Sound too challenging? Then break out your compiler and compile from source, and handle any dependency/version confl

Re:Why not try it?

[evilviper]

You use the same tools the scripts use. Ifconfig.

Nope, doesn't work on Linux. NetworkManager or some other daemon will come along and overwrite your manual ifconfig change in short order.