Slashdot Mirror

Unless Splashtop uses a static path and assumes all systems are placing it in the exact same place on the exact same hard drive configuration (IDE, SATA, etc), I would assume that anything having to do with a BIOS loading linux distribution would have to at least touch the BIOS to install.

You mean the same way standard operating systems don't install to a static path on a fixed device and therefore need to touch the BIOS to install? Oh, except they don't! The BIOS already scans for a bootable OS and it can scan for SplashTop as well.

How hard do you think it is to scan for partitions with a certain ID and load a file off them? It's certainly a whole lot easier than solving the problem by implementing a BIOS routine to hardcode the loading location in a way that will break as soon as someone moves the partition, then programming a Windows-based setup program to get the starting sector of the file and invoke the BIOS routine. Oh, and there's a good chance this installs its files directly to the Windows partition so it doesn't have to go through all the trouble of shrinking the active partition and making a new one. Which would mean a simple defrag would break SplashTop if it works the ridiculous way you think it does!

Whether or not it's loading into a ROM chip, it's talking to the BIOS, something linux is more than a little bit retarded at.

That's a generalization, not a fact. It implies a whole set of instances of Linux being bad at "talking to the BIOS." I challenge you to cite one instance, never mind a whole set, of "talking to the BIOS" that Windows performs without problems and that Linux has trouble doing. I can cite the reverse: getting or setting the wakeup alarm that every modern PC and even laptops have, that you can set from the BIOS screen. Windows just can't do it. The capability certainly isn't built into Windows already, but even beyond that I couldn't even find a third-party program to do it in Windows. In Linux it's trivial. Just read or write /sys/class/rtc/rtc0/wakealarm. So looks like Windows is pretty retarded at talking to the BIOS.

On my desktop machine with MythTV, my system regularly powers on to record a program, then afterwards if no one is logged on it sets the alarm for the next recording and shuts down. It's been doing this for years and hasn't blown up yet! I can even cite the code in case you want to nitpick it or claim it's not BIOS access. cmos_read_alarm and cmos_set_alarm.

Really? Oops. Checking facts...

Okay: It seems that I was wrong in a couple of ways. The second number (eg, 2.5) was the number that denoted unstable. See here (big page, so Cntrl-F 'unstable') and mvdwege is correct that presently every there's no 'unstable' branch (as 2.3 and 2.5 were) linky here.

http://www.kernel.org/pub/linux/kernel/Historic/old-versions/RELNOTES-0.01

Hardware needed for running linux:
        - 386 AT
        - VGA/EGA screen
        - AT-type harddisk controller (IDE is fine)
        - Finnish keyboard (oh, you can use a US keyboard, but not
            without some practise :-)

Yep.

We are using a combination of Cacti and mon to monitor about 200 devices, both network gear and PC servers. Cacti is used to graph performance data(bandwidth, cpu, mem, temp) and maps for the visually inclined, while mon is used to do the actual service monitoring and alerting.

I won't comment on Cacti, since it has been mentioned here already, though iI will say that you CAN change the default behavior of "sample averaging" by increasing the size of the RRD database. There are discussions on the Cacti forum/wiki that cover this topic.

Mon on the other hand, I didn't see mentioned at all, so here's my blurb on that. The core of mon is a scheduler written in perl, which handles running monitor tests(also perl or any script/program that can exit with a 1/0) and then alerting(also perl, or other languages, and can do more than just sending mail or paging) when necessary, based on the configuration for that service. Like most open source projects, it is extremely flexible, if you have the initial time investment to set up your tests and dependencies correctly, but once this is done, the tests/alerts can be reused, or further modified. There are quite a few monitor tests and alert scripts already included, along with some handy tools for interaction through a web browser(via moncgi), generating dependency trees, generating reports, and more. Theres also a perl module, Mon::Client, that provides an API for interacting with the mon scheduler. The downside, besides configuring it with a text file(m4 can be helpful here), is there hasn't been any activity since 2007(according to the CVS repo on sourceforge).

Probably not the solution for an extremely large number of hosts, though resource-wise, it could handle it, but maybe someone else might be able to benefit from it. If you need very specific tests(number of BGP routes, verifying NH on routes, customer redundancy) and smart alert logic, it's worth looking at.

