Nah, just a simple matter of Javascript to test if you have certain pieces of chrome installed relating to this script to determine if the clicks are fake. No Javascript, no ads for the plug-in to click on anyway. Then the plug-in is going to have to randomize where it stores its chrome evade detection.
Advertisers really don't want to get into this arms race. They're bound to lose. The browser has resources at its disposal that no web page can. If someone were so inclined, he could create a method of hiding ads that scripting running in a sandbox couldn't possibly detect. Image elements would seen normal; popup windows could be virtualized.
Oh, sure, advertisers will try to run timing attacks and such, but those can be faked as well. Ultimately, all the advertiser is doing is wasting resources he can better spend creating ads that people don't feel so strongly opposed to seeing.
What I meant was that for each device, Amazon would generate a key pair. The device would ship with the decryption key, and Amazon would keep the encryption key. What you call public and private can get confused in this context.:-)
A better solution is to DO RESEARCH prior to purchase, in order to eliminate ignorance as much as possible.
You know damn well that most people won't do research no matter how much you yell at them. You know damn well cell phone companies will exploit slick marketing to make people make decisions that aren't in their own interests. You can't change this. It's human nature. Even the best of us are sometimes fooled. We only have 24 hours in each day, and I for one don't want to spend my life doing market research.
I am contract-free and I did it *by myself* rather than rely on a politician.
I am too, but I recognize most people won't do the same.
Now for the meat:
"People are ignorant" is a poor excuse to turn-over the markets to politicians.
It's physically impossible for even a very intelligent person to perform the research he needs to make fully-informed decisions in every instance, and so capitalism's underlying assumptions are invalidated. I'm not proposing to put politicians "in charge" of the market. That's a strawman. What politicans can do is:
Enact regulations to make the market more transparent. By keeping the market honest, open, and free of collusion, we can approximate what we'd see in a true free market with omniscient supermen participating in it.
Make the market take into accounts its externalities. Pollution credits are a perfect example of this principle, and have been very effective.
Regulation makes the market work better. Regulation interferes with the markets like oil interferes with an engine. Both will grind to a halt and break down if you leave them alone.
The smart thing for Google to do would be to completely ignore the program, and let advertisers use their usual click-fraud dispute resolution mechanism. By fighting the program, Google would only be giving the program legitimacy. Without the "I'm being oppressed" notoriety, the program will pick up very few users and the total effect on the market will be small.
I'm not against advertising. I'm against fraudulent, manipulative, and obstructive advertising. Google AdWords typically score relatively low on all three counts, so they're fine with me.
An identifying number cannot be copyrighted. Feist vs. Rural Telephone held that a copyrighted work must exhibit some sort of discretion or creativity. An algorithmically-assigned serial number does not satisfy that condition, and therefore is not subject to copyright.
If you crack open a sealed appliance your warranty goes poof. If you fry the neighbor's kid when he touches the stainless steel case, you go poof.
The modification itself isn't illegal. Yes, it may void a separate contractual relationship with a third party, and you may incur some liability if your modifications cause damage. But the modification itself is not illegal.
You have a house to rent. What you don't have is a Certificate of Occupancy. Because you were too cheap to hire a plumber to fix the drains.
Building regulations are specific rules enacted by the government for the public good. You could argue the DMCA is like a building regulation for computing, but it lacks the legitimacy building codes have: ignoring building codes can hurt or kill someone. Ignoring the DMCA might... reduce profit? If you want to make an analogy between building codes and the DMCA, imagine if a town required you to use the original contractor for any repairs to the house, and required the house to be rebuild every few decades, again by the original contractor. Like the DMCA, that regulation would be pure corruption that did not benefit the public good. Building codes are morally defensible; the DMCA is not.
Your car has a valid registration. It has been inspected. You have a driver's license. You have insurance. Your loan payments are up-to-date.
The same reasoning applies to automobile regulations. It's the public good. The DMCA is illegitimate because it does not serve the public good.
I fully expect paper books to become luxury items in the next 20-30 years, where you'll have to pay quite a bit of extra for the privilege of "feeling".
Oh, I agree. You really can't beat the zero marginal cost of an e-book. That said, I'll still purchase at least some of my books as bound sets of paper pages, and there are lots of people like me. We see something like that dynamic today when we compare hardcovers and paperback books: some people buy hardcovers even though the paperback contains the same text, either as a way to support an author, because they want the feel of a more rugged volume, or because they want a book soon after its release.
e-books will become commodities, sure, but they'll just work as a tier lower than today's paperbacks. Hardcovers will still be around: in fact, I suspect we'll see publishers start to include e-book copies of the text as a way to entice people to buy the very profitable hardcovers.
Thanks for the anecdote. It illuminates why laissez-faire capitalism fails again and again: market capitalism works flawlessly in theory. This theory, however, rests on the assumption that all market participants are rational actors, and that these participants have access to all the information they need. This assumption does not hold in real life.
In real life, even relatively intelligent people only have 24 hours a day in which to make decisions, and nobody has the time to obtain all the information he needs to make rational decisions about everything. Most people will not have the skepticism or the presence of mind to question the service representative the way you did. Slick marketing exploits this weakness by pushing incorrect information that average people, pressed for time, will take as fact. Neither will most people use the courts to have contracts like this canceled, even if they become aware they were cheated: a lack of time again neuters the tools that capitalism in theory gives us to counter these abuses.
This is why we need explicit market regulation: to compensate for human inefficiency and weakness in the market. Cell phone contracts should be made illegal outright, the way they are in parts of Europe.
There's already a perfectly good legal mechanism to amortize high up-front costs over a product's lifetime: it's called a lease. If a company wants to restrict how a product is used, the company and the customer can sign a lease agreement. Xerox very successfully used that business model for its early photocopies.
The problem we're seeing today is that companies want to have their cake and eat it too. They want customers to feel like they're making a purchase, but act like they're under the terms of a lease. That's fucking bullshit, and runs counter to personal property rights at the core of Western civilization.
In short, if you want to tell me how to use your widget, you'd better lease it to me. No way in hell should you be telling me how to use property I've purchased outright without signing any kind of contract with you.
I love the sound a new hardcover makes when you open it for the first time; I love being able to take a book camping without worrying that it will be crushed. I love being able to physically browse through everything on my bookshelf and pick something that interests me. Oh, and I love being able to make margin notes and dog-ear pages. I love that I can feel a book's right side become smaller and smaller as I read, and how I can become excited (or nervous) about feeling the ending being near.
There's just something satisfying about a physical book that I can't replicate with an E-Book. Sure, I'd rather have an E-Book dictionary or cookbook, but you'll pry my narrative paper books from my dead hands.
I really wish that were the case, but the congress critters who passed the DMCA, and the president who signed it, didn't see it that way.
Thank you for posting this: it gives me a chance to highlight the difference between our moral code and the law. Any law that attempts to curtail a popular public activity is not only futile, but also doomed to cause a lot of misery while it fails. The DMCA is one such wicked piece of legislation. That said, I don't think the DMCA applied here because nothing is actually circumvented. Amazon is simply using it as a legalistic bully club.
Unfortunately, some believe in the pernicious notion that things are wrong simply because they are illegal. There are few ideas more harmful to a free society.
IANAcryptographer, but public key cryptography is a no-brainer for this scenario. Amazon should have created an RSA keypair for each kindle sold. Amazon would keep the private key and put the public key on the Kindle. When selling an E-Book, Amazon would just encrypt the Mobi file with its private key. That way, it wouldn't matter if some third party obtained the RSA public key for a specific kindle --- all he could do with it pound sand, since Amazon would keep the private keys secure and internal.
Granted, I think the DRM is vile. But I can't understand why Amazon also implemented DRM so poorly.
(If you want to be able to let multiple people read the same Mobi file, do this: generate a random symmetric cypher key (K) and encrypt the E-Book with it, resulting in ciphertext B. For each Kindle you'd like to be able to read the E-Book, let its key be M1, M2, and so on. The file you send out contains K itself encrypted with M1, then K encrypted with M2, K encrypted with M3, etc., and then finally B. A kindle would try all the keys in the E-Book file and just use the first one that successfully decrypted B.)
They're counting on making their money back and more selling the e-books over that network
If Amazon would like to try this approach, that's fine. But our personal right to do what we will with our property trumps Amazon's business model. If Amazon's business model won't work in a free society, it has no business working at all.
Oh, I'm sure the reason OP didn't come up with a better example is that he was being crushed by a fucking tank. Come on -- China is what the Bush regime aspired to be like.
The problem is that the file itself may not be synced at the time of the rename.
Historically, it has worked that way, and for a good reason: it's sane behavior. That's my whole point. More precisely, the file's data blocks need to be committed before the rename operation itself is committed to disk. That's not saying that the syncing must occur before rename returns.
Do you realise that what you want is equivalent to having the FS do the fsync for you?
That's not the same at all. How many times do I have to explain the difference between an ordering constraint and an explicit sync?
rename(A,B) must flush A's data blocks before writing the record of the rename itself. The filesystem does not need to do this when you call rename! It could do it six minutes or six months in the future, as long as the data blocks for B are written before the rename record itself. This property preserves atomicity. Sometimes you want atomicity without durability, and this is how you get it.
Performance is vastly improved over the fsync-everything model because the filesystem can still batch updates. "Do A and B when you have a chance, but make sure to do A before B.=" is saying something fundamentally different from "do A now. Do B."
Well duh, if you write hundreds of 50-byte files, performance will suck, unless you skip safety protocol.
Blame, blame, blame the victim. This is 2009. There's no fucking reason for a modern filesystem to not cope well with hundreds of small files.
KDE (and Gnome) are truncating critical system files without a backup available. How is that sane? Sure they will immediately rewrite the file, but who will guarantee that the system will not crash between the truncate and the write?
Under ext4 and XFS, you lose when doing an atomic rename.
Are you arguing that such a sequence should be treated specially by the OS? Why?
Yes. It's not that the sequence as a whole should be treated specially: it's that rename should be sane enough to introduce ordering constraints on the source file's data blocks. Why? Because it's useful, application developers have fucking relied on it for years, and the alternative, fsyncing all the time, is a different request that's slow as hell.
Personally, it seems 'cleaner' to me to do fsync on files that I absolutely want to get written to disk, especially since it's portable over OSes to some extent
There's a big difference between ensuring relative ordering and asking for a disk sync. Relative ordering corresponds to atomicity, a database property. Pure disk-syncing is durability, a different database property.
Under traditional Unix filesystem semantics, you have three options for a filesystem operation:
atomic and durable: open-write-fsync-close-rename
atomic, but not durable transactions: open-write-close-rename
durable, but not atomic: open-write-close
As it turns out, Windows without Transactional NTFS only gives you one option: durable, but not atomic. (Where you open the file in synchronous mode and just write to it.)
Windows does not support an atomic rename. If you have files A and B, in order to rename A to B, you need to delete B first. If the system crashes between the deletion of B and the renaming of A to B, you end up without a B at all!
Only you can tell whether you need durability, atomicity, or neither in your application.
For example, if you're writing a mail server, you need both: you need to tell the mail program on the other end that you received a message and stored it securely, so you need to know that the message hit the disk. Thus, you need a durable transaction. It won't do to have partial messages laying around, so you also need an atomic transaction*.
If you're writing something like KDE's configuration stuff, it really doesn't matter whether you end up with the old configuration file or the new one. In the worst case, the user loses a setting he just made. So you don't need durability. However, you can't have corrupt configuration files laying around: the desktop environment might not come up at all then. So you do need atomicity.
If you're writing a compiler, the user can just re-run the compilation if the machine crashes. Since the output can be regenerated at any time, you don't need durability. You'll never have multiple compile jobs writing to the same output at the same time anyway, so you don't need atomicity either. Therefore, a compiler can just open its output directly without fancy rename tricks.
If you're writing a log recorder, you want to make sure log messages hit the disk. But since your program controls all access to the log file, you don't need atomicity from the filesystem. You can just open the logfile and write, syncing to it after each entry. That way, you get logs up to the instant before the machine crashes. (This is precisely what syslog does by default.)
What atomic rename under Unixish systems gives you is the ability to have atomicity. Without atomic rename, we can only achieve atomicity by using a locking system that's not part of the filesystem itself, which is a whole other level of pain and complexity.
I don't know what you're writing in Python. But under Windows, all that fsync is giving you is durability. It can't give you atomicity. Are you sure you really need it?
* (Which you get for free with maildir, incidentally. But if you're delivering to an mbox file that contains multiple messages, you need to lock the mbox file to make the message delivery atomic. One popular method of locking is to use atomic renaming...)
But isn't it a bit odd to do a rename operation for this purpose? It isn't what renames are for.
Yes and no. Atomic rename has been part of Unixish systems for a very, very long time. Everyone has always used it to implement changes that need to be atomic, and for the most part, atomic rename has been all that's been needed for that purpose.
I'd also like to see a fbarrier system call that would preserve relative ordering of writes within a single file, but it's not a critical piece of missing functionality. In most of the situations I imagine you'd want to use fbarrier, you'd really rather be using a database engine anyway, and database engines implement the moral equivalent to fbarrier internally.
Vista's Transactional NTFS is also interesting, and I wish we had something like it in unixland. But on the other hand, it's not absolutely essential in the way atomic rename is.
Or to be more precise, POSIX lays out the bare fucking minimum for a half-sane system. It's a set of requirements, not a golden holy tome!
This is Slashdot, so here's a car analogy. POSIX is the law that says what's street-legal. A car needs two headlights, two tail-lights, emissions below a certain point, and so on. Both a base-model Chevy Aveo and a Ferrari are street legal, but I'd rather drive the Ferrari? Why? Because it makes guarantees that go beyond street legality.
Now say you drove Ferrari and the air conditioning malfunctioned. Image how angry you'd be if the Ferrari dealership said, "nope, sorry. We're not going to fix this. Your car is still street legal, so you should have just gotten used to driving without the air conditioning."
You know what I'd say? Fuck you.
You can guess what I'm saying about filesystems that break the perfectly reasonableopen-write-close-rename sequence.
What if the FS NEVER wrote anything until a fsync was called? All applications would then have to add these calls.
Right. Those who demand we use fsync for atomic rename are telling us to ask for a guarantee we don't need.
Here's a rule of thumb: if you're calling fsync because you need to ensure data has been preserved, you're using fsync correctly. If you're calling fsync to preserve integrity even when it's not critical to save your data, you're abusing fsync and the filesystem you're using is broken.
open-write-close-rename already asks for atomic but asynchronous rename under all sane systems. XFS and ext4 break that perfectly sane sequence of operations. These filesystems are doing the equivalent of replacing your bicycle's tires with cats, and then telling you to buy a Mack truck when you complain.
Slashdot Mirror
Advertisers really don't want to get into this arms race. They're bound to lose. The browser has resources at its disposal that no web page can. If someone were so inclined, he could create a method of hiding ads that scripting running in a sandbox couldn't possibly detect. Image elements would seen normal; popup windows could be virtualized.
Oh, sure, advertisers will try to run timing attacks and such, but those can be faked as well. Ultimately, all the advertiser is doing is wasting resources he can better spend creating ads that people don't feel so strongly opposed to seeing.
What I meant was that for each device, Amazon would generate a key pair. The device would ship with the decryption key, and Amazon would keep the encryption key. What you call public and private can get confused in this context. :-)
You know damn well that most people won't do research no matter how much you yell at them. You know damn well cell phone companies will exploit slick marketing to make people make decisions that aren't in their own interests. You can't change this. It's human nature. Even the best of us are sometimes fooled. We only have 24 hours in each day, and I for one don't want to spend my life doing market research.
I am too, but I recognize most people won't do the same.
Now for the meat:
It's physically impossible for even a very intelligent person to perform the research he needs to make fully-informed decisions in every instance, and so capitalism's underlying assumptions are invalidated. I'm not proposing to put politicians "in charge" of the market. That's a strawman. What politicans can do is:
Regulation makes the market work better. Regulation interferes with the markets like oil interferes with an engine. Both will grind to a halt and break down if you leave them alone.
The smart thing for Google to do would be to completely ignore the program, and let advertisers use their usual click-fraud dispute resolution mechanism. By fighting the program, Google would only be giving the program legitimacy. Without the "I'm being oppressed" notoriety, the program will pick up very few users and the total effect on the market will be small.
I'm not against advertising. I'm against fraudulent, manipulative, and obstructive advertising. Google AdWords typically score relatively low on all three counts, so they're fine with me.
An identifying number cannot be copyrighted. Feist vs. Rural Telephone held that a copyrighted work must exhibit some sort of discretion or creativity. An algorithmically-assigned serial number does not satisfy that condition, and therefore is not subject to copyright.
IANAL.
The modification itself isn't illegal. Yes, it may void a separate contractual relationship with a third party, and you may incur some liability if your modifications cause damage. But the modification itself is not illegal.
Building regulations are specific rules enacted by the government for the public good. You could argue the DMCA is like a building regulation for computing, but it lacks the legitimacy building codes have: ignoring building codes can hurt or kill someone. Ignoring the DMCA might... reduce profit? If you want to make an analogy between building codes and the DMCA, imagine if a town required you to use the original contractor for any repairs to the house, and required the house to be rebuild every few decades, again by the original contractor. Like the DMCA, that regulation would be pure corruption that did not benefit the public good. Building codes are morally defensible; the DMCA is not.
The same reasoning applies to automobile regulations. It's the public good. The DMCA is illegitimate because it does not serve the public good.
Oh, I agree. You really can't beat the zero marginal cost of an e-book. That said, I'll still purchase at least some of my books as bound sets of paper pages, and there are lots of people like me. We see something like that dynamic today when we compare hardcovers and paperback books: some people buy hardcovers even though the paperback contains the same text, either as a way to support an author, because they want the feel of a more rugged volume, or because they want a book soon after its release.
e-books will become commodities, sure, but they'll just work as a tier lower than today's paperbacks. Hardcovers will still be around: in fact, I suspect we'll see publishers start to include e-book copies of the text as a way to entice people to buy the very profitable hardcovers.
Lay-flat bindings can help.
Thanks for the anecdote. It illuminates why laissez-faire capitalism fails again and again: market capitalism works flawlessly in theory. This theory, however, rests on the assumption that all market participants are rational actors, and that these participants have access to all the information they need. This assumption does not hold in real life.
In real life, even relatively intelligent people only have 24 hours a day in which to make decisions, and nobody has the time to obtain all the information he needs to make rational decisions about everything. Most people will not have the skepticism or the presence of mind to question the service representative the way you did. Slick marketing exploits this weakness by pushing incorrect information that average people, pressed for time, will take as fact. Neither will most people use the courts to have contracts like this canceled, even if they become aware they were cheated: a lack of time again neuters the tools that capitalism in theory gives us to counter these abuses.
This is why we need explicit market regulation: to compensate for human inefficiency and weakness in the market. Cell phone contracts should be made illegal outright, the way they are in parts of Europe.
There's already a perfectly good legal mechanism to amortize high up-front costs over a product's lifetime: it's called a lease. If a company wants to restrict how a product is used, the company and the customer can sign a lease agreement. Xerox very successfully used that business model for its early photocopies.
The problem we're seeing today is that companies want to have their cake and eat it too. They want customers to feel like they're making a purchase, but act like they're under the terms of a lease. That's fucking bullshit, and runs counter to personal property rights at the core of Western civilization.
In short, if you want to tell me how to use your widget, you'd better lease it to me. No way in hell should you be telling me how to use property I've purchased outright without signing any kind of contract with you.
I love the sound a new hardcover makes when you open it for the first time; I love being able to take a book camping without worrying that it will be crushed. I love being able to physically browse through everything on my bookshelf and pick something that interests me. Oh, and I love being able to make margin notes and dog-ear pages. I love that I can feel a book's right side become smaller and smaller as I read, and how I can become excited (or nervous) about feeling the ending being near.
There's just something satisfying about a physical book that I can't replicate with an E-Book. Sure, I'd rather have an E-Book dictionary or cookbook, but you'll pry my narrative paper books from my dead hands.
Thank you for posting this: it gives me a chance to highlight the difference between our moral code and the law. Any law that attempts to curtail a popular public activity is not only futile, but also doomed to cause a lot of misery while it fails. The DMCA is one such wicked piece of legislation. That said, I don't think the DMCA applied here because nothing is actually circumvented. Amazon is simply using it as a legalistic bully club.
Unfortunately, some believe in the pernicious notion that things are wrong simply because they are illegal. There are few ideas more harmful to a free society.
IANAcryptographer, but public key cryptography is a no-brainer for this scenario. Amazon should have created an RSA keypair for each kindle sold. Amazon would keep the private key and put the public key on the Kindle. When selling an E-Book, Amazon would just encrypt the Mobi file with its private key. That way, it wouldn't matter if some third party obtained the RSA public key for a specific kindle --- all he could do with it pound sand, since Amazon would keep the private keys secure and internal.
Granted, I think the DRM is vile. But I can't understand why Amazon also implemented DRM so poorly.
(If you want to be able to let multiple people read the same Mobi file, do this: generate a random symmetric cypher key (K) and encrypt the E-Book with it, resulting in ciphertext B. For each Kindle you'd like to be able to read the E-Book, let its key be M1, M2, and so on. The file you send out contains K itself encrypted with M1, then K encrypted with M2, K encrypted with M3, etc., and then finally B. A kindle would try all the keys in the E-Book file and just use the first one that successfully decrypted B.)
kindlefix.py
If Amazon would like to try this approach, that's fine. But our personal right to do what we will with our property trumps Amazon's business model. If Amazon's business model won't work in a free society, it has no business working at all.
Oh, I'm sure the reason OP didn't come up with a better example is that he was being crushed by a fucking tank. Come on -- China is what the Bush regime aspired to be like.
Historically, it has worked that way, and for a good reason: it's sane behavior. That's my whole point. More precisely, the file's data blocks need to be committed before the rename operation itself is committed to disk. That's not saying that the syncing must occur before rename returns.
That's not the same at all. How many times do I have to explain the difference between an ordering constraint and an explicit sync?
rename(A,B) must flush A's data blocks before writing the record of the rename itself. The filesystem does not need to do this when you call rename! It could do it six minutes or six months in the future, as long as the data blocks for B are written before the rename record itself. This property preserves atomicity. Sometimes you want atomicity without durability, and this is how you get it.
Performance is vastly improved over the fsync-everything model because the filesystem can still batch updates. "Do A and B when you have a chance, but make sure to do A before B.=" is saying something fundamentally different from "do A now. Do B."
Blame, blame, blame the victim. This is 2009. There's no fucking reason for a modern filesystem to not cope well with hundreds of small files.
Under ext4 and XFS, you lose when doing an atomic rename.
Yes. It's not that the sequence as a whole should be treated specially: it's that rename should be sane enough to introduce ordering constraints on the source file's data blocks. Why? Because it's useful, application developers have fucking relied on it for years, and the alternative, fsyncing all the time, is a different request that's slow as hell.
It was never necessary in the first place.
There's a big difference between ensuring relative ordering and asking for a disk sync. Relative ordering corresponds to atomicity, a database property. Pure disk-syncing is durability, a different database property.
Under traditional Unix filesystem semantics, you have three options for a filesystem operation:
As it turns out, Windows without Transactional NTFS only gives you one option: durable, but not atomic. (Where you open the file in synchronous mode and just write to it.)
Windows does not support an atomic rename. If you have files A and B, in order to rename A to B, you need to delete B first. If the system crashes between the deletion of B and the renaming of A to B, you end up without a B at all!
Only you can tell whether you need durability, atomicity, or neither in your application.
For example, if you're writing a mail server, you need both: you need to tell the mail program on the other end that you received a message and stored it securely, so you need to know that the message hit the disk. Thus, you need a durable transaction. It won't do to have partial messages laying around, so you also need an atomic transaction*.
If you're writing something like KDE's configuration stuff, it really doesn't matter whether you end up with the old configuration file or the new one. In the worst case, the user loses a setting he just made. So you don't need durability. However, you can't have corrupt configuration files laying around: the desktop environment might not come up at all then. So you do need atomicity.
If you're writing a compiler, the user can just re-run the compilation if the machine crashes. Since the output can be regenerated at any time, you don't need durability. You'll never have multiple compile jobs writing to the same output at the same time anyway, so you don't need atomicity either. Therefore, a compiler can just open its output directly without fancy rename tricks.
If you're writing a log recorder, you want to make sure log messages hit the disk. But since your program controls all access to the log file, you don't need atomicity from the filesystem. You can just open the logfile and write, syncing to it after each entry. That way, you get logs up to the instant before the machine crashes. (This is precisely what syslog does by default.)
What atomic rename under Unixish systems gives you is the ability to have atomicity. Without atomic rename, we can only achieve atomicity by using a locking system that's not part of the filesystem itself, which is a whole other level of pain and complexity.
I don't know what you're writing in Python. But under Windows, all that fsync is giving you is durability. It can't give you atomicity. Are you sure you really need it?
* (Which you get for free with maildir, incidentally. But if you're delivering to an mbox file that contains multiple messages, you need to lock the mbox file to make the message delivery atomic. One popular method of locking is to use atomic renaming...)
Grr. Standard output is line buffered when connected to a terminal, not fully buffered. That was a silly typo.
Yes and no. Atomic rename has been part of Unixish systems for a very, very long time. Everyone has always used it to implement changes that need to be atomic, and for the most part, atomic rename has been all that's been needed for that purpose.
I'd also like to see a fbarrier system call that would preserve relative ordering of writes within a single file, but it's not a critical piece of missing functionality. In most of the situations I imagine you'd want to use fbarrier, you'd really rather be using a database engine anyway, and database engines implement the moral equivalent to fbarrier internally.
Vista's Transactional NTFS is also interesting, and I wish we had something like it in unixland. But on the other hand, it's not absolutely essential in the way atomic rename is.
Or to be more precise, POSIX lays out the bare fucking minimum for a half-sane system. It's a set of requirements, not a golden holy tome!
This is Slashdot, so here's a car analogy. POSIX is the law that says what's street-legal. A car needs two headlights, two tail-lights, emissions below a certain point, and so on. Both a base-model Chevy Aveo and a Ferrari are street legal, but I'd rather drive the Ferrari? Why? Because it makes guarantees that go beyond street legality.
Now say you drove Ferrari and the air conditioning malfunctioned. Image how angry you'd be if the Ferrari dealership said, "nope, sorry. We're not going to fix this. Your car is still street legal, so you should have just gotten used to driving without the air conditioning."
You know what I'd say? Fuck you.
You can guess what I'm saying about filesystems that break the perfectly reasonable open-write-close-rename sequence.
Right. Those who demand we use fsync for atomic rename are telling us to ask for a guarantee we don't need.
Here's a rule of thumb: if you're calling fsync because you need to ensure data has been preserved, you're using fsync correctly. If you're calling fsync to preserve integrity even when it's not critical to save your data, you're abusing fsync and the filesystem you're using is broken.
open-write-close-rename already asks for atomic but asynchronous rename under all sane systems. XFS and ext4 break that perfectly sane sequence of operations. These filesystems are doing the equivalent of replacing your bicycle's tires with cats, and then telling you to buy a Mack truck when you complain.