Slashdot Mirror

You may be able to mount ext3 as ext4, but you won't get the cool new features like extents. From Converting an ext3 filesystem to ext4, it is easy to enable these features without a reformat. You may want a plain ext3 /boot partition for compatibility with older versions of GRUB, but it looks like the GRUB for Jaunty will support ext4, so a separate /boot partition may not be necessary.

It's absolutely true that Linux has a terrible time suspending to RAM (or coming back from suspend) on certain hardware. It has DEFINITELY been improving over the past two years though (one of my systems was fixed around 9 months ago).

First up make sure you are using the latest kernel you can (new fixes for suspend issues seem to have gone into each of the past few kernel releases including the very latest one). If you have the time you might be able to use the OpenSUSE instructions on debugging suspend to RAM to isolate where the fault lies.

Assuming the problem is more than monitor being off (i.e. the system is completely hanging without any binary only drivers being loaded) if you know how to run the very latest kernels (a prerelease 2.6.29) could you file a bug report over on Kernel Bugzilla after you've checked out the Linux kernel suspend debugging howto?

I converted a ~40GB partition and it took a while (I didn't time it... between 1 and 2 hours).

Per Ted Ts'o The fix is checked into e2fsprogs 1.41.4 but release is waiting for a couple other high priority bugfixes to be released. If you want it now, you can pull it from his git repo

And for those kind words I'm going to post a follow up to my original post of more relevant changes between the 2.4 and latest 2.6 kernels (I'll try and add a few more words after each point).

Kernel configuration was overhauled. Outside support for more GUI menus, it now means you no longer have to do make dep after changing something. Further building modules outside the kernel tree is now not so baroque. The time to build and partially rebuild kernels also dropped. Building a kernel in parallel (i.e. using more than one CPU during the build process) works better.

Better support for configuring out unneeded parts of the core kernel on embedded systems. You can see the seeds of this going mainline in a git commit on 2.5.70. There is an outside project called Linux Tiny that produces patches aimed at being able to configure out features not needed for embedded systems. Over the course of 2.6 many of these patches have trickled into the mainstream kernel.

I mentioned that 2.6 scales better under load in my previous post. Here are some benchmark comparison graphs of 2.4 versus 2.6 kernels (the graphs also include comparisons against the BSDs but you can see that Linux 2.4 had some serious problems that Linux 2.6 addressed).

The kernel is now (on systems where there is reliable device discovery) able to automatically load the modules it needs to drive hardware. No more having to adjust static lists of which modules need to be loaded.

udev was introduced. This change meant that the entries in /dev were no longer static. In 2.4 all possible device entries (even for devices you didn't have) were shown in /dev and their major/minor numbers were fixed (which was causing problems as new devices were turning up - what major/minor number do you give them?). Additionally the other dynamic /dev system (devfs) was whittled away and killed off.

FUSE support (LWN article about FUSE). Allows filesystem drivers to be written in userspace. Currently the best Linux NTFS driver is written using FUSE and it allows fun things like sshfs. Might be handy if you need users to be able to configure where data is stored remotely, you are writing your own filesystem or you need to support writing to NTFS formatted USB disks...

There is better CFS (Samba/SMB/Windows File Sharing) support. NFS version 4 support was also added.

cpufreq support. The kernel can clock down the CPU speed (usually by changing voltages via some hardware interface) to save large amounts of power. This can be done in response to work load so you run at full speed as often as possible and then when things are quiet you scale down to the lowest setting (you often save the most power when doing absolutely nothing so it pays to finish things as quickly as possible).

Any switch from 2.4 to 2.6 will of course require userspace changes (updated modutils, udev, later gcc, later glibc).

There is also davej's post Halloween document discussing changes from 2.4 to 2.5. This is very detailed and is another excellent reference.

Many many other things have changed too (e.g. ALSA support for sound has been added) but I have tried to keep the ones mentioned at least tangentially related to the original scenario :)

