Slashdot Mirror

Fix available now.

He's... not even wrong. It's rather impressive, the number of misconceptions and sheer volume of ignorance he manages to cram into just six short paragraphs.

It was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout.

Except that it wasn't by default. You logout, your shell gets the HUP signal. That signal gets propagated down to all of the shell's children, and all of their children, and their children - all the way down to the end of the chain. By default, HUP terminates a given process. If it doesn't terminate a process as described, it's because one of three things has happened. First possibility: the process has deliberately severed its child-parent relationship with the shell, as any program designed to run as a daemon will do. Second possibility: the process has explicitly set a signal handler to trap (or ignore) the HUP signal. Third possibility: the process has been launched with the nohup command (which effectively is the same as the second possibility).

If a program hangs around after logout that isn't supposed to, that's a bug in the program, not in the operating system. The defaults are all set up properly; if a program deliberately sets out to ignore them, presumably that's for a good reason.

It has never been the default that a program will just hang around forever for no good reason.

we should consider it our duty as Fedora developers to improve the Linux platform

Right. That's it. I'm done. I'm out. I've been involved with Linux in some form or another since the days of the a.out to ELF transition - over ten years. I've been grumbling about systemd breaking a whole bunch of conventions for no good reason since I first laid eyes on it. This? This is the straw that broke the camel's back. Any operating system that quietly introduces a breaking change like this - something that is a fundamental part of the design of the Unix operating system, that is a basic assumption that every long-term Unix user is aware of - is not an operating system I want to have to deal with. Sure, it's easy to change the configuration setting for this thing. What about the next change that breaks something fundamental? Or the one after that? Or the one after that?

This isn't good enough. Sure, sometimes change is necessary - the a.out to ELF transition was done for good reasons; swapping out telnet to ssh was done for good reasons - but this kind of subtle breakage is a huge time sink to any halfway serious systems administrator.

Well, at least there are alternatives out there.

DragonFlyBSD's HAMMERFS does much of this - you can examine the version history of files and directories using hammer history and undo commands, and reference versions directly by appending @@ to filenames.

You can control how long history is preserved for and in what level of detail, as well as efficiently replicate it all across the network to remote filesystems (which can have their own, different rules). All this in addition to the more traditional named snapshots approach you're limited to with, e.g. ZFS.

https://www.dragonflybsd.org/d...

The way I see people using smartphone cameras these days is almost entirely for consumable pictures... pictures you take and gawk at for a few seconds, maybe post, and then are forgotten in the pile of tens of thousands of similar pictures. Only a very few are good enough to be memories and with the extremely narrow sweet spot of a smartphone camera or even a modern point-and-shoot, it is relatively difficult to create something that distinguishes itself. The medium and high-end DSLR camera vendors shouldn't try to go after that market.

But there is a market. Any vacation or long trip that you might want to create a memory with. You don't have to be a professional photographer. But if you want to create something memorable from that sort of trip and make a little (or big) book about it, a smartphone or point-and-shoot camera ain't gonna do it. You won't get something like this with a smartphone:

http://leaf.dragonflybsd.org/~...

For anyone with an interest in travel, or even modestly-sized vacations closer to home, bringing along a decent camera (something bigger than a point and shoot) is what gives you that permanency after you've returned home.

Probably the younger crowd doesn't understand so much because you simply haven't taken enough pictures in your lives yet (even with a smartphone and social media). But you will understand once you get to the point where you are overflowing with crap in your photo archive to the point where you don't even bother to look at it any more.

-Matt

Desktops and servers are hardly the entirety of the world. They don't even dominate it. Ever heard of ARM?

Yes, but I don't see any support for it, or any non-x86 architecture, in the DragonFly BSD source tree, so I don't think DragonFly BSD is that interested in embedded systems.

If Linus felt that way about 32-bit, there would be no Android, or it would have to develop its own kernel. Sheesh. FreeBSD and linux are found in routers and such with very weak CPUs.

So they've made different choices than DragonFly BSD.