I think this is a relatively recent addition. In the kernel as provided as the official one in both Debian/Etch and Debian/EtchAndHalf RAID1 arrays read at the speed of one drive. The change to make it try balance the reads was made a minor version or two after the version those distros use as their base so it is present in the newer Lenny (though I have not yet got round to doing any performance tests on the one Lenny box I have with a RAID1 array to see how much difference this makes).

See http://kernelnewbies.org/KernelProjects/Raid1ReadBalancing and the patch it refers to that updates the feature, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=06386bbfd2441416875d0403d405c56822f6ebac

So for better RAID1 read performance with software RAID in Linux, make sure that your kernel is new enough (or has had that particular update back-ported and patched in.

You don't have a hardware or integrated RAID controller.

What you have is a non-RAID SATA controller, plus software RAID support in BIOS + Windows driver.

This is easiest to see when booting Linux, whose policy it is to only export your hardware, without any fakery.

See Linux SATA RAID FAQ for a clue...

Why is this blog posting worthy of the Slashdot front page? The Moblin beta was reported 6 weeks ago (it wasn't actually a beta, the quality was shoddy). Since then they've decided they're having something called a 'beta refresh' program, with new releases to play with on May 29, Jun 07, Jun 16, and a new one today. That latter build is not actually linked from the download page yet so it's probably not what this breathless press-release is referring to. So, what's the significance of this "It's here" report>

I put my important files on ftp://ftp.kernel.org/ and expect the rest of the world to mirror it.

Sounds like this would be great for the end user. All live recordings would be reduced to free because here is the current value: http://www.archive.org/details/etree . Most all software would be free because of http://www.gnu.org/ and http://kernel.org/ , and http://sf.net/ .

Basically, everything will asymptote to $0.00, and any percentage of that is also $0.00. I doubt the lawmakers thought of it that way, now did they?

I agree with almost every point in this article. I have been a dedicated Linux user since RH 4.2

My observations about why Linux is not ready for the desktop:

1) Lack of compatibility between versions.

I can't say enough about how frustrating this is. Every time I upgrade versions, something breaks. Usually audio. In fact, most multimedia functionality breaks every time I upgrade. I generally find that the /dev/cdrom symlink is broken at the very least, but I've frequently found that all of my CD writer scripts have to be modified.

Recently, Ubuntu arbitrarily renamed the "libglib1.2" package, breaking every application that links against the GTK+ library. Why? No answer.

It's as if Linux is actively hostile to the concept of backwards compatibility.

2) Lack of support for hot-plugging. (point 13 in the article)

I plug in a thumb drive or usb hard drive and maybe the OS will notice it and mount it for me, and maybe it won't. Usually it doesn't. Usually, I have to become super-user and perform actions to identify the drive and mount it that would be beyond the knowledge of the average end user. And even if the user does know how to do it, why should they have to? A 10-second task just got turned into a 5-minute task.

USB scanners are the same way. They used to work, now you have to become super-user to use them. Some script that detected scanner plugin events and change the permissions just stopped working.

Multi-card readers: Same thing. Sometimes they work, sometimes they don't.

Windows, Solaris, and MacOS all solved the hot-plugging problem years ago, why can't Linux?

3. Hardware support regression

Mentioned in the article, but worth repeating. I really hate upgrading my OS and discovering that some of my existing hardware is no longer supported. Recent discovery: you can have USB1 or USB2 enabled, but not both at the same time. If you want USB1, remove the ehci_hcd module. If you want USB2, install it. See Bugzilla, Launchpad.net. It seems unlikely this bug will ever be fixed.

http://www.kernel.org/

I keep seeing new boards like this come out, hoping one will have all the features I want for an ideal NAS (network attached storage) build. Right now, there is always some trade-off for what I want. Show me the board that has...