Psst! Hey...don't tell anyone but you can download a pirated copy here.

And yet Vista is doing well. Millions of copies sold. 20% market share already. Where is linux? 0.85? ohhh wait .. another smelly linux hippie tricked his mother into installing linux... its .8500001% now. LOL The mac is doing well too, and yet linux is down in the dumps. What a shame...

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

Year of the Linux? Started with a crash

What a fucking toy OS... HAHAHAHA

I hadn't really thought of that, I had assumed you were referring to Subversion's rather common case where multiple projects are stored in the same repo, and you checkout different directories to access one of them.

Anyhow, most, but not all, public git servers have a gitweb or similar attached, which will at least let you browse and download files from the tree if you need to. For example, grabbing the latest README of Linus' Linux tree can be had via http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=README;hb=HEAD

Git itself doesn't provide any mechanism for it, however, but it's fairly unusual to be interested in a specific file rather than the entire project.

Security is one reason one cannot require a compiler (makes it easier to make exploits if you can compile from source & headers).

Meh.

ssh# cat /proc/cpuinfo
ssh# cat /proc/version
ssh# ^D
local$ firefox http://kernel.org/

Headers are easily available. Compile it locally, copy it back. Not much more than a speed bump -- and an irritating one for legitimate users, too.

And yes, Ubuntu doesn't change more often than 6 months, but I don't want to have to chase bugs during the entire 6 month cycle either (or get blind-sided when the next release comes out and my app breaks).

That's what LTS is for -- stable for 3 years.

In practice, it hasn't been a problem for server deployments, though Kubuntu's handling of KDE4 does not inspire confidence.

Blackberry Linux kernel charging driver by Greg Kroah-Hartman (February 16th 2007 so it would have turned up in 2.6.21, eeepc kernel is a patched 2.6.21.4). Greg likes see open source kernel things to go upstream quickly and is a USB maintainer.

You should have a look at git's remote tracking branches. I think they do what you want to here. git-remote(1)

You can only clone the x most recent commits with the --depth option, but it limits what you can do with the repository.

It is possible to rewrite history, delete a file with bad data, or remove a password, etc, using git-filter-branch. It is going to change your commit names, but it can be pulled anyways, git-rebase has some of the details on how to do that. You just have to force a pull if you don't have any local commits, worst case you have to deal with it the same way you do a rebase. (Or maybe you just run the command yourself.)

Put it this way, keeping the history in one place is _always_ asking for trouble down the line.

All of those problems go away when you can easily merge, because then branches cease to be painful - but then I've found that the best merges Git makes are the ones you get from rebaseing or cherry-picking, which SVN cannot do.

When was the last time you used SVN? Everything you just said is very confusing, 1.5 came out over a year ago and seems to have most of the features you say it does not.

http://subversion.tigris.org/svn_1.5_releasenotes.html
http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge.cherrypicking

As for rebasing, this is the first I've heard of it. It sounds interesting, but I don't really understand the problem it was meant to solve.
From http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#using-git-rebase

Suppose you are a contributor to a large project, and you want to add a complicated feature, and to present it to the other developers in a way that makes it easy for them to read your changes, verify that they are correct, and understand why you made each change.

If you present all of your changes as a single patch (or commit), they may find that it is too much to digest all at once.

If you present them with the entire history of your work, complete with mistakes, corrections, and dead ends, they may be overwhelmed.

Just seems a little superficial to me :\ A single patch is too much, the actual VCS history is too much, so the ideal is offering a doctored up change history?
Wouldn't the end result be more interesting? I think good source comments with other documentation would be easier to understand and more proper than reviewing the change history of someone's patch.
Since when was how someone's patch was developed more important than what was developed? Isn't diving into the VCS to find reasons for something being just a sign that the code wasn't documented properly? So, yes, we dive into VCS history to solve preexisting documentation problems, but when it comes to accepting someone else's patch, isn't that the time to simply demand good comments and or documentation?