But it's been HAMMER time for a while now. And perhaps HAMMER2 soon, too.

(It's comparable to ZFS, in case you're interested.)

Check http://www.dragonflybsd.org/features/, there's a list of random links under the DEVFS bullet point.

things tend to go slow. Real slow. If you want things now, now, now, pay the man/men. It is free, as in someone-else-will-do-it, so you get what you, that's right, didn't pay for.

Fortunately, eventually people found this hobby project worth paying for, although I think it proved its worth before the big money started pouring in.

There are, of course, some other hobby projects that also manage to support a little more hardware than the Hurd does without huge amounts of money poured into them.

So far I see a lot of complaints from people who don't appear to even know how to run SMART tools to get write cycle and wear statistics from their SSDs... you know, so real actual numbers can be posted.

So far none of my SSDs have failed, and I have almost 20 installed in various places. The one with the most wear is one of the first SSDs I purchased, an Intel 40G device:

da0: Fixed Direct Access SCSI-4 device
da0: Serial Number CVGB951600AC040GGN
da0: supports TRIM

Power on hours - 19127
Power cycle count - 48
Unsafe shutdown count - 32
Host writes x 32MiB - 375697
Workld media wear - 5120
Available reserved - 99/99/10
Media wearout - 91%

Basically 12TB worth of writes on this 40G drive over the last 2.18 years. No failures. Media wearout indicator 99 -> 91. Estimated durability based on the wear indicator is around 132TB. Roughly comes to ~3300 cycles/cell. This vintage of SSD uses MLC flash whos cells are roughly spec'd at ~10000 cycles.

While firmware issues are well documented for various SSD vendors over the last few years, and cell erase cycle life has gone down as the chips have gotten more dense, I would still expect the vast majority of failures to be due to wear-out.

Lots of things can cause premature wear-out but probably the most common would be using the SSD for something really stupid, like to host a database doing a lot of random writes or with a high frequency of fsync()s, using the SSD for swap on a system which is paging heavily 24x7, using the SSD for WWW log files on a busy web server, formatting an unaligned filesystem on the SSD or a filesystem which uses too-small a block size, and any number of other things.

Venerable but still mostly correct:

http://leaf.dragonflybsd.org/cgi/web-man?command=swapcache

The only adjustment I would make is that as the Intel 40G continues running, the wear I'm getting on it is pointing closer to ~130TB of durability and not 400TB (400TB is the theoretical max at 10,000 cycles/cell). Still reasonable. Generally speaking, that's the older 34nm technology. The newer 24nm technology will get fewer cycles but devices tend to have more storage so, as I say in the manual, you could expect similar total wear out of a newer 120GB 310 series SSD whos flash cells have 1/3 the cycle life.

-Matt

Take a look at DragonFly BSD -- it exists, Matt Dillon has a track record, and it's doing cool stuff (like HAMMER fs).

You sound like a person who should subscribe to Dillon's mailing list.

Save yourself some money:

http://leaf.dragonflybsd.org/mailarchive/users/2011-05/msg00063.html

AMD has indicated to me that the Bulldozer is not effected, which is a relief.

I guess I should have realized this would get slashdotted. In anycase, it took quite a bit of effort to track the bug down. It was very difficult to reproduce reliably. It isn't a show stopper in that it really takes a lot of work to get it to happen and most people will never see it, but it's certainly a significant bug owing to the fact that it can be reproduced with normal instruction sequences.

I began to suspect it might be a cpu bug last year and after exhaustive testing I posted my suspicions in December:

http://leaf.dragonflybsd.org/mailarchive/kernel/2011-12/msg00025.html

Older versions of GCC were more prone to generate the sequence of POP's + RET, coupled with a deep recursion and other stack state, that could result in the bug. It just so happened that DragonFly's buildworld hit the right combination inside gcc, and even then the bug only occurred sometimes and only one a small subset of .c files being compiled (like maybe 2-3 files). The bug never manifested anywhere else, doing anything else, running any other application. Ever.

