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.

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)

Fine. You go write a DNS server and see how horribly bug your shit is. (hint: DNS is a *complicated* protocol)

What f'ing "tax purposes"??? You are SPENDING money, not making it. And it's not the bank's job to collect taxes on your transactions. (interest they pay you, sure.)

Then explain why people NOT running md/dmraid have reported corruption. (and why Samsung themselves confirmed issues with their internal firmware)

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

If you're still USING a sparc32 system, you should rethink your life choices. :-) sparc64 systems are readily available for dirt. (you can even find some with SBUS interfaces.)

HOWEVER, this move by debian results in the dropping of sparc64 as well. (which is a seriously boneheaded move.)

Sparc includes "sparc64", for which there is a shitton of hardware still out there. That people actively use. Removing "sparc32" I could understand, but all of SPARC?!? Yet mips, powerpc, and s390 are still there.

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)

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+)

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.

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.

YES. The contract states you do not disclose your salary information with ANYONE. HR knows, and will share that information with whomever requires it.

The response was to revoke the other cellphones

And that's exactly what should have happened. Obviously, those people don't need a company issued phone. As that was the justification for the additional employee getting one, I'd say they didn't need it either.

(I say that as the only one in my office with a company issued phone. However, my coworkers can call/text for whatever at any time. Also, I could expense a personal phone.)