I like what I've heard of DVCS systems so far, but I don't see what the mad rush to git is all about. Maybe it just makes more sense in the OSS context where a bunch of strangers are working on a project, wherever, whenever they want to. *shrugs*

kernel hacker guide to git, git tutorial git bisect manpage, git bisect example.

kernel hacker guide to git, git tutorial git bisect manpage, git bisect example.

kernel hacker guide to git, git tutorial git bisect manpage, git bisect example.

Your question feels a bit of strange question to ask as surely anyone who has looked would notice a huge difference between the latest 2.6 (2.6.28) and the latest 2.4 (2.4.37).

Preemptible kernel (so lower latencies are possible)
Far more devices supported (both in terms of architectures and additional add on devices e.g. SATA support)
Better scheduler (initially made O(1) scales better under load and then fairer with CFS)
Task Control Groups
Better support for threads (schedules them in a more intelligent fashion)
Strict overcommit
Massive VM changes
Tickless/dynticks support
Asynchronous I/O support
Introduction of different I/O schedulers (deadline, cfq
Network stack improvements (faster, better under load e.g. NAPI support)
epoll support
Improved ACPI support
Network filesystem improvements
Initramfs support

There is a huge list of Linux kernel changes that happened between 2.4 and 2.5. There is also a good Linux kernel 2.5 changes page on IBM's developerworks. Kernelnewbies has an excellent summary of changes for each of the 2.6 kernels and a 2.5 changes page. LWN is also excellent for kernel news.

I hate it when people don't bother to state exactly the points they object to. What other changes (not listed above) do you think the question poster wouldn't benefit from? Follow the links to the full lists (don't just use the ones off the top of your head)...

oh, how true ;)
http://bugzilla.kernel.org/show_bug.cgi?id=12164

Fixed link: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=746976a301ac9c9aa10d7d42454f8d6cdad8ff2b

If that link doesn't work, blame Slashdot because I sure as hell previewed it.

Interesting. I couldn't get that link to work, here is a working one:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=746976a301ac9c9aa10d7d42454f8d6cdad8ff2b;hp=872aad45d6174570dd2e1defc3efee50f2cfcc72

After some google searching, at least some of these issues may be attributable to a bug in the Linux code that handles the leap second. http://lkml.org/lkml/2007/7/3/103 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=746976a301ac9c9aa10d7d42454f8d6cdad8ff2b

Sigh ... I still (vaguely) remember when running the 2.2-ac kernel on RH was basically required to get useful hardware support and modern features. It was pretty much the standard one to use.

I really want them to implement this business model, because it would be a great push for greater GNU/Linux adoption.

Hi everyone,
Ever since 2.6.27.x came out I have not been able to compile from source and have the internet connection work correctly at all.

Basically I try to take old source configs and run them in the new kernels, but I get the same result.

Even binary Ubuntu kernel builds fail to run internet connections correctly...

Apparently this item may be related to it:
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fd6149d332973bafa50f03ddb0ea9513e67f4517

(regarding the reordering of TCP options... how do I fix it?)

Any advice very gratefully appreciated ...
M

Eh? You don't get a fsck on mount by default with ext3 unless you've exceeded either the check interval or max mount count. If the filesystem has the needs_recovery flag set (i.e. wasn't cleanly unmounted) the journal will be replayed.

Lengthy filesystem checks on large filesystems holding large filesystems are only a problem if you don't create the filesystem properly in the first place. The time to do a fsck is pretty much linear to the number of inodes; specify a reasonable bytes-per-inode ratio and fsck time drops dramatically. Even this is unnecessary under ext4 since they no longer check unused inode groups.

If you RTFA they give brief summary of the additional features of ext4: "Later, others (Lustre, IBM, Bull - see Theodore T'so comment) got involved and added extents, delayed allocation, online defragmentation, and more." and the development wiki goes into further detail.

Finally, I thought I'd never find you !

I am being harassed for years now about your shoddy coding. Please start here http://bugzilla.kernel.org/show_bug.cgi?id=1786

Linus

All of the features I mentioned are in ZFS. The GP wanted a filesystem with the functionality of ZFS, so those are the points I emphasized. BtrFS has other features which can be found on its homepage.

And dkms doesn't deal with the fact that the Linux kernel APIs (let alone the ABIs) are deliberately not kept stable, so any driver has a restricted window in which it will work.

They don't change the APIs that drastically or often in the kernel and when they do break things, it's not as often as Windows does between versions.

Manu of the user-visible problems in Vista were due to Microsoft changing the driver API for the first time since Windows 2000, and that's been one of the things that's sold people on risking the switch to Linux or OS X.

Microsoft introduced changes to the kernel API in Windows 2000 with service packs that broke graphics support partially until there were new drivers, Windows XP with wireless and graphics, Windows XP SP1 with memory addressing changes in the kernel that broke drivers, Windows SP2 another set of Windows addressing changes with DEP and wireless API changes.

that's been one of the things that's sold people on risking the switch to Linux or OS X.

No it hasn't. I think that's one of the last reasons why people would be using Windows since people don't even know this stuff to begin with. General people don't use a OS for technical merit at all.

I'm running Windows 2000 on my Wintendo. That was released in 1999, and hasn't been supported in years, but apart from Bluetooth devices pretty much every third party driver has Just Worked.

Wouldn't work with my Wacom.

Would a 5 year old Linux system work with a driver released in 2008?

Sure

What would you need to do to make it work?

The only experience I have with this, was with a Slackware install and wireless almost a year ago, I was lazy and grabbed a new kernel off http://www.kernel.org/ and some libraries I knew I didn't have with the wireless driver pack from http://linuxwireless.org/. Compiled, installed, done (really just typing ./configure, make, make install a lot with each thing).

Looking at GoboLinux, it doesn't look even vaguely similar to the NeXTstep style bundles in OS X. It's a linkfarm model, which is also a useful approach, but it's not what I'm talking about.

As I've said, there were some distributions even far closer to doing everything the OS X way, but after a couple of years they simply died out because of lack of interest. Some had a idea of using a kernel and having stable ABI/APIs like Windows/OS X etc.

Just goes to show how that model really mattered to users.

With that said, linux REALLY needs ZFS , and not in userspace.

Due to deliberate licensing issues we won't have native ZFS in Linux any time soon. However, BtrFS should be merging into the mainline kernel soon enough (~2.6.29), and it includes most of ZFS's features plus a few of its own: storage pools, checksumming, mutable snapshots, built-in extent-level striping and mirroring, etc. It even supports in-place, reversible conversion from ext3 via a copy-on-write snapshot.

I'm sorry to hear that suspend to RAM didn't work for you. I think MS did well to get it working well on as many computers as they have done and this is one of those areas where Linux has to work hard to even achieve parity.

Having said that, do you know what kernel you are running? Every release of the linux kernel more fixes go in that enable more machines to work (my own suspend problem was fixed in 2.6.26). If you are using a year old kernel then the tedious advice of "test the latest live CD" (which should have a recent kernel and does not need to be installed to do this test) may yield a different result. With 2.6.27 hopefully things are reaching the point where it should be more likely than not to work...

One thing to note though is that if you are using binary only drivers all bets are off. Those can take huge amounts of tweaking to get going with suspend to RAM and there's no guarantee of success even after hours of trying. If it turns out your problem is binary only driver related it's probably better to give up on suspend to RAM...

Since that many lines = approx. 125,000 pages, which = approx. 0.0175 terabytes

and "approx. 0.0175 terabytes" == approx 18 GB which explains why the kernel source's tarball weighs 48 MB.

That's compressed, Uncompressed the source is more like 270M

Since that many lines = approx. 125,000 pages, which = approx. 0.0175 terabytes

and "approx. 0.0175 terabytes" == approx 18 GB which explains why the kernel source's tarball weighs 48 MB. Yup, if you wanted to know how big the kernel source is you just had to look for it ;-).

Besides, I really wonder how you got to that figure, considered how code has little in common with classically formatted text anyways. Not to mention how 125,000 pages == 18 GB, I mean do you have 150,000 characters per page (2,000 lines per page?)?

Just to jump in here...you can't read parity data and invent the missing bits. You need to read the n-1 data bits + parity to work out your missing bit.

Well said. I was pretty low on the sleep when I wrote this. I should have remembered this :-)

If you really did get 1 unrecoverable error out of every 12TB read we'd have an awful lot more data loss on personal computers.

I admit I find the value counter-intuitive too but at the same time I acknowledge that given the size of data that I generally move about on my hard drive it seems plausible that these errors are beneath our ability to detect.

So if you're with me so far try bounding things on the basis of something that you would have experienced vs something you would have heard of.

For example I've never opened a word file to find a sector-sized error but since word files are generally less than 20 MB.

Even given that I shuffle hundreds of word files around on my drive. I'd still have to do it over 600,000 times to be guaranteed an URE. On the other hand if most people shuffle hundreds of small documents across their hard drive. Then it only makes the odds of
knowing someone who has had this problem around the one in one or two hundred mark. I've certainly have met people who have had corrupted files and It's difficult to discount this as a possible cause.

Now clearly bigger files represent a higher likelihood so moving up the chain lets look at the 1GB videos I routinely have on my hard drive. Currently I can't have more than about 100 or so of these on my drive but even so I'd still need to move about 12,000 of these to guarantee an error. Most of these use some form of lossy compression. So even though I am more likely to encounter a read error it also seems much less likely that I would notice. Not to mention that there are some upper layer facilities to fix problems with these files.

Let's take the biggest amount of personal data I tend to move: My RAID. I had about 1TB of data on a RAID 5 across eight 200GB discs. I moved this to a 1.5 TB RAID 5 on 4 500GB discs and then from there to a 3TB RAID 50 on 8 500GB discs.

There was only a 1 in 12 chance of any data corruption in the first move, the same in the second move. Still an 84% chance of never having a single sector hurt.

That combined with info from places like CERN

It seems a reasonable conclusion to me.

I like to think of it the opposite way: RAID 5 is a special-case implementation of RAID 6. The parity calculation in RAID 5 work out to be a simple XOR, but the second (and third, fourth, etc) parity calculations in RAID 6 with two or more parities are significantly more difficult.

If you're interested in implementation, check out The mathematics of RAID-6 (pdf) by H. Peter Anvin, and A Tutorial on Reed-Solomon Coding for Fault-Tolerance in RAID-like Systems (pdf) by James S. Plank (I used these as references to write a RAID-6 implementation in Java).

I find it curious that nobody mentions keywords.

The reason why I did not switch to GIT when Linus created it is that it was not possible to add auto-modifying keywords. With keywords, the SCM can physically modify your files, in precisely marked spots, to indicate the version level of a file in the actual code. I really like this aspect.

At the first publication of GIT, I remember Linus holding a strong stance against keywords. This is why I did not convert to GIT (I am a one-man-company and I do not need to collaborate on code: I need SCM to keep all old versions and changes).

(You can read Linus' stand on this, for example, in this e-mail from 2006)

In the current GIT faq they mention that keyword substitution is "not recommended", but they then point to the man page of gitattributes, which, disappointingly, does not mention keywords.

This is why I keep using SVN. I need my sources to hold within themselves an easily trackable age indication.

Quite a lot of people have actually read the manuals of git, and are using it in all manner of projects.

As I was hinting at with my first post, there is a world of difference between "a lot of people" and "the majority of people". I'm sure a lot of people use git, but far *more* people use some other repository such as CVS or SVN. Making the code available *exclusively* over Git is annoying. They should at least have provided a zip download or something.

They should make the source browseable directly off their website to spare us all this headache.

At least I did not, and I hope that few others do, have any difficulty locating the gitweb repository at http://android.kernel.org/

That's a step in the right direction but not 100% there either. I just spent the last 10 minutes trying to find the speech-recognition related code and found nothing. The developer API seems to be buried below tons of stuff.

1) Who the heck uses Git? I know a lot of important companies do, but most people do not.

Quite a lot of people have actually read the manuals of git, and are using it in all manner of projects.

2) Who the heck is going to download 2.1GB just to look at 1-2 files in the source-code? That's just insane.

