DragonFlyBSD 1.0 Released

eeg3 writes "One year after starting the project as a fork of the FreeBSD-4.x tree, the DragonFly Team is pleased to announce its 1.0 release. Check out the project's diary for a list of the improvements the project has implemented. Also, be sure to grab it from one of the mirrors."

Comments

Serious question:

[Anonymous Coward]

What was the reason behind this fork?

Re:Serious question:

[RupertJ]

IIRC, the DF team wanted to implement SMP in a different way and weren't happy with the over-complicated approach in parts of FreeBSD. They're also ripping out a fair bit of the Perl dependent stuff too.

Check the DF interview article for more info.

Re:Serious question:

[swb]

Isn't Perl supposed to be dropped from FreeBSD's base real soon now? AFAIK it wasn't supposed to be a permenant part of 5, and wasn't going to be necessary to build world.

For a project that wanted to get away from FreeBSD, the final diary entry shows at least two imports from FreeBSD.

I can't be critical of a group of people that release their own BSD in their spare time, but I guess I'm not seeing SMP as being important enough to fork an entire BSD system.

Re:Serious question:

[Bloody Pulp]

DragonFlyBSD project is intended to take over development of the FreeBSD 4.X branch. Using a different method SMP and rewrite of packaging system.

Check out the original announcement of DragonFlyBSD on the FreeBSD stable list:

http://lists.freebsd.org/pipermail/freebsd-stabl e/ 2003-July/002183.html

Re:Serious question:

[Anonymous Coward]

Well, FreeBSD 5.X also take over development of the FreeBSD 4.X branch. They just don't do it the same way.

Re:Serious question:

[RupertJ]

Totally agree on the SMP thing. I work with some seriously "into it" techies (including myself) who live and breathe Linux/OpenBSD/FreeBSD/Solaris/HP-UX/IRIX at both work and home. Not a single one of them has a personal box with more than one CPU. Maybe that's a European, or maybe even specifically UK trend for developer's own kit at home. Weird. Maybe others would like to chip in here.

As for the "two imports" thing, the only OSS project that I was aware of a serious initial temporary code-freeze on was when Theo forked NetBSD into OpenBSD and audited the lot. But that said, they're now using NetBSD's SMP code as a starting point. Not that that is a bad thing, by any stretch of the imagination.

With Perl being dropped from FreeBSD, what are they actually replacing it with? (I know very little about the FreeBSD project and it shows =).

RJ

Re:Serious question:

[Anonymous Coward]

I have a couple SMP boxes at home.

Once you use a dual cpu machine, you never want to go back to single cpu.

This is true whether you're using Windows 2000/XP or *BSD/Linux.

When running Windows 2000, misbehaving apps that would normally suck up 100% of cpu only consume 1/2 of available cpu power.

Only downside (and maybe this is good for the reason mentioned just now) is that most apps don't take advantage of multiple cpus yet.

Another comment I have is that hyperthreading and other pseudo-smp technologies are evolving--so SMP might become more important sooner than we think.

Re:Serious question:

[Anonymous Coward]

They're not "trying to get away from FreeBSD". They think FreeBSD 5 has taken the wrong direction in some areas. They consider DFly to be the logical continuation of the FreeBSD 4 tree.

Because they're aware of how high quality FreeBSD is, they're very comfortable taking lots of code (drivers, etc) that would be impossible for such a small team to write/maintain. All they have to do is modify the code to work with their kernel modifications.

In addition to their kernel changes, they plan on (eventually) having a "better" ports system, with support for things like multiple versions installed concurrently, and selectable with variant symlinks.

Really, there's a lot more to Dfly than just improved SMP. Take the time to peruse the site and mailing list archives to learn more.

Re:Serious question:

[bsd_usr]

They're dropping Perl from the base. Meaning that it won't be required in order to build the system. Also, it will be installed as a third party port (add-on software).

Actually, the 4.X branch still has Perl in the base system. The 4.X branch is where DFBSD forked from. The 5.X branch is where Perl was removed.

Before, there were quite a few "system" programs that were perl scripts. Those programs were rewritten as "C" programs in order to rid the dependency of Perl in the base system.

It's not a bad thing. A Unix OS really doesn't need Perl. And if you really do need it, you can easily install it via the ports system or via the package system. No biggie. Makes the base install smaller and neater.

Re:Serious question:

[RupertJ]

Good points, and it could also be that quality multi-CPU hardware always seems to fetch a hefty price here in Blighty. I remember seeing a Sun Ultra 80 with 4 x 400MHz processors going for something like US$600 on eBay USA, whereas a dual 300MHz Ultra 60 went on the UK site for about equivalent $650. Before anyone jumps down my throat with quotations for a dual P4 Xeon, notice the first line included the word "quality".

I've just bought an HP Visualize Workstation from a place in the USA. In the UK, 400 (~US$750) would have got me a C3000 with FX2 graphics, 512MB RAM and a 9GB SCSI disk. For the same money in the USA I got a C3000, FX4, 1GB RAM, 76GB Disk, plus loads of extra accessories and software ... AND that includes insured airmail shipping to the UK.

And that's just a single CPU system!!!

Re:Serious question:

[m.dillon]

