Please create an account to participate in the Slashdot moderation system


Forgot your password?

Comment Re:50m 200ft (Score 1) 511

Everybody likes to make car analogies. However, that doesn't work here. CARS have well established, documented legal procedures for having them removed. (I know them all too well.) An un-tagged, un-titled car.. I most certainly can destroy it. (in fact, the police/dmv won't touch it.)

Moving out and leaving your stuff also has mountains of legal backing. YOUR. PROPERTY. IS. ABANDONED. As such, it's no longer "your property". It can be disposed of, or publicly auctioned -- legally. (I can't keep it, but I can throw it away or put it on eBay!) As for entrusting your stuff to a friend, no contract exists; if it's damaged or lost it's entirely between you and your friend.

Comment Re:Really? (Score 1) 511

For an Olympic skeet champion, maybe. At 200ft, most quad-copters are very hard to see. They aren't brightly painted skeet targets moving in a predictable path. Of course, *one* bird-shot pellet is all it would take to bring it down. (those things aren't remotely "armored") Does anyone have pictures of the thing "riddled with holes"? (more holes === closer to the gun)

Comment Re:How soon until x86 is dropped? (Score 0) 152

Don't even try the "embedded market" BS. Debian is incredibly bad for anything "small". How big is a pure "base" install again? A fuckload more than 99% of embedded devices have.

The entire logic (read: Debian Political BS) behind what arch's are supported is (a) popularity, and (b) having a pool of active maintainers. SPARC has neither of those. The entire backstory is over a year long and boiled down to some nut screwing up the gcc packaging -- changed only for SPARC, that broke only SPARC. (I smell a rat.) Ultimately, it probably needed to go. Just like for the PC -- where amd64 took multiple eons for the fools to finally support -- many eons have passed without a migration to a full 64bit distro. The build system still, to this day (22 years on), builds everything as 32bit. Yes, there's a 64bit kernel, there are 64bit libraries, and gcc can output a working full sparcv9 64bit executable, yet, they still spit out a 32bit userland.

(One would hope this lights a fire under the sparc64 ports project.)

Comment Re:Enterprise Storage (Score 1) 219

Replication is not Archival. Corruption can be copied to a "backup" as well. If you aren't paying attention to what is being duplicated and to where, then "stupid is going to catch up to you eventually." For the record, I've seen the exact same mistake happen to people doing "backups" (RDX and tape) -- the error wasn't caught within a media cycle. (which was "weeks" for them)

Comment Re:Talk to Vendors (Score 1) 219

Obviously, you've never used LTO technology. They cannot repair tracking errors -- the bits written when the tape was low-level formated, something NO commercial drive can do! "Bit Rot" will destroy LTO tapes in a matter of months if they are not kept at a nearly constant temperature. Conversely, I have DLT, DAT (4mm and 8mm), QIC, Exabyte (8200?) etc. tapes that are still readable after decades. (one of those 8200 tapes sat in a kitchen drawer for 11 years!) Yet, I have a trash bin full of LTO-2 tapes that are 100% unusable after one cycle through Iron Mountain's archive. The SDLT-I's have lasted 8+ years of continuous use (~1wk in the library, then 2-3mo on a table in the DC @ a constant 68F); the LTO-2's (fuji and sony) begin to fail after ~2yr in the same environment.

(In fact, the SDLT DRIVES are failing more often than the media these days. The laser tracking servo fails. The drives are 10+ years old, the tapes 8+)

Comment Re:"Gigabit service" is FRAUD. (Score 1) 120

Numion? That looks like something from the 80's. Java: Check. FRAMES: Big fat CHECK.

And I'm sure various site admins love being selected by him as a traffic source. This alone makes his data completely unreliable -- who knows what state those selected sites are in at any given moment.

Comment Re:No it's a bug in OpenSSH (Score 1) 55

Actually, it's an issue with OpenSSH's blind acceptance of a user supplied device list. The PoC uses "PAM", but any valid device can be used. (hint: PAM isn't the only one.) There's an additional bug in that the code ignores ("overrides") KbdInteractiveAuthentication no -- if I put that in my config, it should be off, PERIOD, anything that requires it is disabled as well.

"In the face of entropy and nothingness, you kind of have to pretend it's not there if you want to keep writing good code." -- Karl Lehenbauer