So don't!

They should make the source browseable directly off their website to spare us all this headache.

Ehm. This thing about documentation. Oh, and the acronym RTFA... At least I did not, and I hope that few others do, have any difficulty locating the gitweb repository at http://android.kernel.org/

to be fair, reading about brtfs, the design also mentions things like snapshots, mirroring, included raid stuff.
http://btrfs.wiki.kernel.org/index.php/Main_Page
i guess, some middle ground will be reached with brtfs for code reuse and functionality.

Creepy Crawler:

Ext3 file defragmentation

http://en.wikipedia.org/wiki/Ext3#Defragmentation

Consequently the successor to the ext3 filesystem, ext4, includes a filesystem defragmentation utility and support for extents (contiguous file regions).

Also: http://ext4.wiki.kernel.org/index.php/New_ext4_features

Looks like defragmenting is coming to Linux as well, so there goes your argument with that.

Garbageware

Just because an OEM would put Linux on a machine does not necessarily mean it won't come pre-loaded with a large amount of crap. It would, and if you think differently you're fooling yourself otherwise. In fact, I'm willing to bet given the "open" nature of Linux, that the garbageware would not only be installed on the system, it would be a core part of the system. There would be no removing it. While this is merely nothing more than conjecture, it's a very real scenario. Microsoft does not allow the OEMs to modify core parts of the OS, but an OEM could modify a core part of any Linux variant and, for example, include advertisements all the way around your applications.