Well, price and power is also a downside, especially if you run the boxes 24x7. All of our dual-cpu boxes (primarily DELL-2550's and some old VALinux boxes [running FreeBSD or DragonFly]) eat power like there was no tomorrow. Our single-cpu AMD64 boxes, on the otherhand, are twice as fast (as both cpus in the dell put together) and eat half the power (or less).

In nearly all cases you will be paying a premium for a SMP box over a UP box, so much so that if space is not an issue for you, and you have no special requirements (e.g. big honking database app), it will be more cost and maintainance effective to buy two single-cpu boxes then one dual-cpu box.

What this means is that I, at least, am turning off the SMP boxes in my machines room as fast as I can migrate them to new, faster, and far cheaper UP boxes.

On the flip side, though, both Intel and AMD are moving to dual core (and power-pc has had quad cores for a long time), so a SMP-efficient kernel design is as important as ever. Within the next 5 years I believe that all consumer cpus will be dual-core at a minimum.

Now all one needs to be able to do is seemlessly cluster them together, which is precisely one of our long-term goals! (seemless != the current hacks you see on Linux currently).

-Matt

Re:Serious question:

[NanoGator]

"Only downside (and maybe this is good for the reason mentioned just now) is that most apps don't take advantage of multiple cpus yet."

It's still useful even when you don't have SMP software. If you have an app that's burnin all of one CPU up, you still have the other CPU available to do just about anything else. For example, I have a plugin for Lightwave that is a 3D renderer. It's not multi-threaded yet, so I couldn't make it go faster with both processors. So while that was rendering, I played a game of Quake. Q3 ran great, and the rendering still happened on time. Pretty slick.

Re:Serious question:

[tverbeek]

Once you use a dual cpu machine, you never want to go back to single cpu. This is true whether you're using Windows 2000/XP or *BSD/Linux.

Or OS X.

Budget constraints forced me to buy the least-possible PowerMac G5 for my home system last year, with only 1 CPU. The dual-G5 systems at the work place make me wish they paid me well enough to afford one ("two"?) myself.

Re:Serious question:

[aanantha]

SMP will be mainstream very soon. You already need SMP support to use Hyperthreading/SMT. All recent Pentium 4's are 2-way hyperthreaded: so 2 logical processors. 2 sets of registers with shared functional units and cache.

Intel and AMD will be coming out with dual core CPUs by the end of next year: 2 CPUs in one chip with a very speed interconnect between the two. A dual CPU configuration is often faster than a single CPU that's twice as fast. (On the other hand, Hyperthreading gives a measly 30% at most). A dual core Pentium series processor would have 2 real processors each with 2 logical processors: so a quad processor. Once all new computers have at least 2 processors in them, the operating systems that can utilize them effectively will be have a significant advantage.

Re:Serious question:

[MavEtJu]

A Unix OS really doesn't need Perl.

That was not the reason. The reason is that there is more than one Perl version out right now (5.0, 5.6, 5.8) and that different people need different versions. So to get rid of this, Perl is removed from the base-system and if you need whatever-version of perl, install it via the ports system. Much more flexible.

Edwin

Re:Serious question:

[pyrrhonist]

Not a single one of them has a personal box with more than one CPU.

Does any of your friends have a CPU with Hyperthreading? That uses an SMP kernel, doesn't it?

Maybe others would like to chip in here.

Ha! I get it!

Re:Serious question:

[Alan Hicks]

Well, price and power is also a downside, especially if you run the boxes 24x7. All of our dual-cpu boxes (primarily DELL-2550's and some old VALinux boxes [running FreeBSD or DragonFly]) eat power like there was no tomorrow. Our single-cpu AMD64 boxes, on the otherhand, are twice as fast (as both cpus in the dell put together) and eat half the power (or less).

I can't speak for whatever you're VA-Linux machines are, but aren't those Dells 2U rack mounts with something like 800 Mhz processors. Comparing that to a modern Athlon64 or Opteron isn't exactly fair.

For the record, my purely anecdotal evidence follows. SMP machines are an order of magnitude better than a single UP, even at a lower combined clock rate. They just seem to work better, balance things better, and never get particularly bogged down by any single process like a UP machine.

Re:Serious question:

[name773]

kudos to you (seriously), puns are great, too bad they aren't appreciated by everyone... glad to see you making one :)

Re:Serious question:

[be-fan]

Actually, a dual CPU configuration is rarely twice as fast as a single CPU that's twice as fast. Especially not in shared-bus architectures like the P4. Or the dual-core P4/AMD64 CPUs, which will share a memory bus.

Re:Serious question:

[Anonymous Coward]

All joking aside, FreeBSD really is "dying" in a sense. After Jordan and Mike left, the project has been a shambles. The best way to describe FreeBSD kernel code now is "shabby". Matt is a brilliant perfectionist who wants to do the right thing. The current state of FreeBSD kept him from pursuing excellence.

Unfortunately the FreeBSD core has come to be dominated by political types who are short on engineering skills. They gave Matt the air and locked him out of CVS. The FreeBSD kernel is currently full of ugly expedient hacks *and* several intractable bugs.

Of all the BSD kernels, FreeBSD can now be considered the most hackish and ill conceived. It wasn't always this way, of course. But presently the FreeBSD development environment continues to favor the political solution over the technically correct one. OpenBSD and NetBSD both do much better on quality issues. I suspect that DragonFly will come to be highly regarded as well.

Re:Serious question:

[Tony-A]

Not a single one of them has a personal box with more than one CPU.

I can think of a very "sneaky" reason why. Dual processors tend to make response time much less dependent on system load. For a server, consistent response can easily be more important than the average response. It's predictable. For a developer on his own machine, this benefit only serves to mask variations that are important to the developer.

Re:Serious question:

[Brandybuck]

But without a scheduler specifically written for hyperthreading, you might not get that great of performance. Hyperthreading and true SMP just act differently.

Re:Serious question:

[kylemonger]

With Perl being dropped from FreeBSD, what are they actually replacing it with? (I know very little about the FreeBSD project and it shows =).

Leaving aside CPAN, Perl is a nice integration of sh, sed, grep and awk. sh, sed, grep and awk are still there, so you probably don't have to replace Perl with anything.

Re:Serious question:

[nusuth]

Once you use a dual cpu machine, you never want to go back to single cpu.

Hmmm, isn't it a bit too far-fetched? What's the advantage of dual cpu machine for Internet browsing? Or editing files? Or for gaming (decent video card is more important here)?

He doesn't say a dual cpu box is optimal, he say you don't want to go back, which, IMHO, is very true. I have used a few single cpu computers faster than mine but none have the same fluidity and responsiveness of my dual athlon mp box. This is purely a perception thing. Many GUI and IO operations use 100% of CPU time for short burst intervals. On a single CPU system, you notice unresponsiveness. A faster CPU just makes that time shorther. On a SMP system, as long as not all CPUs are pegged - which doesn't happen all to often- you don't notice that.

Re:Serious question:

[aanantha]

Actually, a dual CPU configuration is rarely twice as fast as a single CPU that's twice as fast.

This was a typo, right? Because I said 2 CPUs were often faster than 1 CPU running at twice the clock rate, not that it was twice as fast. I admit that "often faster" was overstating it. It really depends on how parallel and I/O bound your workload is. The responsiveness of a dual processor system can be better than a single processor system because there will be half as many wasteful context switches per CPU.

Especially not in shared-bus architectures like the P4. Or the dual-core P4/AMD64 CPUs, which will share a memory bus.

Yes, the P4 has a terrible multiprocessor bus architecture as do all Pentium processors. But that's because Intel didn't care. The standard Microsoft operating system for the desktops (Windows 9x) never supported multiple processors so there wasn't much incentive for Intel to optimize their bus for it. The AMD64's bus is far superior, and so is the PowerPC's.

And for a dual core, the interprocessor bandwidth will be much higher and the latency much less. Cache coherence is handled on die. The dual core Opteron will still have 2 distinct L2s. But they won't have to go off chip to maintain coherence between each other. There's no HyperTransport latency for snooping between L2s on the same die. And the off chip (HT) latency will be the same for dual core as it is for a single core.

Re:Serious question:

[LWATCDR]

"For the record, my purely anecdotal evidence follows. SMP machines are an order of magnitude better than a single UP"
I do not think that you mean an order of magnitude. An order of magnitude would mean that you think an SMP machine is 10x better than a UP machine.

It is an easy rule of thumb. You buy an SMP machine when you can not find an UP machine that is fast enough.

Re:Serious question:

[swb]

Totally agree on the SMP thing. I work with some seriously "into it" techies (including myself) who live and breathe Linux/OpenBSD/FreeBSD/Solaris/HP-UX/IRIX at both work and home. Not a single one of them has a personal box with more than one CPU. Maybe that's a European, or maybe even specifically UK trend for developer's own kit at home. Weird. Maybe others would like to chip in here.

I'm actually replacing a dual CPU system (PIII-667) with a single CPU system. I think you can get longer life out of a dual CPU system, especially in a server environment, and for a workstation it's nice to have the extra response when running piggish single-CPU tasks.

However, when building my new box I found that the prices for SMP were just too high, unless I was willing to seriously sacrifice single CPU performance. Either I got a fast single CPU system or a much slower dual CPU system for slightly more money. I could get an equivilent performance dual system, but it was more expensive by at least a factor of 2. It's too bad AMD and Intel don't let you go 2-way with a standard CPU.

The other thing I found after several years of owning a SMP system was that there were very few apps that I ran that made good use of the SMP setup. I got good desktop performance and could do some CPU intensive stuff on one CPU while doing something on another CPU, but overall my second CPU was largely idle.

Re:Serious question:

[Anonymous Coward]

> Ha! I get it!

How often?

Ba-da-chink! Thank you, thank you, I'll be here all week. Try the veal.

Re:Serious question:

[LordMyren]

friends dont let friends drive non-smp machines

Re:Serious question:

[phoenix_rizzen]

Perl was removed from the source tree with the release of FreeBSD 5.0. The installer installs Perl from a package so that the installed system still has Perl. But, it can be removed with a simple "pkg_delete perl\*" or upgraded to whichever version the user wants/needs/requires. All the system administration scripts that were written in Perl have been rewritten in either C or sh.

DragonFlyBSD doesn't "want to get away from FreeBSD". They want to try out new directions, new technologies, new ways of doing things. There have been several dozen imports from FreeBSD 4.x and 5.x, as well as from NetBSD and OpenBSD. That's the nice thing about the BSDs: they are all separate projects, but the source code flows freely between them all.

Considering that SMP will soon become standard issue in the x86 world, I don't see how SMP can not be important. Both Intel and AMD are putting the finishing touched on their dual-core CPUs. In another year, two at the most, you'll be buying a system with one physical CPU "chip", but two physical CPUs on it, making every system an SMP system.

There are several different ways to make an SMP system. FreeBSD 4.x used a simple "Big Giant Lock" on the kernel. FreeBSD 5.x uses fine-grained, mutex-based locking and Kernel Scheduled Entities. DragonFly will use a lockless, message-passing system based on Lightweight Kernel Threads. Very different beasts, and it's not possible to use both LWKT and KSE in the same system. Why not fork off another project, see if it works or not, and either let it live as a separate OS or fold the tech back into FreeBSD as needed?? Forks are not inherently bad things.

Re:Serious question:

[eofpi]

What's the advantage of dual cpu machine for Internet browsing? Or editing files? Or for gaming (decent video card is more important here)?

I'm sitting on a dual athlon system right now, and, as others have said, there's a feeling of fluidity with SMP systems that makes it worth it if you multitask much, even if it's all relatively lightweight stuff (IRC, web browsing, email, etc.).

For file editing, it depends on the kind of files. Your basic office stuff won't benefit any more than the aforementioned internet usage will. But if you're working with media, it will go a lot faster (not quite a 100% gain, because of SMP management overhead, memory bandwidth limitations, etc., but it will be well above 50% for anything multithreaded, and allows you to do multiple instances for single-threaded things).

Gaming will start to show more benefit as hardware shifts things that are traditionally hardware functions into their drivers (particularly 3D audio in sound cards, as shown here). When a sound card is trying to use 30% of a cpu for 3D audio (as one sound card in that link did at times), that'll have quite an effect on gaming performance on a single-cpu system. An SMP system will just have the other cpu pick up the extra load from the sound card drivers, along with whatever network, AI, and other threads the OS load balances onto it, leaving the first cpu free to handle whatever's most cpu-intensive in the game (usually graphics).

Re:Serious question:

[pyrrhonist]

But without a scheduler specifically written for hyperthreading, you might not get that great of performance. Hyperthreading and true SMP just act differently.

So what you're saying is that BSD doesn't do hyperthreading?

Re:Serious question:

[Brandybuck]

Of course not. Sheesh!

It (as in FreeBSD) does indeed do hyperthreading. But don't expect huge performance boosts after turning it on. For some usage profiles you might see an improvement, but for others you might actually get a performance decrease.

This is simply because FreeBSD hasn't specifically targetted the scheduler at hyperthreading. What it does is to treat treat a HT CPU machine as if it were a dual-CPU SMP machine. The official adjective to use in this situation is "naive".

This doesn't mean that FreeBSD is "dying". It merely means that without software specifically written for it, "hyperthreading" is merely marketing masturbation. The situation is much the same with "stock" Windows and Linux, though with the latter I understand you have a choice of schedulers.

Should FreeBSD spend a lot of work getting a hyperthreading scheduler up and available? Considering that hyperthreading is soon to be obsolete with the emergence of dual core CPUs, I would say no.

Re:Serious question:

[aanantha]

Aaaand I quote (from your own grandparent comment):

A dual CPU configuration is often faster than a single CPU that's twice as fast.

No mention of clock rates there.

My mistake, that was what I meant but I did a bad job of writing it. No doubt, getting double or more of the performance by adding a second CPU is absurd. But being able to do better than a clock rate double is something that we can expect with a good dual processor implementation when software is parallelized. Sun recently claimed a 1.8 times performance boost with the dual core UltraSparc IV over the same clock rate single core UltraSparc III. A clock doubling offers much less than double the performance because of the bottleneck that is main memory latency.

Re:Serious question:

[TheLink]

The reason why SMP systems are more responsive for most people is because there's lots of "wasted" CPU - you can't easily use all CPUs. I'd like to see how responsive your system is when you have the same number of CPU intensive programs running as the number of processors you have.

People who want responsiveness above everything would probably like an O/S task scheduler that always reserved CPU and time slice for UI processes, or refused to give more than X% of CPU to any process - never 100%, even if it means having unused resources. Voila, nearly the same fluidity you'd get with two CPUs of half the GHz.

It seems to be a scheduler issue. If the priorities of a scheduler was responsiveness and not efficient usage of a CPU you might get better responsiveness. It does not seem easy to make a scheduler that provides both super responsiveness and super efficient CPU usage.

For the price of most dual CPU systems I'd rather spend a bit more and get two PCs.

AMD's "drop-in" dual core thing _may_ change that. We'll see.

Re:Serious question:

[TheLink]

" and never get particularly bogged down by any single process like a UP machine. "

Doh. That's coz most people haven't figured out a general/common way to make single process use both CPUs, so when you have a single process, extra CPUs are wasted.

One person's bogged down system is another person's CPU-usage efficient system.

Re:Serious question:

[TheLink]

"What it does is to treat treat a HT CPU machine as if it were a dual-CPU SMP machine. The official adjective to use in this situation is "naive"."

"Naive" isn't so bad in that situation.

"Naive" is bad when you have a dual HT CPU machine being treated as a real quad-CPU SMP machine.

It's ugly when you have two CPU intensive processes being migrated to two HTs on ONE real CPU, instead of being migrated to TWO real CPUs.

This HT thing is really overrated. It probably works well for _some_ programs that don't make efficient usage of a processor's execution units - so running two instances would maximize CPU usage.

For some reason turning on HT seems to make things slower for most server stuff - apache, DB, at least in the benchmarks I've seen.

Re:Serious question:

[TheLink]

"of the bottleneck that is main memory latency."

Well if the two CPUs share the same path to memory then I don't see how two 1.5GHz CPUs would _often_ be faster than one 3GHz CPU. Since with the exception of the Opteron, most current common SMP systems have the CPU's sharing the same path to memory.

AFAIK Dual-core CPUs would share the same memory paths. Worse if they share the same cache - they'd be messing each other's cached entries.

Sorry but my BS meter wiggled a bit when you said Sun claimed _its_ 2 CPUs = 1.8x 1CPU and then added some handwaving to try to stretch that to say that 2 CPUs would be faster than 1CPU with double the clock rate (all else remaining same).

Maybe when I have time I'll go see if a 2GHz CPU is slower than 1.8 x a 1GHz CPU of the same or similar architecture. Doubt if I can do that given my CPU multipliers, but I could probably do something close.

Anyway it's not that simple - lot of stuff isn't memory bandwidth starved. And the "often faster" is quite subjective ;).

Re:Serious question:

[c13v3rm0nk3y]

I can't be critical of a group of people that release their own BSD in their spare time, but I guess I'm not seeing SMP as being important enough to fork an entire BSD system.

That would be one of the main points. DragonFly wanted to get away from a specifically symmetric model (the "S" in SMP) that was being adopted for FreeBSD 5.x.

Part of their aim is a more modern MP model that also benefits UP, and does not depend on symmetric processing. This can also gives them a headstart on support for the future multi-core CPUs, which are decidedly not symmetric.

Also, this fork is not about "getting away" from another BSD at all. All BSDs borrow heavily from each other -- it's part of the culture.

Re:Serious question:

[phoenix_rizzen]

The P6 and NetBurst SMP architectures use a shared memory bus. This means that as you add CPUs to a system, you decrease the memory bandwidth available to each CPU. The total memeory bandwidth of the system never changes.

The K8 architecture uses a point-to-point memory system. The Opteron CPU includes the memory controller on the die and uses HyperTransport links to communicate between CPUs. This means that as you add CPUs to a system, you increase the overall memory bandwidth of the system. Each CPU only get 6.4 GB/s (or thereabouts) of bandwidth, but that's per CPU. Put in 2 or 4 CPUs, and you have 12 or 24 GB/s of memory bandwidth.

Ars Technica has a nice comparison of the 3+ GHz Xeons with 3 MB L3 and the Opteron in 1, 2, and 4-way configurations. Very enlightning little article, and shows just how horrible SMP on Intel hardware really is.

Re:Serious question:

[Pieroxy]

People who want responsiveness above everything would probably like an O/S task scheduler that always reserved CPU and time slice for UI processes, or refused to give more than X% of CPU to any process - never 100%, even if it means having unused resources. Voila, nearly the same fluidity you'd get with two CPUs of half the GHz.

Ok. Can you indicate me such an os task scheduler? So far I've tried SMP on linux and Win(NT, 2k, XP) and all three of them really are smoother, no matter how many pegged CPUs you have. IE: even with two 100% processes running in normal priority, the 2 cpu box feels more responsive than the same box with 1 cpu and only one 100% process running.

And if I believe this thread, the same trend can be observed on Mac.

So please indicate which OS you are referring to, cause I'd be interested.

Re:Serious question:

[Frobnicator]

The reason why SMP systems are more responsive for most people is because there's lots of "wasted" CPU - you can't easily use all CPUs. I'd like to see how responsive your system is when you have the same number of CPU intensive programs running as the number of processors you have.

Multiple CPUs *do* help on modern OS's. Most programs, including the OS and its API, spawn off threads for many reasons. You say I can't easily use all the CPUs. In reality, you could wake up a dozen or more threads (meaning that for an instant, you could use that many CPUs) by simply moving the mouse between two windows.

Just checking on four local boxes: On my XP development machine, I have 501 threads running under 44 processes, with about 5% CPU usage. On a small XP server box, I've got 258 & 18, and moderate load. Our multi-CPU linux and Solaris boxes are similarly not seriously loaded (about 95% idle, a few hundred processes, and I'm sure there are thousands of threads).