• Support for ECC RAM. AFAIK, all modern AMD CPUs all support ECC RAM. Seems like AMD should be able to make something that competes with the Atom on the low-wattage side of things. A full-blown 4850e or even Sempron is overkill.
• At least six SATA ports. Eight to 10 would be perfect. Modern Intel (ICH10) and AMD (SB700) chipsets seem to max out at six SATA ports. And Intel likes to pair the Atom with even older chipsets (ICH7 I think) that support at most four SATA ports.
• A PCIe x16 slot. Not necessary if and only if the motherboard has everything needed integrated. This requirement is really just a stop-gap, assuming the board itself will lack some crucial feature. Or for providing for unforseen future expansion.
• A built-in compact flash slot. My understanding is that PATA and CF are closely related (one is a subset of the other maybe?)... in this day and age, I would imagine PATA controllers are dirt cheap. But the idea is to use CF as the system drive, i.e. the place to hold the OS and config files. (You could also use USB + thumb drive, so as a compromise I'd settle for an on-board USB socket into which a thumb drive can be directly plugged.)
• At least one Gigabit LAN port, preferably a high quality controller like Intel makes. Two Gigabit ports for bonding would be ideal.
• Super-low power CPU. The load on this machine will be virtually all I/O. Intel Atom, AMD Geode, or even ARM should suffice.
• Chipset with sufficient IO muscle and integrated video without the high power consumption. The chipset Intel is supplying with the Atom is awful from a power consumption perspective (actually, none of Intel's chipsets are particularly low-power). AMD's 740G and 780G look decent, but still have way over-powered video. Super old school, VGA only video is sufficient. I'd even be happy with serial console only.

One board comes close: the VIA NAS 7800, but it doesn't appear to be available to the general public. And I don't see anything about supporting ECC memory. For no reason other than hearsay, I'm not so sure I'd trust important data to a Via chipset.

The next best, IMO (and I actually have one of these), is the Gigabyte GA-MA74GM-S2. Check out SilentPCReview's writeup on this board. Only problem: I'm not sure if it supports ECC or not (AMD CPUs do, but I've heard it still requires the motherboard vendor to enable it). One annoying problem is that the PCIe x16 slot is for video only---you can't put a SATA controller card, extra NIC or anything else useful to a NAS in there. Still, while it's a very low-power board when paired with the right CPU, it's still overkill for a NAS. In general, I think the power draw for a NAS (excluding the hard drives) should be under 15 Watts.

The Point of View Ion/Atom board linked above looks promising. But, as far as I can see, no compact flash, and probably no ECC memory support.

Are you aware that Linux 2.6.3 is 5 years old? Linux increased the default group limit in the following release, 2.6.4, to 65536

I absolutely love this argument that "linux is better" because one constant in the kernel is bigger in the linux kernel (thus also causing certain kernel data structures to be necessarily larger) than on FreeBSD, neither are runtime configurable, both can be changed at kernel build time, and the common case is that a user belongs to well under 65K groups. I concede, linux has won the day, and is the One UNIX-like System To Rule Them All.

Three UNIX-like Systems for the mainframe users under the sky,
Seven for the RISC lords in their halls of stone,
Nine for Open Source projects doomed to die,
One for the Penguin Lord on his dark throne,
In the land of Helsinki where the Penguins lie.
One UNIX-like System to rule them all, one UNIX-like system to find them,
One UNIX-like System to bring them all, and in the GPL legally bind them
In the land of Helsinki where the Penguins lie.

That is, until some pesky meddling halfling tosses it back into the fiery chasm from whence it came.

Are you aware that Linux 2.6.3 is 5 years old? Linux increased the default group limit in the following release, 2.6.4, to 65536

Why would you think that Btrfs is unstable and slow...

There have been other Btrfs benchmarks. The main page of the Btrfs wiki says:

Btrfs is under heavy development, and is not suitable for any uses other than benchmarking and review. The Btrfs disk format is not yet finalized, but it will only be changed if a critical bug is found and no workarounds are possible.

The Wiki doesn't say it's unstable or slow at all... only that its not complete so they don't recommend it for production. It could be the fastest and most stable file system on the planet and still have that warning if the developers were not 100% confident that the disk format won't change.

If anything, one could hope that Oracle pulls some folks from ZFS to btrfs and actually speeds development, why develop two competing open file systems?

If they were going to pick just one, why would they favor the one that is not done over the one that has been in production for years? Especially considering that more people deploy Oracle on Solaris/SPARC than on Linux?

The one that is done is not compatible with the linux kernel. Why do you think that Oracle started the btrfs project to begin with, they wanted something as feature rich as ZFS but would run on linux.

It's possible that they will drop BTRFS in favor of pushing Solaris/ZFS, but I doubt it.

Why would you think that Btrfs is unstable and slow...

There have been other Btrfs benchmarks. The main page of the Btrfs wiki says:

Btrfs is under heavy development, and is not suitable for any uses other than benchmarking and review. The Btrfs disk format is not yet finalized, but it will only be changed if a critical bug is found and no workarounds are possible.

If anything, one could hope that Oracle pulls some folks from ZFS to btrfs and actually speeds development, why develop two competing open file systems?

If they were going to pick just one, why would they favor the one that is not done over the one that has been in production for years? Especially considering that more people deploy Oracle on Solaris/SPARC than on Linux?

What about BTRFS? Will that continue as the future direction or will they pick up ZFS instead?

i got a hp 2140 and well, they (hp) put suse sled 10 on it. it was terrible slow, old software, and even the webcam didn't work! then i tried ubuntu's netbook remix based on upcoming jaunty. well, it was much faster, up to date software, webcam and everything else worked. wlan connected much faster (took up to 2 min on sled 10) only problem: the kernel (2.6.28) can't boot if the DC power is plugged! http://bugzilla.kernel.org/show_bug.cgi?id=12984 i really want linux since i only use linux, but it is a bit hard to go mainstream based on such a level of quality... preinstalled linux is horrible and the more recent software has bugs.

I'm trying to look on the Ubuntu servers but they're getting hammered right now.

Will this Ubuntu release be using 2.6.29? The previous kernels have a serious filesystem issue that often kills the whole machine on high performance systems. Supposed to be fixed in 2.6.29.

My apologies - I didn't know what you had already tried. It looks like I just told you what you already knew.

As for has anything changed, I think you would be better off asking on the Linux wireless mailing list rather than Slashdot as that's where the devs are. Certainly there have been changes made to the Ralink wifi drivers but whether they would help your case is something I would just have to ask someone else or read the source (and time is limited as it stands).

I wasn't trying to shoot down your theory. It's just that I felt that just finding out that you had master mode support would not be enough to know whether it would really work and that something else could be wrong even if master mode worked. I am basically agreeing with your observation that with what you currently know it's not worth pouring more time on this until you learn of a reason why something would have changed.

I would guess the ability get at raw frames is down to firmware support that has a mode that passes packets unchanged to the OS in a known manner rather than additional hardware. This is an extra that most people simply don't need and is another thing that can go wrong so I'd guess some vendors feel no need to expose such a feature.

Most likely Ted T'so, based on the git commit logs. I say most likely because someone more familiar with the kernel git repo than myself should probably confirm or deny this statement.

Did you report it? Can't get fixed if it's not reported. http://bugzilla.kernel.org/

Finally here's a guide to using hostapd to set a card up in access point mode (just using iwconfig to set master mode is not enough). Googling for hostapd linux will turn up plenty more guides which may be easier to follow.

Good luck!

The Linux wireless drivers page lists which drivers support master/access point mode (see the AP column). The list isn't perfect (the hostap driver definitely supports AP mode :-) but it seems to be a case of omissions. The table also says what form factor the supported chipsets come in (so you can tell which ones you will be able to get in USB form). I'd guess the rt2500usb or p54usb drivers would be your best bet.

Another useful page is the Linux wireless chipset directory which tries to list which cards have which chipsets (there's even a single page table with all the added chipsets but I won't link to it from here). This lets you build a list of boxes with the desired chipsets inside them (finding out whether this is true in reality can in itself can be a fraught process though). The chipset is really the important part in all of this.

I'm not going to point to an Amazon page because I have not bought a USB wifi card with the capabilities you describe from Amazon. I'm in no position to tell you that XYZ USB device on Amazon definitely works as I haven't done it myself. I have used hostapd on Linux and OpenBSD before now on a creaky old Prism 2.5 card and that worked for me but again that's not what you asked.

Finally here's a guide to using hostapd to set a card up in access point mode (just using iwconfig to set master mode is not enough). Googling for hostapd linux will turn up plenty more guides which may be easier to follow.

Good luck!

Tuz the Tasmanian devil has replaced Tux as the kernel mascot (for this release) to raise awareness of this endangered species (which is threatened with extinction due to a scientifically interesting but horrific transmissible facial cancer.).

Gah.

1. You're
2. Second link should have been http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=dbc85aa9f11d8c13c15527d43a3def8d7beffdc8

Does this, this, and this not solve the problem?

Does this, this, and this not solve the problem?

Does this, this, and this not solve the problem?

That's an improvement, but it can be made even safer by skipping the delete step. Once the new file is created just rename it on top of the original. The rename system call guarantees that at any point in time the name will refer to either the old or the new file. I'm not sure you really need the sync step. I haven't read the spec in that kind of detail, but if that sync step is really necessary I'd call that a design flaw. The file system may delay the write of the file as well as the rename, but it shouldn't perform the rename until the file has actually been written.

That is exactly the problem. People who are saying that the issue is just longer times before sync have not RTFA. The problem is that applications that are just trying to update files can completely delete them. It is not just recent changes that are lost. Quoting Ted Ts'o:

OK, so let me explain what's going on a bit more explicitly. There are application programmers who are rewriting application files like this:

1.a) open and read file ~/.kde/foo/bar/baz
1.b) fd = open("~/.kde/foo/bar/baz", O_WRONLY|O_TRUNC|O_CREAT) --- this truncates the file
1.c) write(fd, buf-of-new-contents-of-file, size-of-new-contents-of-file)
1.d) close(fd)

