Slashdot Mirror

OpenBSD also has support for SMEP/SMAP on newer Intel processors in addition to NX, which at least makes arbitrarily poking around memory a little more risky.

http://freshbsd.org/search?pro...
http://freshbsd.org/search?pro...

OpenBSD also has support for SMEP/SMAP on newer Intel processors in addition to NX, which at least makes arbitrarily poking around memory a little more risky.

http://freshbsd.org/search?pro...
http://freshbsd.org/search?pro...

You can also track the changes in a somewhat friendlier format using FreshBSD. Full commit messages (up to a point) upfront, more useful Atom feed, breakdown by committer etc.

Changes so far to OpenSSL 1.0.1g since the 11th include:

• Splitting up libcrypto and libssl build directories
• Fixing a use-after-free bug
• Removal of ancient MacOS, Netware, OS/2, VMS and Windows build junk
• Removal of “bugs” directory, benchmarks, INSTALL files, and shared library goo for lame platforms
• Removal of most (all?) backend engines, some of which didn’t even have appropriate licensing
• Ripping out some windows-specific cruft
• Removal of various wrappers for things like sockets, snprintf, opendir, etc. to actually expose real return values
• KNF of most C files
• Removal of weak entropy additions
• Removal of all heartbeat functionality which resulted in Heartbleed

See also:

Do not feed RSA private key information to the random subsystem as entropy. It might be fed to a pluggable random subsystem.... What were they thinking?!

So far as all the "won't this introduce more bugs than it fixes" comments go, this is a recurring argument I have at work. I am of the "clean as you go", "refactor now" school.
Everyone else says "If it works don't fix it"(IIWDFI), "don't rock the boat" etc.
Heartbleed is what happens when the IIWDFI attitude wins. Bugs lurk under layers of cruft, simple changes become nightmares of wading through a lava flow of wrappers around hacks around bodges.
Whenever anyone says IIWDFI, remind them that testing can only find a small proportion of possible bugs, so if you can't see whether it has bugs or not by reading the code, then no matter how many test cases it passes, it DOESN'T WORK.

Do you know why Microsoft only releases patches once a month for its operating systems?

Do you know that Microsoft releases patches for its operating systems once a week, specifically every Tuesday? Yes, the Wikipedia article implies once a month, except that really isn't the case any more -- they're deployed weekly, except for critical/uber-important security holes, which are pushed out ASAP. Things like "general security issues", even for older OSes like XP, are still pushed out weekly.

This is the 2nd thread I've seen from you talking about Microsoft as if you know the place. I get the impression you may have worked there or knew someone who worked there who gave you a lot of misinformation. I worked there for a total of 7 years (non-linearly; 2 years as a contractor, then many years later, 5 years as a FTE) and it disappoints me to see so much misinformation being spread. :(

As for your opinions on Firefox release schedules, for corporate environments your opinion is spot on - the Firefox release model does not work well in corporate environments (at my past job we used Firefox 3.x exclusively, despite Firefox double-digit builds being available, because upgrading would have caused more issues than sticking with what worked), and their "Enterprise" edition is not realistic/pragmatic in the least. But that has absolutely nothing to do with which browser is "used the most".

As for product which lack updates indicating stability or reliability - this is often nonsense spewed forth from mouths of people who are managerial and not actual engineers. Real engineers know that deep down inside there are always bugs, and that updates to fix those are always warranted, no matter how long it has been since the previous update. Here's a good example of a bug that lasted almost 20 years; does this indicate stability to you? It shouldn't.

We're really looking forward to the changes that FreeBSD 8.0 will bring, as it includes ZFS v13, removes the 2 GB kmem barrier

Already in 7.1.

Yeah, the latest ZFS is in 8-CURRENT; it's far too new for RELENG_7, never mind RELENG_7_1.

If you don't want to bother with the commit mailing lists, you can track this stuff using FreshBSD. You could have an RSS feed which tracks commits to RELENG_7 mentioning ZFS in the message, if you wanted to.

List: openbsd-misc
Subject: Re: Linux Driver Violates BSD License
From: "Constantine A. Murenin" [...]
BTW, since this is misc@openbsd.org, people might be interested to
know about the history of the licensing terms of ath(4) in OpenBSD.

OpenBSD's ath(4) consists of two parts:
1. a driver, copyrighted by Sam Leffler of FreeBSD
2. a HAL, copyrighted by Reyk Floeter of OpenBSD

What Theo explained above concerns the OpenHAL code. OpenHAL is the
Linux name for madwifi driver connected with reyk's entirely free and
open source ath(4) HAL code.

Sam originally put a dual BSD/GPL licence onto his driver code.
Reyk always put a BSD-style licence onto his HAL code.

At the time OpenHAL was forked from OpenBSD, OpenBSD's ath(4)
_driver_, but _not the HAL_, was dual licensed.

As already mentioned, OpenBSD's ath(4) HAL, written by Reyk, was
_never_ dual licensed. See the history on /sys/dev/ic/{ar52{10,11,12}{.c,{reg,var}.h},ar5xxx .{c,h}}.
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ ic/#ar5210.c