Most of us don't use ALL the CPU speed ALL the time, although math intensive simulations (such as games) can do that. More often, your apps end up waiting for the user, the disk, the network, and other I/O. But we don't think about that time. We don't care if the back buffers of the animated .GIF files are running 100 milliseconds behind what they ought to. Most of us only care that when I push the 'x' key, that the little glyph better show up on the screem immediatly; when we move the mouse around our desk, it better move the arrow at the same time, and light up any hover buttons instantly.

Usually when you interact with the box, you end up waking up lots of threads. Just moving the mouse around can wake up dozens or possibly even hundreds of threads. The mouse generates some interrupts, that needs to be processed by one or more drivers, drivers report to the OS which generates messages that are queued in the windowing system, movements generate even more messages which are all dispatched to programs, each program has to deal with the mouse movements individually. Events are handled by possibly several applications, each of these incuring their own set of scheduling problems, cache misses, and memory or disk accesses. It might not seem like much to you, but it really is a lot of CPU work to move the mouse out of one application window, and over an image-changing icon in another app. If it doesn't happen within 50 milliseconds or so, you normally feel that the system is pretty slow.

Every one of those things incurs a cost from scheduling and queuing to changing of the CPU protection ring. For that split second, your computer has lots of work to do.

The second processor cuts that split-second load almost in half, which is noticable to most of us. Sure, there is a tiny bit of overhead, but if you've did much low level programming, you'd know that all those CPU state changes and context switches are EXPENSIVE, splitting those expensive calls between two CPUs really helps.

