The "funky address style" is just a way of expressing the much longer IPv6 addresses in a way that's 1) not onerous to enter manually, for the cases where you need to do this and 2) visually and syntactically different from existing IPv4 addresses.
At one point (~1994) the IPng working group in the IETF was contemplating 64-bit addresses, but roughly, they decided to go to 128 bits with the reasoning that they didn't want to repeat another major transition a few years down the road. (Think long-term...I think the goal was for at least a 20-year lifetime for the protocol.) Well, it's taken quite a bit longer for IPv6 to be widely adopted than was once originally believed, for a variety of reasons, but that was the rationale.
IPv6 got its version number from the value 6 assigned to it in the IP header (the "header version" field is the first four bits). The value 5 was already assigned to an experimental and mostly-forgotten network protocol called ST-II (I think). So "IPv5" was never really an option.
Matt is still on some of the mailing lists. I've seen him recently (past several days) involved in some very deep technical discussions.
I personally think that even if Matt had not lost his FreeBSD commit bit, he might have started DragonFly anyways. DF is an excellent vehicle for trying out some new architectural approaches to problems that are just fundamentally different from FreeBSD 5 was/is doing.
No. The patches are incorporated at the same time when advisories are released. I'm assuming they list them in the release notes just to imply that since you're using 4.9 you don't have to worry about all the security issues which were discovered in 4.8
Right. The release notes list changes between released versions, and some of those changes come about as the result of security vulnerabilities that have been discovered and fixed. If you look at the release notes for one of the development branches (e.g. 4-STABLE or 5-CURRENT) between releases, you can see items such as security advisories listed in more-or-less real-time (usually one of us tries to get them into the release notes or errata within about a day of being issued).
Actually, it's my experience that the patches are usually in the source tree well before an advisory is issued, depending on what branch you're tracking.
Let's ignore, for the moment, any bikeshedding over the name STABLE and the stability of the code.
The reason for the sentences in question (I had a small part in writing them) was simply this: PAE is a fairly young (in the 4.X series) feature that touches a lot of bits in the kernel (yes, even if it's not enabled). When it was first committed, it caused a number of problems (well-documented on the mailing lists), but they seem to have been fixed. If we thought there were any major problems remaining in this area, we wouldn't have released. However it's an undeniable fact that PAE in 4.X hasn't had a lot of testing time compared to most of the rest of the kernel, and this bears a bit of consideration.
I believe that for the vast majority of users (myself included) 4.9 works just fine. (I run a mix of 4.9-STABLE and 5.1-CURRENT on various laptops, desktops, and non-critical servers.) If you're really one of the most conservative users, you probably wouldn't jump on the new release bandwagon anyways, and would spend some time evaluating 4.9 (regardless of PAE, or what anyone on the release engineering team says) before deploying it in some mission-critical environment.
FYI: That document is really the release notes for 4-STABLE, and is a work in progress. I still have a bunch of things to do to get it caught up to reality.
> A third, pkg_version, is like port_version but much faster.
Actually, pkg_version is in the base system, portversion is the program that comes with portupgrade.
portversion is faster because it relies on a database of installed packages, whereas pkg_version depends only on knowing what ports are installed (via pkg_info) plus either an up-to-date ports tree or an INDEX file. Both are useful IMHO.
But I agree with the general sentiment...the whole portupgrade package is extremely useful, and it's one of the first things that goes on a system that I install if I think I'll ever be upgrading ports on it.
It's true that FreeBSD uses CVS, but we also use Perforce for some out-of-tree work that later gets merged back into CVS. Our experience has been that CVS doesn't work real well for long-running development branches that need to get resynchronized periodically with the CVS HEAD.
(Examples of long-running branches in our Perforce tree are those for the SMPng project, and for works-in-progress for newer architectures such as ia64, amd64, etc.).
Scott is trying a slightly different model for 5.1. You might have seen where we did two BETA releases earlier in May. These occupy the same places on the schedule that the first two RC snapshots did on some other releases. The idea is that the thing called 5.1-RC1 should be really really really close to what we'd ship for the release, with almost all of the bugs (that we're able to catch anyways) ironed out during 5.1-BETA1 and 5.1-BETA2. Also, 5.1-RC1 was/is released from the CVS branch to be used for the release.
Most of the process changes affect only committers (I think)...I'd expect that the only changes visible to most users would be the names of the snapshots.
1. It takes time to prepare security advisories. The security-officer team (of which I am not a member) likes to check facts and test things before issuing them.
2. Note that this happened over a weekend.
3. The timing of events was largely driven by public disclosure of a vulnerability.
From where I stand (release engineering team) the security-officer (Jacques Vidrine) and his team did a pretty darned good job under the circumstances. Greg Shapiro of Sendmail, Inc. helped by committing the appropriate changes to ten (count 'em, ten) different CVS branches.
It's the second ISO image (for example, 5.0-RELEASE-i386-disc2.iso). You'll usually find it next to the disc1.iso and miniinst.iso images, for all five platforms (i386, alpha, pc98, ia64, sparc64).
The developer status reports were all written just before 5.0-RELEASE (when it was still "anticipated"). It so happens that the person who collated all of the reports is the same person who managed much of the 5.0-RELEASE process, and partially as a result, the whole collection of status reports didn't get released until after 5.0.
Seriously, one person (me) writes most of the release notes, and the base system is more than enough to: 1) Keep that person busy and 2) Make for a really long document.
GNOME, KDE, and OpenOffice all have their own Web pages that can be found without too much effort, and they do a far better job describing the most recent progress with these packages than could a couple of lines in the release notes.
pchar will attempt to find the bandwidth of links along a path. But if a link is congested (as it might be if it was oversubscribed), pchar will only tell you this indirectly, via the drops and average queueing delays. I don't think that it'll be all that useful in this scenario, although it might tell some interesting things about the ISP's links.
(I wrote pchar, and I now work with the author of pathchar, if that counts for anything. Thanks for the reference, by the way!)
As the person who committed the 4.6 release documentation to the FreeBSD Web site, I can pretty authoritatively say why these files were there in advance of the release. The reason is so that when Murray (or whomever else) makes the release announcement, the pages pointed to by the release announcement are already on the main Web site. It basically makes it easier for users to find the information they need.
But these pages had (have) no inbound links to them at all. The fact that some people had to do some "creative surfing" to actually find the release documentation should really have been a clue that the release wasn't ready yet. If we *had* released, wouldn't it be kind of silly to keep this information obscured?
This wouldn't be such a big deal except we had a very similar situation in 4.5 with someone posting a bogus release announcement to Slashdot (and having it slip past the editors). I really hope there isn't a third time.
Oh yes. I'm also the person who wrote the so-called "delays and excuses" message. I didn't see it as making excuses for anything. I wanted to give our users some explanation as to why things would be delayed.
Peace,
Bruce A. Mah (Member, FreeBSD Release Engineering Team)
FFS (the filesystem used by the BSDs) is designed not to require defragmenting, not in the sense of Microsoft FAT-type filesystems. (FFS uses different algorithms for laying the data out on disk, which I unfortunately can't explain well enough to be of use.) So it's kind of a non-issue here.
RAM fragmentation: "Fragmentation" is a vastly over-used word in the computer world. As applied to filesystems, it means a suboptimal layout of disk blocks on the disk, therefore requiring lots of seeks to read/write the data blocks. RAM disks are random access, and it generally takes the same amount of time to grab a disk block from a RAM disk no matter where it is. The word "fragmentation" can be applied to memory but in a different context that what you cited.
Slashdot Mirror
Wait a minute...how do we know you're the real Michael Lucas? :-)
The "funky address style" is just a way of expressing the much longer IPv6 addresses in a way that's 1) not onerous to enter manually, for the cases where you need to do this and 2) visually and syntactically different from existing IPv4 addresses.
At one point (~1994) the IPng working group in the IETF was contemplating 64-bit addresses, but roughly, they decided to go to 128 bits with the reasoning that they didn't want to repeat another major transition a few years down the road. (Think long-term...I think the goal was for at least a 20-year lifetime for the protocol.) Well, it's taken quite a bit longer for IPv6 to be widely adopted than was once originally believed, for a variety of reasons, but that was the rationale.
IPv6 got its version number from the value 6 assigned to it in the IP header (the "header version" field is the first four bits). The value 5 was already assigned to an experimental and mostly-forgotten network protocol called ST-II (I think). So "IPv5" was never really an option.
Matt is still on some of the mailing lists. I've seen him recently (past several days) involved in some very deep technical discussions.
I personally think that even if Matt had not lost his FreeBSD commit bit, he might have started DragonFly anyways. DF is an excellent vehicle for trying out some new architectural approaches to problems that are just fundamentally different from FreeBSD 5 was/is doing.
No worries. It would have been nice to have had more detail in the release announcement but we usually try to keep them short.
No. The patches are incorporated at the same time when advisories are released. I'm assuming they list them in the release notes just to imply that since you're using 4.9 you don't have to worry about all the security issues which were discovered in 4.8
Right. The release notes list changes between released versions, and some of those changes come about as the result of security vulnerabilities that have been discovered and fixed. If you look at the release notes for one of the development branches (e.g. 4-STABLE or 5-CURRENT) between releases, you can see items such as security advisories listed in more-or-less real-time (usually one of us tries to get them into the release notes or errata within about a day of being issued).
Actually, it's my experience that the patches are usually in the source tree well before an advisory is issued, depending on what branch you're tracking.
Let's ignore, for the moment, any bikeshedding over the name STABLE and the stability of the code.
The reason for the sentences in question (I had a small part in writing them) was simply this: PAE is a fairly young (in the 4.X series) feature that touches a lot of bits in the kernel (yes, even if it's not enabled). When it was first committed, it caused a number of problems (well-documented on the mailing lists), but they seem to have been fixed. If we thought there were any major problems remaining in this area, we wouldn't have released. However it's an undeniable fact that PAE in 4.X hasn't had a lot of testing time compared to most of the rest of the kernel, and this bears a bit of consideration.
I believe that for the vast majority of users (myself included) 4.9 works just fine. (I run a mix of 4.9-STABLE and 5.1-CURRENT on various laptops, desktops, and non-critical servers.) If you're really one of the most conservative users, you probably wouldn't jump on the new release bandwagon anyways, and would spend some time evaluating 4.9 (regardless of PAE, or what anyone on the release engineering team says) before deploying it in some mission-critical environment.
FYI: That document is really the release notes for 4-STABLE, and is a work in progress. I still have a bunch of things to do to get it caught up to reality.
> A third, pkg_version, is like port_version but much faster.
Actually, pkg_version is in the base system, portversion is the program that comes with portupgrade.
portversion is faster because it relies on a database of installed packages, whereas pkg_version depends only on knowing what ports are installed (via pkg_info) plus either an up-to-date ports tree or an INDEX file. Both are useful IMHO.
But I agree with the general sentiment...the whole portupgrade package is extremely useful, and it's one of the first things that goes on a system that I install if I think I'll ever be upgrading ports on it.
It's true that FreeBSD uses CVS, but we also use Perforce for some out-of-tree work that later gets merged back into CVS. Our experience has been that CVS doesn't work real well for long-running development branches that need to get resynchronized periodically with the CVS HEAD.
(Examples of long-running branches in our Perforce tree are those for the SMPng project, and for works-in-progress for newer architectures such as ia64, amd64, etc.).
Scott is trying a slightly different model for 5.1. You might have seen where we did two BETA releases earlier in May. These occupy the same places on the schedule that the first two RC snapshots did on some other releases. The idea is that the thing called 5.1-RC1 should be really really really close to what we'd ship for the release, with almost all of the bugs (that we're able to catch anyways) ironed out during 5.1-BETA1 and 5.1-BETA2. Also, 5.1-RC1 was/is released from the CVS branch to be used for the release.
Most of the process changes affect only committers (I think)...I'd expect that the only changes visible to most users would be the names of the snapshots.
1. It takes time to prepare security advisories. The security-officer team (of which I am not a member) likes to check facts and test things before issuing them.
2. Note that this happened over a weekend.
3. The timing of events was largely driven by public disclosure of a vulnerability.
From where I stand (release engineering team) the security-officer (Jacques Vidrine) and his team did a pretty darned good job under the circumstances. Greg Shapiro of Sendmail, Inc. helped by committing the appropriate changes to ten (count 'em, ten) different CVS branches.
It's the second ISO image (for example, 5.0-RELEASE-i386-disc2.iso). You'll usually find it next to the disc1.iso and miniinst.iso images, for all five platforms (i386, alpha, pc98, ia64, sparc64).
The developer status reports were all written just before 5.0-RELEASE (when it was still "anticipated"). It so happens that the person who collated all of the reports is the same person who managed much of the 5.0-RELEASE process, and partially as a result, the whole collection of status reports didn't get released until after 5.0.
Call me an optimist, but yeah, I *am* hoping there isn't a fourth time. :-)
We had to draw the line somewhere. :-)
Seriously, one person (me) writes most of the release notes, and the base system is more than enough to: 1) Keep that person busy and 2) Make for a really long document.
GNOME, KDE, and OpenOffice all have their own Web pages that can be found without too much effort, and they do a far better job describing the most recent progress with these packages than could a couple of lines in the release notes.
pchar will attempt to find the bandwidth of links along a path. But if a link is congested (as it might be if it was oversubscribed), pchar will only tell you this indirectly, via the drops and average queueing delays. I don't think that it'll be all that useful in this scenario, although it might tell some interesting things about the ISP's links.
(I wrote pchar, and I now work with the author of pathchar, if that counts for anything. Thanks for the reference, by the way!)
As the person who committed the 4.6 release documentation to the FreeBSD Web site, I can pretty authoritatively say why these files were there in advance of the release. The reason is so that when Murray (or whomever else) makes the release announcement, the pages pointed to by the release announcement are already on the main Web site. It basically makes it easier for users to find the information they need.
But these pages had (have) no inbound links to them at all. The fact that some people had to do some "creative surfing" to actually find the release documentation should really have been a clue that the release wasn't ready yet. If we *had* released, wouldn't it be kind of silly to keep this information obscured?
This wouldn't be such a big deal except we had a very similar situation in 4.5 with someone posting a bogus release announcement to Slashdot (and having it slip past the editors). I really hope there isn't a third time.
Oh yes. I'm also the person who wrote the so-called "delays and excuses" message. I didn't see it as making excuses for anything. I wanted to give our users some explanation as to why things would be delayed.
Peace,
Bruce A. Mah
(Member, FreeBSD Release Engineering Team)
FFS (the filesystem used by the BSDs) is designed not to require defragmenting, not in the sense of Microsoft FAT-type filesystems. (FFS uses different algorithms for laying the data out on disk, which I unfortunately can't explain well enough to be of use.) So it's kind of a non-issue here.
RAM fragmentation: "Fragmentation" is a vastly over-used word in the computer world. As applied to filesystems, it means a suboptimal layout of disk blocks on the disk, therefore requiring lots of seeks to read/write the data blocks. RAM disks are random access, and it generally takes the same amount of time to grab a disk block from a RAM disk no matter where it is. The word "fragmentation" can be applied to memory but in a different context that what you cited.
Certainly, that's your right. But the proceeds from the CD-ROM sales (from whichever company is selling them) help fund development.