Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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"

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

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.

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.

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...

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.

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.

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.

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.

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.

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.

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 [gnu.org] 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?

That is EXACTLY what he is saying given his comments regarding LLVM.
Referring to this [gnu.org] 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.

"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.

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 Met

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 n

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.

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).

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 Andro

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.)

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.

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 t

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).

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 t

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.

002: SECURITY FIX: April 8, 2014 All architecturesMissing 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.

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.