For the price of most dual CPU systems I'd rather spend a bit more and get two PCs.

That is your choice. Seeing as I alrady have enough computers to do the work I need, I'd rather get a 2 CPU, or even a 4 CPU, box for my local software development. Spend the money where you get the most bang for your buck. For you, that might mean a second machine. For me, where I have multiple monitors hooked up to my XP boxes, for watching and debugging the interaction between applications, the most bang for my buck is in a multi-CPU system.

frob

Re:Serious question:

[aanantha]

Anyway it's not that simple - lot of stuff isn't memory bandwidth starved. And the "often faster" is quite subjective ;).

You're missing the point. I'm not talking about memory bandwidth, I'm talking about memory latency. Very few programs have any natural need for a lot of memory bandwidth. What they do want is low memory latency. But there's a fundamental problem: CPU performance increases outpace memory performance increases. Most programs, most of the time, are waiting for a memory access to complete. The direction you take on a conditional branch often depends on the result of memory access. There's branch prediction, value prediction, and all that but they can only go so far. They don't work well enough to keep CPUs occupied. The goal is to let a CPU do other things while waiting for a memory access to complete. The benefit of SMP and SMT is that you're working with 2 threads each with separate stacks and registers. If you imagine the simple case where your memory controller can only handle one memory access at a time, one thread can do its computation while another waits for the memory access. The other thing you need to consider is context switching. When you switch contexts, your virtually addressed cache and TLB are meaningless. You have to save your registers. That takes a hell of a lot of time because it's completely a memory latency bound operation.

I also never said that Sun's claims on UltraSPARC IV performance should be accepted at face value. They all cheat. But the one thing you won't hear claimed is that they'll get double the performance by doubling the clock rate. That's too easy to disprove. If that was possible, Intel wouldn't even be screwing around with EPIC and dual core.

And obviously, if code isn't multithreaded with few accesses to shared memory then that program won't run any faster. But nowadays people run multiple programs at once, and like having good response time when switching between them. However, that improvement is hard to quantify and it has really prevented SMP from going mainstream earlier.

Re:Serious question:

[aanantha]

When you switch contexts, your virtually addressed cache and TLB are meaningless.

Correction, I should have said that your virtual addressed TLB and the (physically addressed) cache have no values meaningful values for the next thread/process that is context switched in. The TLB gets flushed and the cache will be overwritten. So you hit main memory quite a bit on context switches. It's very very wasteful.

