My TV sometimes shows little ads in the top-left by itself, on top of the content. It's pretty rare, and it's mostly to get me to use the smart-tv features so they can show me more ads, but it already happens

LG TV.

No, atime is completely crazy. It has two uses I'm aware of (and I assume a few I don't)

• Mailbox-like "did this change since I last read it" (that requires monotomic timestamps instead of real ones to work correctly)
• Tiering/cleanup. "No one's read this in two years: I think it can be deleted/archived offline/etc"

And in return, every read becomes a write, and you lose all parallelism of read-primary workloads. Nope, atime's crazy. Relatime is a good hack, but better would be throwing that misfeature away.

Similarly I can go on about Posix locking, fcntl(..., F_[GS]ETLK(W)?, ...) vs. flock. fcntl has the lock owned by the file descriptor, so if you fork while you hold the lock, your child owns the lock... but support range locks. lockf has the lock owned by the process so you're not shocked by the ownership rules ... but doesn't support range locks. fcntl() locks calls "set the lock state" instead of taking a lock... so if you lock [0-10] and [5-15] and then unlock [5-10], you have [0-4] and [11-15] locked... don't lose your state. And so on...

rename? Rename we should keep. And hard links while we're at it.

The problem for adapting applications that assume posix semantics to object storage isn't mmap()... it's rename(). Unix systems use rename as a core atomic primitive, which is possible because of an implied "directory object". A nameserver or other system that implements an atomic rename would cover around 80% of the use cases... and many of the others could be forgotten about. (atime. Wat?. Posix advisory locking isn't really what anyone exactly wanted either. The lifecycle around that is ... a bit crazy and not what you think it is)

These are protests against the police, and we're asking the people being yelled at and shamed to mediate the protests... of course it's not in their interest to de-escalate the situation.

Most of the issues raised so far are exactly in line with your view... largely non-issues being hyped because you can get press now that you're targetting today's cool thing.

The "encryption keys came from servers in China" one ... is more serious.

(the "poor use of encryption" one is ... back to fear mongering. Everything that deals with connections that can drop will have to use block an EBC-like mode with similar issues. Otherwise a lossed frame loses much more.)

Lead researcher Dr Alex Wilkinson said: "The gases within these canisters are such powerful greenhouse gases that they can contribute significantly to an individual's carbon footprint and if you are using one or two of these inhalers every month, then that can really add up to hundreds of kilos of carbon dioxide equivalent over the course of a year, which is similar to other actions that people are keen to take to reduce their carbon footprint such as going vegetarian."

Emphasis added.

My inhaler has 200 doses when new, and I use around 10 doses a month? (2-3 a week, exercise induced asthma). To use an inhaler up inside a month suggests you're using it ~6-7 times per day, which seems completely insane. To use 1.5 inhalers up in a month would be 10 doses a day...

Anyone with that kind of asthema issue shouldn't be using standard Albuterol inhalers of the type being discussed, so either my experience is deeply non-typical, or the study authors have no relevant experience.... and I can't be sure which.

and thinks this is "Very Fair".

(and given payola pushes this down to "makes money per stream", likely has an argument)

Which may be why Zimmerman's defense didn't invoke SYG.

IMHO, there was not proof beyond a reasonable double that Zimmerman was on top. It's quite possible he was on the bottom, and was legitimately scared for his life. From what I know from the trial, I don't think I'd have convicted either.

On the other hand, from what I know from the trial, I also wouldn't have convicted TM if TM had managed to kill Zimmerman. It's a crappy situation for everyone.

You're assuming that the drive failures are independent. His point is that they might not be: the common cause may be write cycles.

Let's say that a drive under your write patterns will last 9 months. (Bad wear leveling algo, combined with very re-write heavy data structures?). You put 5 of them in a raid 5 enclosure, all brand new drives. 9 months later, they all fail within minutes of each other. Whoops, lost your data.

If they fail for different reasons, you're more likely to be safe. If they all fail from wearing out the ability to erase cells, you're more likely to be hosed, until you've swapped out enough to randomize the write count./p?

You posted this in reply to an O'Reilly promotion. You know, the one company who's ebook format is "unencrypted PDF". That one. The one company that CAN NOT take your book away. Where the book won't change unless you want it to. Where you can keep it on your own HD for as long as you can and no one will even know.

That company.

No, helping the country be better, and the citizen be better off is.
Aka: Leading the country.
Getting elected is a MEANS, it is not the end.

"Did you put the disk in the DVD drive?"

Excuse me for being a horrible pedant, but I would also get confused if you told me to put a disk into the DVD drive. That drive takes discs... the ones that are visibly circular and have no case.

Ahem. Back to your point, and sorry for making the point of the original article.

I had a small OCZ SSD of some variety in my foo-server (which mounted the NAS for all the important changing data). One day I realized that / had gone ready-only days earlier. Console showed a write failure to the journal (ext3).

Rebooted it, and it worked for ~1 day. Reformatted (managed system, I have no idea if there was data corruption. Didn't seem to be any, but I didn't look for any) and it worked for around 1 week. At that point I gave up and replaced it. It had lasted for just over a year when it failed.

The two Intel SSDs I've bought have not failed yet, nor has another OCZ brand SSD (Vertex3, fwiw).

I wrote an interface to OSS back in ... 98? Something like that. It was dead simple to use: configure device, write sound data. Done.

Handling underflow/overflow was also so easy (write ahead as much as the device will take. Use an IOCTL when you need to stop... because the buffer won't run out for several seconds) that it amazes me that buffer sizes apparently have to be configurable in current sound-using applications. Crazy.