That's a wait-and-see thing but certainly very possible.

Quote: MS could have done this the Right Way. Chroot is your friend. Programs that whine about XYZ not being where it is, then throwing up a UAC prompt is not the right way to do things. Instead, they could have made a default CHROOT environment for each program, with access to the users home directory.

Unfortunately it isn't quite this simple. In order to maintain backwards compatibility, which is a very important thing moving from here on out, software needs a level of interaction with the system. Whether or not this is/was the correct way to do things is up for discussion, but Microsoft has made it available for software to be coded correctly many years ago. They just never enforced it. Why? Who knows. Now they chose to enforce it, but also offer the user a choice.

UAC and Sudo are very, very similar.

The only exception being that sudo can allow you to elevate yourself and do things without getting bugged again until you are finished.
Of course, it can be argued that this in and of itself doesn't really solve the problem.

If you want to see a fully secure environment, just take a look at SELinux and get back to me. See for yourself how difficult it is to operate an OS and manage it with multiple tiers of users when you don't have root access.

Quote: Once I get it, I need to go into properties (or commandline) and go set the executable bit. If I dont do this, the OS refuses to run it. Now, is his a bad program? Nope. But it solves the "run_anything_from_email" and related issues in MS based systems.

It can be argued that having to flag a program as executable would be a serious problem for the user. Look only so far at the negative reception of UAC, which you took a jab on earlier. Having to nag the user to take extra steps when they just want to run an application is begging for a serious amount of whining. So your proposed solution really doesn't solve this in any way.