Re:Serious question:

[eofpi]

and never get particularly bogged down by any single process like a UP machine.

Doh. That's coz most people haven't figured out a general/common way to make single process use both CPUs, so when you have a single process, extra CPUs are wasted.

Well, the BeOS folks did, but that OS is now rather dead for other reasons.

And we care... why?

[LostCluster]

For those of us hearing about this fork for the first time, could somebody explain what these people felt was so wrong about the FreeBSD tree that they decided to go off on their own?

Or, to put it another way... what's the diference between DragonFlyBSD and FreeBSD?

Re:And we care... why?

[Teckla]

For those of us hearing about this fork for the first time, could somebody explain what these people felt was so wrong about the FreeBSD tree that they decided to go off on their own? Or, to put it another way... what's the diference between DragonFlyBSD and FreeBSD?

With all due respect, they answer your questions right on their home page! RTFHTML!

Re:And we care... why?

[eeg3]

Quoting Matt Dillon, the project creator:

However, while committer relations have always been an issue, DragonFly split off from FreeBSD-5 over major architectural differences, not anything else. We really do feel that FreeBSD-5 is taking the wrong approach to SMP and building something that is so complex that it will ultimately not be maintainable. We think we have a better way.

You can find more information if you actually visit the project homepage, or read a fairly recent ONLamp.com interview with the developers.

Re:And we care... why?

[sparrow_hawk]

Umm... why would you RTFHTML? You only need to RTFHTML if you don't have a Web browser installed and are telnetting to port 80...

(wink)

FreeBSD 5

[CaptainPinko]

They felt that the approach the FreeBSD was taking for FreeBSD 5 was going in the wrong direction. I believe they hada problem with all the Mutexs or something specific like that. The main focus of DragonflyBSD is scalability and clustering. The are hoping to have SIS (Single Image Systems) as a priority. It won't be hear anytime son but thats a long term goal. OSNews has had some stuff on them over that last while. Here is the thread http://osnews.com/comment.php?news_id=7660 and here is the torrent I used http://download.exodusmachine.net/torrents/dfly-1. 0REL.iso.gz.torrent . Let me be the first to say: I for one welcome our new Dragonflu overlords! http://www.dragonflybsd.org/main/mascot.cgi

Re:FreeBSD 5

[chrwei]

Let me be the first to say: I for one welcome our new Dragonflu overlords!

great, another new strain of the flu

Packages?

[RLiegh]

What is the ports/packages situation look like for Dragonfly? Have they ported the old ones over, or is their selection severely limited?

Re:Packages?

[eeg3]

Quoting Matt Dillon, the project creator:

We have been in rigorous discussion over what kind of ports/packaging system we want to have. We have already agreed that the core ports/packaging system visible to end-users should be a binary system rather then a source build system. This isn't to say that sources would not be made available for customization purposes, just that most users just want to get a port/package installed as quickly as possible. While the BSD ports/packaging system does have a binary install capability it is insufficient for our needs.

The other thing we've decided on is to give the ports/packaging system the ability to isolate installations. One of the biggest problems one has maintaining a large multi-use system is when upgrading a package for one particular subsystem. Upgrades to the packages for one subsystem can interfere with packages already installed for another, and sysops cannot afford to have upgrades break unrelated subsystems. So, for example, we want there to be isolation between the packages associated with, say, the mail subsystem, and packages associated with, say, a workstation user. The two subsystems might install the same package or might install different versions of the same package... we want that to work.

Also... in response to whether they might use pkgsrc, he replies...

We are considering everything. Nothing is set in stone yet.

Re:Packages?

[m.dillon]

It's a big hack at the moment... we have an override system that runs on top of FreeBSD ports to try to keep the more interesting ports operational.

The DragonFly team has been discussing what ports/packages system to move to (or to build one) that supports our requirements. We've investigated several existing packaging systems so far and are right now investigating OpenPkg (www.openpkg.org), as it has the multi-instance support that is an absolute requirement for us.

Keep in mind that the DragonFly *USERLAND* is still primarily FreeBSD-4.xish (though with all the C99 stuff from FreeBSD-5 integrated), so anything that runs on 4.x will run on DFly with only minor tweaking.

-Matt

Re:Packages?

[XeRXeS-TCN]

From their downloads page on the site:

GoBSD.com, a BSD-centric community website, is providing access to thousands of pre-built DragonFly software packages. These can be added via pkg_add -r packagename.

From a quick cursory glance at the site, it looks like there are more than enough packages sitting around to be getting on with, you shouldn't be left with nothing to use if you don't want to.

And there's always the option of compiling from source...

Re:Packages?

[Hatta]

Keep in mind that the DragonFly *USERLAND* is still primarily FreeBSD-4.xish (though with all the C99 stuff from FreeBSD-5 integrated), so anything that runs on 4.x will run on DFly with only minor tweaking.

Now I'm really tempted to switch to BSD. Can't beat a system with integrated C99

Re:Packages?

[cant_get_a_good_nick]

But after playing with DFly, would you get the munchies?

Re:Packages?

[bcrowell]

The DragonFly team has been discussing what ports/packages system to move to (or to build one) that supports our requirements. We've investigated several existing packaging systems so far and are right now investigating OpenPkg (www.openpkg.org), as it has the multi-instance support that is an absolute requirement for us.
Took a look at openpkg.org, and it seems interesting. What is multi-instance support?

Do you think OpenPkg has any advantages for the end-user, or are the differences more like things that systems dudes would care about? My perception as a FreeBSD desktop user is that the ports system, although it's great in many ways, has been saddled with some awkward inherited problems. The portupgrade system is bolted on rather than designed in, and although portupgrade is supposed to be optional, it seems like more and more developers are acting as though they expect it to be mandatory. I've had a lot of problems with doing a portupgrade in order to fix a dependency problem, only to find that it hoses my whole system.

Re:Does it run Linux?

[RLiegh]

Emulating linux, and running linux kernel modules are not the same thing, as anyone who has fought to use vmware under NetBSD (a 50/50 proposistion) can tell you.

New BSD distros...

[NoMoreNicksLeft]

Deserve their own slashdot icon. Give this thing 3 months, and if they're still around, do the right thing Taco.

Re:New BSD distros...

[/dev/trash]

Yes please Taco in the scope of the world that includes war and poverty PLEASE make a BSD icon!

Re:New BSD distros...

[ArbitraryConstant]

Well, they've been around for a year. Another 3 months won't be a problem.

But why do they need an icon?

Re:New BSD distros...

[Nimrangul]

I think it is supposed to be for more equality and fairness between Linux and BSD.

There is a Redhat, Debian, SuSE, Novell and Caldera icon, then there is a BSD icon. I'd think would it nice to have a Horde, Charlie, Puff and Fred icon for these guys.

Re:New BSD distros...

[ArbitraryConstant]

I'm biased towards BSD, but honestly I don't think each of them independantly create enough article traffic to justify extra icons.

Re:New BSD distros...

[Nimrangul]

And much of the news reported for the various Linux distrubitions isn't really justifications for them having their own icons, yet they do.

As I said, that is how I interpreted his post, may not be what he actually means, but I agree with what I think he said.

Obscure Fawlty Towers reference....

[Anonymous Coward]

fish wife!....flying tart! no, no! It got off to a flying START, and it's name...

