DragonFly BSD 3.0 Released

An anonymous reader writes with word of the release earlier this week, after eight months of development, of DragonFly BSD 3.0. The release includes improved scalability through finer-grained locking, improvements to the HAMMER file system in low-memory configurations, and a TrueCrypt-compatible disk encryption system. DragonFly is an installable system, but it can also be run live from CD, DVD, or USB key.

Comments

Will Try it

[hardburlyboogerman]

I'll let y'all know

Re:Will Try it

[Runaway1956]

Is there a torrent? My internet sucks - I prefer torrents, which I can throttle. When I'm downloading ISO's the wife bitches, the kids bitch, yada yada yada. Torrents are great, I set them at 20 k/s and no one complains - much.

Re:Will Try it

[hairyfeet]

Why not use one of the bazillion free download managers? I assume by your sig you don't use Windows but I assume Linux has similar software.

As for TFA, how does this compare to the other major OSes, like OSX, Win 7, Ubuntu, or even PC-BSD? What advantages does it give over the others? What are its best features? Why would you recommend this over other OSes? This is why i hate announcements like TFA because they don't give someone who doesn't use the OS a reason why we should care or try it.

Re:Will Try it

[Runaway1956]

Well - if I get it downloaded, I might answer some of your questions, LOL!

I guess I'll wait til the wife goes to bed tonight, and start the download running. Unless she goes to town later today. Whatever. I plan to run it in a virtual machine, just to play with. I could decide to install it on hardware, if it's really nice.

Re:Will Try it

[Anonymous Coward]

I would also like to know what FreeBSD offers over Linux. Is it faster / easier to use / etc.?

Re:Will Try it

[Anonymous Coward]

wget --limit-rate=20k --continue http://mirror-master.dragonflybsd.org/iso-images/dfly-i386-3.0.1_REL.iso.bz2

If you don't have wget, get it. You can get it for pretty much anything. Linux. Other Unixes. Windows. OS/2 Warp. Macs. Android. 20 year old Amigas. Atari STs. Commodore 64s.

Re:Will Try it

[kestasjk]

No-one (very few) care about whether BSD is "genuine UNIX" or "genuinely free software".

I administer three UNIX servers, all FreeBSD, and here's what I can tell you about the differences between it and Linux and Windows Server (which are also decent server OSes):

• It's free
• BSD is really simple; the kernel and OS are maintained by the same group, so they go step by step.
• It doesn't change much; this is as much a great thing for servers as it is a terrible thing for everything else.
• The ports system. This is a really big plus for BSD; I've tried many *nix distros and none are quite as consistent and reliable (for servers) as the ports system
• pf. Although originally an OpenBSD thing this is a firewall which has a beautifully simple syntax. It's just so easy to express solid firewall rules, with queuing and everything. (Tbh iptables is probably at least as configurable, but last I checked pf definitely offered more power / learning-effort.)
• Good community: You'll almost always find the solution to your problem, and it'll almost always be tailored to your BSD installation, rather than this or that flavor of Linux.

YMMV, Im sure many people here maintain great Linux servers, but for my humble needs I really like my three FreeBSD servers.

Re:Will Try it

[Anonymous Coward]

And......?
That silly semantic game is an advantage how exactly?

Re:Will Try it

[Runaway1956]

Obviously, if I had bothered with the man pages, I could have figured this out. Thank you, AC, for helping a lazy old man!

Re:Will Try it

[Anonymous Coward]

BSDs are never easier than Linux. Linux is more modern, while BSDs stick to "tradition" and take pride in keeping things complicated. Just read their manuals/handbooks and you will have a pretty good idea. For example, see what it takes to encrypt a file system in Linux, then check the procedures for FreeBSD, then NetBSD, then OpenBSD. On Linux, it usually feels like you're running a command. On BSDs, it usually feels like you are writing a script. Everything is like that with BSDs. Other examples, the entire world calls a partition a "partition," not BSDs, they have to be different and call them "slices" (and put "partitions" inside "slices"). Your third partition on Linux will be /dev/sda3, but on BSD it will be /dev/ad0s3e (note that it numbers disks from 0 but slices from 1, and there is still the letter "e" for the partition inside the slice - isn't that simple?)

FreeBSD advocates spent a good portion of their time claiming that FreeBSD is faster than Linux. Maybe on servers under very heavy load. In all the tests I have made on a simple desktop, FreeBSD always felt a little bit slow, jerky, worse than Linux with a lightweight window manager such as LXDE (but not worse than Linux with KDE 4, for example). NetBSD feels very light and fast, but then it doesn't do much out of the box. If you ever try Tiny Core Linux, check what it can do out of the box, that's about 18 times as much as what NetBSD can do.

Never dare suggest BSDs should be easier or user-friendlier. They HATE it. They absolutely hate it.

Re:Will Try it

[Anne Thwacks]

*BSDs each have a central Engineering team - managing things like quality control for the entire distro - including all apps. This offers long term stability.

Linux allows a wide range of contributors with, at least for some distros, not much quality control. This allows rapid development.

Licence differences mean that *BSD is more likely to be used commercially - and provides a lot of infrastructure and embedded environments - so by definition it is the standard in many areas.

Linux is more contributor friendly, so has more contributors - some excellent - some not so much.

The main BSDs Open, Free, and Net each have their own speciality. While they share much code, they are not all suited to the same task.

Use OpenBSD for security (at the expense of limited peripheral support)

Use FreeBSD for stability (and wider range of supported peripherals)

Use NetBSD if you are porting so a new environment, or running some bizarre piece of vintage hardware.

The rest of the mob are basically desktop variants of FreeBSD for people with different tastes (KDE, Gnome, Xfce95) .

BSD is Real Unix - if you have been using it since 1978, you wont have to keep learning to look in new places for things which are not where you expect them - however, unless you have been using it since 1978, some things can be hard to find!

Re:Will Try it

[rev0lt]