Slightly more sophisticated application writers will do this:

2.a) open and read file ~/.kde/foo/bar/baz
2.b) fd = open("~/.kde/foo/bar/baz.new", O_WRONLY|O_TRUNC|O_CREAT)
2.c) write(fd, buf-of-new-contents-of-file, size-of-new-contents-of-file)
2.d) close(fd)
2.e) rename("~/.kde/foo/bar/baz.new", "~/.kde/foo/bar/baz")

...

The fact that series (1) and (2) works at all is an accident....

Is that clear? The file system is not "truncating" files. The application is truncating the files, or is constantly overwriting the files using the rename system call....

In other words, the application (in scenario 2) is copying the file, changing the copy, and renaming only after it writes the changes. But POSIX doesn't guarantee that the filesystem calls will be written to disk in order in the event of a crash. ext4 does not write them to disk in order: it writes the rename first and only then the new file's contents. So if the system crashes in between, the file will be truncated.

This is much like ext3's behavior in the data=writeback mode; the default mode for ext3 is data=ordered, which ensures that operations like these are properly ordered (at some performance cost). You can emulate this with ext4 by using nodelalloc, but you'll lose most of the performance advantage.

All of this is worked around in some patches that are queued for 2.6.30:

http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=3bf3342f394d72ed2ec7e77b5b39e1b50fad8284
http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=6645f8c3bc3cdaa7de4aaa3d34d40c2e8e5f09ae
http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=dbc85aa9f11d8c13c15527d43a3def8d7beffdc8