was DragonFly!

Re:Obscure Fawlty Towers reference....

[0racle]

Now now now, O'Reilly, no need to post anonymously. You're gonna have that gnome inserted into you either way.

Re:Sounds cool

[eeg3]

Although their team is small, it's compiled with very competent and capable developers such as Jeffrey Hsu and Matt Dillon, among others.

Also, a small commit team helps get things done at a faster rate, whereas it's not so hard to get things added.

Six Syllable Names Suck

[Anonymous Coward]

The logo looks neat but the name is way too long to pronouce in conversation.

Maybe they could name it Firebird. Oh wait...

Re:Six Syllable Names Suck

[Alan Hicks]

the name is way too long to pronouce

DFly.

Re:Six Syllable Names Suck

[Brandybuck]

...as in "my system it d'fly man!"

Re:Does it run Linux?

[DashEvil]

/usr/ports/emulators/vmware-tools4

Re:*BSD is dying

[Anonymous Coward]

Good News Everyone!
Turns out that *BSD is stronger than ever!
According to an Inernetnews article, Netcraft has confirmed that *BSD has "dramatically increased its market penetration over the last year."
There has been a steady increase in *BSD developers over the past decade.
There are currently 307 FreeBSD developers as of the 2004 core team election.
You can read more about FreeBSD here

If you would like to try out a BSD, you can download: FreeBSD, OpenBSD, NetBSD, or DragonflyBSD
Enjoy!

Any visible userland differences

[beforewisdom]

Does Dragonfly offer any visible differences to the casual end user?

Re:Any visible userland differences

[CaptainPinko]

Read Matt Dillion's post. Most of the userland *IS* FreeBSD and most of the improvements are geared toward SMP.

The beat of a different drummer

[stox]

Congratulations to the Dragonfly team! Instead of continously whining and moaning, they are speaking their opinion with what really matters: hard work and code. It will be interesting to see how well it continues to develope and evolve.

Re:Does it run Linux?

[kardar]

FreeBSD (I am using 4.10) has a Gentoo "stage 1" port, actually.

There is a directory called /usr/compat/linux, under which you have all the usual /usr (that would be /usr/compat/linux/usr/, if you know what I mean) and /bin and /lib, and so on...

so you... "chroot" into /usr/compat/linux and then you can "make system" or whatevever. It's not bad.

The default is a Red Hat - I have what is essentially a basic Red Hat 9.0 system on my FreeBSD machine, there is also a port for Debian Stable.

