Slashdot Mirror

Jaunty Jackelope is certainly worth a download. I've been using it on my eeePC 900 with the Ubuntu Netbook Remix (UNR) for a month and while its got its shortcomings, overall its the best OS I'v used with my netbook.

The greatest plus is Ext4. I know that isn't an Ubuntu exclusive upgrade or anything (Fedora 11 is going to offer the option of installing to a Ext4 partition) but combine that w/ my SSD and I boot in like 23 seconds flat...I don't even bother "putting the pc to sleep" since I boot so quick, I just shut down.

The downfall that I found with this release, and Intrepid Ibex, is w/ the eeePC hardware and graphics tiling. Basically the kernal being used in the release candidate has some issues threading the graphics processing and you get signifigant and annoying lag in the UNR interface...but only there. If you open any app it runs as normal, but the UNR interface lags like a son of a bitch. A patched kernal update did fix this however that fix was reverted due to other issues and as of yet a new kernal patch addressing all issues has not been released. You and review the details of the bug here. The .41 kernal is what is shipping and the .40 kernel is what works w/ the eeePC. If you want to install your own kernel you can get the .40 here.

The use of Ext4 makes this a true upgrade and a reason to install a new build. Enjoy!

Jaunty Jackelope is certainly worth a download. I've been using it on my eeePC 900 with the Ubuntu Netbook Remix (UNR) for a month and while its got its shortcomings, overall its the best OS I'v used with my netbook.

The greatest plus is Ext4. I know that isn't an Ubuntu exclusive upgrade or anything (Fedora 11 is going to offer the option of installing to a Ext4 partition) but combine that w/ my SSD and I boot in like 23 seconds flat...I don't even bother "putting the pc to sleep" since I boot so quick, I just shut down.

The downfall that I found with this release, and Intrepid Ibex, is w/ the eeePC hardware and graphics tiling. Basically the kernal being used in the release candidate has some issues threading the graphics processing and you get signifigant and annoying lag in the UNR interface...but only there. If you open any app it runs as normal, but the UNR interface lags like a son of a bitch. A patched kernal update did fix this however that fix was reverted due to other issues and as of yet a new kernal patch addressing all issues has not been released. You and review the details of the bug here. The .41 kernal is what is shipping and the .40 kernel is what works w/ the eeePC. If you want to install your own kernel you can get the .40 here.

The use of Ext4 makes this a true upgrade and a reason to install a new build. Enjoy!

I realize it's mostly the fault of Intel, but it would be nice if the modern (2 years old) Intel chips worked well with Linux.