These basically add a forced fsync() at some point in the process in some common cases.

As for this not being a filesystem bug . . . in the event of a crash, POSIX makes no guarantees at all unless you've fsync()ed. A filesystem that deletes things at random on crash would be POSIX-compliant. That doesn't mean that it's not buggy.

I strongly encourage everyone to read the comments in

That's an improvement, but it can be made even safer by skipping the delete step. Once the new file is created just rename it on top of the original. The rename system call guarantees that at any point in time the name will refer to either the old or the new file. I'm not sure you really need the sync step. I haven't read the spec in that kind of detail, but if that sync step is really necessary I'd call that a design flaw. The file system may delay the write of the file as well as the rename, but it shouldn't perform the rename until the file has actually been written.

That is exactly the problem. People who are saying that the issue is just longer times before sync have not RTFA. The problem is that applications that are just trying to update files can completely delete them. It is not just recent changes that are lost. Quoting Ted Ts'o:

OK, so let me explain what's going on a bit more explicitly. There are application programmers who are rewriting application files like this:

1.a) open and read file ~/.kde/foo/bar/baz
1.b) fd = open("~/.kde/foo/bar/baz", O_WRONLY|O_TRUNC|O_CREAT) --- this truncates the file
1.c) write(fd, buf-of-new-contents-of-file, size-of-new-contents-of-file)
1.d) close(fd)

Slightly more sophisticated application writers will do this:

2.a) open and read file ~/.kde/foo/bar/baz
2.b) fd = open("~/.kde/foo/bar/baz.new", O_WRONLY|O_TRUNC|O_CREAT)
2.c) write(fd, buf-of-new-contents-of-file, size-of-new-contents-of-file)
2.d) close(fd)
2.e) rename("~/.kde/foo/bar/baz.new", "~/.kde/foo/bar/baz")

...

The fact that series (1) and (2) works at all is an accident....

Is that clear? The file system is not "truncating" files. The application is truncating the files, or is constantly overwriting the files using the rename system call....

In other words, the application (in scenario 2) is copying the file, changing the copy, and renaming only after it writes the changes. But POSIX doesn't guarantee that the filesystem calls will be written to disk in order in the event of a crash. ext4 does not write them to disk in order: it writes the rename first and only then the new file's contents. So if the system crashes in between, the file will be truncated.

