Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Comment: Re:I call BS (Score 1) 184 184

You must be joking. We would be in deep trouble if flash memory held its information for only about a year.

Nope, not joking. It also depends on the process size. Nice big (i.e. low capacity in a large die size) SLC flash cells hold data for quite a long time. The higher-density they get (and the less electrons per bit used to store data) the worse it gets.

So a lot of device firmwares and BIOSes, which generally use nice big chunky flash cells, will last 10-20 years. High-capacity flash storage, not so much.

That's just the way it is. Flash is currently the least worst solid state storage solution we have, but it still sucks.

(Note that if your device is powered on occasionally the flash can error-check and rewrite itself, which at least partially "resets" the time for data loss. This is only an issue for devices that are constantly powered off or devices that will not rewrite themselves as required.)

Comment: Re:Archive? (Score 4, Informative) 219 219

From this article here it appears that shingled hard drives are not completely random-access for writes. They will probably need some sort of flash-like translation layer to support normal file systems. (Or Seagate has provided that layer internally like SSDs do, in which case as a first-generation device it is probably buggy and will lose your data...)
Data Storage

Apple Disables Trim Support On 3rd Party SSDs In OS X 327 327

MojoKid (1002251) writes One of the disadvantages to buying an Apple system is that it generally means less upgrade flexibility than a system from a traditional PC OEM. Over the last few years, Apple has introduced features and adopted standards that made using third-party hardware progressively more difficult. Now, with OS X 10.10 Yosemite, the company has taken another step down the path towards total vendor lock-in and effectively disabled support for third-party SSDs. We say "effectively" because while third-party SSDs will still work, they'll no longer perform the TRIM garbage collection command. Being able to perform TRIM and clean the SSD when it's sitting idle is vital to keeping the drive at maximum performance. Without it, an SSD's real world performance will steadily degrade over time. What Apple did with OS X 10.10 is introduce KEXT (Kernel EXTension) driver signing. KEXT signing means that at boot, the OS checks to ensure that all drivers are approved and enabled by Apple. It's conceptually similar to the device driver checks that Windows performs at boot. However, with OS X, if a third-party SSD is detected, the OS will detect that a non-approved SSD is in use, and Yosemite will refuse to load the appropriate TRIM-enabled driver.

Comment: Re:Linus is right (Score 2) 365 365

Ugh.

The bloody MUSB driver/OMAP hardware combination caused me to have to write this horrible thing:

local kmsg = io.open('/proc/kmsg', 'r')
for line in kmsg:lines() do
--...
--elseif line:match('USB IS HORKED %- HELP PLEASE!') then
----local reset_usb =
------io.open('/sys/devices/platform/<product>-kludges/reset_usb', 'w')
----reset_usb:write('1\n')
----reset_usb:close()
----log.log('Reset USB')
--end
end

...because some (rare) USB devices would occasionally cause the harware to basically completely lock up when plugged in. I could identify this and cry for help from within the driver, but the only way I found to successfully unkludge it was to completely remove and reinstall the kernel device, thereby completely reinitializing the device and driver.

Fortunately(?) it looks like this product is unlikely to actually ship...

Comment: Re:What a fscking disaster (Score 2) 361 361

Youtube uses EME for 1080p streams, no EME and you only get 720p or lower

Youtube uses Media Source Extensions for 1080p streams. That's completely different; it's a way to source data to a <video> element from Javascript. They use it to implement their dynamic HTTP streaming, where rather than just sucking down a file you suck down individual file segments allowing dynamic quality adjustments based on your available bandwidth. There's no DRM involved.

Comment: Re:Framing the debate (Score 3, Informative) 280 280

And Git's hashes are not for the sake of security. Linus made that abundantly clear when he refused to allow SHA-2 to be used, even after people were able to manufacture a Git collision using SHA-1.

Citation needed. I can't find a published example of any actual SHA-1 collision, much less one from a Git repo.

Comment: Re:Yawn, another fork (Score 3, Informative) 219 219

The MongoDB core is AGPL. Its drivers are all Apache license, as explained here, therefore not polluting your web application code and forcing it under the AGPL.

BerkeleyDB, on the other hand, is linked in directly, and would force anything using it to be under the AGPL.

Comment: Re:How much of the 'operating system' needs to sig (Score 2) 393 393

Something like a config option - 'Enable OS installation for one boot cycle.'

If the purpose of secureboot were just to secure the boot process, that's all it'd take.

That limitation isn't possible, because the UEFI/BIOS is not a hypervisor. Once something else is running in ring 0 there is no way to prevent it from doing whatever it wants. Implementing those kind of hardware locks would entail a much more serious change to many parts of the PC architecture.

The whole system of key signing is a rather obvious attempt to squeeze all the little players out of the game so the big boys can seize more power and profits.

Despite the above, this statement is probably quite accurate, though. It's certainly a convenient side-effect.

Comment: Re:In other news (Score 1) 710 710

What are you talking about?

Home video was traditionally 24 or fewer frames per second. (Unless by "traditionally" you mean the past few years when you could record digital video at more than 30 frames per second.)

The GP poster is correct. Super 8mm film is not "video" and hence is not "home video". NTSC VHS is absolutely 60 fields per second. The only way to get 24 FPS on VHS is with 3:2 pulldown, which no consumer cameras I know of ever did. Even getting close to a "real" simultaneously-sampled 30 frames per second instead of 60 interlaced fields would require a sample-and-hold, which again consumer VHS camcorders didn't have AFAIK.

Comment: Re:Adds bufferbloat and reduces VoIP sound quality (Score 2) 275 275

You should have updated to IPv6, where is no such checksum in TCP.

I think you're misinformed. IPv6 has no IP header checksum, unlike IPv4. However, the higher-level protocol checksums are still there; in fact, UDP over IPv6 is required to include a valid checksum, unlike in IPv4 where it can optionally be 0x0000.

Reality must take precedence over public relations, for Mother Nature cannot be fooled. -- R.P. Feynman

Working...