In particular the bug disappeared with later versions of GCC and disppeared when I messed with the optimizations. We use -O by default, not -O2. The bug disappeared when I produced code with gcc -O2 (using 4.4.7).

It is really unlikely that Linux is effected... the sensitivity to particular code sequences laid out in the compiler is so fine that adding a single instruction virtually anywhere could make the bug disappear. Even just shifting the stack pointer a little bit would make it disappear.

In anycase, for a programmer like me being able to find an honest-to-god cpu bug in a modern cpu is very cool :-)

-Matt

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.

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.

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

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?

Considering that the BSD network stack is pretty much THE reference, whatever you code has to stay compatible with it.

"Compatible" at the API level or "compatible" at the network level? ("Compatible" at the API level is irrelevant, as it's not going to happen; PE is not a.out or ELF.)

So you're going to need to copy ALL the BSD constants,

No, you're not. Nobody's going to give a damn about AF_DATAKIT/PF_DATAKIT, for example. You're only going to have to copy the names of the ones that matter, namely AF_INET and AF_INET6.

and ALL the BSD typedefs,

Again, you'll only have to copy the ones used in socket calls.

So, tell us, how are you going to write something that complies with the standard without those constants, typedefs, and api? Magic? Time machine? Million Monkeys?

So, tell us, how are you going to write something that complies with various UN*X standards without using the code of an existing implementation?

As indicated, you don't have to copy the exact definitions of the constants; even the existing *BSDs don't all have the same numerical value for AF_INET6 (28 in FreeBSD and DragonFly BSD and 24 in NetBSD and OpenBSD; it's 30 in Mac OS X and presumably iOS).

In any case, even if they copied and pasted some typedef calls, that, in and of itself, doesn't mean that it's derived from the BSD code in any interesting way.

As for the "api", an API isn't code, it's documentation. There are a number of cases where multiple implementations of an API exist without sharing code. (You may have heard of some software called "the Linux kernel" and "the GNU C library" - and those APIs include more than the socket calls, so arguing that the Linux networking code may have been in part based on the BSD socket code is insufficient to dismiss those examples.)

I was doing similar research a few days ago.

Some of these are already mentioned...

• Lessfs - v1 is stable, v2 is pre-alpha/alpha. http://www.lessfs.com/
• Blackhole - http://www.vanheusden.com/java/BlackHole/ - requires Java, which seems like a bad idea to me for a block level device, but I haven't tested it yet.
• SDFS from OpenDedup - http://code.google.com/p/opendedup/ - http://www.opendedup.org/ - looks very promising, but may have stalled
• Dedupfs for Ext3 - http://pages.cs.wisc.edu/~kosmatka/dedupfs/
• ZFS. You know about that.
• DragonFly/Hammer - http://www.dragonflybsd.org/hammer/ includes dedup. Competitor to ZFS and Btrfs, also using Btree. Includes block level dedup, but I'm not sure if it's fixed block or not. Suspect it is fixed.
• Btrfs - there's a patch. Not sure if it's in mainlined yet. But without fsck btfs is not trustworthy enough. That's coming soon, but has been for a while. In case you read this as being negative about btrfs, it's not; it's an awesome file system, combining modern ideas and an excellent implementation, but it's still at testing stage for critical data.

Other stuff:

• Dext2 - an idea. No code. http://code.google.com/p/binarywarriors/
• BackupPC, the next version may have block level dedup, it's been suggested/requested. Numerous people pointed out the hard linking scheme it uses. I'm backing up VM images, which is what started me on this block-level dedup search, and when you have a small change in a 60BG file, it's a new file. (Yes, I have thought of schemes to split them.)
• Bacula have been experimenting with block level dedup, fixed and sliding. May be in future versions.
• Bup - https://github.com/apenwarr/bup has many of the ideas. It's not a file system, but could be reconstructed, I think. Based on Git store. I recommend reading http://apenwarr.ca/log/ which has more, and is entertaining. I think this is an excellent approach. Read back in his blog for details on bup ideas.
• SquashFS - for static data.
• Epitome - http://www.peereboom.us/epitome/man/ - for static data too, I think. Not fully investigated.
• I know I saw at least one Google Summer of Code submission about dedup. Haven't followed it up yet, and couldn't find the tab in my browser.
• Interesting conversation - http://news.ycombinator.com/item?id=2932335

By fixed block I mean that the file system does not search out shared data when the blocks are not on block boundaries. So if you add one byte to the beginning of a 10 GB file, and that has the unfortunate consequence of rippling up through all the blocks that make the file, then there will be no block level sharing with the original file. Of course that's a pathological case, but you get the idea.

Original poster, perhaps you could keep us informed of your findings? There's at least me who is also interested.

HAMMER's online deduplication doesn't need an incredible amount of memory because it will only match duplicate block that it has the checksums of cached. If the checksum is not cached, HAMMER won't deduplicate the block even if a duplicate exists on disk, because it won't know the duplicate exists. That's my interpretation of the coder's explanation, anyhow ( http://leaf.dragonflybsd.org/mailarchive/users/2011-04/msg00044.html ).

HAMMER's offline deduplication doesn't have this limitation because it can re-iterate as many times as is required to compare each checksum, but that's not helpful if you want (or require) online deduplication.

Hurd was a Victim of Good Enough.
Linux turned out to be good enough for most people. People want to be part of something important and want to matter so they tend to work on projects that are popular. Some of it is ego and some of it I fear is that people don't want to feel like they are wasting their effort.
There a lot of projects that really are very interesting that just don't get the publicity or help they need.
Like
The Haiku Project http://www.haiku-os.org/
Free VMS http://www.freevms.net/
AROS http://aros.sourceforge.net/
Dragonfly BSD http://www.dragonflybsd.org/
And Minix 3 http://www.minix3.org/
I really like the ideas behind Minix3 It could be a very interesting project if it gets enough support.

Already posted a solution for that.

http://ask.slashdot.org/comments.pl?sid=2120414&cid=36004040

Double NAT works tolerably well if you set up your interior router as DMZPlus under the 2wire router config. DMZplus eats incoming ICMP traffic, so if you have MTU problems on your vpn link, the link may appear to be dead, but you can probably fix it by manually reducing the vpn's mtu. VOIP shouldn't be a problem; SIP uses tcp/udp so you can forward that through like any other app even if you don't use DMZplus.

The 2wire routers also have horrible routing capability, so getting a static IP block is a bad idea, and the 2wires are also very picky about what's on their local layer-2 network. Plugging a device onto the 2wire's visible ethernet (i.e. not behind another router) and giving the device multiple IPs, or switching its IPs, is a great way to confuse the 2wire router. The firmware was written by morons.

Recommendations for 2wire router users: get another router (my current favorite is the buffalo wzr-hp-g300nh, 32mb flash 64mb ram, comes with branded dd-wrt and can be easily flashed with openwrt). Put that router behind the 2wire in dmzplus mode. Connect a switch to the interior router and connect everything to that.

The only things that need to be on the 2wire's local layer 2 lan are the interior router and the uverse cable DVR if you get TV as well (and if you get voip through uverse then you probably need that on the 2wire's ethernet domain too).

Matt Dillon complains about the 2wire router: http://leaf.dragonflybsd.org/mailarchive/users/2011-02/msg00074.html

MidnightBSD, MirBSD, DragonFly. Let's mention everybody if you're going to talk about the pc bsd distro.

BSD (it's not dead, after all!)

This shows a huge amount of ignorance. BSD is alive and fine, in several forms:
- FreeBSD
- NetBSD
- OpenBSD
- DragonFly BSD
These are probably the most important. Take a look at Freebsd Derivates. You'll see there are many commercial products derived from Freebsd too.

Also, there are initiatives of porting different Linux distros on top of the BSD kernel:
- Gentoo/*BSD
- Debian GNU/kFreeBSD
- Debian GNU/NetBSD (abandoned in 2002 it seems)

BSD was, is and will be alive for a long time.

Not sure I would call it an OS hack but DragonFly has precisely that, called swapcache. Swapcache Manual Page. It isn't so much making standard paging work better (systems rarely have to 'page' these days) but instead its ability to cache clean data and meta-data from the much larger terrabyte+ hard drive that makes the difference. Anyone who has more than a few hundred thousand files to contend with will know what I mean. -Matt

There's nothing BSD cannot do.

From Wikipedia:

In DragonFly, threads are locked to CPUs by design, and each processor has its own LWKT scheduler. Threads are never preemptively switched from one processor to another; they are only migrated by the passing of an "inter-processor interrupt" (IPI) message between the CPUs involved. Inter-processor thread scheduling is also accomplished by sending asynchronous IPI messages. One advantage to this clean compartmentalization of the threading subsystem is that the processors' on-board caches in SMP systems do not contain duplicated data, allowing for higher performance by giving each processor in the system the ability to use its own cache to store different things to work on.

and from dragonfly bsd:

DragonFly belongs to the same class of operating system as BSD and Linux and is based on the same UNIX ideals and APIs. DragonFly gives the BSD base an opportunity to grow in an entirely different direction from the one taken in the FreeBSD, NetBSD, and OpenBSD series.

The DragonFly project's ultimate goal is to provide native clustering support in the kernel. This involves the creation of a sophisticated cache management framework for filesystem namespaces, file spaces, and VM spaces, which allows heavily interactive programs to run across multiple machines with cache coherency fully guaranteed in all respects. This also involves being able to chop up resources, including the cpu by way of a controlled VM context, for safe assignment to unsecured third-party clusters over the internet (though the security of such clusters itself might be in doubt, the first and most important thing is for systems donating resources to not be made vulnerable through their donation).

What about HAMMER?

http://en.wikipedia.org/wiki/HAMMER
http://www.dragonflybsd.org/hammer/

Old stuff:
http://leaf.dragonflybsd.org/mailarchive/kernel/2007-10/msg00006.html
http://www.dragonflybsd.org/hammer/hammer.pdf

What about HAMMER?

http://en.wikipedia.org/wiki/HAMMER
http://www.dragonflybsd.org/hammer/

Old stuff:
http://leaf.dragonflybsd.org/mailarchive/kernel/2007-10/msg00006.html
http://www.dragonflybsd.org/hammer/hammer.pdf

What about HAMMER?

http://en.wikipedia.org/wiki/HAMMER
http://www.dragonflybsd.org/hammer/

Old stuff:
http://leaf.dragonflybsd.org/mailarchive/kernel/2007-10/msg00006.html
http://www.dragonflybsd.org/hammer/hammer.pdf

drag windows from one computer to the other. That would be awesome.

DragonFlyBSD are working towards migration of processes between different systems...

That's been one of their goals ever since splitting from FreeBSD years ago. Maybe, some day, they'll get there...

Neither worked on my 18 yr old CVS repo (that was populated with 7 yr old RCS files). What I did find was fromcvs. I found a couple of bugs, with the author fixed very quickly. It is also fast. My 3.5G CVS repo was converted in about an hour. Both of the others took 10+ hours (and didn't produce usable output). The biggest reason I love it: it allows incremental updates from CVS to GIT. You can run it any number of times and it imports the new stuff. You do need to leave the git repo you are importing into alone (no commits other than the import commits).

I still have more testing to do before we go live, but it's looking very, very nice.

worth a mention for large media space.

http://www.dragonflybsd.org/hammer/index.shtml

HAMMER provides similar capabilities; you can view files, directories, or entire filesystems as of specific versions. "hammer history foo" to find the history of a file, then look at foo@@[id] to view the file at any given point.

This is why HAMMER is the holy grail of filesystems.

Well, just like the holy grail, it certainly was a pain to find: http://www.dragonflybsd.org/hammer/. Hint to developers: don't reuse common words as your project name, makes it difficult to Google.

By the way, take a look at Hammer if you want to see something closer to the truth than ZFS. It has a cluster replication model too, considerably in advance of ZFS replication.

"OpenSSH now has a blacklist feature for weak Debian-generated ssh keys." From: http://www.dragonflybsd.org/community/release2_0.shtml Please do just a LITTLE bit of research before posting.

Please do some research before telling someone else to do research before posting.

DragonflyBSD is a fork of FreeBSD and not exactly mainstream so you can hardly accuse me of not being aware of what it said. Further, apart from that remark on the page you linked-to claiming that "OpenSSH contains a blacklist feature", there's nothing to suggest that OpenSSH itself actually contains any such blacklist management.

My research: There's nothing in the OpenSSH ChangeLog at ftp://ftp.plig.org/pub/OpenBSD/OpenSSH/portable/ChangeLog which mentions blacklisting and there's nothing in the source tarball either. I've looked (both the core distribution and the portable version).

It may be that DragonflyBSD includes blacklist management, but if so, they didn't get it from OpenSSH.

I raised the bug https://bugzilla.mindrot.org/show_bug.cgi?id=1469 because I thought that such a feature should be included. If the OpenSSH developers were interested in supporting this, I'm sure they'd have (a) commented on the bug and (b) written the code or used some of the contributed code. They may well have good reasons for not including this, but they haven't commented either way.

Speaking of DragonFly, here's this doc http://www.dragonflybsd.org/docs/nanosleep/index.shtml about how they managed to get rid of an important timing bug to minimize the sleep/wakeup delay in nanosleep() calls. Very interesting for those in multithreaded apps.

The break from BSD is in regards to code resemblance. The code of DragonFly has changed enough that it doesn't resemble BSD so much anymore.

In regards to teh Big Giant Lock...

DragonFly Projects

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

Extend Multi-Processing (MP) support

        * Robert Luciani, mentored by Simon Schubert
        * Back in 2003 when DragonFly was born, the first subsystem to be implemented was the LWKT. The reduction in complexity achieved by using message passing (as opposed to a shared memory environment using locks) was undeniable. What was also "unlocked" though, was the potential for near linear performance scaling on multiple CPU systems. Unfortunately many kernel systems, such as the network stack, need to be modified to take advantage of this potential, since they are still encumbered by a legacy "Big Giant Lock". In this project I will remove the MP lock in important areas of the kernel that have a direct affect on the performance of popular programs such as PostgreSQL.

http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008

DragonFly Projects

Enhance dma

* Max Lindner, mentored by Matthias Schmidt
* See EnhanceDmaGSoC for more information

Port DragonFly to the AMD64 architecture

* Jordan Gordeev, mentored by Thomas E. Spanjaard
* See AMD64GSoC for more information.

RFC3542 support

* Dashu Huang, mentored by Hasso Tepper
* The standard application program interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s, it has also been implemented on DragonFly BSD with support for IPv6 applications. Today, to fit new demands, the API standard that support IPv6 applications has experience some changes from RFC2292 to RFC3542. However, the DragonFly BSD operating system now only support RFC2292, and it don't support RFC3542 advanced sockets API, to make it catch up the change, we need to make it support RFC3542. To make DragonFly BSD support RFC3542. My work will research the codes of current IPv6 stack in DragonFly BSD and understand how it works. At the same time, I should understand some related RFC, and how other BSD's such as FreeBSD, openBSD, merged RFC3542. Through this way, I can figure out which part of the old IPv6 stack should be improved. Finally,I will update the old IPv6 stack to make it support RFC3542.

Extend Multi-Processing (MP) support

* Robert Luciani, mentored by Simon Schubert
* Back in 2003 when DragonFly was born, the first subsystem to be implemented was the LWKT. The reduction in complexity achieved by using message passing (as opposed to a shared memory environment using locks) was undeniable. What was also "unlocked" though, was the potential for near linear performance scaling on multiple CPU systems. Unfortunately many kernel systems, such as the network stack, need to be modified to take advantage of this potential, since they are still encumbered by a legacy "Big Giant Lock". In this project I will remove the MP lock in important areas of the kernel that have a direct affect on the performance of popular programs such as PostgreSQL.

Proportional share userland scheduling algorithm

* Mayur Narayan Bhosle, mentored by Jeffrey Hsu
* Proportional share algorithms like lottery scheduling, Stride scheduling algorithm guarantee proportional share of resources like (CPU) to a processes as per their requirement stated specified during the start. The traditional schedulers achieve fairness or resource allocation by adjusting priority, but the effect is observed over a long term. But instead in case of proportional share schedulers we observe the fairness of allocation over a bounded period of time when we adjust the requirement of resources dynamically.

Anticipatory disk I/O scheduler

* Nirmal Thacker, mentored by Simon Schubert
* This project aims at developing an Anticipatory Disk I/O scheduler for DragonFlyBSD. An Anticipatory Disk I/O scheduler will ensure that an anticipation heuristic will nullify all possible deceptive idleness between consecutive disk accesses and at the same time try to maintain an overall good throughput. In the DragonFly BSD operating system it must also take into consideration the MP- safety factors.

LiveCD with a DragonFly-specific X desktop

* Louisa Luciani, mentored by Sascha Wildner
* In this project I will integrate more functionality into the nrelease build system. The build will generate a persistent liveCD with Dragonfly specific features. It will be customized for recovery, demonstr

Check the BSD mailing lists for yourself, they are affected. I'll give you one example below:

http://leaf.dragonflybsd.org/mailarchive/commits/2008-03/msg00072.html

Before flaming people next time, at least try and learn about what you're talking about.

The FreeBSD core team consists of 9 people, so losing 92% of them would mean losing 8.37 of them, which doesn't really make sense.

The loss of a single man — Matt Dillon, who went on to found DragonFlyBSD — was devastating. He is not only quite bright, but also energetic and somehow able to devote a lot of time to the open-source software development.

His being expelled — over an exasperated comment in a cvs-commit — was highly unfortunate in my not-so-humble opinion...

I've killed some time on this since it's a pretty interesting idea. It turns out there are plenty outside the D and F range. It does seem to like pages with a single Flash object and not much else, so that's bad. It also makes some pretty arbitrary decisions which don't mean squat to many sites. There are some sites that get enough traffic that speed is a factor but not so much that a content delivery network is really necessary, for example.

I skipped the actual link and score on sites that are pretty much just representative of the sites around them. I wanted to include them by name, though, to show where they fall. I've stuck mostly to main index pages, and I've noted where I've gone deeper.

A: Google (99%), Altavista main page (98%), Altavista Babelfish (90%) (including upon doing a translation from English to French), Craigslist (96%), Pricewatch (93%), Slackware Linux, OpenBSD, Led Zeppelin site at Atlantic (100%), supremecommander.com, w3m web browser site (96%)

B: Apache.org (87%), the lighttpd web server (84%), Google Maps, which also got a C once (84% in most cases), Perlmonks (84%), Dragonfly BSD (85%), Butthole Surfers band page (81%), 37 Signals

C: One Laptop Per Child,, ESR's homepage, the Open Source Initiative (78%), Google News (73%), Lucid CMS (74%), Perl.org (75%), lucasfilm.com, Charred Dirt game

D: gnu.org, The Register, A9 (66%), kernel.org, Akamai (64%), kuro5hin.org, freshmeat.net, linuxcd.org, Movable Type (61%), Postnuke, blogster.com, Joel on Software (67%), Fog Creek Software, metallica.com, gaspowered.com, Scorched 3D (68%), id software (64%), ISBN.nu book search

F: MS IIS (49%), microsoft.com, msn.com, linux.com, fsf.org, discovery.com, newegg.com, rackspace.com, the Simtel archive (26%), CNet Download (29%), Adobe (58%), savvis.com, mtv.com, sun.com, pclinuxos.com, freebsd.org, phpnuke.org, use.perl.org, ruby-lang.org, python.org, java.com, Rolling Stones band page (56%), powellsbooks.com, amazon.com, barnesandnoble.com, getfirefox.com

My site for my company (96%) gets an A (no, I'm not going to get it slashdotted) which is pretty simple but has a pic and some Javascript on it. Several sites I have done or have helped design with someone else get C or D ratings.

Perhaps the reality is that Linux is not that great for clustering? Other operating systems are specifically designed with clustering in mind. DragonflyBSD springs to mind. From the DragonflyBSD website:

I don't know the specifics but maybe it was a case of square peg and round holes with Linux and clusters.

DragonflyBSD 1.4.x, 1.6.x, and 1.8.x systems have already been patched.

This very serious message urging all users to upgrade was posted on their mailing list earlier this week: DFBSD Message 2007/5/63

It's a good idea to kick such people out of the project. Why is that? Because they often go off on their own, and create their own projects that often far exceed the usefulness of the project they were booted from. The BSD world has two good examples of this: OpenBSD, and Dragonfly BSD.

In the case of OpenBSD, Theo was ejected from the NetBSD project, and has gone on to create the most secure general-purpose operating system known to mankind. Matt Dillon will be doing something similar with the Dragonfly BSD project. In short order it will be the only BSD-based system able to scale well on the 100- to 500-core CPUs we will soon be seeing in typical, low-end desktop systems. There have even been predictions that it'll scale better than Solaris and IRIX on lone systems with 1500 to 3000 cores.

So do us all a favour, and kick those people out. What they will create will trump whatever it is you are working on.

Real linux users use BSD, http://www.lemis.com/grog/

http://www.freebsd.org/
http://www.apple.com/macosx/
http://www.openbsd.org/
http://www.netbsd.org/
http://www.dragonflybsd.org/

That condition is not a whim, is the only mechanism known to work to protect Free as in Speech in software. Free code as in the BSD and MIT licenses is how software was created at the beginning, and it quickly derived into an incompatible set of compiting closed, proprietary systems.

Yeah, it was awful. All the BSDs went away, and nobody used their code anymore.

Seriously, though, the BSD license has worked out well for many projects. I don't know who said this, but "the goal of the GPL is to make all software free; the goal of the BSD license is to make all software better."

Or, maybe, DragonFlyBSD. A complete OS targeting i386 platforms, with fewer GNU-licensing issues to worry about.

What GNU licensing issues?

Or, maybe, DragonFlyBSD. A complete OS targeting i386 platforms, with fewer GNU-licensing issues to worry about.

You can find a solution(s) to your problem at one or more
of the following locations:

http://www.centos.org

http://fedoraproject.org/wiki/

http://en.opensuse.org

http://www.opensolaris.org/

http://www.ecomstation.com/

http://www.redhat.com

http://www.reactos.org/en/index.html

http://www.debian.org/ports/hurd/

http://www.openbsd.org/

http://www.freebsd.org/

http://www.netbsd.org/

http://www.dragonflybsd.org/

http://www.osfree.org/doku/en:start

http://www.skyos.org/

http://www.freeos.com/

http://www.minix3.org/

Added to bypass the stupid slashdot lameness filter which apparently doesn't like a post full of links. WTF is wrong with the
stupid lameness filter? Jeez, what does it want, for us to type paragraphs of meaningless drivel just to get past the lameness filter?
Sheeesh. OK, this is really stupid. Why don't ajfajf al;djal a fa fa lkdf jaa fal ja;ljf af af ajf;lajf alfjalf a fjal;fjafl; jaflakjf af;laj
jalkfaj fjf af af fajjjajal jajfa f afjdlakej2233 2235t2352 dsfalkfjal f 222j2 afdkja f23 2 2 2t2352322 233252352 2323232.

In the past, when notable members of the BSD community have encountered difficulties with the status quo, they have taken the initiative to go out on their own. This has proven to be a successful path twice over: first with Theo de Raadt forking OpenBSD from NetBSD, and then Matt Dillon forking DragonFly BSD from FreeBSD.

Will we ever see Charles back up his rantings with a similar fork? The community won't take him seriously until he does at least attempt to rectify the problems he sees by creating his own fork of NetBSD.