This is much like ext3's behavior in the data=writeback mode; the default mode for ext3 is data=ordered, which ensures that operations like these are properly ordered (at some performance cost). You can emulate this with ext4 by using nodelalloc, but you'll lose most of the performance advantage.

All of this is worked around in some patches that are queued for 2.6.30:

http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=3bf3342f394d72ed2ec7e77b5b39e1b50fad8284
http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=6645f8c3bc3cdaa7de4aaa3d34d40c2e8e5f09ae
http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=dbc85aa9f11d8c13c15527d43a3def8d7beffdc8

These basically add a forced fsync() at some point in the process in some common cases.

As for this not being a filesystem bug . . . in the event of a crash, POSIX makes no guarantees at all unless you've fsync()ed. A filesystem that deletes things at random on crash would be POSIX-compliant. That doesn't mean that it's not buggy.

I strongly encourage everyone to read the comments in

That's an improvement, but it can be made even safer by skipping the delete step. Once the new file is created just rename it on top of the original. The rename system call guarantees that at any point in time the name will refer to either the old or the new file. I'm not sure you really need the sync step. I haven't read the spec in that kind of detail, but if that sync step is really necessary I'd call that a design flaw. The file system may delay the write of the file as well as the rename, but it shouldn't perform the rename until the file has actually been written.

That is exactly the problem. People who are saying that the issue is just longer times before sync have not RTFA. The problem is that applications that are just trying to update files can completely delete them. It is not just recent changes that are lost. Quoting Ted Ts'o:

OK, so let me explain what's going on a bit more explicitly. There are application programmers who are rewriting application files like this:

1.a) open and read file ~/.kde/foo/bar/baz
1.b) fd = open("~/.kde/foo/bar/baz", O_WRONLY|O_TRUNC|O_CREAT) --- this truncates the file
1.c) write(fd, buf-of-new-contents-of-file, size-of-new-contents-of-file)
1.d) close(fd)

Slightly more sophisticated application writers will do this:

2.a) open and read file ~/.kde/foo/bar/baz
2.b) fd = open("~/.kde/foo/bar/baz.new", O_WRONLY|O_TRUNC|O_CREAT)
2.c) write(fd, buf-of-new-contents-of-file, size-of-new-contents-of-file)
2.d) close(fd)
2.e) rename("~/.kde/foo/bar/baz.new", "~/.kde/foo/bar/baz")

...

The fact that series (1) and (2) works at all is an accident....

Is that clear? The file system is not "truncating" files. The application is truncating the files, or is constantly overwriting the files using the rename system call....

In other words, the application (in scenario 2) is copying the file, changing the copy, and renaming only after it writes the changes. But POSIX doesn't guarantee that the filesystem calls will be written to disk in order in the event of a crash. ext4 does not write them to disk in order: it writes the rename first and only then the new file's contents. So if the system crashes in between, the file will be truncated.

This is much like ext3's behavior in the data=writeback mode; the default mode for ext3 is data=ordered, which ensures that operations like these are properly ordered (at some performance cost). You can emulate this with ext4 by using nodelalloc, but you'll lose most of the performance advantage.

All of this is worked around in some patches that are queued for 2.6.30:

http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=3bf3342f394d72ed2ec7e77b5b39e1b50fad8284
http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=6645f8c3bc3cdaa7de4aaa3d34d40c2e8e5f09ae
http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=dbc85aa9f11d8c13c15527d43a3def8d7beffdc8

These basically add a forced fsync() at some point in the process in some common cases.

As for this not being a filesystem bug . . . in the event of a crash, POSIX makes no guarantees at all unless you've fsync()ed. A filesystem that deletes things at random on crash would be POSIX-compliant. That doesn't mean that it's not buggy.

I strongly encourage everyone to read the comments in

EePC 900

Install works fine.

Issues:

The machine hibernates and fails to bring back the wireless card.

Driver for the wireless that comes with the eePC is OK, but I get better sensitivity from the driver here:

http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-old.tar.bz2

Pretty simple....just unpack, make install should work, reboot.

Fedora 10's network manager is quite good, and is usable for the average joe with the current posted updates.

Power management works.

If you do not like the login manager, you can just add a file to the /etc/sysconfig directory called "desktop" and place the following line in there:

DISPLAYMANAGER=KDE

(KDE fanbois....:-)

KDE 4.2 is quite a looker, however, you can't use the special effects options as the machine is just too slow.

One other thing.

