NetBSD is once again going to be a mentoring organization. A number of project ideas is available here, though applicants can (and should) of course also come up with their own ideas.
From what I read here, I understand that 'pkg_add -r' automatically updates the given package and all of its dependencies. It's not quite clear to me, though, what exactly that means. After upgrading a given package, does it: (a) upgrade each package that depends on this one to the latest available binary package? (b) upgrade only those packages that rely on the newer version (for example, for ABI changes) but leave others (the ones that will work perfectly fine with the older version as well as the newer) alone? (c) only update the given package and reshuffle dependencies so that all packages that used to depend on foo-old now depend on foo-new?
(a) has the following problems: what if binary packages for all dependents are simply not available? Leave the old packages in place? What if it's known that the depending package will not work with the newer to-be-installed one?
(b) would be great, but is very difficult, I think. It requires that the binary package contains information about a large number of other packages and how they may or may not work together.
(c) is trivial (for pkgsrc (not binary packages) that would be 'pkg_add -u'), but has the same problems as 'make replace'.
pkgsrc approaches (b) by the use of so-called recommended vs required dependencies. (Again, for pkgsrc, though binary packages built with IGNORE_RECOMMENDS can be forced to be installed.)
If I want to upgrade, say, kde3 (*shudder*) from binary packages, I'd simply run 'pkg_add -u kde3' -- ie, I'd start at the leaf package and let it pull in all dependencies. This is not the same as starting with a package somewhere in the middle of your dependency-tree, but it has a much clearer solution. Rippling downwoards through a dependency-tree from the middle is obviously difficult ('make update' does that if building from pkgsrc instead of using binary packages).
I may be mistaken, but I don't think that NetBSD's pkg_add has the functionality to do that -- presumably just b/c people haven't figured out what The Right Thing To Do is exactly. On the mailing lists, pkg_chk and pkg_comp are usually suggested to perform these tasks.
Binary packages will be uploaded as soon as the various bulk-builds on the different operating systems and NetBSD ports have completed. This takes a while on some older platforms, though I'd expect some of the faster platforms to soon upload.
The article does not mention anywhere that ``MIT Urges Brazilian Government to Use Linux'',. MIT seems to suggest to use ``Free software''. I wish people would stop equating the two; there are many, many other free software or open source projects that are not linux, and I believe it's harmful to the overall open source community to continue to enforce the notion that Open Source == Linux (and linux only).
Why is OpenBSD called OpenBSD ? because it was the first BSD to make its CVS tree accessible for everyone. That's right, anyone can subscribe to source-changes and see the commit messages. And anyone can get the sources.
You seem to be stating that the other BSD's didn't do this or at least not until OpenBSD did it first. Granted, I wasn't around at the time OpenBSD forked off of NetBSD, but looking at this message it would seem that NetBSD's commit messages were public quite a while before OpenBSD existed. It would also seem that at that, anybody could get the sources. Just FYI.
To give one example where a Live CD is incredibly useful: I recently used a custom NetBSD Live CD for a programming contest -- all machines at two locations needed to be absolutely identical and using a Live CD obliterates the hassle of installing a new OS or reconfiguring your current setup in any way -- just pop in the CD, boot, done. See this link and this link for details.
The latest binary packages currently available are built under 1.6.2 and should therefor run just fine under 1.6.x (including 1.6.0). Given that the 2.0 release is coming Really Really Soon Now (tm), it's a pretty safe assumption that after the freeze the binary packages from the new branch will be built under NetBSD 2.0. Of course a 2.0 kernel can run older binaries (if you have the necesary COMPAT options(4) in your kernel). In addition, pkg_add(1) will warn/complain/fail depending on the discrepancy of the version under which the binary package was built compared to the version you are running.
I'm quite certain that the overwhelming majority, if not all, of the talks and tutorials will be in English.
On another note, it might be worth pointing out that there are a lot of developers attending/speaking, so if you want to meet some of the people behind your favorite OS, this looks like a good opportunity.
There was a problem with the site being recreated from the xml sources using not-quite-up-to-date tools. That's quite unfortunate. Anyway, it's been fixed in the mean time.
It's hard to say (meaning, I haven't done my research) if DBSD's revisiting of the issue inspired the cleanup and release of pkgviews, or if that was proceeding quietly before Dillon-and-friends even thought to begin their stab.
Well, actually, it's quite easy to say:-) : DragonFlyBSD came into existence in July 2003. Package views, as noted above, were first presented by Alistair Crooks at EuroBSDCon 2002.
While it's not the merger of FreeBSD Ports, portage and fink, NetBSD's Packages Collection aka pkgsrc supports a large number of different operating systems (NetBSD, Darwin, FreeBSD, Irix, Linux, OpenBSD, Solaris), with support for more platforms (BSD/OS, HP-UX, AIX) in the works. Full Documentation here.
Yes, it can replace stuff in-line. But you better be aware of the side-effects. If the ABI of a given library has changed, ``make replace'' will really really mess up your system. This is, obviously, not a limitation within pkgsrc, but simply in the way shared libraries work.
However, if you're sure that all dependencies will be able to deal with the new package (say a shlib minor version bump, in theory at least, should not break other packages), then ``make replace'' can save you a lot of time rebuilding dependencies.
You can find some more details at http://www.netbsd.org/Documentation/pkgsrc/binary. html. The nice thing is, they are quite configurable, so that you can run a bulk-build with xpkgwedge (to ensure that even X11 programs do not end up outside of/usr/pkg (or whatever your PREFIX is)) or with gcc-3 (if your OS or Port has not yet been switched to use gcc3 as the default system compiler) etc.
The bulk builds are run regularly on different ports, and the resulting binary packages are then uploaded to the ftp sites.
FWIW, NetBSD's pkgsrc was updated on Wed Sep 17 22:58:45 2003 UTC to include KDE 3.4.1, too. Binary packages will surely soon be available for download, but if you have a decent build-host for your packages, building from source will work without a hitch, too.
As usual, when this comes up, let's plug NetBSD's Packages Collection. ``pkgsrc'', as it's known, originally derived from FreeBSD's ports is available for a large number of platforms (Netbsd, of course, and then Darwin, FreeBSD, OpenBSD, Linux, Solaris and Irix), thus allowing system administrators who have to take care of more than one OS to take advantage of its strengths. So, uhm, sorry, but I'd also have to add my vote to the ``who needs portage'' camp.
While NetBSD is probably not the one referred to as ``that other OS'', it still holds that ``of course it runs [on] NetBSD'': binary packages for blender 2.28 will show up on the mirrors shortly -- pkgsrc has already been updated.
Hmm, while you _do_ have to get the source (as if that was a bad thing!), it's certainly very simple to update only the relevant parts. As the SA states, you do not need to update the entire system but can simply do:
# cd src
# cvs update -d -P -r netbsd-1-6 lib/libz/gzio.c
# cd lib/libz
# make USETOOLS=no cleandir dependall
# make USETOOLS=no install
(Similarly for the other advisories.) This is not really very difficult.
Slashdot Mirror
Briefly skimming the article in question... how exactly is Yahoo! involved in this?
The article's title is "YouTube suspends Egyptian blog activist's account". YouTube is not affiliated with Yahoo!.
NetBSD is once again going to be a mentoring organization. A number of project ideas is available here, though applicants can (and should) of course also come up with their own ideas.
Binary packages have been uploaded (so far) for:
NetBSD-2.0/amd64, NetBSD-2.0/i386, NetBSD-1.6.2/i386, NetBSD-2.0/sparc and IRIX64-6.5 (including PGP signed checksum files).
From what I read here, I understand that 'pkg_add -r' automatically updates the given package and all of its dependencies. It's not quite clear to me, though, what exactly that means. After upgrading a given package, does it: (a) upgrade each package that depends on this one to the latest available binary package? (b) upgrade only those packages that rely on the newer version (for example, for ABI changes) but leave others (the ones that will work perfectly fine with the older version as well as the newer) alone? (c) only update the given package and reshuffle dependencies so that all packages that used to depend on foo-old now depend on foo-new?
(a) has the following problems: what if binary packages for all dependents are simply not available? Leave the old packages in place? What if it's known that the depending package will not work with the newer to-be-installed one?
(b) would be great, but is very difficult, I think. It requires that the binary package contains information about a large number of other packages and how they may or may not work together.
(c) is trivial (for pkgsrc (not binary packages) that would be 'pkg_add -u'), but has the same problems as 'make replace'.
pkgsrc approaches (b) by the use of so-called recommended vs required dependencies. (Again, for pkgsrc, though binary packages built with IGNORE_RECOMMENDS can be forced to be installed.)
If I want to upgrade, say, kde3 (*shudder*) from binary packages, I'd simply run 'pkg_add -u kde3' -- ie, I'd start at the leaf package and let it pull in all dependencies. This is not the same as starting with a package somewhere in the middle of your dependency-tree, but it has a much clearer solution. Rippling downwoards through a dependency-tree from the middle is obviously difficult ('make update' does that if building from pkgsrc instead of using binary packages).
I may be mistaken, but I don't think that NetBSD's pkg_add has the functionality to do that -- presumably just b/c people haven't figured out what The Right Thing To Do is exactly. On the mailing lists, pkg_chk and pkg_comp are usually suggested to perform these tasks.
Binary packages will be uploaded as soon as the various bulk-builds on the different operating systems and NetBSD ports have completed. This takes a while on some older platforms, though I'd expect some of the faster platforms to soon upload.
The article does not mention anywhere that ``MIT Urges Brazilian Government to Use Linux'',. MIT seems to suggest to use ``Free software''. I wish people would stop equating the two; there are many, many other free software or open source projects that are not linux, and I believe it's harmful to the overall open source community to continue to enforce the notion that Open Source == Linux (and linux only).
You seem to be stating that the other BSD's didn't do this or at least not until OpenBSD did it first. Granted, I wasn't around at the time OpenBSD forked off of NetBSD, but looking at this message it would seem that NetBSD's commit messages were public quite a while before OpenBSD existed. It would also seem that at that, anybody could get the sources. Just FYI.
To give one example where a Live CD is incredibly useful: I recently used a custom NetBSD Live CD for a programming contest -- all machines at two locations needed to be absolutely identical and using a Live CD obliterates the hassle of installing a new OS or reconfiguring your current setup in any way -- just pop in the CD, boot, done.
See this link and this link for details.
The latest binary packages currently available are built under 1.6.2 and should therefor run just fine under 1.6.x (including 1.6.0). Given that the 2.0 release is coming Really Really Soon Now (tm), it's a pretty safe assumption that after the freeze the binary packages from the new branch will be built under NetBSD 2.0. Of course a 2.0 kernel can run older binaries (if you have the necesary COMPAT options(4) in your kernel). In addition, pkg_add(1) will warn/complain/fail depending on the discrepancy of the version under which the binary package was built compared to the version you are running.
Two days ago, RC3 was tagged, adding an NFS fix (transfers or directory operations hang under special circumstances).
I'm quite certain that the overwhelming majority, if not all, of the talks and tutorials will be in English.
On another note, it might be worth pointing out that there are a lot of developers attending/speaking, so if you want to meet some of the people behind your favorite OS, this looks like a good opportunity.
There was a problem with the site being recreated from the xml sources using not-quite-up-to-date tools. That's quite unfortunate. Anyway, it's been fixed in the mean time.
Dunno 'bout OpenBSD, but NetBSD will certainly be a good choice, too. See this page for some reports of NetBSD on laptops.
/home, take a look at NetBSD's cryptographic disk driver. I use it on my IBM T30 to encrypt /home and swap. Neato.
As for encrypted
Well, actually, it's quite easy to say
While it's not the merger of FreeBSD Ports, portage and fink, NetBSD's Packages Collection aka pkgsrc supports a large number of different operating systems (NetBSD, Darwin, FreeBSD, Irix, Linux, OpenBSD, Solaris), with support for more platforms (BSD/OS, HP-UX, AIX) in the works. Full Documentation here.
Indeed, imagine...
Yes, it can replace stuff in-line. But you better be aware of the side-effects. If the ABI of a given library has changed, ``make replace'' will really really mess up your system. This is, obviously, not a limitation within pkgsrc, but simply in the way shared libraries work.
However, if you're sure that all dependencies will be able to deal with the new package (say a shlib minor version bump, in theory at least, should not break other packages), then ``make replace'' can save you a lot of time rebuilding dependencies.
You can find some more details at http://www.netbsd.org/Documentation/pkgsrc/binary. html. The nice thing is, they are quite configurable, so that you can run a bulk-build with xpkgwedge (to ensure that even X11 programs do not end up outside of /usr/pkg (or whatever your PREFIX is)) or with gcc-3 (if your OS or Port has not yet been switched to use gcc3 as the default system compiler) etc.
The bulk builds are run regularly on different ports, and the resulting binary packages are then uploaded to the ftp sites.
FWIW, NetBSD's pkgsrc was updated on Wed Sep 17 22:58:45 2003 UTC to include KDE 3.4.1, too. Binary packages will surely soon be available for download, but if you have a decent build-host for your packages, building from source will work without a hitch, too.
As usual, when this comes up, let's plug NetBSD's Packages Collection. ``pkgsrc'', as it's known, originally derived from FreeBSD's ports is available for a large number of platforms (Netbsd, of course, and then Darwin, FreeBSD, OpenBSD, Linux, Solaris and Irix), thus allowing system administrators who have to take care of more than one OS to take advantage of its strengths. So, uhm, sorry, but I'd also have to add my vote to the ``who needs portage'' camp.
While NetBSD is probably not the one referred to as ``that other OS'', it still holds that ``of course it runs [on] NetBSD'': binary packages for blender 2.28 will show up on the mirrors shortly -- pkgsrc has already been updated.
You already can: Behold NetBSD's Packages Collection. Use it on NetBSD, FreeBSD, OpenBSD, Linux, Solaris, Irix, Darwin, Mac OS X...
More details here.
Hmm, while you _do_ have to get the source (as if that was a bad thing!), it's certainly very simple to update only the relevant parts. As the SA states, you do not need to update the entire system but can simply do:
# cd src
# cvs update -d -P -r netbsd-1-6 lib/libz/gzio.c
# cd lib/libz
# make USETOOLS=no cleandir dependall
# make USETOOLS=no install
(Similarly for the other advisories.)
This is not really very difficult.
NetBSD just imported XF 4.3.0. See the cvs repository and the posting to current-users.