Slashdot Mirror
Walnut Creek CDROM And BSDi To Merge
It's been planned for some time, and on March 4 at a user
group meeting in the Netherlands, Jordan Hubbard let slip the
news that the ink was dry, and Walnut Creek CDROM, a big
player in the development and promotion of FreeBSD, and BSDi are merging. Obviously,
this has big implications for FreeBSD. You can read what's been
written so far at this DaemonNews article. Later today we'll have an interview with Walnut Creek president, Bob Bruce. If you've got questions, then you know the drill. . . Oh, OK. If you don't know the drill, post them here,
let the moderators moderate them up, and I'll make sure they get an
airing later.
Wheeh, and I was one of the people present at the NLFUG (Netherlands FreeBSD Usergroup) meeting. I don't remember all the new benefits of the merge he mentioned (Jordan H.) but some were:
:)
- Much better SMP support
- FreeBSD ports to SPARC and probaly StrongARM
and a lot more
- Snowdude!
Linux may be a "joke" as a home user desktop, but as a corporate desktop it works, it is low maintenance (the users cannot trash their system no matter how hard they try, and all user-changable files are mounted off of the NFS server so that all user files are backed up every night without any special software other than plain old BRU), and the users have a pre-defined desktop with easy-to-use icons for all the software they need to run. And any user can log in to any machine on campus and get his own desktop -- no "roaming profiles" needed!
Upsides: Low maintenance. Easy to swap out dead machines without disrupting user's work (he can just go to another machine, or I can slide in a backup machine, he logs in, and is back to his desktop).
Downsides: User can't install games that he brings from home. Hmm, is that really a downside? (grin).
-E
Send mail here if you want to reach me.
The guy had some reasonable points, with which you may agree or disagree. But, have the decency to reply to him in a comment, instead of using your moderator points to respond. Moderators who do this sort of thing are the real "Anonymous Cowards."
New XFMail home page
/bin/tcsh: Try it; you'll like it.
Over the years I recognize a lot of people working on FreeBSD, but I know nearly nothing about the folks at BSDi. Anyone has informations about their staff and the company history?
I believe Walnut Creek has moved all Linux related distros and software to ftp.freesoftware.com. They are indeed the official site for Slackware Linux, and for FreeBSD. I think this is a great merger, but I wonder what effects it will have for Mac OSX, which runs off of a mini BSDI 4.4 me thinks..
EraseMe
Good question, and at most we can just speculate at this stage. One would hope that it would make FreeBSD easier to get. It might also provide more leverage to get hardware vendors to release driver specifications. There would also be more employed developers, which should be great, and lead to more drivers, better code, and so forth.
Re: the linuxes disappearing from cdrom.com
S'OK, so has FreeBSD... WC sold the cdrom.com domain sometime ago. The new domain is (I think) freesoftware.com. WC can still be found at wccdrom.com.
N
And why would we be concerned?
The relationship between BSDI and the other BSD's hasn't been ill. Basing on all the FUD I have been encountering in the comments posted it seems as if most people whom seek something ill behind the merger are Linux users whom think that BSDI is a Microsoft kind of company. Well it isn't guys, in fact, the people there are actually pretty cool.
That said, BSDI already used large parts of all BSD source trees without the individual projects building a grudge about that towards BSDI. That's why we use the BSD License and that is why we are not concerned; we _explicitely_ allow such things!
Jeroen Ruigrok/Asmodai
Mostly, as I understand it, it will be the NDA'd drivers and related stuff that don't get freed.
And yes, the intent is a merged source tree at some future date.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
In theory, sure, someone could "steal" the resulting code.
In practice, OS-level code isn't *worth* stealing if your system isn't fairly similar, on an architectural level.
Could NT try to steal our code? Sure. Just like they could steal NetBSD or FreeBSD code today. They don't, because it's easier to engineer from scratch, using our code as a reference base - which they could have done at any point for the cost of a source license.
And yes, I think this may be YAOSL, but I think it's a temporary one only. FreeBSD will still be under the BSD license.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
Probably technically a first, although be aware that drivers under NDA will stay under NDA.
It's not that big a deal; BSD/OS has always been based largely on 4.4BSD code, and we've given away code to other systems before; NetBSD-current has our 'login.conf' code, for instance.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
I don't see any point to changing cdrom.com over, but yes, I would expect BSD/OS can handle comparable loads to FreeBSD. Despite getting there by very different paths, both systems have fairly good reliability and performance...
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
If the BSD/OS SMP is so awful, why is the FreeBSD one the one getting scrapped?
BSD/OS is *not* the same thing as FreeBSD, and it sure as hell isn't "the same thing two years older". It's a different system, with different goals, targeted at a different market.
I'm sorry you didn't find that BSD/OS met your needs, but I think it's a little drastic to talk about "things which don't suck nearly as much". BSD/OS may not be the be-all and end-all of systems, but it doesn't *suck*, not by any stretch of the imagination.
Anyway, as the code starts getting shared between the systems, we'll see a lot of changes for both communities, and I think they'll all be for the better. FreeBSD will get a "real" SMP, instead of a "pretty-good-hack" SMP. BSD/OS will quite possibly get the bus_space code.
(Of course, that's NetBSD's work, not FreeBSD's, originally.)
It's amazing; it's almost as though, when multiple groups of developers work on different projects, they produce different things. What's really amazing is that this surprises people.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
Hee hee.
Remember, a bunch of the drivers are still under NDA, and *CANNOT BE RELEASED*.
That said, calm down a little, and wait and see what happens. No one will be harmed by waiting a few days to hear more about release plans.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
Gauntlet may be the best known, but they're running a *very* old BSD/OS codebase, and I don't think they're doing driver updates. They got bought by Network Associates a while back, and I think that was about the point at which they stopped following our "current" releases.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
Yeah, but does "the source tree" compile on 20 different kinds of computers? Multiple different branches that integrate fixes from each other are not the same thing as a unified source tree.
I don't think it's unreasonable to consider the Amiga and the Sun3 different "ports", because they're substantially different systems, even if they have the same CPU.
I do think it's unfair to use the existance somewhere of a port of a piece of software to a platform maintained by a third party as "support" for that platform.
It's all trade-offs; if nothing else, can we at least agree that Windows NT is *not* the multi-platform leader?
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
True enough, but we're talking OS stuff, not just lightweight userland utilities.
Heh. I wonder if they ever give credit for that ftp client; if not, maybe someone should whack them.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
I wonder if this is the reason why, yesterday, when I wanted to install a package on my Slackware box, the /pub/linux folder on ftp.cdrom.com was empty...
Okay, so after 3.2, 3.3 and 3.4 I am getting bored of the stickers. I hope they have some nice shiny new ones for FreeBSD 4.x :-) Maybe on a cunning silver metallic background that does pretty things when you hold it up to the light and tilt it.
I must buy a FreeBSD Daemon doll at some point...
I've never really seen a comparative "study" between BSDi and FreeBSD (although that would be really interesting). I will say, however, that the FreeBSD configuration on ftp.cdrom.com isn't quite an "out-of-the-box" configuration. David Greenman has had to tweak the heck out of that box, even down to writing his own ftp daemon. It was a happy day when we found out that we had broken the "one terabyte downloaded in one day" milestone several years back...
--
http://www.aikiweb.com - AikiWeb Aikido Information
I look forward to the good things that will come from this merger!
The cake is a pie
I figure that most of the obvious, and technical, stuff is going to be easy to sort out.
But, the more difficult question is going to be, what about the developers?
While I don't think anyone will have a problem with giving Mike Karels any commit privs he wants, what about Joe Random Developer inside BSDi? Will he/she have to go through the same things that FreeBSD developers have historically gone through?
Clearly, this isn't something where there are only a few developers, and I expect that most people wouldn't even be able to tell if FreeBSD added a few dozen committers (FreeBSD has a boatload already), but inside the community, this is of some importance.
I quote:
--
Brad Knowles
Brad Knowles
http://daily.daemonnews.org/ -- if you're not
As a longtime advocate of the free BSD's I have a few views I'd like to express.
;)
If Jordan thinks this is a good thing, I've know jkh long enough to know, that while he is human, generally he considers long term implications of things. the BSD's now have a commercial backing. Walnut Creek, while having funded FreeBSD developnment for a while, did not have the commercial power of BSDi.
Also, this signals the change in strategy for BSDi, instead of keeping things relatively closed, most things being distibuted by BSD Inc. will be Open Source. However I wonder about the funding of Slackware development, but I'm sure provisions have been made.
This was bound to happen, Kirk Mc. has been involved with both FreeBSD and BSDi, and it was just a matter of time before something like this happened.
I personally will wait to see what happens. while I trust jkh's judgement, I also reserve the right to be cautious
lets hope this *does* turn out to be for the best.
-Pat
-- FreeBSD - The Power to Serve NetBSD - of course it runs NetBSD OpenBSD - Armed to the Gills Three tools in our
The numbers aren't artificially inflated; I can't run MacLinux on an Amiga, just as I can't run NetBSD/mac68k on an Amiga. And quantity isn't the only measure of which OS "owns" multi-platform. I think NetBSD's integration of all of its ports into a single source tree counts for a lot, as does having a clean split between arch-dependent code and arch-independent code so that, e.g., most of the drivers are shared between all the arches. Someone wrote a driver for sound cards using ForteMedia FM801 chip on his x86 machine. I added the driver to my Alpha's kernel config file, compiled a kernel, and had the sound card working perfectly, with no changes to the source code. I wouldn't be surprised if the same driver would work in a PowerMac or Ultrasparc (perhaps there may be some endian issues the author overlooked, but those would be very minor things to fix).
Similarly, the S/390 Linux port is one Linux port but would be four NetBSD ports, assuming NetBSD ever gets around to supporting S/390 (the Linux port runs on the bare metal or as a virtual session under any of the three OSes available for S/390).
I dunno about that... isn't the idea of the S/390 that the virtual machine looks identical to the bare metal? If there aren't really major differences in OS's view of the hardware, I'd think that NetBSD would put it all in one port. After all, although they were originally separate, NetBSD even managed to combine the sun3 and sun3x ports (I think the sun3x machines looked more like the sun4 SPARCs, except they had a 68k processor).
Actually, I'd say that NetBSD owns multi-platform. No clue about SMP, other than NetBSD definitely doesn't own it ;)
Quite simply, how does this merger benefit the end user/purchaser?
-- On the side of the software box, in the system requirements section it said "Requires Windows 95 or better." So I i
This paragraph seems a bit confusing. First, does this really mean that there is Yet Another Open Source license available?
Furthermore, since the BSDi code will be released as part of BSD which follows the BSD license, is BSDi's code is now available for commercial operating systems (eg, Windows 2K+1?, *nix)
What steps will new company take to protect against this scenario?
Just posted this morning to the freebsd-current mailing list:
h a/4.0-20000307-CURRENT 6 /4.0-20000307-CURRENT
- IMAGES/4.0-20000307-CURRENT/
:). Thanks!
From: "Jordan K. Hubbard"
Subject: FreeBSD 4.0 release candidate #3 now available.
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/alp
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i38
With ISO images available from:
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO
.. just as soon as they finish uploading (the i386 image is already
there and the alpha image is about 8% there and should be in place by
the time most of you read this message).
This will probably be the last release candidate image before release
day unless folks find some real show-stoppers here, so please look
thoroughly
- Jordan
So, barring any big problems, FreeBSD-4.0 will be released on Monday, March 13th.
You may start to see some BSDI code being integrated in the coming months, but the two codebases probably won't be completely merged for at least a year or perhaps two. This means that 5.0-RELEASE or perhaps 6.0-RELEASE would be the first realistic version that would be completely merged.
--
Brad Knowles
Brad Knowles
http://daily.daemonnews.org/ -- if you're not
- How is that a "feat"? AFAICS, it just illustrates the weakness of the BSD license: Anyone could easily keep a closed-source OS competitive with an open-source template that was free for the taking. What was that somebody said about "Microsoft's" implementation of DNS (or whatever it was) in Windows 2000...?
Obviously you don't have much experience with actually participating in Open Source development of operating systems.The reality of it is that people who take a freely available OS with a BSD-style license and then add on their own proprietary enhancements, have a real problem with having to constantly re-apply those patches every time the freely available version is updated. As a result, they usually are actively interested in getting those changes re-incorporated into the base system, so that they don't have to continue to maintain their own private branch.
The primary problem that maintainers of code with BSD-style licenses have is that sometimes the changes are quite big, and the maintainers are usually unpaid volunteers, thus making it rather difficult for them to incorporate changes of that scale.
These kinds of problems are precisely what the merger between BSDI and Walnut Creek will help solve, since they will now have some real money to be able to pay some programmers to take all these changes from all these various different sources and start serious work on incorporating them into the FreeBSD baseline.
--
Brad Knowles
Brad Knowles
http://daily.daemonnews.org/ -- if you're not
What next, should Redhat and the other successful companies run around buying closed source companies and release their source, maybe they should do this immediately before their market price crashes :-). Even if they go belly up afterwards they still will have achieve opening up the source. A cunning idea methinks
C.
I sometimes write stuff
One of the unfortunate but inevitable driving forces behind software development, once it becomes seriously involved in the commercial world, is feature-creep: adding more features so the market perceives the software as more modern, up-to-date, and desireable.
... I run FreeBSD, and I'm only reporting what I really hear friends saying).
We're all aware of how this dynamic drives the feature-rich but bug- and complexity-riddled MS offerings, but it appears that this is starting to happen in the Linux world as well. Most of the Linux users I personally know have switched from RedHat due to problems with 6.x being too unwieldy. One would hope for better from a relatively expensive boxed distro produced by a company with a huge recent IPO. (Don't flame me!
Will there be binding, concrete mechanisms, such as user-community input into decisions, or something like the sepate foundation set up to mediate the Troll/QT relationship, to prevent feature-creep from warping FreeBSD out of shape? What will these mechanisms be?
The ready answer, of course, is that the BSD license and market forces, combined with the philosophyies of the principal players in the merged company, will prevent this from happening. However, I worry that these aren't enough to stand up against the lure of big money --- or the pressure of big money from wealthy outside companies.
This is a good move for the BSDs in general. They have been losing ground to Linux, which is the more 'media friendly' OS. It is good to see that BSDi are contributing a lot of their code (except that under NDA - still available as a plus-pack though) to the BSD code base, under the BSD license (not under some other license).
I wonder what ramifications this has for FreeBSD 4.0? It hasn't been released yet, so will it be delayed while several core BSDi components are added? I doubt it, but FreeBSD 5.0 will occur before the end of the year otherwise, as I imagine the differences between FreeBSD and BSDi are significant enough to warrant a version increase. OTOH, it could just be that they will be merged smoothly into the 4.x series...
They could have called it FreeBSDi :-)
I would hate to see Slack go the way of the Dodo because of this. Granted, this announcement means that the box that I was going to wipe RH6.1 off of (I test each new RH, Deb and Slack distro as they come out and I have the time and drive space) and put Slack back onto will probably be getting a FBSD 3.4 install instead. Time to start playing in that space a bit. Most of the mainstream Linux distros (RH, Deb, SuSE, Turbo) don't suit me well. Deb is nice once it's set up, but the devel process is broken. Evolution will fix this, but I don't have the time to waste on it right now. Great distro, just not for me. RH...well, it's really not bad, but I don't much like their config style. Not the SYSV part...that's ok. The /etc/sysconfig directory mess is what I'm refering to. Makes the construction of the official admin tools easier, but at the expense of making manual or custom config/mgmt a pain. Don't even get me started about SuSE in this regard! As for Turbo, I've not done more than a simple install, so no comment. (And the crowd goes wild!!!)
Anyhoo....this rambled on longer than I had inteded. I suppose I should just email the Slack crew and WCCDROM for a real answer, rather than asking here. I would say that it was to save the time, but typing all this drivel took at least as long as the emails would have.
[1] Yes, I know they do a great job of following the file hierarchy standerd. I was refering the the LSB, which is going to be good, but would be better with Slack folk working on it, too.
--
If your map and the terrain differ,
trust the terrain.
- Most of the BSD/OS code will be available to open source projects.
- BSD now has a commercial backer on the same scale, or at least potentially so, as some of the Linux backers.
- A more competitive BSD means that Linux will have to respond to an increased rate of BSD improvements (just as BSD has had to respond to a faster rate of Linux improvements!), forcing general innovation.
(disclaimer: I work for Daemon News, and wrote the merger article)