I put Fedora 10 on the large internal SSD drive on the eePC 900, and left the original partition intact so i can just swap drives in the BIOS and reboot to get the original install.

The only consequence is that disk access is horrendously slow. Lots of disk lag. So I am sorta considering the idea of putting Fedora on a SD II card (8 Gig) for booting off of.

I did make a swap partition on the SSD, but the unit has 1 Gig of memory, and never uses it for what I use it for: XMMS, Mozilla, Thunderbird, Mplayer, Kismet, Samba, Portable BGP router.

Video performance is OK. I watch some movies on it and it works pretty well.

Also, make sure you get the latest BIOS update as it solves a shutdown problem with the eePC's ACPI.

The original software install has a easy way to install BIOS updates, so that alone is worth keeping the original install.

-Hack

So true. This is offtopic but do you have any tips of how to speed up compilation on linsux?

I gotta compile my browser and video player before I can watch some pr0n action as is recommended on all linux forums.

BTW I heard that some rogue has silently introduced very subtle buffer overflows in part of the kernel. It explains why the linsux servers constantly get rooted.

Even slashdot servers crashed on new years.

http://patchwork.kernel.org/patch/612/

I mean seriously.. even my 2 yr old niece can crash linux.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/257666

Does anyone besides the basement dwellers (aka losers) here use this crap? Should MS throw cash at ubuntu just like they did for Apache?

LOL..

I can see running Windows under Linux as a VM (BSOD only takes down the VM and bringing up a new VM takes seconds..not a 3 minute reboot)

Until Linux crashes with a Kernel Panic. I'm joking of course. For that to happen there would have to be bugs in the code, bad hardware, or poorly written drivers.

like the FOSS cock up your ass? ME hardly sold any copies. Since Linux fags are used to being in the 2% of morons who use some weird OS which is useless on the desktop it seems like ME was a huge success, but in reality nobody even bought it. Oh yeah I've seen some smelly hippie "demonstrate" linux (aka prove that its useless) by showing people in the office some spinning cubes or some other crap by typing shit in the command line. Most people laugh and go home and play Assasins Creed or fuck their girlfriend while the hippie goes home and comments on slashdot how he "converted" people to linux and how "amazed" they were. hahaha.. i mean what a fucking joke. You fags cant even keep the OS running through the newyear -> http://patchwork.kernel.org/patch/612/

But whats funny is bugs like this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/257666 Even my 2yr old niece can crash linux. Put in a SD card.. BOOM instant crash.

In closing - ME is unlike Vista, which is a success. In terms of marketshare, anyway. Win 7 will be too. Unless the market gets scared of some commenters here. What do you think? LOL. To any non-tech person reading this, most /. comments; ranting about micro$oft are like white noise. Very peaceful and can be ignored....

This bit:

echo 0 > /proc/sys/vm/drop_caches

doesn't actually do anything. See the relevent code here.

More importantly, kernel developers believe the drop_caches mechanism to be unsafe. It is a hack to permit easy benchmarking and other testing.

I must agree with the the GP; Linux VM behavior has been and continues to be poor. I particularly dislike the way inactive code pages are removed to buffer IO when there is clearly no reason to do so. You suffer this every time you copy a large file.

Huh? http://bugzilla.kernel.org/

Linux only attracts freeloaders and cheapskates who don't want to pay for other peoples effort. The whole "Freedom" thing is a a huge scam. The aim of all FOSS nuts (including your god stallman) is to drive developers out of business by making all software a commodity and essentially free. Whats that? Pay for maintenance? Isnt OSS software supposed to be bug free? Many Eyes and all that hand waving is supposed to mean something , AMIRITE? Although I guess "employed in my moms basement" does count for something... Can I put it on my resume??

I think FOSS is good at whoring themselves out. MS throwing cash at apache, Mozilla whoring out their search bar and front page to google so they can monitor every firefox user's activity on google.com. Is that the new thing?

The bigger point is that Linux fags cant agree on anything.. The OSS world is fucking chaos. Which is why nobody wants to ship software for you cunts. (Other than the fact that most of you wont pay for shit and basically steal music and movies right now anyway) Just look at what poor opera has to do.. http://www.opera.com/browser/download/?os=linux-i386&ver=9.63&local=y

200 downloads just to ship software for Linux? LOL... Microsoft doesn't have to do anything. You morons still cant figure it out. Linux is a horrible platform to ship any commercial software on.

