Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

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

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

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

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

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

Comment Re:In other news (Score 1) 428 428

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

Comment Re:Sort of.. (Score 2) 86 86

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

Comment Re:MITM or unencrypted (Score 1) 104 104

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

Sometimes, too long is too long. - Joe Crowe

Working...