Forgot your password?

Comment: Re:Can Iowa handle a circus that large? (Score 3, Insightful) 368

by Sique (#48469267) Attached to: Former HP CEO Carly Fiorina Considering US Presidential Run
I wonder what Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; means then. It is probably about Congress giving priviledges to some religions while reigning into the exercise of others and forcing religion down everyone's throat including that of atheists.

Comment: Re:Can Iowa handle a circus that large? (Score 1) 368

by Sique (#48469227) Attached to: Former HP CEO Carly Fiorina Considering US Presidential Run
The modern image of the angels is a missunderstanding of the greek word angelos, which actually means messenger. An angel surely is not a guardian. While sometimes the Bible mentiones God sending some of his guardians (the seraphim) to earth as messengers, they went there to deliver a message, not to protect someone or fight on your side or whatever. So whoever believes in angels as guardians, his belief is definitely not based on the Bible.

Comment: Re:Ok, so what's the new flavor of the moment? (Score 2) 233

by TheRaven64 (#48469161) Attached to: Is Ruby On Rails Losing Steam?
As with C before it, the fast languages are the ones where people have invested a lot of time and effort in the compilers. JavaScript is pretty horrible to compile, but there's no reason why languages like Java or Ruby would be slow, other than effort. The Ruby implementation is pretty slow, but it's also pretty simple. Go and C had the advantage of being able to get fairly good performance from a simple compiler, but if you compare a modern GCC or Clang to an early C compiler you'll see a massive performance improvement. A modern JavaScript implementation employs all of the techniques from Self and Smalltalk, as well as some new tricks (in particular, loading time is far more important for JavaScript in a web browser than any other language). If you look at the WebKit JavaScript implementation, it has four different implementations (a bytecode interpreter, a simple fast JIT, an optimising JIT and a more complex optimising JIT) and promotes code to the later ones as it appears on hot paths.

Comment: Re: Everyone hates Ruby (Score 2) 233

by TheRaven64 (#48469077) Attached to: Is Ruby On Rails Losing Steam?
Indeed. I always found it entertaining to see what was going on in Ruby-land: concepts from 20-30 years ago that other languages had explored (and often discarded having discovered major issues with them) being touted as new and shiny and one of the reasons why Ruby is great. Rails itself is something of an example of this: NeXT's WebObjects (of which there's been an open source reimplementation in the form of GNUstepWeb since the mid '90s) had a very similar model and was the first (or possibly second, depending on exactly how you count, but within a couple of months either way) ever web-app development framework. 20 years later, Rails is a new and exciting way of developing data-driven web applications that is completely different from anything that's come before!

Comment: Federal Sentencing Guidelines (Score 3, Interesting) 163

by davidwr (#48468873) Attached to: Hacker Threatened With 44 Felony Charges Escapes With Misdemeanor

If the charges stuck, the man was facing multiple lifetimes worth of imprisonment.

Bull****. Federal sentencing guidelines almost never ask for "fully stacked" sentences. Instead, you wind up with X months for the "top count" and a significant "discount" of additional time for each additional count that is either proven or conceded. For a single count, the maximum sentence is almost never handed out unless there are other factors in play. So let's say this guy did admit to all 44 charges and accept a guilty plea on all 44 counts, and that there were no other factors that counted for or against him under the sentencing guidelines. The guidelines would probably recommend that he get a few years for the first count, a year or two more for each of counts 2 and 3, and a month or two for each additional count, likely resulting in a sentence in the 10-15 year range.

Comment: Manual door and ignition locks? (Score 1) 97

by davidwr (#48468815) Attached to: Auto Industry Teams Up With Military To Stop Car Hacking

If you MUST have a remote-control door lock, make it something that requires very close physical proximity that is very hard to override.

For example, have a receiver that is on the car-facing side of the door handle using a very-near-field communications setup. You swipe your "key" under the handle and the door locks or unlocks.

Yes, it might be possible for a thief to make a small "reflector" and tape it to your car door near the handle, but that's one more step he'll have to go through and one more opportunity for him to be caught or leave his fingerprints behind. Plus, unlike today, the thief can't just sit in a parking lot all day collecting "sample transmissions" for later analysis/reverse-engineering.

Comment: Re:Shock-resistance? (Score 1) 411

by davidwr (#48466805) Attached to: How Intel and Micron May Finally Kill the Hard Disk Drive

Close. I forgot to say "without anything except the laptop and - when the battery is low - a power cord."

That same machine with one of the internal drives replaced by the SSD would be perfect, assuming of course that it fit within my budget and met my other needs (not to heavy, not too big, not too small, etc.).

[The following is for casual readers NOT you or other Slashdotters as you guys already know this]

Regarding portability: Not only must the computer be bootable over the USB (i.e. not someone else's computer with a locked-down BIOS) but the "core" device drivers required to use that computer must be pre-loaded on all the OSes. I've had brand-new computers not boot common Linux ISOs without special tweaks on the command line due to issues with video or other drivers. I've had brand-new computers refuse to boot Windows install/rescue/etc. disks/external-drives and/or boot them but not "see" the hard drive without either customizing the install disk, loading device drivers manually, or going into the BIOS and changing settings to decrease the hardware's performance. The biggest "gotchas" these days will probably be the USB 3 chipsets (the fix is to just find a USB 2 port and suffer the performance it) or the video driver (the fix is to use "safe"/"low resolution"/"low performance"/"generic" boot options if you can).

Comment: Re:Constant writes such as backups, security camer (Score 1) 411

by TheRaven64 (#48465433) Attached to: How Intel and Micron May Finally Kill the Hard Disk Drive

The consumer-grade SSD in my laptop can happily handle 2-300MB/s of sustained writes (and, simultaneously, 200MB/s of sustained reads). If you're doing linear writes, then you're the optimal workload for wear levelling. You'll be hard pressed to find a drive that isn't guaranteed for 5 years of writes at the maximum throughput the drive can handle.

Although, as other posters have pointed out, you'll get better sequential write speed and reliability from a RAID array of slower disks.

Comment: Re:What about long-term data integrity? (Score 1) 411

by TheRaven64 (#48465355) Attached to: How Intel and Micron May Finally Kill the Hard Disk Drive

Now what about storage durability? With 3 bits per cell, how long before the data fades?

I was under the impression that the controller would handle this. Cells are typically marked as dead once their thresholds are such that you can't guarantee that they'll hold their contents for a year (there was an interesting paper at EuroSys this year about extending the lifespan by using these cells for short-lived data and exposing that functionality to the OS). If a cell is getting close to the time when the data has been unmodified for long enough that its integrity is in danger, then the controller will use the same mechanism as wear levelling to read it and write it back (either in the same place or somewhere else). Most of the time, this will happen as part of normal wear levelling, as unmodified data are moved around to sit on cells that have been rewritten a few times and spread the wear onto some of the cells that were only written once.

Comment: Re:Shyeah, right. (Score 1) 264

by TheRaven64 (#48465303) Attached to: Is LTO Tape On Its Way Out?

Tape was never alive for consumers

Not true. In the '90s, you could buy a tape drive and one tape to back up your £120 hard drive for £100 for the drive and £20 for the tape. I remember quite a few companies including tape drives on their more expensive consumer machines for exactly this reason. The tapes have stayed about that price, but now the drive is £1000 - and that's a single drive, not a tape library. That doesn't just price it out of the market for consumers, it does for small businesses too. It won't be long before it's also too expensive for medium businesses. For very large companies like Google, it's also too expensive because the bandwidth to tape is too slow unless you buy so many drives that the cost is prohibitive.

Comment: Re:Shyeah, right. (Score 1) 264

by TheRaven64 (#48465283) Attached to: Is LTO Tape On Its Way Out?

Also, we use raw storage in the context of _individual_ incompressible backup sets, not backup data at scale, because very few places backup a high ratio of incompressible data overall.

I'm not convinced that's true. At home, my NAS uses compression, so the raw capacity of the tapes is likely the relevant one, unless the tape somehow manages to recompress lz4-compressed blocks and gain a benefit (not entirely impossible, as lz4 is optimised for speed, but pretty unlikely). At work, the NetApp filer that the tape backups run from also uses compresses and deduplicates online, so not much redundancy there either.

What's the cost of doubling your storage capacity with either technology, for a few iterations? It's buy more tapes vs. $2&%fhqwgads!!1

Not really, unless you're talking about longer backup cycles. With tape, the backup time can quite quickly become a bottleneck, so you end up needing a second jukebox.

Disks travel in packs.