Quote: Now, IE will open up and run whatever.

How long has it been since you've run IE? IE will not just "run whatever". It will actually bug the user multiple times whether or not they want to allow the application. There are security dialogs, warnings, and a final "Accept/Install" before you're allowed to run or install any ActiveX file. Again, providing the user a choice. Sure, most users click OK and this is a serious problem, but would you rather the OS just not allow you to do something?

It's actually kind of funny because as the web seems to evolve we appear to be getting more and more to the point where a browser is an execution environment. It's not a si

My wifi hardware is based on the rt2500 chipset series and is quite common on most laptops and until recently were reliable. As far as I remember the drivers were being rewritten for the kernel - which is fine but if it breaks hardware (which until that time had been reliable)
then people should have been made aware of this or even work with the distos for a interm fix.

Try out one of the wireless driver packages from http://linuxwireless.org/ (for hardy http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-old.tar.bz2 ).

You will need to install your kernel source headers and the build environment

sudo apt-get install linux-headers-generic build-essential build-common

Then it's simply,

tar jxvf compat-wireless-old.tar.bz2
cd compat-wireless-old
make
sudo make install
sudo make unload
sudo make load

This will install the latest wireless drivers for your system and will not conflict with your distribution's package manager, should you want to remove the install and restore your previous drivers:

