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.)
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.
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.)
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
Hybrids don't have a range problem, and they also aren't the subject of the article... LOTS of people have hybrids today; you don't notice them as much because they look just like their non-hybrid models. Pure EVs aren't selling well because they cost (a lot) more (in some cases 2x), have crap range (100-200mi vs 500-700mi), and take forever to recharge (hrs vs. mins.)
For the record, I make numerous 200+mi trips per year: 223mi 3-4x, 209mi 2x, 536mi 1x. Last year included a trip to Sebring FL (752mi)
You've clearly never worked in any admin position. When someone is being fired, only those required to make the firing decision (management, HR, etc.) will be in-the-know. At the time of firing, only those necessary to effect the dismissal (i.e. IT, security, etc.) will be told about it; and they won't be told shit as to why.
The mods are a bunch of stupid children. If they aren't happy with the way things are being run, they can work within the system tty to change it, or they can quit. Paid or not has nothing to do with it; unprofessional childish bullshit is just that. Trashing the site is what a 5yo would do.
The key annoyance of "chrome" is chrome. Opera is nothing more than a different skin on the same steaming turd. (and their devs have all but said so. They aren't happy with chromium's extreme memory consumption, but there's only so far they can go to "fix it".)
Cellphones operate in licensed bands. Thus, jammers are illegal.
Drones (RC crap) operate in unlicensed bands and must accept any interference that may exist. Jamming them is not, technically, illegal. However, jamming them would not be in anyone's best interest -- or really worth the effort. (how many jammers would it take to cover a mountain?)
Arming the DC10 is, of course, the correct answer.:-)
There are lots of switches running linux. Of course, linux isn't the thing doing the switching.
The question to ask is can you get to the OS and/or ssh configuration to remove whatever the vendor may have installed? (i.e. remove whatever ssh backdoor keys they left there.) In most cases, the answer is "Hell. No."
Slashdot Mirror
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.
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.
Hybrids don't have a range problem, and they also aren't the subject of the article... LOTS of people have hybrids today; you don't notice them as much because they look just like their non-hybrid models. Pure EVs aren't selling well because they cost (a lot) more (in some cases 2x), have crap range (100-200mi vs 500-700mi), and take forever to recharge (hrs vs. mins.)
For the record, I make numerous 200+mi trips per year: 223mi 3-4x, 209mi 2x, 536mi 1x. Last year included a trip to Sebring FL (752mi)
That's ok, just make it all work like Facebook. That seems to be the standard progression of every app on every device on the market today.
You've clearly never worked in any admin position. When someone is being fired, only those required to make the firing decision (management, HR, etc.) will be in-the-know. At the time of firing, only those necessary to effect the dismissal (i.e. IT, security, etc.) will be told about it; and they won't be told shit as to why.
The mods are a bunch of stupid children. If they aren't happy with the way things are being run, they can work within the system tty to change it, or they can quit. Paid or not has nothing to do with it; unprofessional childish bullshit is just that. Trashing the site is what a 5yo would do.
Nope. If you have what's called a "legacy allocation", then your block is old enough to not be encumbered by any of ARIN's current rules.
The key annoyance of "chrome" is chrome. Opera is nothing more than a different skin on the same steaming turd. (and their devs have all but said so. They aren't happy with chromium's extreme memory consumption, but there's only so far they can go to "fix it".)
Cellphones operate in licensed bands. Thus, jammers are illegal.
Drones (RC crap) operate in unlicensed bands and must accept any interference that may exist. Jamming them is not, technically, illegal. However, jamming them would not be in anyone's best interest -- or really worth the effort. (how many jammers would it take to cover a mountain?)
Arming the DC10 is, of course, the correct answer. :-)
There are lots of switches running linux. Of course, linux isn't the thing doing the switching.
The question to ask is can you get to the OS and/or ssh configuration to remove whatever the vendor may have installed? (i.e. remove whatever ssh backdoor keys they left there.) In most cases, the answer is "Hell. No."