FreeBSD changes quite a lot between major releases, but usually doesn't break/remake what already exists. There are some few exceptions.
The ports system is also available on Linux; The pkgsrc system (that is used by DragonFly and NetBSD) is available for both Linux and Solaris.
PF is an awesome user-friendly firewall, but it has its limitations on high traffic systems (pf isn't multi-core friendly). Probably NPF will be an option soon.
The documentation is existing, up-to-date and usually accurate.
For servers, there are 4 key awesome technology components ATM - Jails (Linux has namespaces, but I don't know if it's funcional yet), CARP (pf-based redundancy), ZFS and HAST (somewhat equivalent do DRDB).

Re:Will Try it

[Anne Thwacks]

Never dare suggest BSDs should be easier or user-friendlier

BSD is very user friendly - its just kind of selective about who its friends are!

Re:Will Try it

[kdemetter]

And......?
That silly semantic game is an advantage how exactly?

It isn't.
The difference is more than semantic though, but it's hard to call one 'more free' than the other.
Short answer : GPL is liberalism . BSD is libertarianism .

Re:Will Try it

[Anonymous Coward]

FreeBSD changes quite a lot between major releases, but usually doesn't break/remake what already exists. There are some few exceptions.

There is work in the FreeBSD world fixing this. Hopefully by 9.2 or so we will see the fruits of the effort.

Re:Will Try it

[Anonymous Coward]

You should download BSD and setup QoS :P

Re:Will Try it

[fast turtle]

Unlike Linux, BSD has plenty of commercial apps available - no arguments about tainting the kernel as the BSD license allows for that, so support is available for that app. BSD Tends to be very stable between releases with a longer release cycle. This helps commercial software apps as they can target a specific version and Know it will work unlike linux where you have so many different versions of the LFSHS or even what's supposed to be installed by default. BSD is the Unix Standard - means that if you write to that standard, it will work. That's why Apple chose BSD as the base of OS X.

People tend to complain that BSD doesn't work well on a desktop and that's true because BSD is designed/optimized for Servers. PC-BSD is the desktop version. OpenBSD is geared towards security from the beginning and most of what they do (code audits and such) tend to find their way back into the regular BSD branches.

Re:Will Try it

[unixisc]

The BSDs - FreeBSD, OpenBSD, et al, would have to go through an official and formal certification w/ the Open Group in order to be certified as Unix. I don't doubt that they'd pass, but then, I don't doubt that Linux would pass either. That too, every version would have to be certified separately. I doubt that any distro would want to go thru the expense of doing it, and so the only certified Unixes out there are the ones like Solaris, HP/UX, AIX and OS-X.

The licensing issue is also somewhat tangential here - if a BSD has something that Linux hasn't, a customer will have no issues working w/ BSD, since BSD code can be incorporated in and released as a part of anything from proprietary to GPL3 software. If Linux has something that BSD hasn't, customers who need it will work around it, like Google did w/ Android. On the Linux side, I can see it getting confusing, since Linux is not going to become GPL3, but the things it uses - glibc, gcc, etc have become GPL3, which is a source for potential confusion.

Aside from that, I agree w/ the others like kestasjk below - few will care about whether it's genuine Unix or genuinely free software.

Re:Will Try it

[unixisc]

One question - what does DragonFly BSD offer that FreeBSD doesn't? For instance, PC-BSD too is a FreeBSD derivative, fine-tuned for use as a desktop, w/ a choice of user interfaces, a new PBI packaging system, USB3 support and so on. So I can see a desktop BSD user prefering PC-BSD to FreeBSD. What sort of BSD users would want to use DragonFly over FreeBSD? Ones that have SMP systems?

One thing I understand about BSDs is that there are commands that are applicable across distros, and that the sticking to tradition means that something you learned years ago is still applicable. In RHEL, I would use commands like system-config-network and service network restart to get my network configuration going, but in Debian, those commands didn't seem to be recognized. I imagine that similar variations would be there w/ others like Gentoo and Slackware. I would think that that would be an advantage of using BSD over Linux.

But you are right - BSDs are not user-friendly, and I'd say, neither is Linux. If you want to configure anything in either of these environments, you have to go and edit files in /etc, and one thing that experienced admins say is that since that's where Unix looks for its settings, that's the reliable way of doing it. But that's precisely what feeds the reputation of user unfriendlyness - it should be possible to do anything using GUI utilities in whichever DE one is working - KDE, GNOME or whatever.

Note that these comments I've made are regarding the desktop distros - in case of Linux, things like Mint, Fedora and so on, and in case of BSD, things like PC-BSD. I'm not talking here about things like Debian, RHEL, FreeBSD, OpenBSD or the others.

Re:Will Try it

[afabbro]

Short answer : GPL is liberalism . BSD is libertarianism .

So as the OP said, one isn't free and one is.

Re:Will Try it

[unixisc]

One question - if NBSD is supposed to be this most portable BSD out there, how does one explain that FBSD has been available on the Itanium platform for a while, whereas only recently w/ 5.1 does NBSD have a port there, and that too, only in source code form, not binary downloads?

Also, would FBSD plus OpenSSH be a good substitute for OBSD should one want both the stability and performance of FBSD as well as the wide peripheral support? Maybe this is unrelated, but to what extent would Capsicum help FBSD improve its security wrt OBSD? Reason I ask is that there are too many good things in FreeBSD for one to not want to leave it for OBSD - things like them having the latest & greatest in IPv6 support, widest variety of supported platforms and peripherals, performance and stability, good application packages...

Also, are the performance lags in OBSD a result of their strict security policies, or something totally independent of that?

Re:Will Try it

[ABCC]

Obviously substitute the url for which ever one you decide to actually d/l, but the following ought to work:

wget --limit-rate=20k http://www.dragonflybsd.org/download/#index1h1

Re:Will Try it

[Anonymous Coward]

FreeBSD includes the latest OpenSSH with each major release, and the ports tree offers the latest versions as they are released.

Many of the security improvements made in OpenBSD (which I would consider a research OS) and then incorporated in to FreeBSD, via projects such as OpenSSH, PF, etc.

Re:Will Try it

[unixisc]

Looking @ their home page, it looks like this is a FreeBSD geared @ multiprocessing sytems, not your usual made for home users desktops or laptops. Since it's a FreeBSD derivative, if you are looking for a FreeBSD distro suitable towards home users, the only thing that comes to mind is PC-BSD, which was released I think a month or so ago.

Re:Will Try it

[Anonymous Coward]

What does DragonflyBSD offer that FreeBSD doesn't?

They diverged quite a bit ago - so things have changed - some notable things:

- DragonFly has HAMMER fs - FreeBSD does not (but does have ZFS)
- DragonFly has 'VKernel' virtualization as well as jails but no XEN support
    (other than HVM domU though people are working on paravirt dev drivers)
- DragonFly uses NetBSD's pkgsrc packages whereas FreeBSD uses FreeBSD ports
- DragonFly has 'swapcache' metadata caching which can speed up performance quite a bit
- Toolchain has diverged - still gnu but different versions

http://www.dragonflybsd.org/features/

DragonFly does have a much smaller user/developer base, so expect to get your hands dirty -
that being said most popular software works fine due to pgksrc being so portable and people
have worked on getting many things running.

disclaimer: DragonFlyBSD dev / user

Re:Will Try it

[Anonymous Coward]

Your information is old. FreeBSD uses GPT partitions by default. What you are talking about is deprecated. Get your information straight before you sow FUD.

Re:Will Try it

[blade8086]

Also - forgot to discuss this:

"
For instance, PC-BSD too is a FreeBSD derivative, fine-tuned for use as a desktop, w/ a choice of user interfaces, a new PBI packaging system, USB3 support and so on. So I can see a desktop BSD user prefering PC-BSD to FreeBSD. What sort of BSD users would want to use DragonFly over FreeBSD? Ones that have SMP systems?
"

This is not an 'apples to apples' comparison - PC-BSD is basically a FreeBSD 'distribution' -
FreeBSD base OS rebuilt with added user-friendly features that you mention - a FreeBSD binary will run on PC-BSD and vice-versa - and as I understand it you can update the base PC-BSD system by pulling
FreeBSD source and rebuilding/reinstalling as the PC-BSD stuff is 'added on' - you can still use FreeBSD ports with PC-BSD, etc.

DragonFlyBSD is a FreeBSD fork - so a totally different OS, with common heritage. DragonFlyBSD is no longer directly binary compatible with FreeBSD (without using the binary emulation layer for old FreeBSD 4 binaries), and the kernel architecture has diverged quite a bit w/r/t threading, various device driver api's, networking etc being quite different (but still close enough that code can be ported back and forth without too much trouble). People (myself included) who would prefer DragonFlyBSD share the same philosophy w/r/t the design of the system and related goals. Purpose wise the two are quite similar - general purpose for desktop/server on mainly/exclusively x86/x86-64 platform - but my personal take and alot of the community is that DragonFly has taken the 'right approach' to 'next gen' features such as SMP, etc, and focusing on clean internals for these features has left things more flexible for future work. The 'fruits' of this effort can be seen in similar performance for the initial lock-free SMP in the last release compared to FreeBSD despite a much much smaller amount of developer time - with more performance improvments likely as the changes leading to 3.0 are tuned further.

I got into DragonFlyBSD because at the time (~2006) I was quite interested in OS internals / design, and the SMP work design goals seemed to 'seem right' as compared to the FreeBSD5+ approach - the small DragonFly community made it easy to get involved and seems much more 'cosy', so I stuck with it, esp. because at the time the VKernel work was just taking shape which was very exiting to have a BSD derived OS with native, BSD licensed full system virtualization (if not hardware assisted) - which is still unique among the BSD derivatives.

Re:Will Try it

[blade8086]

Quite simply - because someone ported it to FreeBSD first. Doesn't at all 'prove' the portability question -

FreeBSD: 6 architectures - with support for alpha having been *dropped*
NetBSD: 8x 'tier 1 architectures' and 49 'tier 2' architectures -> 57 architectures. Its like freaking Heinz Ketchup -
    57 varieties - goes on anything!

As for:

"
FBSD plus OpenSSH be a good substitute for OBSD should one want both the stability and performance of FBSD as well as the wide peripheral support?
"

OpenSSH runs on just about any unix-like os - so this is kind of a moot point. The security features of OpenBSD are much more than ssh with things like stack-smashing protection, randomized address loading, code audits, etc.

OpenBSD also has very good hardware support - between all the bsd-derived system this is really a matter of what particular hardware you want to run - often the first driver for hardware 'x' is added to one of the systems first (wherever whichever dev has that hardware and wants to make it work), and is then ported elsewhere. Quite a few of those drivers have first been added in OpenBSD, as well as NetBSD or FreeBSD, etc. For example, my eeepc901 laptop's wireless driver only works on OpenBSD last I checked but I'm planning on porting this driver to DragonFly so I can use it there.

For: "Also, are the performance lags in OBSD a result of their strict security policies, or something totally independent of that? "

While I'm not an openbsd dev and don't speak for the project -

OpenBSD is focused on "Our efforts emphasize portability, standardization, correctness, proactive security and integrated cryptography. "

So, unlike popular conception, the focus is not just security, but all of the above, equally. A big focus is stability and making sure code changes are rock solid before committing, so things like SMP / threading, etc. have been less of a focus as the team doesn't want to make as radical changes which have the potential to negatively affect the above things - plus alot of the supported architectures weren't SMP architectures to begin with so the effort was not as important.

However, it will still run reasonably quick on most hardware, and there is SMP support nowadays, so for most tasks it will be fine. The extremely high stability and very high quality of releases / ease of binary maintenance would often be a good tradeoff for the performance in many scenarios. And high-end routing / firewalling (pfsync + carp, openospfd, openbgpd, etc) features make it the best choice for quite a few applications.

Both NetBSD's pkgsrc and OpenBSD's ports are also quite extensive with most important things being available.

IpV6 support, while different between the systems, is generally quite good.

Capisicum is a different kind of 'security' than what OpenBSD is focused on - more about fine grained multi user configuration of various roles, logging, etc. for high security corporate / govt type scenarios where you want auditing and a high level of specific process control (think SELinux), whereas OpenBSD's security focus has been more on 'can this program be exploited' / 'how to block a exploitable program from being sucessfully exploited' / 'has this code / protocol been audited for security holes' / 'lets priveledge separate this priveledged process in the system', 'lets replace this historically security lax daemon with another clean rewrite' etc. All related to security - but different aspects.

Personally I use DragonFlyBSD on my desktops primarily, with a linux box or two around to run things over X windows that I haven't gotten around to porting to DragonFly yet / for porting new stuff from, run OpenBSD on my routers, and have a NetBSD box for noodling with and testing netbsd compatibility for patches to pkgsrc (which DragonFly uses primarily but is maintained by the NetBSD team)

Try them all! Use them all! learn / read / etc. It will at expand your knowledge of system design and possibilities.

Re:Will Try it

[ulski]

May I suggest that you test Filezilla http://filezilla-project.org/ Filezilla supports a download limit in transfer settings

Re:Will Try it

[Anonymous Coward]

What?? Linux has plenty of commercial apps available. More than any BSD, I would suspect.

Re:Will Try it

[smash]

I tell you what, the BSDs would be a lot more likely to pass than Linux, as they're directly descended from the AT&T unix code base, and continue to do things the "Unix way". Mac OS X (largely FreeBSD userland) has been certified as Unix. Linux is a clusterfuck of NIH syndrome and GPL software that is often different for the sake of being different.

And the GPL is NOT free. It contains restrictions on what others can do with the code you release (i.e., they can't close it). Just because you might not like the possibility of code being closed, restricting people from doing that is not more free than allowing people to do anything with it.

Re:Will Try it

[Anonymous Coward]

NetBSD does not run on 57 architectures, architecture being "instruction set architecture". That number is the number of "platforms".

alpha, arm, parisc, m68k, mips, powerpc, sh, sparc, vax, x86

10 major CPU architectures. Within each is obviously quite a subset of variations and platforms, but those are the major architectures.

alpha, arm, avr32, blackfin, cris, frv, h8300, hexagon, ia64, m32r, m68k, microblaze, mips, mn10300, openrisc, parisc, powerpc, s390, score, sh, sparc, tile, unicore32, x86, xtensa

25 major CPU architectures for Linux.

If you count the size of the machine dependent code for a port in Linux versus NetBSD, say choose an unchanging platform with comparable support, such as Alpha, and the amount of code for a port is quite similar. Linux is actually a bit smaller for this one. Just to counter howls about how Linux portability is a hack, or other such nonsense.

Re:Will Try it

[rev0lt]

9.0 is the first release I remember since 5.0 that actually broke things; I have some un-upgradeable servers with gmirror that will require a clean installation because of incompatibilities introduced. I'm shure that will happen again, as it is an evolving system.

Re:Will Try it

[CraigParticle]

Coming from a user of both Linux and both FreeBSD and NetBSD, I can't agree with the absolutes of your post.

BSDs are never easier than Linux. Linux is more modern, while BSDs stick to "tradition" and take pride in keeping things complicated. Just read their manuals/handbooks and you will have a pretty good idea.

An alternate wording: "Linux engages in constant superfluous redesign, while BSDs stick to conventional but consistent, stable interfaces that are well documented". The fact that up-to-date man pages and well-written manuals/guides exist says a lot by itself. Linux's myriad of ever-obsolete HOW-TOs is a poor substitute.

One good example of a painful process in Linux that is easy in (Net)BSD is developing for embedded architectures. I can be typing away on, say, a (PPC) Mac or a (Intel) Linux or a (Sparc) BSD box, and can cross-compile a NetBSD distribution for an ARM single-board-computer with one line: ./build.sh -u -m evbarm release. I could replace 'evbarm' with 'alpha' or 'sparc64' or 'i386' or even 'vax' (!) and I would magically get a system built for these very different architectures, constructed from whatever system I want, all built from the very same code! I didn't have to rely on some vendor to package the cross-compiler or (very painfully) do it myself -- it's just a part of the basic NetBSD system. They got a lot of stuff right!

While I do agree -- "Desktop BSD" is still not where it should be for the traditional BSDs, Linux has a long way to go here too. However, PC-BSD has done a pretty good job of doing the basic grunt work that is otherwise sorely lacking. "PC-BSD is to FreeBSD, what Ubuntu is to Debian".

Your third partition on Linux will be /dev/sda3, but on BSD it will be /dev/ad0s3e (note that it numbers disks from 0 but slices from 1, and there is still the letter "e" for the partition inside the slice - isn't that simple?)

This is a red herring. (1) On my NetBSD system, the first disk is /dev/wd0a. That's not any different than Linux's /dev/sda0. (2) Who cares? Mac OS X shows my root file system as /dev/disk0s2, and you don't see everyone complaining that OS X isn't ready for the desktop! And sometimes the extra information can save your butt. Example: I have an old Sun workstation with 3 SCSI disks that has run Linux, BSD and Solaris at different points in its life. One of the more painful moments I experienced w/ this box was under Linux, when I removed a nonessential disk (mounted as /data) after removing its entry in /etc/fstab and unplugging it. I restarted the system -- and it would no longer boot -- because the /dev entries (/dev/sda, sdb, sdc, etc.) are enumerated in ad-hoc fashion, had reordered themselves, and the root drive was no longer where init thought it should be. In BSD and Solaris, the verbose naming corresponded to their physical locations on the SCSI bus, so you could pull a nonessential disk and it would still 'just work'. That prevented a ton of headaches.

These issues have been solved in Linux with unique UUID's, but now your entry for /dev/sda3 might instead say something like "UUID=1924d0d6-496d-4bbf-8fd1-aaaac6764bc5" in /etc/fstab. Good luck parsing the UUID to mean "3rd partition" unless your fstab file is well-commented! That makes BSD look positively friendly by comparison.

FreeBSD advocates spent a good portion of their time claiming that FreeBSD is faster than Linux. Maybe on servers under very heavy load. In all the tests I have made on a simple desktop, FreeBSD always felt a little bit slow, jerky, worse than Linux with a lightweight window manager such as LXDE (but not worse than Linux with KDE 4, for example).

Re:Will Try it

[Superdad]

....... and so the only certified Unixes out there are the ones like Solaris, HP/UX, AIX and OS-X.

And Tru64 UNIX. IIRC it received the branding ahead of the others mentioned above.

Re:Will Try it

[blade8086]

Looks like you're right on cpu families- however:

And how many of those m68k / mips / arm / etc. sub architectures that you so smoothly dismissed run on Linux?

they are separate 'ports' for a reason in netbsd . Personally, I'd think the important factor in 'counting' these is 'platforms' supported rather than CPU's

also r.e portability:
can you cross compile one from another, or even from another os simply from a checkout of the codebase without manually bootstrapping a toolchain?

r.e 'hack' - last I checked the linux code is much less modular w/r/t cpu platforms with more being duplicated in the subplatform code which is why I think this has a reputation for being 'hackish' - though I'm absolutely not knowledgable on linux portability.

anyhow - not trying to start a flamewar - more free OS's on more hardware is better all around no doubt

Re:Will Try it

[Anonymous Coward]

It offers the HAMMER filesystem, which ATM offers some of the features of ZFS with much lower overhead (50+ gig filesystem dedup-able with 256 megs of ram, rather than the 768+ that zfs would require.) It also focuses exclusively on x86/x86_64 for people who believe that will help with code quality, and otherwise appears to be aimed primarily at high reliability featuresets.

Re:Will Try it

[Anonymous Coward]

What do you mean, smoothly dismissed?? They're simply not distinct "architectures".

You would have to define exactly what you want to count, and then go and count them all up. I suspect by most metrics, Linux would be much more ported.

I don't understand your question. Cross compiling depends on the toolchains installed. If you don't have a toolchain installed to build a target with, then no you can't build it. If you have one installed, then you can. Exactly how the package build systems work depends on the distribution. Debian is what I use, and it supports cross compiling pretty easily, but so do other distros (SUSE does this nicely too).

This "not modular", "not portable", "hackish" is quite a myth. And that's why I have looked at lines of code required for a port in Linux versus NetBSD, and Linux is by no means obviously worse. Nobody who repeats these claims ever offers any more substantive evidence that one can go and verify.

Re:Will Try it

[pixr99]

Looking @ their home page, it looks like this is a FreeBSD geared @ multiprocessing sytems, not your usual made for home users desktops or laptops.

It's a funny thing though, isn't it? When Matt Dillon began the fork, multi-core technology was only just getting started. If you had multiple cores or multiple CPUs, it was in a server. These days, just about every laptop or home desktop has more than one core. An OS written to scale across multiple CPUs certainly has an advantage on those platforms.

Re:Will Try it

[Anonymous Coward]

uh, you can label partitions in Loonix. No need for ugly UUIDs

Re:Will Try it

[CraigParticle]

Sure, you can. But UUIDs are the default behavior in many distributions (fortunately, 'blkid' will tell you the mapping between /dev entry and UUID). I'm not saying it's a bad system. My point is that the parent's complaint about naming conventions in /dev is silly -- there are generally good reasons for each system's behavior. The complaint distracts the discussion from what's actually important.

Re:Will Try it

[evilviper]

wget has a speed limit option that works well.

More than that, you should look into prioritizing ACKs or changing the queuing method on your router and never have the problem again.

Re:Will Try it

[Anonymous Coward]

And the GPL is NOT free.

The GPL is free, I saw it running down the street the other day

Re:Will Try it

[ninejaguar]

And the GPL is NOT free.

GPL'd software is...

"Free software, software libre or libre software [...] that can be used, studied, and modified without restriction, and which can be copied and redistributed in modified or unmodified form either without restriction, or with restrictions that only ensure that further recipients have the same rights under which it was obtained and that manufacturers of consumer products incorporating free software provide the software as source code. The word free in the term free software refers to freedom (liberty) and is not at all related to monetary cost."
http://en.wikipedia.org/wiki/Free_software

It contains restrictions on what others can do with the code you release (i.e., they can't close it).

That is correct. The GPL and the BSD each allow an option to restrict freedom.

For GPL:
If the developer who freely chooses to modify someone else's GPL'd work takes the option to distribute the derived work, then that developer is restricted from restricting other developers from the same freedom to freely choose to access and modify his derived work so that they and everyone else, including the original developer and the modifier, may contribute to and benefit from generations of evolving code changes.

For BSD:
If the developer who freely chooses to modify someone else's BSD'd work takes the option to restrict the freedom of other developers to access and modify his derivation of the existing code, even if he takes the option to distribute the derived work, then those other developers don't have the freedom of choice to access or freedom of choice to modify his derived changes and are restricted from contributing to and benefiting from generations of evolving code changes from that derived work.

It is up to the original developer to decide which behavior to allow by choosing which type of restriction to allow based on the license.

= 9J =

Re:Will Try it

[smash]

The original code released is still free for anyone to do anything with. Derived works are not free, that is up to the author of the derived works. Even if they close THEIR works, the originals they leverage are still available for others.

Re:Will Try it

[ninejaguar]

The original code released is still free for anyone to do anything with.

This is true for GPL and BSD.

Derived works are not free, that is up to the author of the derived works.>

This is true for the BSD in that it allows the developer who modifies someone else's work to restrict the freedom of other developers, including the original developer, to access and modify to the derived work even if it is distributed.

The GPL would restrict the freedom of the developer from restricting the freedom of other developers to access and modify the derived work for further evolution if the derived work is distributed.

Even if they close THEIR works, the originals they leverage are still available for others.

Both the BSD and the GPL allow the freedom to access and modify the original work assuming it is still available for access in its original form somewhere. Yes, the BSD does allow a developer to restrict the freedom of other developers, including the original developer, to access and modify the derived work that was originally BSD'd even if the derived work is distributed.

= 9J =

Re:Will Try it

[smash]

And thats the point. Why should derived work have limitations placed on the owner of the derived works? It stifles the ability of people to take well tested code and build commercial applications with it. Contrary to GPL zealot indoctrination, not ALL software will be developed for free. BSD people get this, and would rather that commercial software use well tested, robust code for the parts of the software that are non-industry specific, and spend their time focused writing on software that DOESN'T already exist.

Re:Will Try it

[ninejaguar]

Why should derived work have limitations placed on the owner of the derived works?

It's up to developer of the original work to decide which type of behavior to allow based on the license.

The GPL only limits the freedom of the developer borrowing the original work if they decide to take the option of distributing the work, whether it was modified or not.

Another question would be, why should the developer who borrowed someone else's work consider himself the owner if he simply modifies it?

Or, another way to state it, why should a developer allow another developer to take ownership of his work when he's already allowed that other developer to benefit from it by allowing that other developer to access the work, to study the work, to use the work, and to modify the work to fit a need? Now, the other developer also wants ownership of it because of a modification that he was allowed to make? For the original developer's openness, in reciprocation the other developer wants to lock out the original developer, and all other developers, from modifications to the work that the original developer might find useful?

It all depends on the type of behavior the original developer wants to allow by the license he chooses. If he wants to encourage selfishness, he can choose the BSD, if wants to encourage reciprocity he can choose the GPL.

It stifles the ability of people to take well tested code and build commercial applications with it.

I suspect this is an unfounded belief. I do find examples of GPL'd works successfully being built as commercial applications while continuing under the GPL. Please cite actual examples of how this supposed stifling process has affected actual applications if the license requires that the freedom to access modified changes continue to be passed on to later developers as under the GPL. Otherwise, your assertion remains a myth.

If a developer prefers to close source code that they take so that it will now have a Proprietary license, they only have to find another developer willing to provide the code to them on a charity basis, such as under the BSD, where there is no requirement for reciprocity and the charity recipient can treat the code given to them as their own by locking out the original developer and later developers from evolving their modifications. Of course, now that the code is closed, the benefits of Open Source can no longer be applied to the closed modifications since other Open Source developers cannot view, test, or improve the modified code any longer.

Contrary to GPL zealot indoctrination, not ALL software will be developed for free.

I haven't heard or read that claim and couldn't find examples. Is this further myth making? Please provide examples, as I would be interested to read their reasoning on why they expect that all software will be developed for free. I may respond back to them with additional queries on the logic of that position.

BSD people get this, and would rather that commercial software use well tested, robust code for the parts of the software that are non-industry specific, and spend their time focused writing on software that DOESN'T already exist.

I'm not sure as to why commercial software is being discussed on a topic regarding the characteristics of Open Source and Free Software licenses, since commercial applications can be of just about any license, whether BSD, GPL or Proprietary.

Is the assumption that commercial software should always be under a Proprietary license? And, is a Proprietary licensed commercial software supposed to be in some way a superior product? If that is the case, then shouldn't commercial software always rely on Proprietary licensed commercial software components to make the best product?

I don't follow that assumption myself since my belief is that Proprietary licensed code, if closed source, is les

Not the big one

[laffer1]

This release is interesting, but the rest of the year is dedicated to HAMMER2 and that will be the real story with DragonFly next. Most of the work on this release was incremental. Some interesting benchmarks were posted against FreeBSD in the last few months for PostgreSQL. There was some coverage on OSNews on this

http://www.osnews.com/story/25334/DragonFly_BSD_MP_Performance_Significantly_Improved

Re:Not the big one

[Anonymous Coward]

Why is HAMMER2 big news? We already have distributed filesystems that support posix, snapshots, etc. It seems to be more of the same. I mean, good for a free BSD OS to have such a thing, but why is it any more real of a story than DFBSD3?

Re:Not the big one

[laffer1]

If you're writing stories about DragonFly, then you want to cover all of it's distributed systems. The whole point of DragonFly is getting it ready for clustering. That's what Matt Dillon is into.

Some of the features of HAMMER & HAMMER2 are duplicated in other file systems, but most of them have much less friendly licenses. Even ZFS is under CDDL, which isn't terrible but precludes it from being used in Linux (the kernel). From my perspective, HAMMER could be the file system that everyone could use due to the license.

HAMMER is clearly the biggest feature of DragonFly that originated there. I think that constitutes coverage.

Re:Not the big one

[Anonymous Coward]

HAMMER and HAMMER 2 will never be used in the linux kernel for 2 reasons.
One : The linux kernel guys suffer from a NIH syndrome same as Microsoft.
Two : HAMMER/2 is tailored to DragonFly. Porting it over the linux kernel means rewriting a good portion of the whole file system hierarchy. And that is not going to happen. So other less well know OS get better engineered file systems while linux gets a host of half assed file systems. Pick your poison.

Re:Not the big one

[Anonymous Coward]

When compared to BtrFS, ZFS, etc - HAMMER is the first next-gen FS that is genuinely free software. It can therefore someday become the One Universal File System, fully supported on open source and proprietary systems alike.

Re:Not the big one

[Anonymous Coward]

Is there a good reason to use HAMMER over ZFS or BTRFS? Performance certainly does not seem to be a reason.

http://www.phoronix.com/scan.php?page=article&item=dragonfly_hammer&num=1

I don't know that any features in HAMMER are not found in others either.

Re:Not the big one

[rgbrenner]

Your benchmark compares HAMMER, ZFS, UFS, and EXT, when really HAMMER is most similar to ZFS. And in the benchmark, those two are pretty similar. The difference between the two: ZFS expects virtually unlimited RAM and will consume GBs easily; HAMMER will work with as little as 256MB of RAM.

Re:Not the big one

[m.dillon]

Every open-source filesystem to-date has had serious pitfalls. Very serious pitfalls. In the Linux space it comes down to either significant bugs under heavy loads or extremely poor performance. I don't use Linux in production myself but I have several friends that do and they have yet to find any solution that doesn't occasionally explode in their faces. People talk about a lot of these linux filesystems as if they were the best thing since sliced bread but that's really only on paper. Every linux filesystem to-date has had and still has serious issues... everything from pseudo-commercialization or licensing to serious bugs when pushed... it's a mess.

In the BSD space there is basically no viable choice other than HAMMER1 (DragonFly) or ZFS (FreeBSD). And, no, I don't consider UFS w/softupdates and logging (let alone 'background fsck' or its very limited snap features) to be a viable choice.

HAMMER1 and ZFS also have serious deficiencies. For HAMMER1 its excessive seeking to access meta-data. For ZFS its excessive kernel memory use and the need for a lot of tuning to match the workload (and good luck with mixed workloads). With UFS you begin to hit major issues the instant kern.maxvnodes is hit, or the moment the directory hash cache limit is reached.

For DragonFly users, HAMMER1's meta-data issue is fairly easily solved. One big lesson we learned was that it doesn't actually take a whole lot of cache to cache the meta-data for even a modestly large filesystem (~several terrabytes), so DragonFly's generic swapcache feature coupled with a small SSD solves the meta-data problem very neatly. DragonFly also doesn't have a maxvnodes issue for caching purposes with the HAMMER+SSD combination and it solves it WITHOUT having to integrate the SSD into the filesystem like ZFS does. I learned a number of other lessons from HAMMER1 as well, particularly when it came down to the level of sophistication required to manage HAMMER1's B-Tree and the vulnerability (for any filesystem) of depending too much on the free block map.

However, even with all the features HAMMER1 has (automatic fine-grained history, trivial snapshots, trivial streaming incremental backups, etc)... it couldn't get us to our goal.

HAMMER2 is going to give us numerous additional features while at the same time solving the limitations of HAMMER1 that prevented it from being easily extended to cluster setups. HAMMER2 will have all the features of HAMMER1 plus also writable snapshots, multi-branching snapshots, a copies mechanism that ought to work considerably better than ZFS's, larger checks (up to 192 bits), block compression, a better de-dup implementation, and numerous other features. Plus it will be better matched for the clustering features we want. And, on top of all of that, HAMMER2's code base is actually going to be less complex than HAMMER1's code base was.

The biggest lesson learned from the HAMMER1 work is that meta-data is easy to cache, even for super-huge filesystems. We are taking advantage of that realization to greatly simplify the allocation scheme to make snapshot management & features utterly trivial to implement. Most free space management will be disconnected from production access paths (reading AND writing).

-Matt

Re:Not the big one

[darrylo]

(I'd give you mod points if I had any. Since I don't, I'm going to ask a silly question.)

I'm not familiar with either HAMMER1 or HAMMER2, but will migrating to a HAMMER2 FS require a backup and restore, or is the HAMMER1 FS compatible/migratable? I realize that, as HAMMER2 is in development, you might not have a clear answer, but I thought I'd ask anyway.

Re:Not the big one

[mehemiah]

thats like making a blanket statement about Anonymous, there's no unified culture to dominate the community so people do what they want, like use their own scheduler (CFQ,BFK ... )or security model implementation ( see APPArmor,PAX etc)

Re:Not the big one

[Anonymous Coward]

Well, in terms of features, HAMMER is most similar to BTRFS and ZFS. BTRFS will run with a small amount of RAM too.

Re:Not the big one

[bill_mcgonigle]

Does HAMMER have unusable performance in the event of apps using fsync() or if somebody is using virtualization? BTRFS might be usable some day but it's not today. (I run ZFS for important work and have BTRFS on my desktop for real-world testing).

Re:Not the big one

[Anonymous Coward]

They won't use HAMMER because they already have a superior filesystem (BTRFS) that was started development before HAMMER.

They already have distributed filesystems and cluster filesystems, so it's not clear whether they'd use HAMMER2. There is no reason why they wouldn't, if it offers sufficient advantages.

Not sure what you mean about NIH syndrome. They took OCFS2 from Oracle, XFS from SGI, JFS from IBM, in fact many different filesystems from different developers. Entire subsystems from different developers even (SCSI target stack, infiniband stack)

Re:Not the big one

[g00ey]

But will/does HAMMER2 have end-to-end checksumming like ZFS has? Will it have support for software raid similar to ZFS raidz/raidz2/raidz3 (like hardware RAID5/6/7 but safer)? Will it have support for ditto blocks, or par2-like single disk/vdev redundancy on both data and meta-data?

If it doesn't have these above features it will be a deal-breaker at least for me.

Other things that I miss in some of these file systems are; defrag (even ZFS has potential fragmentation issues), the possibility to convert a raidz2 pool to raidz3 after adding an extra disk to cover for that extra redundancy, a laid out "contingency plan" if a corruption would occur.

Re:DragonFly BullShit Distribution 3.0

[Anonymous Coward]

Still better than Multiple Sclerosis Windows, or those Wildebeest/linux OSes named stuff like "exact scaly anteater"

Hard disk encryption - good job!!!

[Anonymous Coward]

First dm-crypt/LUKS, now Truecrypt. It seems to me that Dragon BSD is the only BSD Unix that actually cares about hard disk encrytpion, by implementing popular options already present in other operating systems. Free/Net/Open BSD all did the Microsoft thing, i.e. implemented their own way of doing things that won't work in other operating systems and likely never will. Heck, they could at least have agreed on ONE common implementation for all the BSDs, but noooo...
Anything that prevents me from reading my data elsewhere is evil and must be repelled. Well done, Dragonfly!

Re:Hard disk encryption - good job!!!

[allo]

what about the filesystems? afaik there is no ext(2,3,4) support in the BSDs, is it? so my LUKS-Ext4 FS will still be useless on BSD.

Re:Hard disk encryption - good job!!!

[Anonymous Coward]

I think ext2 and fat32 are supported by all major BSDs. See: https://en.wikipedia.org/wiki/Comparison_of_BSD_operating_systems
No journaling on either, but it's better than nothing.

Re:Hard disk encryption - good job!!!

[Anonymous Coward]

It takes literally 30 seconds to find an answer to your question:

http://www.freebsd.org/doc/handbook/filesystems-linux.html

So, please, stop spreading FUD.

Re:Hard disk encryption - good job!!!

[rev0lt]

If the filesystems themselves are different, why should they bother on standardizing device encryption? The kernel implementations are at this point so different, it is easier to provide reliable encryption within their own framework, than to cater to other's interests.
And, last I checked, TrueCrypt is very strong with Microsoft users (as probably BSD/Linux users have other strong alternatives already in the base system), so I really don't understand your problem.

Re:Hard disk encryption - good job!!!

[unixisc]

Are ext3 & 4 under GPL3? Or any other reason why they're not available in BSD?

Re:Hard disk encryption - good job!!!

[allo]

not ported, yet?

Sorry, my last information was, there is no ext3/4 support. For ext3 it would be possible to remove the journal, converting ext4 to ext3 seems to be harder. Anyway, for dualboot i do want to have at least ext3 on my linux, so the bsd would need to provide at least ext3, too.

good guy; bad choice

[Anonymous Coward]

Matt Dillon's a fairly bright guy who made the mistake in the mid-'90s of trying to get involved with the bunch of elitist has-beens on the FreeBSD core team. The reason the BSDs have been festering for the past decade is that there is and never has been any interest in properly documenting and welcoming contributions - the only way you can really make a contribution is to play the sycophant to one of the core team and act as their personal ego stroker until they act as your mentor, moulding you into a lesser version of themselves.

Unfortunately, Dillon has therefore got stuck with an underlying project which isn't going to improve much as the resources involved in advancing the BSDs are mostly tied up and down by those involved in FreeBSD and OpeNBSD.

Re:good guy; bad choice

[Anonymous Coward]

Matt Dillon may be a nice guy and good programmer etc., but I still think he was awful in Rumble Fish.

Re:good guy; bad choice

[rev0lt]

If I recall correctly, there were some major conflicts regarding the design decisions of FreeBSD 5.0 branch. If I recall correctly, Dillon wanted to continue the 4.X work and gradually remove the giant lock from kernel, and other developers wanted to rewrite/re-engineer the kernel torwards multiprocessor support.
Dillon left the team and started working on DragonFlyBSD.
It is interesting, all this years later, that it seems Dillon was right. According to the Dfly 2.13 benchmarks, FreeBSD and DFly are close enough to be considered equivalents, and with DFly taking a lead in some tests. AFAIK PostgreSQL isn't threaded so for at least process-based applications, both Dillon's vision and the FreeBSD team turned out to be equivalent. (But the "breaking of things" and funcionality that started with the 5.0 branch was a huge long-term benefit, as it forced the reimplementation of key infrastructure components - network, storage, etc).

Re:good guy; bad choice

[rgbrenner]

The reason the BSDs have been festering for the past decade

As a FreeBSD user since 3.4, I resent that statement. Just recently I was trying to get a FreeBSD domU working on XenServer... 7.x was unusable; 8.x was a little better but still unusable/unstable.. but 9.0 works and has been stable (with a couple of minor problems). It's only 2012, and FreeBSD already has near production-quality virtualization. FreeBSD is really on the cutting edge of this 'virtualization' tech...

And just a couple of major versions ago, we got BINARY UPDATES.

Things are getting really exciting. Watch out Linux. FreeBSD is creating some really cutting-edge software.

Re:good guy; bad choice

[adolf]

As an off-and-on FreeBSD user since prior to version 3, I must say that the whole tree has been full of new and interesting things that actually for well over a decade...and that Linux still reigns as king of the "free" *NIX crowd.

I cut my teeth on *nix in the mid-90s using the FreeBSD shell machines at the former io.com (while I myself had a modem and Telemate under MS-DOS), and while I was a customer of theirs they slowly started introducing Linux shells but their Linux boxen were never as stable or featureful as the FreeBSD machines. (And, yes: The admins were both very competent and open about all things, both good and bad.)

That FreeBSD 9 includes some new function-or-other that works well isn't news. FreeBSD has always been ahead of the curve in a lot of ways that matter on a server box (and often, on a user machine). It has always had a lot of irons-in-the-fire that make it seem like the Next Big Thing than any other OS. This is par for the course for FreeBSD.

But somehow, it has also always failed to gain any real traction. Dunno why. Perhaps it is just so, because it has always been so. But the devs keep pressing on, pushing out an awesome codebases with unwavering regularity, and it continues to thrive despite it its popularity disadvantage.

So while it's consistently been an awesome system, I'm not holding my breath while I wait for it to achieve world domination.

Re:good guy; bad choice

[rgbrenner]

My post was written tongue-in-cheek... I've been using FBSD on my servers for years, and on my desktop since 3.4 until 6 months ago. Honestly, trying to get FreeBSD working on Xen was the first time I really wondered about where the project was going. They're 10+ years late to the party.. for a server OS to miss the move to virtualized servers... Other than that, FreeBSD is a great server OS.

The installer in 9.0 is disappointing.. they switched from sysinstall to a new installer "bsdinstall".. but bsdinstall isn't really mature. They stripped out a bunch of options, and a minimal install is quite a bit bigger than a minimal 8.x install with sysinstall. Not sure how much of that is bsdinstall v 9.0 though.

They never did do much of anything on the desktop.. KDE was always incredibly buggy, Finally got frustrated enough with it to wipe it from my desktop, and install CentOS. Should have done that years ago. FreeBSD really is server-only.

I really like FreeBSD.. but I don't think it's as big a mystery about why it hasn't caught on.. It's a smaller project so they have to compromise on some things. Like the lack of desktop support.. fewer desktop users == fewer people who know it == fewer servers. Lack of virtualization...

Updates: have you ever tried to update freebsd?

Security updates: download the patch, apply it to the source tree, and rebuild that part of the OS.

Package updates: packages are frozen when the release is made.. security fixes are not backported to the frozen version.. so if there's a security hole in postgresql 9.1.0, you need to use ports and compile postgresql 9.1.1 from source.

OS upgrade: there are binary updates now (that was introduced maybe 4 years ago).. but traditionally you upgraded freebsd by downloading the OS source. Wait a few days and monitor the mailing list to see if anyone posted any problems, then compile the kernel, compile the OS, and then merge the config file changes between the two releases. Takes several hours.

Then compare that to Linux.

Re:good guy; bad choice

[adolf]

Everything you say is true, but: Compared to Gentoo, FreeBSD can be a joy to operate. :)

I never toyed with Redhat or its derivatives, due to an ephemeral dislike for RPM that has yet to fade.

Re:good guy; bad choice

[rgbrenner]

Everything you say is true, but: Compared to Gentoo, FreeBSD can be a joy to operate. :)

lol

I've noticed Gentoo isn't used much on servers either

I never toyed with Redhat or its derivatives, due to an ephemeral dislike for RPM that has yet to fade.

There are some big downsides to RHEL.. I'm not a huge fan of the distro.. but 10 years of support(!)

It's pretty much the only distro that is supported for a decent amount of time. FBSD: 2 years. Debian: 2 years. Fedora/SUSE: 1-1.5 years. Who wants to upgrade their server every 1-2 years?

Ubuntu LTS is 3 years on the desktop and 5 years on the server.. but they focus so much on the desktop that I have some doubts that it would be a good server choice.

Re:good guy; bad choice

[adolf]

I used to use Gentoo on a mail server just because Portage was a rapidly-updated system at the time and it let me keep the small handful of world-facing software that it used updated easily and quickly

But without care and feeding, it falls down on its face after a few years of piecemeal updates. It eventually became easier to migrate to a whole different system than to perform all of the myriad of weird, seemingly unrelated system updates that break -everything- if they're not installed in the right order. This seemed to happen about every 3 years, which I guess isn't too bad...but it's a pain in the ass requiring a new set of hardware to move over to (or a lot of very careful moves) and some downtime.

A modern system with VMs would perhaps make it simpler, but involves its own complications that just don't seem to be worth the extra effort for a box that only really does one thing.

Last time it switched, it went to Ubuntu LTS. My experience with Ubuntu LTS says it's close to the same: Some of the packages I needed (for a headless mail server!) weren't available in the server edition, but were available in the desktop version. So, the server runs "desktop" Ubuntu LTS, which is scheduled to be a goner after 3 years...which is the same timeframe as Gentoo, in practice.

(Cue someone from the peanut gallery calling me a moron for Not Doing It Right somehow, but admin'ing the mail server was just a side responsibility amongst the other non-computer work I was doing, it was a -very- small company, and I had wonderful availability on my server.)

Sometimes, I want the simplicity I used to enjoy from Slackware: Want something new and shiny? Download the source from Sunsite, compile it, and install it. The configure script usually sorted the details automatically (yay GNU!), and the rest of the system didn't care (yay libtool!). (But it's not 1996 anymore, and dependency trees can be huge for even the simplest of things...)

[Anti-package-management rant deleted for brevity.]

Re:DragonFly BullShit Distribution 3.0

[Anne Thwacks]

I am a scaly ant-eater, you insensitive clod!

Single OS Image Across Multiple Systems?

[afabbro]

The DFBSD Goals page is now empty. Hmm.

I seem to recall that at one point the goal was an OS that ran as a single OS image across multiple machines. Memory, processes, storage, etc. was unified into a single OS image. Is that still a DFBSD goal?

GPL vs BSD

[ninejaguar]

Both are free in cost and use, but only Linux is Free.

The GPL license, which the Linux kernel is under, limits the freedom of developers to limit the freedom of other developers to make use of changes from derived code. This is effectively done when Developer A takes GPL'd code from Developer B to benefit from Developer B's work. If distributing the derived work, Developer A must release any changes made to Developer B's work so that other developers, including Developer B, ARE also in turn Free to benefit the same way that Developer A benefited. This is called reciprocity, and is a form of cooperation (something which most parents hope their children learn). A GPL license by Developer B ensures Developer A behaves in a selfless or altruistic manner at the cost of not allowing Developer A the choice to be selfish to others, including to Developer B. For the convenience of Developer A, this requirement is only triggered when Developer A distributes the derived work originally based on Developer B's GPL'd work. The use of work already under the GPL is a completely voluntary choice for Developer A to make. The freedom of choice as to which type of licensed code to take is not limited, and Developer A can instead look for other work already under the BSD license to take for personal benefit while restricting the same benefit to others by closing the source of their changes.

The BSD license, which the BSD kernel is under, allows developers to limit the freedom of other developers to make use of changes by closing the source of a derived change, limiting the benefit of the change to only the initial closer of the derived source. This doesn't just stop the first generation of developers who could've benefited from the change, but it also stops any later developers from benefiting from and contributing to further generation of changes to the derived work. This is effectively done when Developer A takes BSD'd code from developer B to benefit from developer B's work. If Developer A distributes the derived work, and Developer A doesn't release any changes made to Developer B's work, then other developers, including Developer B, are NOT Free to benefit from the changes made by Developer A the way that Developer A benefited from Developer B's work. This is called selfishness, and is an example of non-cooperation. The BSD license allows the choice to be selfish at the cost of depriving the choice by others to utilize derived changes originally based on the work of others. The freedom of choice as to which type of licensed code to take is not limited, and Developer A can instead look for other work already under the GPL license to take for personal benefit without restricting the same benefit to others.

In either case, it is up to the original developer, Developer B, to decide which type of behavior to allow by choosing the license.

= 9J =

Re:GPL vs BSD

[Anonymous Coward]

"[...] but only Linux is Free. The GPL license [...] limits the freedom of developers"

Troll or not? Hard to tell. No real sarcasm. Explanation is well composed but opposite of the summary.

Re:GPL vs BSD

[raynet]

And BSD limits the freedom of users.

Re:GPL vs BSD

[Anonymous Coward]

That is such bullshit.

Re:GPL vs BSD

[Qzukk]

Troll or not? Hard to tell. No real sarcasm. Explanation is well composed but opposite of the summary

Linux is free. Its developers are not.

Re:GPL vs BSD

[ninejaguar]

My apologies for the confusion, I forgot to hyperlink. By "...but only Linux is Free", I meant that when compared to BSD variants, only Linux is Free software as in the following definition:

"Free software, software libre or libre software is software that can be used, studied, and modified without restriction, and which can be copied and redistributed in modified or unmodified form either without restriction, or with restrictions that only ensure that further recipients have the same rights under which it was obtained and that manufacturers of consumer products incorporating free software provide the software as source code. The word free in the term free software refers to freedom (liberty) and is not at all related to monetary cost."
http://en.wikipedia.org/wiki/Free_software

= 9J =

Re:GPL vs BSD

[Anonymous Coward]

BSD is free in cost also, but also free for devels

Re:GPL vs BSD

[evilviper]

The GPL isn't "enforcing freedom" or some such... The code you copied will always be free, as is, forever, whatever the license.

What the GPL does is extract a tax... If you want to distribute modified versions, you have to pay the code tax... Sure, others before you paid the same tax, but that doesn't mean forcing you to pay it is "freedom". You can claim it's apropos, and a small price to pay if you want... But calling restrictions "freedom" is the most flagrant orwellian doublespeak crap I've ever heard.

Up next, laws that give you "more freedom" by taking your money and giving it to other people, ensuring that others have the freedom to have their own money taken from them in the future... I feel freer already.

Re:GPL vs BSD

[ninejaguar]

"Free software, software libre or libre software is software that can be used, studied, and modified without restriction, and which can be copied and redistributed in modified or unmodified form either without restriction, or with restrictions that only ensure that further recipients have the same rights under which it was obtained and that manufacturers of consumer products incorporating free software provide the software as source code. The word free in the term free software refers to freedom (liberty) and is not at all related to monetary cost."
http://en.wikipedia.org/wiki/Free_software

The GPL isn't "enforcing freedom" or some such... The code you copied will always be free, as is, forever, whatever the license...But calling restrictions "freedom" is the most flagrant orwellian doublespeak crap I've ever heard.

The concept of a carefully designed constraint providing more freedom can seem paradoxical and difficult to imagine. However, if 18th century revolutionaries can manage to grasp it, then 21st century readers might be able to as well.

There is a famous law which restricts the freedom of others to restrict your freedom to speak your mind. Because the freedom to say things is foundational to all other freedoms, it has downstream impacts to other laws that follow. The net result is that you are more free in a country that has this restriction than in a country that doesn't. It's called the "First Amendment to the United States Constitution":

http://en.wikipedia.org/wiki/First_Amendment_to_the_United_States_Constitution

= 9J =

Re:GPL vs BSD

[ninejaguar]

Linux is free. Its developers are not. ..free to restrict other developers of having the same rights to the modifications under which the original Linux source was obtained if the derived work is distributed.

There, finished that for you. It's longer but more accurate.

= 9J =

Re:GPL vs BSD

[evilviper]

There is a famous law which restricts the freedom of others to restrict your freedom to speak your mind.

No such thing. The first amendment only says the government can't restrict your freedom of speech.

As a private citizen, I have every right to kick you off my property, shout over you, deface/remove your signs, fire you from your job if I don't like what you have to say, refuse to serve you as a customer, etc, etc., all things limiting your freedom of speech in a very real way that the first amendment doesn't prohibit at all.

It's a completely off-the-wall example, anyhow. The GPL doesn't try to bar you from stopping people from using the same open source code you got. No, it says YOU MUST CONTRIBUTE. It is a tax on coders.

Re:GPL vs BSD

[ninejaguar]

No such thing. The first amendment only says the government (i.e., OTHERS) can't restrict your freedom of speech.

And, not only others like the Federal Government, but also others like State Goverments, County Governments, and City Governments. Hopefully a few concrete examples is more illustrative than the more abstracted "others".

As a private citizen

Yes, even you are restricted in your freedom to restrict the freedom of others. In turn, you are more free as the same restriction applies to others in that they cannot restrict your freedom. I can tell this is difficult to absorb, but the net result is that we are more free.

I have every right to kick you off my property,

Correct, the property is yours and I am restricted from encroaching on it, giving you more freedom on your own property. Consequently, you are restricted from encroaching on my property, providing me more freedom on my own property. I'm hoping you see the pattern in this.

shout over you

Yes, you can because I'm restricted from punching you to stop the shouting. The restriction on my behavior, is your freedom to express your mind. Enjoy the paradox and your freedom which derives from it.

fire you from your job if I don't like what you have to say

The primary restrictions of the First Amendment is on governments of all sizes as a structural foundation to keep them democratic, because prior undemocratic governments were the most likely to have the largest impact on the freedoms of the People as a whole. Whereas a business can only impact the rights of a small subset of the People. However, even businesses have restrictions on their ability to restrict your freedoms.

For example...

refuse to serve you as a customer

Even that freedom to restrict others by refusing service is restricted, allowing more people their freedom to be served at more establishments. The business refusing is restricted not to include race in the refusal, freeing entire populations of minorities to enter all establishments no matter what their race, color, religion, national origin, disability or sexual orientation. Again, it's an example of a carefully considered restriction allowing more freedom for more people.

The GPL doesn't try to bar you from stopping people from using the same open source code you got.

Neither the BSD nor the GPL bar that. What differs is that the GPL'd software can be used, studied, and modified without restriction, and it can be copied and redistributed in modified or unmodified form with restrictions that only ensure that further recipients have the same rights under which it was obtained.

In short, the GPL ensures that others cannot restrict your freedom to obtain their modifications, just as their freedom was not restricted when they obtained modifications made by others.

The net result is that more people have freedom to access the evolving code as long as it is distributed, and you can pick up the evolution further downstream many generations later on since your freedom to access the distributed changes cannot be restricted. Whereas under the BSD, there is the freedom to restrict the freedom of others from evolving the derived changes you made and distributed. Both the GPL and the BSD have restrictions. Which one that is used is dependent on the understanding of the original developer on what type of behavior is wanted.

...it says YOU MUST CONTRIBUTE.

Only if you DISTRIBUTE the derivation.

= 9J =

Re:GPL vs BSD

[ninejaguar]

Not really. It's just incomplete.

The GPL and the BSD each allow an option to restrict freedom.

IF:
Developer B has modified some code that was under the GPL.

THEN:
The GPL restricts Developer A from restricting the freedom of other developers to access, to use, and to modify the code to which Developer A had the freedom to access, to use, and to modify from Developer B's modification. This restriction is only IF Developer A chooses the option to distribute the derived changes.

IF:
Developer B has modified some code and kept it under the BSD.

THEN:
The BSD allows Developer A the option to restrict the freedom of other developers to access, to use, and to modify the code to which Developer A had the freedom to access, to use, and to modify from Developer B's modification.

It is up to the original developer to decide which behavior to allow by choosing which type of restriction to allow based on the license.

= 9J =

DragonFly vs. OpenBSD?

[billstewart]

OpenBSD has a fanatical devotion to security, and a rather prickly-looking fish. But other than access to more hardware drivers, why would I want to run DragonFly instead of OpenBSD? Sure, a faster file system is nice, but basically anything these days is a lot faster than SunOS 4.3 (my last serious BSD use), and it sounds like it's friendlier to install. I can see why I might want to run NetBSD occasionally, because I might have a toaster or wristwatch that needs a better OS, but the big attraction of the BSDs for a while, other than licensing, has been OpenBSD's security.

Re:DragonFly vs. OpenBSD?

[hairyfeet]

See? This is what irritates me about these TFAs as nobody explains nothing! they all just assume we know all there is to know about this OS so their little terse changelog will give us actually valuable information. if all they want is users THAT familiar with it, why bother posting it to /. at all? Won't they know when the next release is?

So I say there should be a new rule, a "Why the fuck should we care" rule, after all there is literally thousands of pieces of software released every day, probably a dozen niche distros a week, if they don't give us a reason why we should care then why should we? if they don't include a link with some basic reasoning, this is why the OS exists, this is its goals, this is what we think makes it better than foo, this is how it compares to bar, THEN we'd have a reason to care! Otherwise this is another "The Phantom menace' where we are sitting here going "Huh, what? Who? Why?" because they haven't even bothered to give us a reason to care! if your distro maintainers are too arrogant or too lazy to even provide a simple "Why we should care" page then frankly they don't deserve the free advertising as it would take...what? maybe an hour tops? Give us a reason to care or just go away!

Re:DragonFly vs. OpenBSD?

[unixisc]

I think any of this announcements should include the target platforms for which they are intended. Previously, it was assumed that Linux or BSD unixes are good for servers and workstations, but since more recent distros have come out targeting things like laptops, netbooks, tablets, et al, it would be a good idea to spell out which platform a distro is targetted towards. Like this DragonFly BSD is clearly aimed @ SMP systems, from the very specific mention of their improved support for multiprocessing. Also, the emphasis on things like HAMMER, Vkernel and so on makes it clear that this is not targeted towards desktops. However, it would be good to make that explicit in the /. announcements, so that people know whether that OS is applicable to their interests or not

Re:DragonFly vs. OpenBSD?

[blade8086]

umm -

the changlog contains many 'why you should care' type of things, and also a link to many 'what is the point' types of pages -

so - sounds to me like you are complaining about your own laziness

r.e. 'distros' - 99% of linux 'distros' are just repackaging of the same software using the same tools with a different default set of packages to stroke some teenyboppers ego - nothing new that you couldn't do with another by running a few yums or apt-gets

this is novel software, that you can 'only get here', and contains some advanced features that you cant get running another system - so thats why you should care.

and if that's not interesting to you - go find another site that doesn't contain 'news for nerds'

Re:DragonFly vs. OpenBSD?

[blade8086]

From my take as a user and dev - dragonfly is targeted towards people that care about these features.

I use DragonFly on my key desktops / laptop / etc. Works just fine. Yes, some rough edges in places, but nothing I cant fix or live with - and some very smooth spots that aren't there elsewhere (like the features you mention). Having vkernels / jails / hammer allows for some excellent system managment features which can help sw development / testing / etc, plus the small group allows for a less disorienting community - it kind of 'feels' like using research unix or something in a computer lab.

plus, being interested in systems dev and having the small but not too bad rough edges and a simple and unified build system (latter common to all bsd-derived systems) allows me to easily add mini features which is great for getting involved in os development and deepening my knowledge of the 'guts' of how a system works

plus it's historically unix derived, which deepends knowledge of historical systems and 'why things are the way they are' immensely

Re:DragonFly vs. OpenBSD?

[hairyfeet]

Thank you for that brilliant suggestion. is it really so much to ask to give us a little overview, why it was created, who its targeted at, why they think its better than the other guys, is that really so much to ask for? For a good example look at Vector Linux which is actually a damned nice distro. it says what their main goals are (speed, performance and stability) why they think its better (keep it simple, keep it small and let the end user decide) and gives a very nice overview of the whole thing. if you want to know more there are plenty of links, its all nice and easy to read. Hell even their download page gives a nice simple summary of each version and who it is for.

Really guys, with over 600 distros on distrowatch asking for a little "why should we care" page really isn't asking for a lot. it would take maybe an hour to cook up and could allow someone to quickly decide if the OS is right for them.