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

And chlorine gas as well, which makes the mixture of H2 and O2 photosensitive. (i.e. it may explode just sitting on the kitchen table.)

Depends on the age of the switch. The ones in the hatchery my family used to run (~40 years ago) had LOTS of mercury in them.

Sealed inside glass tubes, it's perfectly safe for millions of years. A lot safer than the tiny amounts found in fluorescent lights.

You mean ANI? Unless you have a digital line (ISDN PRI or BRI), you don't get ANI.

VoIP systems tend to blindly forward whatever the caller provided.

We aren't talking about a rack full of dell/hp knock-off "servers". OCP hardware is rows of racks full of stripped down, barebones systems. If your "mission critical" app fails, it's because you or your data center are a bunch of fools. Resilience comes from redundancy. If you fail to provide the redundant hardware, or capacity to spin up your crapplication on other systems, then that's your damn fault. (just as much as choosing to build your own rack full of budget trash.)

OCP hardware is cheap, so you can afford a lot of it. But it's cheap, and thus, prone to higher failure rates. This equals, in enterprise definitions, an "unreliable infrastructure". In the end, it'll work out to roughly the same total cost, but with one all the money is spent up front to fill a room no one visits, vs. the other spending very little to fill the same room but has people in there regularly replacing failed components. (Banks prefer the former, Google, the latter.)

My guess is they don't handle them securely because they don't see them as that sensitive. They are, after all, numbers humans have to have to get the right containers. At some point, they will be in a format that can be stolen -- i.e. on the waybill handed to the driver. You're basically trying to secure a phone number -- randomly generated and rotating, but still something more than one person necessarily knows.

How securely do you handle your Fedex or UPS tracking numbers? (granted, you cannot show up at the warehouse, read off a number, and get any package. If you have the, you-weren't-home waybill, however, they'll hand over whatever it is. USPS is the same, btw -- never been asked for ID)My guess is they don't handle them securely because they don't see them as that sensitive. They are, after all, numbers humans have to have to get the right containers. At some point, they will be in a format that can be stolen -- i.e. on the waybill handed to the driver. You're basically trying to secure a phone number -- randomly generated and rotating, but still something more than one person

Last I checked, IT != Accountant.