Slashdot Mirror
NetBSD Packages Collection No Longer Frozen
jschauma writes "As many users will probably have noticed by the increase in recent pkgsrc
commits, the NetBSD
Packages Collection freeze is now officially over.
Starting October
6th, 2003 and lasting almost two months, the NetBSD Packages
team concentrated upon stabilizing the over 4,000
software packages and the pkgsrc
infrastructure to prepare for a stable pkgsrc branch. During that time, the
number of broken packages during a i386 bulk build was brought down to a mere
15, and a large number of PRs was closed.
A new branch with the tag ``pkgsrc-2003Q4'' was created, allowing our users to
maintain a highly stabilized third-party software package managment
environment, as only pullups of significant importance (such as security
issues) are applied to this branch."
Although I don't use NetBSD (did for a short period of time, but now a FreeBSD user), this is still happy news for me.
Hmmmm, I wonder who's poor 486 got stuck with the 4000 package bulk build...
You can compile for other cpus and even other CPU architectures on one machine for use on another.
Also,
A nice cake is waiting for you
You can compile for other cpus and even other CPU architectures on one machine for use on another.
I belive the word 'sarcasm' plays a role in my original post.
A nice cake is waiting for you
Oooo! What kind of cake?
The best thing about this is propably that new stabilized branch. In the past I've used almost everytime the newest sources available to keep up with all the patches, but if this new branch has only the important patches applied to it, it's definetely going to be the one I'm using. If this is going to be updated in the future too, the name of the new branch (pkgsrc-2003Q4) wasn't the best one though.
I demand the Cone of Silence!
It's nice to see my antics don't go unnoticed ;)
I'm pretty sure that cross compiles is supported for the base-OS, but not for pkgsrc.
At least, that was the case the last time I checked (since compiling a bunch of stuff on my Qube2 instead of my Athlon was way way slower).
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
Is it just me or does the linux kernel support more CPU ISAs than netbsd? Here is my count.
mipsa rc64
NetBSD (12):
alpha
arm
i386
m68k
ns32k
parisc
ppc
superh
sparc
sparc64
vax
x86-64
Linux (17):
alpha
arm
cris
h8300
i386
ia64
m68k
parisc
ppc
ppc64
s390
superh
sparc
sp
v850
x86-64
Now can we have our coders back working on FBSD 5.3?
;)
Cheers - FBSD user waiting for 5-Stable
Music is everybody's possession.
It's only publishers who think that people own it.
Fuck Beta
~John Lenno
If you want to stay on the old pkgsrc tree and receive importaint fixes only ( eg, security bug fixes ), then use the 'pkgsrc-2003Q4' cvs tag :)
NetBSD can already cross-compile the system from any arch to any arch. The cross-toolchain can be used in a chrooted environment to cross-build packages, but it is still touchy. see pkgsrc/pkgtools/pkg_comp .
My Athlon XP 1800+, with 1.1 GB RAM and a fair bit of disk, was used. A "from-scratch" bulk-build takes between 5 and 6 days. The time for update bulk builds depends upon what was updated (duh). The machine was running NetBSD 1.6ZF (aka NetBSD-current), and the builds were done in a 1.6.2RC2 sandbox. The 15 broken packages which Jan mentioned can mostly be attributed to this setup: we found that pkgsrc/pkgtools/libkver works really well (it's a wrapper around sysctl(2)), but that Linux emulation has problems with libkver (because NetBSD and Linux use different ways of delivering errno for threaded programs). Using a wrapper for uname(1) allowed the packages which used Linux emulation during the build process to complete successfully, but imake uses sysctl(2) directly to get OS version information, and in the end we had to use a hybrid of the two to make packages. The bulk build results do not reflect this, which is probably the reason for the 15 packages.
Does Linux build to all those CPUs out of a single source-tree? Does it build a complete OS? FWIW, there was some similar discussion on netbsd-advocacy a while back...
As a casual user of NetBSD, I'm interested in version 2.0 as it will have lots of new stuff that I really want (threading etc.) Can anyone enlighten me as to the expected release schedule for 2.0?
You sound like Theo, relying on clever parsing of a sentence rather than the plain and obvious truth.
Stop spreading FUD here. NetBSD shows 17 cpu types. Yes, Linux still supports more with ia64, ppc64, s390, etc. so at least your counting is somewhat off on both sides.
:)) but both are in heavy development and will quickly improve on all OSes. Obscure embedded platforms like v850, cris, h8300, etc. would make me nervous to use in a large production. They are not widely developed for and what info you can dig up suggests that they could be quirky with all the compiler weirdness, etc. that hasn't been shaken out yet. I'd much rather go with a more matured platform like ARM, MIPS, M68k, etc. regardless of the OS being chosen for the application.
:)
Your counts totally ignore edian issues. A playstation 2 and an SGI machine can't run the same binaries even though they are both MIPS because one is big endian and the other is little endian. ARMv2 is completely different architecturally than later versions. There are many other examples.
x86-64 is still a work in progress on both platforms and so is ppc64 (it's only a couple weeks old
There are times when a platform is more mature/complete/etc. (PA-RISC on linux is better supported) but NetBSD is generally very consistent and complete across all of the 40 platforms it currently supports.
The bottom line is use the right tool for the job. If I have a PA-RISC or s390 or wanted to build a PVR then I'd probably choose Linux and I would choose a BSD for most of the rest of my needs. You might choose a little different but both are good tools and very capable.
To get back ontopic. I use pkgsrc on several platforms ( BSD, Linux, OS X, Irix) and these fixes helped out on all platforms. I love the work that everyone has put into pkgsrc and can't wait to see it grow and develop more. Someone else needs to test it on Solaris Sparc/x86 since I don't have a box currently running it.
It allows use to deploy Enterprise class systems without paying "Enterprise" prices!
Thank goodness for BSD!
I honestly don't see how this was modded Informative...
This is the same GPL vs BSD flamewar that has been going on for a while now. It's definatly NOT informative.
The BSDs choose to use a BSD style liscence because they don't care about having a huge market share. They just want very good software EVERYWHERE. There is little hope in hiding the fact that nearly EVERY OS uses BSD code somewhere (usually in the network stack).
BSD style liscences are GREAT for standards, because then any operating system that wants to implement that standard can just copy and paste the source. It doesn't matter whether it's open or closed source.
Linux trolls just have this screwy view on the real world. GPL is great for the open source community, but that's it! BSD is great for the computer industy as a whole. To be honest, I don't care what operating system I use, as long as it get's the job done. It just so happens that right now, linux (on the desktop) get's the job done better than anything else.
You really need to get your head out of the corporate mindset, and realize that you don't have to turn a profit to be successful.
DISCLAIMER: This isn't a flame, trust me. The views and ideas expressed here are intended to open the mind of a GPL whore. Mod this down if you think it's nessisary.
Not Free(as in beer). Free(as in "I'm free to beat you over the head for being a dumbass")
OK let me try to figure this out. If you have a patch for the Linux kernel which enhances functionality or fixes bugs then you ask for it to be integerated into the official source. Similarily if you have a patch for any component of the the main three BSD operating systems then you ask for it to be integerated. In both scenarios if the patch is determined to be of good quality and safe then it is accepted. So just how is the BSD development process any less "open"?
Now, Apache uses a BSD style license but they have an open development model which allows them to take advantage of a very large developer pool in order to stay ahead of their competition. In fact although proprietary versions of Apache exist which perform better than the official releases, SGI has put out some open source patches which generate even larger performance boosts. This is the reason why they have such a strong showing in terms of market share.
And now suddenly your opinion of the BSD license changes. Apache is released with a BSD license but yet it isn't inferior to you eventhough commercial versions of it exist. How convenient. Apple "steals" BSD code and yet they contribute back too... who would've thunk it?
I don't think that there is enough widespread support for BSD to save the operating system.
Nice subtle trolling. What exactly does it need to be saved from? BSD has been around longer than Linux and I don't see it's development being affected. Thank you please don't come again.
Horse cum has a nice flat taste to it...not at all bitter like man's cum. You can easily drink cups of it with no discomfort.
because instead of being almost caught up in packages,
I'm now way behind. The bad side is that while NetBSD
packages is no longer frozen, I can't say the same thing.
Working outside really sucks in the cold weather.
> Stop spreading FUD here. NetBSD shows 17 cpu types. Yes, Linux still supports more with ia64,
:)) but both are in heavy development and will quickly improve on all OSes. Obscure
> ppc64, s390, etc. so at least your counting is somewhat off on both sides.
No, I was only counting dual endianness once for NetBSD which is why its numbers come down. Linux
kernel also supports two endian types for a number of ports.
> Your counts totally ignore edian issues. A playstation 2 and an SGI machine can't run the
> same binaries even though they are both MIPS because one is big endian and the other is
> little endian. ARMv2 is completely different architecturally than later versions. There are
> many other examples.
I'm not really sure about arm versions, so I counted it once for both. Possibly you could say
one or the other does support more arm architectures.
> x86-64 is still a work in progress on both platforms and so is ppc64 (it's only a couple
> weeks old
> embedded platforms like v850, cris, h8300, etc. would make me nervous to use in a large
> production. They are not widely developed for and what info you can dig up suggests that they
> could be quirky with all the compiler weirdness, etc. that hasn't been shaken out yet. I'd much
> rather go with a more matured platform like ARM, MIPS, M68k, etc. regardless of the OS being
> chosen for the application.
x86-64 and ppc64 are both mature ports on Linux. They are both in Linux 2.4 for a while and are in
the upcoming 2.6 of course. Linux has run on 32 way POWER4s with 256GB of memory, it is being
tested on POWER5.
> There are times when a platform is more mature/complete/etc. (PA-RISC on linux is better
> supported) but NetBSD is generally very consistent and complete across all of the 40
> platforms it currently supports.
I wonder how many platforms Linux supports using NetBSD's definition. When porting, Linux typically
treats a CPU ISA as the first class object under which many platforms are supported so its hard to
count.
> The bottom line is use the right tool for the job. If I have a PA-RISC or s390 or wanted to
> build a PVR then I'd probably choose Linux and I would choose a BSD for most of the rest of my
> needs. You might choose a little different but both are good tools and very capable.
Sure
Mares can be quite satisfactory for the average well endowed male. If you are somewhat less developed you might find better pleasure with a pony or Miniature Horse. These are also better as they are lower to the ground. A pony you can fuck standing up.
Sorry that didn't come out well at all... I should have used tags for quoting or something.
And don't forget to send your $699 check to Daryl on the way out.
"Obscure embedded platforms like v850, cris, h8300, etc.
would make me nervous to use in a large production."
Huh? There are more products shipped with any one
of these running Linux then the entire installed base of
NetBSD (no, literally). Choose an ARM (nommu) target
and there are millions of units a month shipped.
Widely developed has nothing to do with production ready.
But you are correct, this has nothing to do with pkgsrc.
D. Jeff Dionne
I am just curious to know if it is possible for you guys to reduce the "from-scratch" build time to 1-2 days?
Thanks
http://www.kottke.org/98/11/index
x86-64 and ppc64 are both mature ports on Linux.
Have you actually used either of these platforms? Yes, there are ports. Yes, they are useable. No, they are not stable yet but they are quickly moving that direction.
x86-64 has provided me with plenty of hours of fighting with it on several *nix OSes. It will be nice to see it matured but it just isn't there yet.
I suppose I'll have to take that as a "no" to the "dialogue" question.
I wonder if I would have gotten a literate response if I had left out the last two items which in retrospect were just written out of irritation.
Of course a reply like this makes me think that I didn't concede too much moral high ground by leaving them in. C'est la vie.
I make it a rule never to reply to Anonymous Coward posts.
It amazes me when people look at "cpu types" instead of "architectures". The old Mac68K's (LC's, SE/30, II-series [most of them]) use the 68030 chip. So, as a matter of fact, does the Sun/3 series. One "cpu type", but the hardware devices and general architecure of the machines are *radically* different. Saying you run on a 68030 is meaningless vs. saying you run on Mac68K and Sun3. So the question is not "how many cpu types" but "how many architectures".
Also, how complete is the OS on those architectures? Last time I looked (a month ago maybe) at Linux/Vax, they maybe had it booting on one or two Vax models. NetBSD supports quite a few more than that. And people are generally working on the ones that aren't working yet (7000's for example). The main issue here is more one of having the hardware available and power to run the things (hey, someone *just* got a 7000 up and running on single-phase power).
Yes, if I was looking for a gaming platform, I'd go with Linux on a fast PC with a top-notch video card. The vendor support is there for their proprietary drivers, etc. If, on the other hand, I'm looking for a simple webserver to run apache... well, I have some vaxen on hand, decstations, 68K macs, PC's, sun's, etc.. that *all* could do the job fine with NetBSD. Crossbuild available between platforms, or locally hosted.. and all from *one* source tree.