So you can do vmware for Linux, or you can do vmware for FreeBSD, just like you can do Mozilla for Linux, or any other app for Linux. I imagine you could install portage under /usr/compat/linux/usr/portage by chrooting into /usr/compat/linux and emerging sync, and then emerge whatever you want - as long as you are chrooted, it should work (I haven't tried it). So everything you emerge should be done while you are chrooted into /usr/compat/linux - if I understand this correctly -- however, the Gentoo port, the Gentoo FreeBSD port, under /usr/ports/emulators/, would be installed like any other FreeBSD port - and actually, there are many FreeBSD "Linux" ports that can be installed automatically from the FreeBSD ports system, no chrooting or anything required. The chrooting would be if you wanted to leave FreeBSD behind and enter into Linux land - apparently this works, but I haven't tried it. Everything I have needed to install that is a Linux binary has been available as a FreeBSD port.

Another cool thing is that you can apparently upgrade from FreeBSD 4.9 and above to Dragonfly BSD, which is something I will probably be doing at some point in the future.

Re: It's a big hack at the moment!!!

[Garin]

I think you're going too far with what the OS is all about.

The integrated OS concept is more about all the base utilities and such being all part of the release. Your bootscripts are xBSD bootscripts. Your /bin/foo is xBSD's /bin/foo. Your kernel is the xBSD version kernel. The core system is a fully-functioning ready-to-go operating system.

This contrasts with Linux because Linux is just the kernel. You build your own ls, your own tar, your own bootscripts, your own login systems and password checkers, etc.

The ports tree is above and beyond all of that. Any properly (for my particular version of "properly") configured production FreeBSD server will definitely NOT contain the ports tree, for example. It will have the base FreeBSD operating system plus exactly the installed packages that it requires to do its job properly. Nothing more.

future vs. now

[r00t]

You're comparing future DragonflyBSD features
with current Linux features.

Hey, Linux has a future too. It isn't stagnant.
There are a number of active projects to give
seamless clustering to Linux. The filesystem
will be shared, including coherent page cache
and user-accesible (flock, etc.) locks. There
are a couple SSI projects. This stuff now has
a conference of it's own. Major developers care.

Re:future vs. now

[Brandybuck]

OMFG he criticized Linux! I'm going to cry!

Re:future vs. now

[Anonymous Coward]

I've been an avid follower of the developments in FreeBSD for around 5 years now, so my overview of the entire history of "glue that binds" FreeBSD together isn't complete. That said, I've come to be a bit disappointed at how events in the last 18 months or so seem to be pushing the project in a direction that has made things more difficult, instead of more successful, that has shown distain for experience and quality and made FreeBSD a platform for large ego's to push their personal projects down everyone's throat.

The statistics sample from 2001 over a year was a cheap attempt to minimize Matt's contribution to the project. The reason why he has been mostly silent is probably one of the most prominent signs of his superior maturity. The fact that the official defense (mostly fronted by Greg, atm) he wasn't such a substantial committer is crap, for the most part. If one wanted to go by the stats, Jeff Robertson (sorry if I munged the spelling) would be one of the key committers, and his UMA system isn't even entirely ripe yet, it's just been committed within the sample timeframe. That suddenly phk is at the top of the list, is simple a result of his newest attempt to add another large chunk of bit rot to the project that he can later claim not to have time to maintain "unless someone is willing to pay for my time" (like the atm bits, the half-finished devd monster, et.al.) One can hardly get him to look at his malloc bits, that put his name in lights at some point in the long past.

Matt didn't contribute because he was convinced that that the smp development direction that was chosen (my impression at least from the archives and my fading memory) was overly complex, too complex for the number and talent level of the contributers involved, and that it would delay a release from the -current branch significantly. So he was right. I'll almost bet that that was a constant sore for John, who still hasn't gotten his long-promised, but little delivered re-entrant work done, but he always had time enough to object to any other commits that might help along the way. Strangely Julian and Matt could work together. One might attribute certain commits to both Matt and Julian (if that would matter anyway, since -core is interested in proving the opposite statistically).

If the issue here had anything to do with IPFW, then you all better get out your C-coder hats and take a little more time to fix that rotting pile of muck that has been the standard broken packet filter interface for FreeBSD long past its possible usefulness. A packet filter with no central maintainer which is subject to once yearly random feature bloat through some wild university project from Luigi. The brokenness that Luigi introduced (and the repository bloat through backing out and recommitting, ad absurdum) was probably no less a threat to security than anything Matt did. If the security officer was to be blatantly honest with himself, ipfw would be marked broken for either a full audit or full removal (just port obsd's pf or something that someone actually actively cares about).

You've alienated Jordan, Mike, Bill Paul (for all I can see), Greenman, you constantly rag on Terry, even though he's seen and done more with FreeBSD than most of you, O'Brien is on the verge of quitting (since he, like I, am not convinced that GEOM is anything more than an ego trip that will never be completely maintained or usefully documented). There are certainly others, too, that have attempted to make technically correct contributions, but didn't fit into the sort of paranoid "glee club" that core would like to have around them. You guys lack the talent to steer the positive from Matt into the project and let the crap fall by the wayside. I'm not saying Matt's rants are the most intelligent thing he's done, but he's sat by the wayside and watch the superstars beat up the code to a point where it's less stable, slower, and more bloated than it ever was. I, for one, can understand his frustration (as I can with Mike's, Jordan's, and a few others),

Re:future vs. now

[k8to]

I think he said currently. Like. Twice.

Anonymity

[dmiller]

It is interesting to see posts like this turn up on Slashdot and other fora. These posts are tendentious, often personally insulting and usually written by someone who is obviously pretty closely involved with whatever group they are ranting about from behind their cover of anonymity. Why be anonymous in cases like this? Don't you have the guts to put your name to your accusations? Do you really think that you will change things you don't like by spewing venom anonymously?

Re:Anonymity

[rsidd]

Actually that troll is a cut-and-paste of this post. The original wasn't anonymous (and it's also very outdated by now), but this troll periodically rehashes it on the FreeBSD lists under fake sender names, and now on slashdot it seems.

daemon on the desktop

[r00t]

I think you can use xsetroot to load wallpaper.
Nothing prevents a Linux box from having a daemon
on the desktop.

Of course, you'd be condemned to eternal damnation,
but that's your choice.

Re:Examining this FreeBSD train wreck

[eviltypeguy]

The source of this message seems to be from here:

http://lists.freebsd.org/pipermail/freebsd-curre nt /2004-July/030500.html

Re:Examining this FreeBSD train wreck

[Eil]

Attention moderators:

This is a very old troll. Don't fall for it. It's already scored at 4.

Wow

[billstr78]

There are some really cool innovations here that were a long time coming. One thing about Linux being slightly aged, large and now widley adopted, is that there is too much inertia against major change. DragonFly targets some serios kernel inefficiencies that will probably never get addressed in Linux. Rock on DragonFly!

Re:Examining this FreeBSD train wreck

[rsidd]

It's an even older non-troll. Or at least, the original (Feb 2003) was not anonymous (and is very outdated by now).

Relax, please!

[Dr. q00p]

Matt: "(seemless != the current hacks you see on Linux currently)"

r00t: " You're comparing future DragonflyBSD features with current Linux features."

I think he just meant it as an example. You know, brackets...

And besides, he put in "current" and "currently" in the same sentense so your comment seams a bit tense as well as redundant. I think we all agree that Linux will improve over time...

Team Interview

[No_Weak_Heart]

Here's a nice, in depth interview at ONLamp with the core developer team from just last week. Covers a lot of ground, I found it very informative.

Thank you, Matt, from an old Amigan

[waferhead]

Just wanted to thank you a "little" belatedly for your ixemul.library for the Amiga in the days of yore, and IIRC the initial port of gcc... saved my ass in a dev project as my A3000 was the only thing my company "had" that could build/run the code I was working on... the project HAD to compile/run/work on a Solaris box I did not have physical or remote access to... It did.

Once Dragonfly matures a bit, I will have to try it.
Peace.

Re:Thank you, Matt, from an old Amigan

[shaka]

Oh my god. I'm laughing like a freak now. I had no idea what ixemul.library was (I checked it up now though) and I thought it had something to do with XML, 'cause "ix em ul" is pretty much exactly how French people say "XML". We used to joke pretty much about that were I used to work, 'cause I went on a few business trips to France around 2000 when XML was all the rage.

And zen, ze applickatsion invockates ze ixemul.librrarrrii...

Thanks for the laugh.

Re:Thank you, Matt, from an old Amigan

[NM156]

'cept that Matt didn't really have much (anything?) to do with ixemul.library (if my memory serves me correctly). I believe it was Markus Wild, the same guy who later single-handedly ported NetBSD to the Amiga.

On the other hand, Matt wrote the most excellent DICE C compiler, which I purchased from him back in the day, and own it to this day. Overall, I think it was a better development environment that the ol' SAS C that CBM standardized on. The price was also much better for a starving college student that I was.

Not that any of this has anything to do with DragonFly BSD, however as an old Amigan myself, I can unequivocally state that Matt was definately considered an uber-hacker in the community. DNet anyone?

I chose you! 3 o'clock, by the flag pole!

[Rhinobird]

http://www.dragonflybsd.org/main/mascot.cgi

Fred is one mean looking insect, the go-lucky demon and the fat penguin are TOAST!

Oh, it's ON now!

Re:*BSD is dying

[Senjaz]

You forgot the ugly duckling of the bunch: Darwin. Unfortunately it only becomes a swan in Mac OS X.

uname(1)

[kivaapina]

Could someone type "uname -a" and send results!

Re:uname(1)

[HungSquirrel]

DragonFly sage.**domain_removed** 1.0-RELEASE DragonFly 1.0-RELEASE #4: Sun Jul 11 20:29:40 GMT 2004 root@:/usr/obj/usr/src/sys/GENERIC i386

Installed it this morning. Worth noting:

- Dfly refers to BSD slices using the Linux/Windows term 'partition', and to BSD partitions as 'subpartitions'.

- Installer cannot create a partition; you must do so manually with fdisk. Installer can format the partition, however.

- Easy, streamlined installer that gives you a base BSD system.

- DOES NOT INSTALL A TEXT-BASED BROWSER OR WGET. This really got on my nerves. I had to download the links browser tarball onto my server and FTP in to get it. Without a working text browser, it is hard to download needed packages.

- Includes the FreeBSD ports system and sample supfiles. So, if I really wanted Links, I could have waited an hour while I did a cvsup and then downloaded the port.

- Does not have bash as the default shell. No big deal, just get a port or download the source once you have a text based browser.

- When compiling software, do './configure --build=386bsd' to tell it the system type. Most configs fail if you don't specify the build.

- Dfly feels faster and snappier at the CLI than most Linuxes and even FreeBSD. This may be psychological.

Re:uname(1)

[bhirsch]

- DOES NOT INSTALL A TEXT-BASED BROWSER OR WGET.

Neither does FreeBSD. I'd imagine NetBSD and OpenBSD don't either.

Re:uname(1)

[sp0rk173]

- DOES NOT INSTALL A TEXT-BASED BROWSER OR WGET. This really got on my nerves. I had to download the links browser tarball onto my server and FTP in to get it. Without a working text browser, it is hard to download needed packages.

Cvsup. Thats all i gotta say. I'm happy they actually included CVSup in the base system - unlike freebsd - as that is the main means of updating the system. The supfile is in /usr/share/examples (i think, i don't have my dfly system booted up). Read through it, it's pretty self explanitory. That'll give you ports and the dfports override, then you won't have to report all kinds of software for it.

Re:uname(1)

[HungSquirrel]

I did use cvsup, later. The point is I shouldn't have to. A text-based browser is one of those things I call a 'necessity'. I mean, it's a few hundred kilobytes and without one you are crippled.

Re:uname(1)

[HungSquirrel]

FreeBSD includes both Links and Lynx on the install disc.

Re:uname(1)

[jsonn]

DragonFly and FreeBSD come with fetch, which offers most of the functionality of wget (minus the mirror stuff). That's enough to download tarballs and the like. For packages, you can also directly use "pkg_add -r" to use binary packages e.g. from gobsd.com without having to compile them or even install the ports tree.