Make sure you are in the directory where the wireless driver installer is.

sudo make unload
sudo make uninstall
sudo make load

(It would probably be a good idea to reboot after that).

Normally I would never, ever recommend people compile stuff on Linux, however, in your case, it seems this would be the only way to get good support and this is really a last resort (a resort that you couldn't do under Windows if you ran into this problem).

It includes a kernel that hasn't been released yet?

Actually it got released today
http://kernel.org/
http://linux.slashdot.org/article.pl?sid=08/10/10/0045239

Perhaps I should have said that I've been using some (all?) of the fastboot patches already. I compile kernels from linux-tip which I believe includes fastboot...

Care to point us at a project you work on in your spare time so that we can mock it?

It's right here. Mock away.

On Linux usb ports can be powered down to save power. However it turns out that many USB devices are broken and can't cope with being powered down. Now the question comes up what version of Linux are you using? If it's something older than 6 months then there's a good chance this has been fixed (the list of things allowed to be powered down has gone from a blacklist to a whitelist of large categories). See this commit talking about the kernel no longer powering anything down bar USB hubs for some more details.

A very short term band aid might be to disable usb autosuspend on that device via /sys/.

From: Christopher Li

Andrey reports e1000 corruption, and that a patch in vmware's ESX fixed it.

The EEPROM corruption is triggered by concurrent access of the EEPROM read/write. Putting a lock around it solve the problem.

link

Linux Kernel developers use USENET? Strange, I thought they used mailing lists.

You can set resource limits per account.

I agree that there isn't much you can do to make an OS resistant to performance degradation if somebody is loading junk on it. However, that doesn't mean that *nix can't enforce resource limits if correctly configured. Also, MS is happy to lean on OEMs in other respects, surely they could do the same with craplets?

Whatever the reason people are dropping support and inevitably an unmaintained file system is going to become at best a marginal legacy tool.

Who is dropping support? I haven't seen any mention of this.

Given that it isn't even a default supported Linux fs chances are it will be broken as of kernel X, and then you will be pretty much forced to migrate, so why bother with it?

I don't know for certain what you mean by "default supported Linux fs", but up to and including the current kernel version, reiserfs is included in the official kernel distribution.

Here is version 1.0 and all of the patches: ftp://ftp.kernel.org/pub/linux/kernel/v1.0.

And here is version 0.01: ftp://ftp.kernel.org/pub/linux/kernel/Historic

Here is version 1.0 and all of the patches: ftp://ftp.kernel.org/pub/linux/kernel/v1.0.

And here is version 0.01: ftp://ftp.kernel.org/pub/linux/kernel/Historic

Well, http://www.kernel.org/ is a good place to start. If your wireless chipset is listed in the kernel's device driver, it is most likely supported.

ralink is one of the most famous ones with Linux support.

There is ndiswrapper, but I wouldn't touch it unless it is absolutely neccessary as it can get hairy and create kernel panic, which may corrupt your file system. The horror.