Follow Slashdot stories on Twitter


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


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

by Phs2501 (#48589455) Attached to: Seagate Bulks Up With New 8 Terabyte 'Archive' Hard Drive
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

Posted by timothy
from the paying-more-for-the-exit-row dept.
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

by Phs2501 (#48058965) Attached to: Object Oriented Linux Kernel With C++ Driver Support


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

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

...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

by Phs2501 (#47003111) Attached to: How Firefox Will Handle DRM In HTML

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

by Phs2501 (#45700861) Attached to: Theo De Raadt Says FreeBSD Is Just Catching Up On Security

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:How much of the 'operating system' needs to sig (Score 2) 393

by Phs2501 (#40412347) Attached to: Ubuntu Lays Plans For Getting Past UEFI SecureBoot

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

by Phs2501 (#40361773) Attached to: <em>The Hobbit's</em> Higher Frame Rate To Cost Theater Operators

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

by Phs2501 (#38817217) Attached to: Google's SPDY Could Be Incorporated Into Next-Gen HTTP

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.

"Text processing has made it possible to right-justify any idea, even one which cannot be justified on any other grounds." -- J. Finnegan, USC.