A browser doesn't belong into a base system, compare with Debian which also doesn't have one by default.

Having the bash as default shell is a typical Linux user comment. There are better shells which are smaller, faster or more comfortable without being GPL licensed.

It's better to specify i386-freebsd4.8 for configure, which is not a fault of DragonFly, but of configure.

DragonFly does currently have a small scheduler bug which leads to skips e.g. of MP3 during high disc activity. Other tasks e.g. the pipe handling are supposedly better than FreeBSD.

Re:uname(1)

[sp0rk173]

Depedending on the person. If you really think it should be in there, send a message to one of the dragonfly mailinglists with a convincing argument. They're reasonable people and might just do it. But expect many, many responses as to why a person it NOT cripped without a text-based browser. Also...this kind of ends up sounding like a broken record on FreeBSD/Dfly posts, but..

pkg_add -r lynx

You really don't have to cvsup.

Re:uname(1)

[sp0rk173]

Depending on which one you get. If you use the mini ISO, it doesn't. If you use the two floppy disk method, it doesn't (and i happen to prefer the two floppy disk method, myself). There is no defacto packaging system in dfly as of yet, unlike FreeBSD, and so I would imagine that's why there are no third party packages included in this first official release. You get the base system. No more, no less. And FreeBSD does not include links or lynx in the base system.

Re:uname(1)

[Nimrangul]

OpenBSD comes with lynx by default.

Re:uname(1)

[HungSquirrel]

My bash comment was not a complaint, just a note. Getting bash was relatively straightforward and not entirely necessary. Tcsh isn't bad, just not what I'm used to.

Re:uname(1)

[Nimrangul]

Why do you feel you need bash as the default, or even the shell used on this system? pdksh has almost all the functionality; it has all the useful functionality.

Re:uname(1)

[HungSquirrel]

Simply a matter of preference. It's what I'm used to using. I don't fault Dfly for not including it, I just thought I'd mention that it isn't included on the CD as it is with FreeBSD.

Re:uname(1)

[bhirsch]

I thought it was only as a package/port...

Re:uname(1)

[bhirsch]

This is really a packaging issue. Compare DragonFly to a FreeBSD mini-iso or the Bonzai Debian installer.

Most people seem to prefer not to use the packages from the FreeBSD install CDs as they tend to be outdated. Generally speaking, I stay away from packages as things can get pretty screwed up when you mix them with ports.

Including a ports snapshot would be nice though, if for no other reason than to take a chunk of the time off the initial cvsup.

Re:*BSD is dying

[the real darkskye]

DYK that modding up the anti-trolls is just as bad as modding up the trolls in the first place. Let them all rot in the n replies under your threshold

Meanwhile back on Earth it was a muggy grey day in mid Wales and a certain slackdotter was busy evading work ...

Re:Examining this FreeBSD train wreck

[Eil]

Yes, the link that I had posted was not the oldest because I was more concerned with keeping the parent from getting modded any higher than with digging through the mailing list archives. Now I know where to get it, though.

And, btw, I still do consider the original a troll, or at best a ill-planned hissyfit. Anonymous or not.

Almost thou persuadest me to use BSD

[stealth.c]

The BSD communities alone are just about enough to sell me on using a BSD. They're not as ready to jump into flamewars as some others can be. If there's an unresolvable disagreement, one side will just fork it and everybody still gets along. If I had the fortitude to switch to BSD I probably would. Being part of such a level-headed group would be much easier on the nerves when looking for help.

Or am I mistaken? These are just my perceptions from the outside. Is the BSD Way not as rosy as I picture it?

Re:Almost thou persuadest me to use BSD

[sp0rk173]

As someone who has posted a couple stupid comments and questions to the DFly kernel mailing list, i can assure you that they are extremely curteous. When they have nothing nice to say, they don't say it at all. I don't think i've seen a single flame war in the past few months i've watched the list. Seriously, they're nice people.

Re:Does it run Linux?

[Santana]

It runs bochs

Nmap

[HungSquirrel]

As a follow-up, I ran nmap on it. All ports closed except SSH. Just the way I like it. :)

# nmap -sV -O 192.168.1.101

Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-07-14 17:48 CDT
Interesting ports on 192.168.1.101:
(The 1658 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.5p1 (protocol 1.99)
Device type: general purpose
Running: FreeBSD 4.X
OS details: FreeBSD 4.6.2-RELEASE - 4.8-RELEASE
Uptime 0.101 days (since Wed Jul 14 15:23:51 2004)

The irony...

[rainman_bc]

Isn't it bad Karma for an OS to have a BUG as their mascot?

Re:The irony...

[cant_get_a_good_nick]

Or MSN with the butteryfly...

Re:hmm.

[sp0rk173]

Not right now, and not in the immediate future. As i understand, if the hardware were donated, they would get it to work on PPC. It's a small project with small funds.

Re:I chose you! 3 o'clock, by the flag pole!

[sp0rk173]

BAHHAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAH

......

HAHAAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAAHAHAH

*deep breath*

HAHAHAHAAHAHAHAHAHAHAHAHAAHAHHAHAHAAHAHAHAHHAHAH

awesome, man. Im putting my money on DragonFly though.

Re: renamed: silly shell discussion

[cant_get_a_good_nick]

I used to be a ksh guy, but I went to bash.
pdksh is ksh88. bash functionality is a superset of that. things like programmable completion, brace expansion, small typo correction (cdspell) makes it hard for me to go back to ksh. Yes, I know zsh is a superset of bash, but I never got into it, bash adds a little functionality without me having to change the way I think (evben though one could argue zsh is for the better). I find all thee not only useful, but essential, but as always, YMMV.

even outside of that, pdksh isn't perfect, and it has it's quirks. Think about pdksh as not so much a ksh clone, but an interpretation of the kornshell spec. It just feels different, in ways I can't think of now since it's been so long it's been my default shell.

"Why would you want to use bash?" Why would anyone want to write an OS? Why would some guy buy a Honda and not a Toyota? sometimes things are just personal prefs.

Re: renamed: silly shell discussion

[Nimrangul]

pdksh currently has the ksh88 usability as well as additions. It can function in the same way as ksh88 if you want, or it can function like pdksh (and depending on what operating system you are using it will have different default behaviour if a package or part of the base).

Nothing is perfect, but for a shell it has all the functionality anyone really needs. I have seen people asking before on mailing lists why BSDs don't have bash as the default, all Linux users checking it out and curious I guess. But that has always made me equally curious, why do people assume they need it? For a .bash script I can understand needing bash, but I cannot see why everyone asks about it for the default shell.

Re:*BSD's Resignation Letter

[HungSquirrel]

Witty, but I respectfully take issue with some of your points.

--To generate media attention

Because media attention has everything to do with OS quality. Windows ME generated plenty of media attention.

--To spawn a professionally managed distribution

I'd like to think OpenBSD is managed more professionally than most Linux distros, but that depends on your definition of 'professional'. If having a huge committe that takes months to come to a consensus is your definition, then I guess OpenBSD isn't professional.

--To innovate

What do you call OpenSSH?

--To be relevant.

Proactively secure systems are relevant as far as I'm concerned. You may equate 'relevance' with 'market share'; not all people do so.