DragonFly BSD Announced 460
JoshRendlesham writes "Matt Dillon announced today on the freebsd-hackers mailing list the creation of the DragonFly BSD project. It seeks to build on the work of FreeBSD 4.x, including a rewrite of the packaging and distribution system, among other goals."
In other news (Score:4, Funny)
Re:In other news (Score:5, Funny)
Rule 1: You do not talk about the -AC kernel tree.
RUle 2: You DO NOT talk about the -AC kernel tree.
Rule 3: If it's your first night in the -AC kernel tree, you HAVE to post.
No, no... (Score:3, Funny)
Re:In other news (Score:2)
Wonderful (Score:5, Funny)
Re:Wonderful (Score:5, Funny)
And listed in order of stability, too! Informative post. :)
Re:Wonderful (Score:2)
Re:Wonderful (Score:2, Interesting)
Anyway, XMach is a version of BSD with a Mach-based kernel. I don't know what's the status of that current project, with Darwin and HURD nipping at its heels (not that either are perfect replacements) its not as popular as it might otherwise be.
Remember, BSD is also defined by the userland. I look forward to BSD/Linux, the one true user land with the best supported ker
Re:Wonderful (Score:3, Informative)
-uso.
Re:Wonderful (Score:2)
Re:Wonderful (Score:2)
Besides, I get 50 spams a day anyway. I don't think it likely that my e-mail address will get slashdotted, any more than it's likely that Goatse.cx or Tubgirl.com will get slashdotted.
For everything else, I have two private addresses.
-uso.
Re:Wonderful (Score:2)
I, frankly, beg to differ. BSD is alive and well - and the troll's information is wildly inaccurate.
I myself dabble in BSD - OpenBSD userland porting. If you download FreeDOS [freedos.org] ODIN 0.4, there is a "cal.com" program included, and guess where it comes from. OpenBSD.
Maybe it is dying (although, evidence points otherwise). No open-source OS of the scale of BSD will ever completely die. Someone will just
Re:Wonderful (Score:3, Funny)
Unhappy with *BSD?
Solution: Simply fork off a new Windows branch and make it a better server OS.
Re:Wonderful (Score:4, Insightful)
Re:Wonderful (Score:2)
Re:Wonderful (Score:2, Insightful)
Or, if you don't have strings installed, just google for it [google.com].
Iduno what else they've used, but they're legally entitled to use any portion they like, and many people surmise that they may have used quite a bit. Given that the copyright notice is no longer required, the world may never know.
Re:Wonderful (Score:2, Informative)
Re:Wonderful (Score:2)
*rimshot*
*ducks*
administrators (Score:2, Funny)
Oh no! Who will pay the administrators the big bucks now?
Re:administrators (Score:2)
Re:PORTAGE! (Score:2)
It would be really cool to see the power and simplicity of portage brought to the BSD world. This would have two beneficial effects:
I love BSD -- it's why
Re:PORTAGE! (Score:2)
Gentoo is not an imitation of BSD: it's a GNU userland with Portage as a package manager. Portage is also not an imitation of ports - Portage is a further development of good ideas of ports after leaving behind bad implementation details of ports. The major improveent of the ports' concept in Portage is fine-grained control of dependencies and system/application settings/configurations.
Re:PORTAGE! (Score:5, Funny)
That's it. I'm going to mail Daniel Robbins and ask him to make the next in his brilliant series of articles at IBM DeveloperWorks a "OS advocacy for overzealous Gentoo freaks" piece.
The first and most important bit: Always bring up Gentoo whenever ANYONE mentions ANY other operating system! This is of UTMOST importance! Just like annoying potential customers works for Internet advertisers, annoying potential users must work for OS advocates!
Longhorn would kick ass if they installed unwanted software using PORTAGE instead of Windows Update!!!!! PR0T4G3 R0XX0RZ J00R B0XX0RS!
I'm going to be burned at the stake for this, but don't worry, my karma ensures that I'll be back as a lotus blossom to annoy all you bloody geeks with pollen.
Re:PORTAGE! (Score:2)
Re:PORTAGE! (Score:2)
or do it all in one sweep with portinstall collection/port
Obligatory Dying Post (Score:2, Funny)
Re:Obligatory Dying Post (Score:2)
working with retards. (something about mary reference)
Why dork with the existing FreeBSD... (Score:5, Insightful)
PORTAGE! (Score:5, Insightful)
Re:PORTAGE! (Score:3, Informative)
You need to rsync quite often and I noticed several broken ports.
FreeBSD ports are simple tcsh scripts that are well tested and integrated since the whole FreeBSD team tests them out. The ports themselves are more stable and under FreeBSD I can chose specific mirrors to specific packages. Try that with portage?
Re:PORTAGE! (Score:2)
By all means, fill me in...
Re:Why dork with the existing FreeBSD... (Score:2)
pkg could be a lot better (Score:5, Insightful)
Re:pkg could be a lot better (Score:2, Flamebait)
Yeah, because cvsup is such a difficult thing to figure out.
Dinivin
Re:pkg could be a lot better (Score:2)
Every decent OS does a better job. Even some not so decent OS's do.
If cvsup is so trivial, why do I have to figure it out? Isn't that what computers are for? Taking care of the trivial?
The truth is that it is trivial, but it should be free. Instead it is another FreeBSD disappointment.
Re:pkg could be a lot better (Score:2)
Believe me, no OS does a better at package management, and package upgrades, than FreeBSD.
Dinivin
Re:pkg could be a lot better (Score:2)
Never mind that you're wrong.
Never mind that I've used MUCH better (the package management system in Nextstep was fab).
The point is that it SHOULD be easier to update it (ie no work).
Re:pkg could be a lot better (Score:2)
Sigh. Hopefully this will get past the lameness filter:
#!/bin/sh
echo "Quick-N-Dirty script to update all your installed ports"
echo "slurping down the new stuff..."
cvsup
echo "rebuilding the ports database..."
portsdb -Uu
echo "building all updated ports..."
portupgrade --all
echo "done!"
Re:pkg could be a lot better (Score:2)
Why did I have to write it?
Why did you have to write it?
Why don't they just make it work?
The point is not that it can't be done. It's not even that it's hard to do. The point is that it should ALREADY be done so that you and I don't have to do it again.
That's what we mean by "could be a lot better." Really, the FreeBSD process could be a lot better for all users if they made this (and other) trivial fix(es).
Re:pkg could be a lot better (Score:3, Informative)
Fourth, you need to understand the UNIX philosophy. In a nutshell it is "many small tools that do only one thing, but do them well." cvsup is a small tool that does one thing well. portupgrade is a small tool that does one thing
Re:pkg could be a lot better (Score:2)
If, on the other hand, you're actually willing to do a little bit of upfront work so your system can behave the way you want it to rather than the way MS thinks it should then do it yourself- it's not that hard to do.
I really can't believe that anyone would complain about how FreeBSD's package system works. Fact is, it does, hands down, and it's not that hard to learn or configure.
Re:pkg could be a lot better (Score:3, Informative)
cd
make update
Put this in
SUPHOST=cvsup.freebsd.org
SUP_UPDATE=yes
SUP=/u
SUPFLAGS=-g -L2
SUPFILE=/usr/share/examples/cvsup/stable-sup
PORTSSUPFILE=/usr/share/examples/cvsup/ports
Re:pkg could be a lot better (Score:5, Informative)
It really pisses me off that FreeBSD does not let you (by default)
cd
make update
I dunno, I think cvsup and portupgrade do the deed quite nicely.
# cd
# make install && make clean
# cd
# make install && make clean
# mkdir -p
# cp
CFLAGS= -O -pipe
COPTFLAGS= -O -pipe
NOPROFILE= true
USA_RESIDENT= YES (if you are)
*default host=cvsup2.freebsd.org
*default base=/usr/local/etc/cvsup
*default release=cvs tag=RELENG_5_1 (or your version)
*default delete use-rel-suffix
*default compress
src-all
ports-all tag=.
doc-all tag=.
#
#
Granted, you have to build a supfile, and tweak your
Re:pkg could be a lot better (Score:2)
Ports in freebsd are cool. But updating packages installed, and updating the whole system, are two very cool things i would like to see.
Re:pkg could be a lot better (Score:2)
Finally someone that understands that I shouldn't have to work to make things easy. They should just be easy.
Re:pkg could be a lot better (Score:2)
So just buy a freakin' Mac already... With that kind of attitude, why are you even messing around with BSD (or Linux for that matter)?
Re:pkg could be a lot better (Score:2)
Gentoo designed their ports system to be elegant, not the constant fiddle and hackjob that FreeBSD boasts. Just because 20 lines of code to make ports updating work was good enough for grandpa doesn't mean you should accept it as an example of intelligent design today.
Re:pkg could be a lot better (Score:2)
Re:pkg could be a lot better (Score:5, Insightful)
I wasn't trying to show that FreeBSD ports was somehow *easier* than Portage (or anything else for that matter), simply that it was not very difficult at all, and it gets the job done nicely.
Personally, I don't see the problem with doing a little configuration to make the system behave exactly as I want. To me, that's a feature, not a flaw. Not to mention the fact that the 20 or so lines of command and code you seem to have a problem with, is a one-time setup task. After that, the system is a two-command process, one command if I create a simple shell script, no command if I add a cron job to do it once a week. This is just like your two-command process, except for the fact that *I* have dictated the mechanics of the process, rather than allowing a distributor to decide those mechanics for me.
Ports in freebsd are cool. But updating packages installed, and updating the whole system, are two very cool things i would like to see.
All you have to do is look, it's all right there. CVSup will update your ports tree, your source tree, your docs, or a custom combination of all of the above. Portupgrade will update all of your ports with one command. As to updating the system, the system and the ports are kept separate *by design*. The system can be upgraded independently from the ports, and vice versa. Updating the system itself is as simple as a 'make buildworld', 'make kernel', 'make installworld', and reboot.
I dunno. Maybe this is just an "old school vs. new school" issue. "Old school" UNIX users and sysadmins simply see this as a reasonable means to get things done. "New school" Linux users (a lot of whom are migrating from the Windows world) seem to be looking for the command-line equivalent of clicking a button to get everything done. No work, and no knowledge of the system itself and how it operates, required.
I, for one, prefer the old school way.
Re:pkg could be a lot better (Score:3, Insightful)
If ease and elegance of updating the operating system were the main criteria for picking one, we'd all be running Windows. Can't get much easier than going to a website and doing it all with one mouse button and rebooting.
Re:pkg could be a lot better (Score:2, Interesting)
And if you add something like the following in /etc/make.conf, you also get "make update" in /usr/src. :-)
SebastianNew Packaging System (Score:2, Interesting)
Re:New Packaging System (Score:5, Informative)
It's more than just replacing ports with portage, or apt-get, or some other userspace packaging system.
What they're talking about doing is having kernel support for packaging. Multiple versions of the same library could be installed with the same filename simultaneously. An application would see the correct versions of the things it needs, and it would see only the things it needs, despite what else might be installed. This is to allow for piecemeal/partial upgrades among other things.
To which I say: HALLELUJAH BROTHER!
This is exactly what I've been wanting to graft onto Linux for some time now; my latest thinking is that it could be done with a userspace filesystem (to make files visible/invisible), extended attributes (to associate the visibility contexts with application binaries), and a bit of extra process state. If the DragonFlyBSD folks make it work, it'll be intrestesting to see how this behaves from an administrative point of view.
In any case, this is not just a userspace change. This involves the kernel itself.
Re:New Packaging System (Score:2)
you mean like VMS? I think the VMS filesystem did file versioning similar to this.
Re:New Packaging System (Score:2, Informative)
Yes, frameworks do something similar. But the design requires toolchains, runtime linking, and the libraries themselves to understand frameworks. So do you modify the applications and libraries to understand a new way of working, o
Re:New Packaging System (Score:2)
The ports system was certainly something of a breakthrough, and the various imitators (and improvers) are simply biting its style, even if they are making improvements.
What a great name idea! (Score:3, Funny)
Re:What a great name idea! (Score:2)
Windows:
Something for bugs to hit and stick to
BSD and Smart People (Score:3, Interesting)
Imagine what these guys could actually *do* if they put aside their differences and worked together!! No unsolved CS problem would be safe.
Re:BSD and Smart People (Score:2, Insightful)
People only live so long- sure, if you could somehow force all the gurus into a "Manhattan Project," they'd probably spit something interesting out the other end, but there'd be more tradeoffs involved. You can't have a system as (philosophically) tight as OpenBSD when people are merging hug
Matt Dillon, eh? (Score:2, Interesting)
Matt: if you're reading this, I loved DICE, and all your other work on the Amiga - your compiler is one of the reasons I'm a programmer today. I hadn't been keeping up with your work but it's good to see you're still out there doing stuff.
(seems a lot of the old Amiga 'big names' have gone on to do interesting stuff in the time since)
Re:Matt Dillon, eh? (Score:2)
I agree with what you wrote. Also he was great in Drugstore Cowboy and The Outsiders.
Re:Matt Dillon, eh? (Score:5, Interesting)
-Matt
Re:Matt Dillon, eh? (Score:2)
I think that and multiple que's for each cpu can make quite a scalable system. It would rock if Dragonfly or FreeBSD implemented these features.
I looked at your notes on threading and it sounds pretty cool even though I am not an OS developer. Threads are one of the few weaknesses if any in BSD
Re:Matt Dillon, eh? (Score:2)
Remember Ms. Kitty? When I was five, I was in love with her. I only found out that she was a woman of ill-repute (or at least some questionable sexual mores) when I was in my twenties.
Damn. Googled it. It was Marshall Dillon, not Matt.
Ah, hell. what's a few letters difference between friends anyway?
Paging Lorraine (Score:5, Insightful)
Matt Dillon's early background as an Amiga programmer is really showing through here. He's basically proposing doing a piecewise conversion of BSD to an Amiga-style message-passing operating system.
He's basically doing the reverse of what so many folks (NeXT, HURD) have done or tried to do.. not taking a microkernal and putting a UNIX layer over it, but taking a UNIX and scooping out the inside to replace it with a message-passing microkernal.
This will definitely be a fun one to watch. Go, Matt, go.
Re:Paging Lorraine (Score:3, Informative)
Oh no, not another! (Score:5, Insightful)
So there.
Re:Oh no, not another! (Score:2, Interesting)
But then maybe I liked Blondie 24 [harcourt-i...tional.com] too much.
Re:Oh no, not another! (Score:2)
Unlike Linux, the *BSD teams are selective on who writes to where and if you piss a few of them off they have the power to refuse and delete your code.
This is why BSD forks more often then Linux. Linux has mini-forks with packages and if it works well and demand is for it Linus typically will accept it and remerge it back. Look at Riser as an example. The auth
Re:Oh no, not another! (Score:2)
s/eliteness/quality/
Re:Oh no, not another! (Score:2)
but how many linux distros have forked the kernel, rather than just repackaging/patching the standard kernel?
Re:Oh no, not another! (Score:2)
Let's see, how many commercial linux distros are there? If something's appended to the version number, it's a fork. Fortunately, if a new kernel feature proves useful or popular, Linus lets it in. Otherwise there would be a reign of confusion.
The BSD forks are of a different kind. NetBSD and FreeBSD forked off the same codebase (386BSD) simply because neither project was aware of the other until too late. OpenBSD forked off primarily because of personality
Messaging layer (Score:2)
Re:Messaging layer (Score:5, Interesting)
Re:Messaging layer (Score:5, Informative)
Another feature taken from the Amiga I/O model (for those who ever looked at the actual assembly code) is the ability to short-cut queueing operations. For example, if the target is able to execute a message synchronously regardless of what the client requested, the target can execute the message in the client's context and return a synchronous result code without even bothering to queue the message (I/O request in Amiga terminology). Likewise, if the client wants to run an operation synchronously and the target decides to run it asynchronously the target doesn't have to queue the message back to the client's reply port when it is through, it simply wakes the (blocked) client up.
To make messaging truely efficient the 'optimal' case must have the lowest possible overhead. The Amiga model serves this requirement very nicely, making optimally handled messages take no more overhead then a subroutine call would take. This is extremely important in an MP design because queueing operations often require some sort of lock and being able to avoid a queueing operation in the optimal case is simply *HUGE*.
Consider the optimal syscall path given the above. If a syscall can run without blocking your syscall 'message' winds up costing no more then a traditional syscall would. After all, there is no point asynchronizing a syscall that can run without blocking, you only have one cpu for any given userland thread anyway so you can't make things faster by switching out to handle something else and then back again. Yet in a traditional asynchronizing model like AIO, a great deal of effort and overhead is taken before you even know whether the I/O operation would block or not, making AIO expensive no matter how you cut it. The same goes with a select() based operation. And in a KSE style operation the expense occurs in having to maintain multiple kernel threads for system calls which are in-progress, instead of much smaller message structuers for system calls which are in-progress. The above Amiga-like features make it possible to encapsulate *ALL* system calls in messages, request asynchronous completion, yet still deal with synchronous completion in a manner which does not introduce a performance penalty.
Re:Messaging layer (Score:5, Interesting)
Technically its not a job but they refuse all his patches and he lost write access. The chances now of it being merged into FreeBSD are remote.
He had no choice but to fork if he wanted to continue developing. That or join the Openbsd team or Linux.
Infact Dillion help fixed the vm bug in Linux 2.4. He actually has already developed Linux code.
Hey pardners! (Score:2)
What does an old gunslinger [imdb.com] have to do with this announcement? Even more important... will Miss Kitty [puzzlehistory.com] be involved?
Well, good luck to him! (Score:5, Interesting)
It would be nice if DragonFlyBSD (gah, ENAMETOOLONG) was a similar deal. As a FreeBSD developer, I hope that there will be plenty of opportunities to take good stuff in both directions. If we can keep people away from each others throats and work on making the code better, then everybody wins.
Diversity is good. Developers fighting each other is bad. Forks can be a good way to relieve the stress. There is no need to make a Big Deal(TM) about it.
Re:Well, good luck to him! (Score:2)
Darwin, Fink and Gentoo are working together to make a shared package system.
Since everyone says, well since it is Unix-like, it probably only takes a recompile to port from X to Y... well, why not have a sourve based package system, and get the BSD's, Fink, Darwin, and Linux to jump on board? a simpel 'install' or 'make' script and BLAM, life is SO much easier.
Security? (Score:2, Insightful)
- Not Theo, but not Bill either
Critical mass (Score:2)
I'm a FreeBSD user, but not by religion. I use Linux on certain systems where some distro fits better.
However during daily usage FreeBSD simply turned to be superior to the big few Linux distro's as far as release engineering goes.
Matt branches, but let's take reasons and goals to be unimportant for now.
How is he going to sustain _any_ release engineering the quality FreeBSD (and the major Linux distro's) has/have?
If bsd is among the dead? (Score:2)
Boy that was a quick troll bot response! (Score:2)
Sounds like a political war between people with gig egos, and axes to grind.
Re:Another one? (Score:4, Interesting)
Re:Another one? (Score:3, Insightful)
POW!
All the various BSDs share code when one solution seems to fit more than just the distribution that developed it. If DragonFly is going to focus on something that the other four aren't, then more power to them. I'm sure the others will adopt any good ideas that come out.
Re:And I thought... (Score:2)
Re:wheres teh (Score:2)
-V
Re:just what this planet needs ... (Score:5, Informative)
In a way it is. Matt Dillon got lost commit access to cvs a while ago [slashdot.org] because he was trying to get some stuff into 4.8 and got rebuffed. Looked like he violated their code of conduct a few too many times, got kicked out, and started a project where he made the rules. TdR in the house?
Re:Dragonfly BSD, life expectancy? (Score:3, Funny)
Re:Won't use it (Score:2)
Re:Won't use it (Score:2)
Re:Won't use it (Score:2)
TenDRA
http://www.tendra.org/
Re:One BSD (Score:2)
Why not one *NIX them?
I'm mainly a BSD user (still like Slackware, my first Linux encounter of the first kind), but from a user perspective the various BSDs are more coherent than the avg Linux distro.
A different kernel is often irrelevant if you come above a certain level. A level below which an average user won't go anyway.
Re:One BSD (Score:2)
In terms of BSD? MacOS X.
Re:BSD? More like LSD (Score:2)
I probably will still do so . .
a) has a standard troll post like that
and
b) it is moderately interesting troll post
and
c) someone bothered to remember a previous troll
May be I don't have enough time on my hands...
robi
*BSD Basher Dead at 16 (Score:5, Funny)
Re:Why 4.x? (Score:5, Informative)
Insofar as performance goes, a higher version number does not mean higher performance. 4.x is a lot faster then 5.x for many types of tasks. DragonFly will be able to implement critical subsystems in MP, like the TCP stack, using an essentially mutexless design, which ultimately means that DragonFly will theoretically be able to perform better then 5.x in an MP environment once both are able to completely remove the MP lock. But that is down the road quite a bit and a lot can happen between then and now.
Re:Why 4.x? (Score:2)
How do you think your proposed BSD model compares to something like RCU [sourceforge.net]?>/p>
Re:Good luck to you Matt. (Score:4, Interesting)
The problem with the GPL is that it doesn't trust its fate to human nature but instead tries to force an effect that tends to be against human nature. GPL is a license based on fear and uncertainty, at least from an idealogical standpoing. The BSD license recognizes human nature and works with it to far greater effect for the society as a whole. I prefer trust to fear. I'm just not the paranoid type and if one doesn't have commercial motives for using the GPL one really has to have a high level of paranoia to justify it. That is the reality of the GPL. I use it occassionally, but for commercial reasons only. Everything else I do under the BSD.
-Matt