YEAR OF THE LINUX ! It started with a crash http://patchwork.kernel.org/patch/612/

HAHAHAHAHHAAHHA...

I'm pretty sure the packaged releases found at http://kernel.org/pub/linux/kernel/v2.6/* are considered the official sources, by pretty much everybody involved. Now, realistically most people deeply familiar with the kernel will pull from git rather than just download the published tarballs, but the are still the most official releases. (I'm really not sure if the are just periodic packaging of Linus's tree or some special staging tree. I don't follow kernel development closely enough to know that.)

is it possible to run ext4 without the journal?

Yes, it is. And, as you can see in the link, ext4 is faster than ext2. Even with journaling.

Many thanks, Maxtorman. Yours is the first useful information I've had out of Seagate so far, and is much more reassuring than the official KB articles and the 'support' I've received from most of the first line techs I've dealt with at Seagate. I only wish you could show this to your management and take credit for it. I hope that they have the sense to keep you and those like you through the coming upheaval.

Now, a few questions, if I may...

• The wording on the 207931 KB article keeps changing; sometimes it's 'manufactured through December 2008', sometimes it's 'manufactured in December 2008'. Which is correct, and does the former mean 'all affected models of drives manufactured upto and including December 2008'?
• Could the '320th log file entry' be a SMART self-test log entry, or are these just entries for reallocated blocks, read errors and so on? I ask, because I run a selective test of part of my discs every day.
• On a tangent, have you any insight as to whether the stuttering problem that Seagate acknowledge with respect to the ST31500341AS also applies to other models running SD15-SD19 (albeit less frequently), as described in http://ata.wiki.kernel.org/index.php/Known_issues#Seagate_harddrives_which_time_out_FLUSH_CACHE_when_NCQ_is_being_used? If so, is the fix for this included in the firmware update for the new 320th log file entry bricking issue?
• On a more radical tangent, one of my month-old ST31000333AS drives has a 'High Fly Writes' SMART attribute of 19, the other is 64. Normally, I wouldn't worry about an attribute as long as it's above the threshold for that attribute, but I'm a bit concerned about the very large difference between the two drives. Is the first drive very much less healthy than the second?

ready, it's got more work than any one human can pull off, and it's located at http://kernel.org/

One minor issue is that this will leave existing data in the previous format, so you might get better performance if you reformat, or at least copy your old data around.

http://bugzilla.kernel.org/show_bug.cgi?id=12309

Use tune2fs (assuming you're currently using ext2/3): http://ext4.wiki.kernel.org/index.php/Ext4_Howto#Converting_an_ext3_filesystem_to_ext4

Also, you can convert an ext3 filesystem in-place to Btrfs: http://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3

Use tune2fs (assuming you're currently using ext2/3): http://ext4.wiki.kernel.org/index.php/Ext4_Howto#Converting_an_ext3_filesystem_to_ext4

Also, you can convert an ext3 filesystem in-place to Btrfs: http://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3

How about the Seagate 1500GB drive hang error? To my understanding Windows has been fixed, but the problem still persists in Linux.

The ST31500341AS requires a firmware update from Seagate to something newer than revision SD19 (more info). In the meantime, if you're using a drive which hasn't been updated to fixed firmware, there's a blacklist in the current development kernel to disable NCQ on affected models as a workaround.

wow, not just badsummary, utterly worthless summary. Here's the relevant discussion from LKML. Yes, this is all of it.

Peter Zijstra

Andrew Morton
In http://bugzilla.kernel.org/show_bug.cgi?id=12309 the reporters have
identified what appears to be a sched-related performance regression.
A fairly long-term one - post-2.6.18, perhaps.

Testcase code has been added today. Could someone please take a look
sometime?

There appear to be two different bug reports in there. One about iowait,
and one I'm not quite sure what it is about.

The second thing shows some numbers and a test case, but I fail to see
what the problem is with it.

This somewhat deflates the excitement evident in the OP. I mean, I know what he's talking about, these apparently random 1-2 second FREEZES while working, but if the guys in LKML arn't talking about it it's probably not being really worked on.

Does EXT3 really have a 30% read overhead?

The btrfs wiki has a link to some benchmarks which included ext3 and ext4 (and btrfs, but it's got a way to go still ...), which show that ext4 is substantially faster than ext3 in a number of the workloads.

For this use case, this is probably about the most representative benchmark (but also one of those in which ext4 really shines), in which ext4 is about 75% faster than ext3.