Few months ago, Sam changed the licence of _his_ code to a 2-clause
BSD licence. Sam had every right to do so, because he was and is the
only copyright holder of that code, as the licence header of the
driver file indicates, in FreeBSD, OpenBSD etc.

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ ath/if_ath.c#rev1.170
http://www.freshbsd.org/2007/06/06?project=freebsd &committer=sam

Reyk committed Sam's changes to OpenBSD the same day, so now,
OpenBSD's ath(4) is _entirely_ BSD-licensed, with no alternative
licensing available.

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ ic/ath.c#rev1.64
http://www.freshbsd.org/2007/06/06?project=openbsd &committer=reyk

However, what Jiri Slaby does in his diff is simply outrageous. He
changes the licensing terms of the code _he does not own_ _at his own
will_. A clear copyright violation.

As I can see from that diff on LKML, Jiri Slaby doesn't even have his
name as the copyright holder in many of the ath5k files that he tries
to change the licensing terms of. In other files, he is not the only
author, so he can't change the terms unless _all_ other copyright
holders agree to the new terms.
I'm very upset that certain people think they can get away with such a
blatant disrespect of the copyright law. I trust that this violation
won't be left unnoticed.

What I personally don't understand, however, is that if Jiri Slaby
thinks that he can simply change the licence of someone's code without
explicit agreement of that someone, then why on earth does he think
that changing the licence to a more restrictive one will offer him any
protections, as, presumably following his logic, other people could
later change the licence to whatever they feel like, in the very same
illegal manner as he did in the first place. IMHO, that is the real
question that he has to answer.

Constantine.

List: openbsd-misc
Subject: Re: Linux Driver Violates BSD License
From: "Constantine A. Murenin" [...]
BTW, since this is misc@openbsd.org, people might be interested to
know about the history of the licensing terms of ath(4) in OpenBSD.

OpenBSD's ath(4) consists of two parts:
1. a driver, copyrighted by Sam Leffler of FreeBSD
2. a HAL, copyrighted by Reyk Floeter of OpenBSD

What Theo explained above concerns the OpenHAL code. OpenHAL is the
Linux name for madwifi driver connected with reyk's entirely free and
open source ath(4) HAL code.

Sam originally put a dual BSD/GPL licence onto his driver code.
Reyk always put a BSD-style licence onto his HAL code.

At the time OpenHAL was forked from OpenBSD, OpenBSD's ath(4)
_driver_, but _not the HAL_, was dual licensed.

As already mentioned, OpenBSD's ath(4) HAL, written by Reyk, was
_never_ dual licensed. See the history on /sys/dev/ic/{ar52{10,11,12}{.c,{reg,var}.h},ar5xxx .{c,h}}.
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ ic/#ar5210.c

Few months ago, Sam changed the licence of _his_ code to a 2-clause
BSD licence. Sam had every right to do so, because he was and is the
only copyright holder of that code, as the licence header of the
driver file indicates, in FreeBSD, OpenBSD etc.

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ ath/if_ath.c#rev1.170
http://www.freshbsd.org/2007/06/06?project=freebsd &committer=sam

Reyk committed Sam's changes to OpenBSD the same day, so now,
OpenBSD's ath(4) is _entirely_ BSD-licensed, with no alternative
licensing available.

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ ic/ath.c#rev1.64
http://www.freshbsd.org/2007/06/06?project=openbsd &committer=reyk

However, what Jiri Slaby does in his diff is simply outrageous. He
changes the licensing terms of the code _he does not own_ _at his own
will_. A clear copyright violation.

As I can see from that diff on LKML, Jiri Slaby doesn't even have his
name as the copyright holder in many of the ath5k files that he tries
to change the licensing terms of. In other files, he is not the only
author, so he can't change the terms unless _all_ other copyright
holders agree to the new terms.
I'm very upset that certain people think they can get away with such a
blatant disrespect of the copyright law. I trust that this violation
won't be left unnoticed.

What I personally don't understand, however, is that if Jiri Slaby
thinks that he can simply change the licence of someone's code without
explicit agreement of that someone, then why on earth does he think
that changing the licence to a more restrictive one will offer him any
protections, as, presumably following his logic, other people could
later change the licence to whatever they feel like, in the very same
illegal manner as he did in the first place. IMHO, that is the real
question that he has to answer.

Constantine.

Knowing a bit about what you're doing is fairly important with ports, especially when dealing with complex upgrades like Gnome; dependency tracking's a lot less anal than apt/dpkg. This is good when you've got something installed from outside ports, and works nicely when you just want to pick and choose a few things to update (say, after running portaudit or tracking an interesting update on FreshPorts/commit logs).

Geeky FreeBSD users need a desktop too, and now we have three variants to choose from; FreeBSD, PC BSD and DesktopBSD. YMMV; just because it's aimed at desktops doesn't mean it's aimed at yours or your mother's.