I went with Intel instead of Nvidia in my laptop so I would have a more stable computer than using the binary blog nvidia provides. (and I don't game) Boy, had I known Intel would totally drop the ball I would have went with Nvidia. Ubuntu doesn't seem to be interested in pushing the issue at all, saying 'it's an upstream problem'. I got burned the same way with the g400 and it's so called open source drivers a decade ago. It took them almost 4 years to get them out the door, and they sucked when they were out.

It's a real sad the best video support on linux is from closed source nvidia drivers and their competitors don't even care.

Check out the list: https://bugs.launchpad.net/xserver-xorg-video-intel/+bugs

So, back on topic, does anybody know how horrid Intel video is in this final release? I need to decide if I'm going to upgrade or not, last I heard it's even worse and locks up after a few minutes. I have an x3100/GM965.

I'm having the same beeping bug, and I did report it (just now): https://bugs.launchpad.net/ubuntu/+bug/363532. Unfortunately, I don't have much of an idea of what's going on; clarifying it with information would certainly be helpful...

This problem has allegedly been fixed but there is no mention anywhere of whether it affects linux-rt as well. Can anyone shed some light? I haven't had my coffee yet, late start today.

You can download the source code and FIX IT YOUR SELF!!!!! Or just why don't you SHUT UP if you can't!

Why should he fix it himself? All he has to do is report the problem at this address and Canonical will fix it.

Obviously you use default panel layout and you have a single display. For the rest of us who have customized their ubuntu looks, notify-osd sucks because it is not possible to change the position of the notification bubbles, or their color to contrast them from background and window theme. And with the gnome mentality of the developers, not having an option is actually a feature. Currently I miss all notifications that I don't expect, because they blend with my background and window theme. The only good news is that they included the indicator applet, which collects some of the missed notifications.

I second that. Eclipse can be a mess, downloading and installing it directly is, by far, the best option.

I have a bunch of co-workers using Eclipse and Ubuntu. Nobody even considers using the Ubuntu distributed version. The age of this bug should make it clear how much attention Eclipse gets in Ubuntu https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/81900

I was going to say that for Java development you are normally better off by downloading and setting up everything yourself, but I guess that is also true for all other programming languages. At least I did that also when developing with Python.

and according to this bug, "apt-spy is no longer in the Ubuntu repository for releases newer than feisty."

You are aware that "closest" in this context means "faster", aren't you?

I'm not. The mirror choices are identified by geography, not throughput. If you're saying the geographically closer mirror is faster, I disagree based on the experience of a slow local. If you mean something else, kindly explain.

I've only used Ubuntu since 5.10 and didn't know about apt-spy, so I guess I'm not a power user. And fool that I am I just checked Google and see it's for Debian mirrors, not Ubuntu. Launchpad but 1780 indicates it was briefly included with Dapper, then pulled back out of the repositories for that reason.

https://bugs.launchpad.net/ubuntu/+source/apt-spy/+bug/1780
http://packages.ubuntu.com/search?keywords=apt-spy

What was that you were saying about -Nonsense?

Yeah, Ubuntu does a decent job of being buggy and unstable

Not in my experience, but do provide verifiable sources that prove to be a decent job of being buggy and unstable - Launchpad can't even help you there as it proves otherwise.

Sure they package it nice for the computer illiterate, but they sacrifice the stability I require to get that wow factor in that the general public wants.

I have some servers running on Ubuntu and, I think I only rebooted them once last year when there was one potential kernel security update that could be a potential problem for the tasks they do - during the time I have ran Ubuntu servers, I have had no problems at all. Needless to say, when I was running other Linux distributions on servers - I also haven't had problems there too.

When it comes to desktop usage, I do have a tendency to reboot a lot - but generally nothing related to the OS stability wise. I don't have 'crashing' issues and I haven't noticed anything significantly different stability wise between other distributions I've used.

but even the LTS versions of Ubuntu are a joke compared to Debian Testing.

Really, how? Could you at least give some examples, because all you've been doing so far is saying it's unstable without any examples.

On a modern filesystem, your writes should essentially be atomic and in theory it shouldn't be possible to leave the drive in an inconsistent state when the write fails.

But when "consistent" means all your files are zeroed, that's not much consolation.

It's probably for the best. If you open the link in Firefox on Ubuntu 8.10 (32- or 64-bit), gnome-panel will segfault, restart, segfault, restart... until you change the tab that firefox is showing.

Bug report, and here

It's probably for the best. If you open the link in Firefox on Ubuntu 8.10 (32- or 64-bit), gnome-panel will segfault, restart, segfault, restart... until you change the tab that firefox is showing.

Bug report, and here

Don't most people just sleep or hibernate their computer these days anyway? I think that before yesterday, the last time I rebooted this machine was a couple months ago. I don't mean this as a slight - it's an honest question.

I agree itÂs an honest question and I wish I remembered my login so forgive me but;
There is for example an unresolved bug in ubuntu 8.10 which has bit me severly. It relates to total failure of sleep/hibernate and all that wonderful functionality on pci-e boxes. In my case it is so bad that using it almost guarantees a reinstall of my root filesystem.
And while uptimes are great, I often need to shut my box down so as to avoid cooking the occupants of my small apartment because it gets so bloody hot in here (26-27+`Celcius) in the middle of a Canadian winter with the heating set at 22.

And no I won't provide the link to the bug, find it yourself on launchpad (I believe that is the correct access point)

Actually Ubuntu has supported PA-RISC/HPPA for ages:

https://edge.launchpad.net/ubuntu/jaunty/hppa
http://cdimage.ubuntu.com/ports/daily/current/

(these are the links for the in-development release Jaunty, but HPPA has been a part of Debian since Breezy).

Er, Drizzle is developed at Sun (lead developer Jay Pipes, Sun Staff Engineer).

There's a number of decent forks of MySQL out there, time to look at them. People, list all of the forks you can think of here, I'll start with drizzle https://launchpad.net/drizzle

Drizzle's no good for me, I want those advanced features.

How about right here for starters.

If you want to get hardware developers to hand over their specs/source, eventually there has to be more motivation than "the kindness of their hearts." Maybe it's 5% market share. Maybe it's 10%. Maybe it's 20%. I don't know which, and I suspect the threshold for each developer is going to be different.

It's either that, or Linux can remain unadopted. You just have to remember that then, Linux will remain unadopted. And there is a better-than-even chance that down the road, some variety of hardware you want to use under linux - maybe a scanner, or a camera, or a TV tuner, or something else - simply won't have Linux support.

Maybe that's all the Linux community is destined to be, a collection of head-in-the-sand "developers" and a bunch of kool-aid drinking, deluded "evangelists" talking about the glories of their Chosen OS while everyone else goes around using something else that actually works for what they need it to work for in their day-to-day lives on the hardware of their choice.

Good for you, and anyone who sticks to this viewpoint, including Linus himself, remembering his "I'm not out to destroy Microsoft. That will just be a completely unintentional side effect". On the other hand, we also have this kind of thing - and those people can't weasel out of having to admit that it is, indeed, their problem.

Yes, it's free. Nobody *has* to listen to you and that's the problem in a nutshell. Nobody gives a rat's patoot about the fact that the wondrous Ubuntu can't see my USB drives and half of my other devices.

Ehm, actually the ubuntu devs would sure like to hear from you. Head to https://bugs.launchpad.net/ubuntu and knock yourself out.

Everything on my Ubuntu installation is 64 bit. Every single application. Since I'm using Chromium, I guess that I have V8 in 64 bit. Just add the Chromium repository to Apt, then apt-get the source. You don't even have to know how to compile. (I do know how to, sort of, but I'm certainly not proficient - just let your installer do the work!)

I suspect it's using ia32-libs and not actually 64 bit. I have two reasons for suspecting this.

1) Chrome does not support 64 bit builds

2) The Ubuntu Chrome Daily PPA page says "no native 64bit debs planed for now. The amd64 package is using ia32-libs."

Yep, like i said, it's a shame, The idea is that we would use it in our project which is a telephony server that runs much better on 64bit, that's really the only show stopper from our being able to try it instead of the spidermonkey library we use now.

Try changing your the audio resample method on pulse audio as described here: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/330006/comments/14

After doing this, my old IBM T30 runs full screen flash videos much smoother. Even with external speakers, I'm unable to tell a difference in audio quality except that it doesn't stutter.

Everything on my Ubuntu installation is 64 bit. Every single application. Since I'm using Chromium, I guess that I have V8 in 64 bit. Just add the Chromium repository to Apt, then apt-get the source. You don't even have to know how to compile. (I do know how to, sort of, but I'm certainly not proficient - just let your installer do the work!)

I suspect it's using ia32-libs and not actually 64 bit. I have two reasons for suspecting this.

1) Chrome does not support 64 bit builds

2) The Ubuntu Chrome Daily PPA page says "no native 64bit debs planed for now. The amd64 package is using ia32-libs."

2.20.10-0ubuntu1 can, and is the one still used in Ubuntu (even in 9.04).

The newest version of gdm available in Ubuntu, version 2.25.2-0ubuntu0.1 in the try-out gdm-new package, really cannot auto-login, nor can it do timed login or allow you to theme it much more than changing the background picture.

It's in the plans to make 2.25 (or a newer version) the login manager in Ubuntu Karmic (see the blueprint here), and they have (had) discussions about gdm at some gnome mailing list (I don't have the link presently).

Try disabling Assistive Technologies and reboot. Seems to be enabled by default for some Ubuntu versions. It will defintely kill the Nautilus experience, as one guy put it.

See this page.

That's a very interesting article. Last night after I took my netbook back to square one and installed some available patches I ended up with a fully up to day Jaunty build on ext4 with a gig of swap space. So far nothing has caught on fire, however there isn't a jump in performance in either direction compared to what was going on with my signifigantly smaller (300MB) of swap space.

I am very lazy. I really hope that the swap size really won't kill me considering how I'm using this netbook. I really only use it to hop online and listen to some NPR at work. The interface still lags like crazy, but I found a bug report detailing the issue. It looks like a patch is coming to fix this lag issue. I may have done all the work formatting and rearranging and of-the-such on a fools errand...especially after reading the link you sent!

Jaunty ships with 2.6.28, but there is a Kernel PPA that you can use if you want to change kernel. There is currently no support for Jaunty, but I expect that to appear in the next few weeks.

Note that these kernels are vanilla kernels, so they lack any Ubuntu-specific patches.

That can't possibly be expected behavior. File a bug with your distribution if it's not already known (see the following; I don't know what distro you're using).

https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/207135
http://bugs.debian.org/505097
https://bugzilla.redhat.com/474745
http://pulseaudio.org/wiki/BrokenSoundDrivers

The developers can't possibly have all of the relevant hardware; they need users who run into problems to help them out. Please try to help if you can; it might help the bug get fixed quicker.

Sure, it may have gone from working perfectly in 2.6.21 to not producing a beep in 2.6.28, but look how fast it has become! Priorities! :-P

After the Ext4 dataloss discussion, and the "Don't fear the fsync()" posts, I don't want to hear about Ext4, fsync(), or data loss again.

eCryptfs filename encryption

Here's the eCryptfs home page for more information on this nifty addition.

Is it really fair to call them buggy applications because they prioritise as:

old changes > performance > recent changes?

I would say that failure allow for this type of prioritisation is a bug in the FS/FS driver or OS, not the application.

Being forced to fsync() to preserve the months/years old data in a file feels like overkill to me, and apparently many application programmers agree. The fact that Ext3, and now Ext4 provide mechanisms to set those priorities would IMO be a feature that allows for significantly increased use of caching, as now a choice can be made to defer the write, as long as keeping the old file in the event of a crash is OK.

I am curious as to how much is gained by writing the file many seconds after the meta data though, perhaps it is wrong headed for me to think the gains of delaying the write in those instances out-way the the harm of having to fsync() those cases, but more aggressive re-ordering of operations is permitted.

As for the suggestion of using a single binary database for configuration, please no.

And I am also sceptical that Ext3 will be in a state that I can lose my months old data for up to 30 seconds without an fsync().

Or am I misreading this comment?
https://bugs.launchpad.net/ubuntu/jaunty/+source/ecryptfs-utils/+bug/317781/comments/54

That's OK for some countries, the hidden O/S option might be useful (since you'd have to give them the password for the "official" volume unless you don't mind rubberhose attacks).

But it's not a good idea if you are trying to enter other countries. You don't even want them to know you are using crypto.

Because:
1) They might just decide to use that as an excuse to get a free laptop.
2) Your project could be jeopardized.

Now the odds of the authorities reacting in unwanted ways just because they see crypto goes down if millions of people have crypto bundled and active on their O/S whether they know it or not:

See: https://bugs.launchpad.net/ubuntu/+bug/148440

BTW while Windows EFS can be useful I feel it's been designed more as data protection in case your system is stolen. It's not so good in many other scenarios.

PS2 Those computer users saying an fsync will kill performance need to get cluebat applied to them by the nearest programmer.
1st. There will be no fsyncs of config files at startup once the KDE startup is fixed.

KDE isn't fixed right now. Additionally, KDE is not the only application that generates lots of write activity. I work with real-time systems, and write performance on data collection systems is important.

2nd. fsyncs on modern filesystems are pretty fast, ext3 is the rare exception to that norm; this will be non-noticable when you apply a settings change.

I did some benchmarks on the ext3 file system, the ext4 system without the patch, and the ext4 system with the patch. Code followed the open(), write(), close() sequence was 76% faster than the code with fsync(). Code that followed the open(), write(), close(), rename() sequence was 28% faster than code with that followed the open(), write(), fsync(), close(), rename() sequence. Additionally, the benchmarks were not significantly affected by the presence which file system was used (ext3, ext4, or ext4 patched.) You can look up the spreadsheet and the discussion at the launchpad discussion.

3rd. These types of programming errors are not the norm; I've graded first and second year computer science classes and each of the three major mistakes made would have lost you 20-30% of your score for the assignment.

Major Linux file backup utilities, like tar, gzip, and rsync don't use fsync as part of normal operations. The only application of the three, tar, that uses fsync, only uses it when verifying data is physically written to disk. In that situation, it writes the data, calls fsync, calls ioctl(FDFLUSH), and the reads the data back. Strictly speaking, that is the only way to make sure the file is written to disk, and is readable.

Finally, as Theodore Ts'o has pointed out, if you really want to make sure the file is saved to disk, you also have to fsync() the directory too. I have never seen anyone do that, as part of a normal file save. Most C programming textbooks simply have fopen, fwrite, fclose as the recommended way to save files. Calling fsync this often is unusual for most C programmers.

I would hate to be in your programming class. Your enforcing programming standards that aren't followed by key Linux utilities, aren't in most textbooks, and aren't portable to non-Linux file systems.

If you require your students to fsync() the file and the directory, as part of a normal assignment, you are requiring them to do things that aren't done by any Linux utility out there. Further, if you are that paranoid, you better follow the example from the tar utility, and after the fsync completes, read all the data back to verify it was successfully written.

If power is lost at the right time, the same results would happen.

The right time being the hundredths of a second between the commit of the file data and the commit of the directory data, not 60 seconds.

No, not "hundredths of a second". Five seconds. Or 30 if you're using laptop mode.
https://bugs.launchpad.net/ubuntu/jaunty/+source/ecryptfs-utils/+bug/317781/comments/54

/proc/sys/vm/dirty_expire_centisecs
/proc/sys/vm/dirty_writeback_centisecs
(from https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/7)

Unfortunately that is case #2 as described here:

https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/54

rename(2) is not guaranteed to be atomic. There are now some patches that get ext4 to perform what most people expect #2 to do. I got bitten by #2 not working correctly on MacOS X some time back, I just googled and found this:

http://www.weirdnet.nl/apple/rename.html

Ever since that time I have been using fsync in my code when I needed it. You just get into a world of hurt when you expect #2 to work right under every OS and fs and set of mount options because it doesn't.

Point being, if such things are really a problem for the application, the application must do things correctly, by writing to temporary files, renaming, and writing in the right sequence so that even if something is interrupted in the middle the data on disk still makes sense.

RTFA -- that is exactly what programs are doing, and it's still considered broken. ext4 reorders the operations so that the new file's contents can be written to disk after the rename is. That means that there's an interval where the new, empty file has overwritten the old file's contents, before the new file's contents are written. This issue causes loss of old data, not just recent changes. According to Ted Ts'o, this sequence of operations is buggy:

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 correct solution, according to him, is to use fsync() if you don't want the old file to possibly be truncated on filesystem crash. But this leaves no option I can see for programs that want to say "I don't really care if the data gets to disk safely, just make sure you don't overwrite the old file until it does."

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

If you read the article, this is precisely false with ext4.

Well. The summary had multiple links, and the pages it pointed to had multiple links to other locations. And I haven't found out which one is supposed to explain exactly what happened.

I went to read https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45 again, and though the wording there is quite confusing, by reading it again now a bit earlier in the day, I managed to figure out that it describes "workarounds" for two situations.

1. A file is overwritten by being truncated to length zero and then new data is written.
2. A new file is created filled with data and renamed over an existing file

The first of those two is clearly a buggy application, and I'd rather the applications were fixed than the kernel have workarounds to minimize the risk of data loss. That case is one where data loss is to be expected, it could happen with any file system, the window for loss just happen to be larger on ext4.

The second case is one where a newly created file is renamed on top of an existing file. A pretty normal procedure. And I wrote "workaround" in quotes because the kernel isn't really working around something inherently wrong in the application. I'd rather say one part of ext4 is working around a problem in another part of it.

I have yet to find an authoritative source telling me which of the two "workarounds" apply to the KDE data loss. I did however find indications that a lot of other applications were affected as well. I can't imagine all of them have the bug of deleting the old version before creating the new one.

Or rather, the rename can be committed to disk before the data writes have been; if you crash in between, you lose.

I can understand that if the system crash and you didn't sync, then what you find on disk after rebooting may not be entirely up to date. If it matches something that logically was on disk two minutes before the crash, that would still be valid. I still think the system should try to minimize this window. In particular if the disk is idle, there is no reason why the difference should be more than one second.

However it sounds like what you get after reboot is something that didn't exist at any point in time. The name refers to a file of zero length after the reboot, and at no point in time did that name refer to an empty file, so it is not just an old version of some data, it is a corrupt version. Saying that it is conforming to the standard is a lame excuse, I'm pretty sure the standard does not say the system must cause data loss in this case.

It is possible to make a fix to the file system that handles this case without data loss and without performance hit. If the disk is idle and you don't want to allocate sectors for the data right away to get a better layout, then just commit the data to the journal. I don't know if the journal format already permits committing data for which no location has been allocated yet, but it certainly could be modified to support it. I doesn't cost you any performance to write the data twice in this case because the disk was already idle, and it doesn't give you a worse layout that will give you performance problems later, because the allocation of the final location is still delayed. If the system crashed before the delayed allocation had happened, it would then happen during journal replay. If the system is busy, it is acceptable for data to take a while to make it to disk, as long as data on disk is consistent. That means don't commit to the metadata changes until after the data which had to go before it has been committed to disk. Of course in that case you still have to take care to avoid starvation.

Saying that it should be fixed in the application is BS. Creating a new file and renaming that should be sufficie

While Jane Q. isn't fully correct as you pointed, you are dead wrong.

ext4 is flawed, for two reasons:

1) The window of opportunity for a dataloss at crash time have been extended. Hence, the filesystem is less reliable for that very reason.

2) It looks like the meta-data journaling have the side effect of guaranteeing the reallocation, so a crash means a 100% sure dataloss, for every file rewritten

Asking application writer to change the way they use APIs to take into account ext4 is just denial.

open() + write() + close() guarantee that the data is accessible to other applications. It does not guarantee that the data survives a crash.

HOWEVER, unix application writers are NOT expected to do anything more, in particular, they are not expected to use fsync() on each file.

FURTHERMORE, fsync have performance issues, in particular, on ext3, fsync() will flush ALL the data for the specified file system, resulting in extraordinary bad performance.

> WE ARE TALKING ABOUT UNEXPECTED KERNEL CRASHED AND POWER OUTAGES. If you care about that situation then you should get a clue before you start coding.

No. What does it means ? Every coder of every unix application everywhere should start caring about the fact that ext4 is fragile ? You are mixing applications that NEEDS integrity (databases, where coders WILL have to care about the situation) with applications that don't (Gnome, KDE where coders MUST not care, because that is the job of the OS)

ext4 is clearly flawed, and even Theodore Ts'o call the behaviour a "problem" and is working on a "solution". See https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45

You should go read the bug again. If applications keep on re-writing the same file again and again, they will loose data. Here it is for your benefit...

"So the difference between 5 seconds and 60 seconds (the normal time if you're writing huge data sets) isn't *that* big, but for certain crappy applications that apparently write huge numbers of small files in users' home directories. This appears to be the case for both GNOME and KDE. Since these applications are rewriting existing files, and are apparently doing so *frequently*, the chances that files will be lost is high."

https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45

And calm down !!

I personally think it should be perfectly OK to read and write hundreds of tiny files. Even thousands.

To paraphrase https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/54 : You certainly can use tons of tiny files, but if you want to guarantee your data will still be there after a crash, you need to use fsync. And if that causes performance problems, then perhaps you should rethink how your application is doing things.

https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45

https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/54

https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45

https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/54

And, like him, I still don't know how to get OOffice 3.0 installed.

Run Synaptic. Under Repositories -> Third-Party Software, add: deb http://ppa.launchpad.net/openoffice-pkgs/ubuntu hardy main. (Or intrepid main, or jaunty main.) Then reload. Then upgrade OpenOffice.org to 3.0.1. That should do it.

Actually, when I go to http://openoffice.org/ I'm offered to download an installer. And they've got .deb packages too, which I think is how I originally installed it.

Would be nice to see it included by default then in either HAL or come with Xorg, or the problem fixed in Xorg perhaps would be a better solution instead of a "patchier" solution, if it is.

The problem with that fix is that you need a database of all the possible joystick names, which isn't practical and undermines the whole benefit of USB-HID (i.e. any input device 'just works'). However a more permanent fix seems to be available, haven't checked it myself.

Xorg is ignoring/overriding the driver?

No, the Xorg problem is just that Xorgs thinks your joystick is a mouse, once that is fixed Xorg is completly out of the way, since games access the joystick/event interface directly. The whole problem with games not recognizing the dpad is a completly different beast and in large part simply caused by gamepads having a wide variety of different configurations (some have one digital stick and two digital buttons, other have two analog sticks, a digital dpad and a dozen of buttons, some buttons are analog, some digital, ...) and games simply are not able to handle all of them, because hardly anybody has all those input devices floating around to test all those things. I don't think that problem will go away anytime soon, since there just doesn't seem to be a clear solution. Microsofts solution was to basically say "fuck you, buy our gamepad instead", which of course isn't a pretty solution. The other solution is that games just tries to handle all the possible cases and allows users configuration, which many try to do, but which many fail, since there is always a weird edge case that they haven't thought of (analog-trigger for example often fail to be recognized as buttons). The cleanest solution at the moment seems to be to just to allow to remap things at the driver level so that the game gets to see an input device which it can handle, which my xboxdrv app does, but that of course means that you have to configure each game individually, but at least it works after that.

They should be doing this:

https://bugs.launchpad.net/ubuntu/+bug/156693

Won't work. If there is a policy mechanism to "always allow" (e.g. "don't annoy me any more for this program"), then clever software developers will figure out how to to solve the "UAC Problem" _once_ in their setup routine (by pre-setting the policy), rather than fixing their programs to run as non-admin. Then they just use and adapt the same setup.exe for all their programs.

Then everyone is back to where we started- everything runs as admin.

I suspect that the Microsoft dev team considered that before they decided to annoy the shit out of their customers. One has to assume that they are neither stupid nor contemptuous of the people who pay their bills...

They should be doing this:

https://bugs.launchpad.net/ubuntu/+bug/156693

http://slashdot.org/comments.pl?sid=1152645&cid=27105713

Summary:
UAC is like getting users to solve the "halting problem", e.g. figure out whether the program will halt or not (aka screw up your PC or not) without having the program's source code, or knowing all the inputs. Google the "halting problem" to see how hard it is.

My suggestion is analogous to:

Program: "Hi, I'm a flash demo, I want 30 seconds of real time"
User: "Sounds reasonable. OK",

The O/S then runs the program, and if the program is still running 30 seconds later, the O/S kills it.
So no need to figure out whether it will halt or not. The program will halt - the O/S ensures it.

If the program says "Hi, I'm a flash demo, I want infinite time", it should be far easier to train the user to go: "No" or "Too bad, you only get two minutes to do your stuff, that's all I'm willing to give you".

AFAIK, Microsoft has lots of very very smart people working for them. I'm sure they have already figured out something far better than my idea, after spending 6 billion dollars and thousands of man-years on Vista.

So UAC is either institution incompetence, or malice (they just want to shift blame to the users, or they don't actually want increased security).