All the other browsers? Sorry, but how is Opera Mobile 9.7 beta a full production release?

No, he's not a reviewer. "*That* much"? Hell yeah! A simple comparison:

I have an eeePC 900 with Celeron - with low brightness, no WiFi, even no sound and nothing intensive to do (say writing some text in vim) I can break the 3 hour barrier, just like you, but that's it. In the US it's probably somewhat better, I heard they shipped with 5600mAh batteries, but the european edition had just 4400mAh. Oh, well, it's still small and good enough.

When my GF asked for one like that, we chose 901 with Atom. 8+ hours is not a problem, with normal brightness, occasional WiFi access, watching some videos on YouTube, etc., but mainly just playing solitaire. I'm sure it would last 5+ hours under heavy use. *And* it's noticeably faster, both CPU and WiFi!

If battery life is important for you, by all means, get a later one with Atom. IMO the new ones (1000 etc.) suck, they're too big (size matters, not just weight), but the 901 is a huge step forward from 900 and earlier models. Man, I must get one myself...

That's definitely true. I visited Paris a few times and a quick bonjour, parlez vous... helps a lot. Anyway, this is stupid. I'm usually not a tourist - if I go somewhere, it's a bussiness trip and it's not always planned weeks in advance. Show enough interest? But what if I'm not interested? It's not really snubbing - I'm at work here, next evening I'll be back home, give me a break! I had tickets for a good play for today and I had to cancel to get here, so excuse me if I just want to get to the right place, get the work done and leave. I may come again later, as a tourist - then I'll be sure to learn a few words, the local customs, etc. I usually do.

I don't expect people in a non-English speaking country to necessarily know English. If they don't, I'll try communicating with gestures, no problem, or just look for someone who does. But if you do know English - why make things difficult? I'm not a native speaker either, so WTF?

Still, it IS getting better in Paris. On my first visit, a long time ago, the few words of French were absolutely necessary. And still, not always sufficient. We couldn't even communicate at a supposed tourist information stand in a train station! And the clerk's eyes said enough about what he thought about us. Seriously, WTF? On my last visit there was no problem. People in hotels, etc. speak English by default. If you're nice, most people on the street will at least try to understand you and help you, even if they can't really speak English. I still try to open the conversation with a few French words, because I can and it feels polite, but it's not absolutely necessary anymore.

But act as if you assume everybody speaks English - good luck finding anybody who does. On the other hand, if you do act like that, count me out as well. Przepraszam, nie rozumiem, po jakiemu Pan w ogole mowi?

Blah... Trivial indeed. I didn't know this. Without those the iPhone would indeed be way better. Oh, well, luckily I'm in Europe.

On the other hand this means that Nokia is shooting itself in the foot - one of the main driving forces for the iPhone in Europe was the pre-existing hype from US. Since you suggest that the best choices (well, almost the best - European market is still way behind Japan) are not available there, this hype was much easier to create than it should.

Maybe, but it's the only thing that gets any attention on /. except the iPhone.

O-kay... Now WHY is parent modded as funny? Fanboy mods probably think that any comment suggesting that some product is better than iPhone must be tongue-in-cheek (with the possible exception of Android).

Just like iPod never was the perfect MP3 player, iPhone is not and never will be the perfect phone. Sure, for many users, including a couple of my friends, the iPhone is great and nothing comes close, but "many" isn't the same as "all".

I played a bit with the iPhone. It's fun. It's well designed. It's not for me. I definitely wouldn't exchange my Nokia E61i for it, and that's an old phone now, better ones are available. If I had a choice - get iPhone for free or buy E61, E71, or something like that - I'd reach for my wallet. For me it's far more functional.

For example - I don't really like touchscreen interfaces, especially with small (<10") screens, multitouch doesn't change this. Typing an SMS or working with SSH is so much faster on a full qwerty keyboard, after you get used to it you can actually touch-type with your thumbs.

Still, I read articles in newspapers and feel that I'm expected to want an iPhone. Even here on /. it's the same thing - it seems that I should want one. So many interesting designs on the market, but only iPhone and Android seem to get any attention.

So, the parent was right in both the title and the comment. The iPhone is not for everyone and it is a bit irritating to see it mentioned everywhere and get weird looks from iPhone owners when they show it to you and you say "It's nice, but I prefer something else".

Unless of course I missed the joke?

What problems in applications? As far as I can see, most pro-ext4 comments bash applications for not doing fsync(), calling this a bug in the application. The problem is that if we fix this "bug" in the applications, ext4 becomes useless! If you fsync() everything, write caching doesn't have a chance of speeding things up - and you'd have to fsync() most files...

The point is that there are three types of files, not two as is usually implied in this discussion. Some files are not important, data loss is acceptable, so they can be cached. Some files are important and should be written to disk ASAP - fsync() gives you that. But many files in the real world (I'd risk saying that "most" would be the better word) do not fit in either category. They're not just created, read and deleted - they're mostly modified. The point is that the changes are in the "unimportant" category, the file itself is not. So, if you lose your changes, too bad, you probably lost some time, that's it. But if you lose the file, you lost a LOT of work, or potentially end up with a system that will not even boot.

The proper, but costly solution is a transactional filesystem. Using a database as a workaround is sometimes suggested (KDE should use sqllite for config, etc.), but how would you use it for your normal files? A transactional FS would be great, but unnecessarily slow. Most files don't need something like that.

The workaround is writing to a temporary file then renaming. This works if order of these two operations is enforced. POSIX does not specify clearly a good enough consistency model for an FS. A causal or even FIFO model would suffice in this case. It's so simple to solve - if two operations on the same file by the same process (or by any process) are done in a given sequence, do not reorder them. If this limits write reordering too much for your taste, another approach might be to sync metadata and data changes - don't rename a file until pending writes to it are synced and don't write anything to a file until pending create/rename/whatever is completed (well, this is a bit more complicated that it seems - the directory is a separate file after all). Sure, this isn't in POSIX, but it is a basic usability requirement.

Another way is to extend the API, adding something like a rename_on_sync() or fclose_with_rename() call - that would be the simplest solution to the problem of low priority updates to high priority files, extremely easy to implement in most filesystems (that's how they do the normal renames, so it's just a #define macro), a bit more work in Ext4. If this is implemented, then applications can actually be fixed and everybody's happy. Don't worry about POSIX compatibility - pure POSIX programs can still use fsync, while smarter ones can add a macro to use the new function if available and replace it with a normal rename otherwise, this will work everywhere, never worse than pure POSIX.

So many solutions. Pick one and everybody's happy. Or keep shooting yourself in the foot with the fsync() BS - if application authors start doing this, everything will be slow and your precious advanced write caching will actually be used once in a blue moon.

POSIX is broken in this aspect - there is NO way to implement the behavior that is required for most files (cache writes all you want, but leave the old version until the update's on disk) based on explicit POSIX guarantees. The only choice: forget write caching or pray that your system doesn't crash before the write is performed. Since this is a very common requirement, any aggresively caching FS must offer a way to do this or risk getting abandoned by users after sufficiently many horror stories.