No, you will not have "permanent static [addresses]". Your IPv6 prefix will not be "yours"; it can (and very likely WILL) be just as dynamic as any IPv4 address today. (esp. since every US ISP I'm aware of is using DHCPv6-PD to hand out prefixes)
Right, tridge completely reverse engineered BK from the output of "HELP"; and Kevin Mitnik could launch nukes by whistling into a phone. He did a lot more than just send "help" to a bkd. He didn't do anyone any good; git is a pile of shit... it was designed in a rush to handle exactly *one* thing. People only flock to it because a) it's free, and b) "the kernel uses it". (which, for the record, are the same two reasons thousands of projects used bitkeeper.)
Tridge did a f***load more than just send "help" to a bkd. The most damning part was that he continued working on it after a) being told to stop, and b) agreeing to stop.
But yes, Larry was very tired of the community continually pissing on his hard work. Tridge was one who shit in the sandbox and got us all thrown out.
Like... WHAT WE'VE BEEN USING FOR DECADES! There are MANY reasons to hate systemd, and only 2(?) reasons to want to use it -- and even those aren't that compelling. Linux (and every other *NIX) has been booting, starting, and stopping applications for decades, but now we have to have a mini-OS to do this (and hundreds of other things that have been very sucessfully handled by numerous other applications for just as long -- like getty, inetd, syslog, portmap, etc.)
Obviously, you didn't learn much there yourself? 25MHz * ??? = 2.5GHz and that would be one core of a modern CPU. (the answer is 100 by the way.) [Security DVRs are some of the least powerful hardware around. We aren't talking about a current gen Tivo Romio -- which is still a bad choice for mining.]
Having driven a '94 honda civic with a power steering rack and no power steering pump for years, the only time you'd notice the lack of "power" is at rest and very low speeds (i.e. people-pushing-the-car speeds.) The manual rack feels almost exactly the same when in motion -- I only know it's different because I know the rack was changed.
The loss of power steering isn't what created a wreck. Driver panic is at least 90% of it. Further panic when the brakes lost boost, plus the unsafe speed and wet roads... and someone plows into her while the airbags aren't armed.
As it was provided by a human being, who is presumed to have the capacity for rational thought, that would be sufficient as "authorization". If they were not actually authorized to provide such "confidential" customer information, then they would be on the hook, not use you as the receiver of the information. Computers, on the other hand, do exactly as they are programmed; programmers do make mistakes. Those errors are not authorization.
If we return to the office building example, this would be equivalent to walking into a building, past a security desk (manned or not), through a set of doors with no locks or signs, down a corridor to a common printer and taking whatever unclaimed output is still there.
Hah. Only because David called him first and hung up.
(by today's screwy courts, we'd add identity theft/fraud to his charges for pretending to be Prof. Falken, i.e. not correcting WOPR/Joshua when it asked.)
Right. He was just sitting there looking at a gmail screen when an AT&T server just started filling his browser with ICC's and email addresses.
He had to *request* the address for each, individual, ICC, through an internal interface that is not publicized. An interface he found while digging through the activation process (looking at the network traffic), apparently. The CFAA has no requirements for a lock-and-key system to constitute unauthorized access; without authorization is just what it says on the tin... no "authorization" has been given. (the old "well, they didn't tell me I couldn't" argument.)
Fighter's have radar jamming and other "stealth" technology making them very hard to track. And if you really think someone cannot fly a plane into or out of US airspace without a dozen systems watching them, you are a paranoid freak. This sort of crap happens all the time -- smugglers and drug runners do it often enough. ('tho no one is doing it with a 777:-))
It's doable with S4, but it's going to be insanely expensive and increasingly harder to find the tapes. LTO 4, 5, or 6 would be a better choice.
*I* use S4 for the high volume systems, but I'm only doing a full dump once per quarter (if that.) The majority of that data never changes. But I need to be able to rebuild any of those systems if they fail. (which is a growing likelihood -- those drives are getting really old.)
(But for archiving stuff that doesn't change, blu-ray is a perfect choice. It's not like he'd be storing 20TB every month.)
Tape vs. hard drive is a wash for the first 20TB. (minus a controller, HD is a bit cheaper) HOWEVER, with tape, capacity scales very cheaply... the next 20TB costs less than a single HD.
DLT-S4, the last generation, holds 800G native. But it's deadend technology now... it hasn't been manufactured in years, and finding actually new tapes is next to impossible. (noone on ebay is selling "new" S4 tapes. I don't give a shit what they claim. The eMAM proves them liars -- any tape without a SN has been bulk erased, RUN away from those.) Also, when you do find "new" (as in never used) tapes, they're old and freakin' expensive.
That's what I was thinking. Legal "hard" copies of all that stuff would be far cheaper than any archival backup technology (tape, blu-ray, etc.)
It would take a lot of blu-ray's, but as the content is entirely static, it wouldn't be that much work to backup. (actually, "archive" is correct term.)
There's only one... ns1.booen.com and ns2.booen.com are the same IP. It's entirely possible comcast's server(s) couldn't get there, but that's a SERVFAIL not NXDOMAIN. And then there's the answer it spits out for www... six identical A's.
Who knows what's actually happening. My money is on comcast having a shit DNS system. (it's the simplest option.)
In this case, it's specific against SSL. But in general, this is another form of differential crypt-analysis. Any credible encryption system takes steps to prevent this. (simply put, a single bit change in either key or plaintext should not have an easily predictable effect on the ciphertext.) As far as I know, no one has tried this method on other crypto methods.
Size alone is a very weak means of mapping content. Almost every modern web application has some variability in the output size at any given URL. Plus it's likely there will be many URLs generating the same size output.
Slashdot Mirror
The model 4 and 4P had 5.25 drives. Everything from the model 3 on had 5.25 drives.
And the pegasus... they hadn't gotten around to loading Baltar's BS defense system update. But it was otherwise as modern as anything in the fleet.
Actually, it's more a matter of "security by not connecting it to the god damn internet"
(surprising how secure a thing can be when you have to actually touch it to use it.)
And how does this matter at all to the millions of residential users? You, know, the people who don't get static addresses.
No, you will not have "permanent static [addresses]". Your IPv6 prefix will not be "yours"; it can (and very likely WILL) be just as dynamic as any IPv4 address today. (esp. since every US ISP I'm aware of is using DHCPv6-PD to hand out prefixes)
It's not called ARP, but it does have the same mechanism... Neighbor Discovery. It's done via multicast, btw.
Right, tridge completely reverse engineered BK from the output of "HELP"; and Kevin Mitnik could launch nukes by whistling into a phone. He did a lot more than just send "help" to a bkd. He didn't do anyone any good; git is a pile of shit... it was designed in a rush to handle exactly *one* thing. People only flock to it because a) it's free, and b) "the kernel uses it". (which, for the record, are the same two reasons thousands of projects used bitkeeper.)
Tridge did a f***load more than just send "help" to a bkd. The most damning part was that he continued working on it after a) being told to stop, and b) agreeing to stop.
But yes, Larry was very tired of the community continually pissing on his hard work. Tridge was one who shit in the sandbox and got us all thrown out.
Like... WHAT WE'VE BEEN USING FOR DECADES! There are MANY reasons to hate systemd, and only 2(?) reasons to want to use it -- and even those aren't that compelling. Linux (and every other *NIX) has been booting, starting, and stopping applications for decades, but now we have to have a mini-OS to do this (and hundreds of other things that have been very sucessfully handled by numerous other applications for just as long -- like getty, inetd, syslog, portmap, etc.)
No, the bug is systemd thinking it's the whole damned universe. The kernel cmdline is the Kernel's Command Line, not f'ing systemd's.
That's one insignificant reason among thousands.
Obviously, you didn't learn much there yourself? 25MHz * ??? = 2.5GHz and that would be one core of a modern CPU. (the answer is 100 by the way.) [Security DVRs are some of the least powerful hardware around. We aren't talking about a current gen Tivo Romio -- which is still a bad choice for mining.]
Having driven a '94 honda civic with a power steering rack and no power steering pump for years, the only time you'd notice the lack of "power" is at rest and very low speeds (i.e. people-pushing-the-car speeds.) The manual rack feels almost exactly the same when in motion -- I only know it's different because I know the rack was changed.
The loss of power steering isn't what created a wreck. Driver panic is at least 90% of it. Further panic when the brakes lost boost, plus the unsafe speed and wet roads... and someone plows into her while the airbags aren't armed.
I have an account, for one.
As it was provided by a human being, who is presumed to have the capacity for rational thought, that would be sufficient as "authorization". If they were not actually authorized to provide such "confidential" customer information, then they would be on the hook, not use you as the receiver of the information. Computers, on the other hand, do exactly as they are programmed; programmers do make mistakes. Those errors are not authorization.
If we return to the office building example, this would be equivalent to walking into a building, past a security desk (manned or not), through a set of doors with no locks or signs, down a corridor to a common printer and taking whatever unclaimed output is still there.
Hah. Only because David called him first and hung up.
(by today's screwy courts, we'd add identity theft/fraud to his charges for pretending to be Prof. Falken, i.e. not correcting WOPR/Joshua when it asked.)
[I know, I'm ruining the movie.]
Right. He was just sitting there looking at a gmail screen when an AT&T server just started filling his browser with ICC's and email addresses.
He had to *request* the address for each, individual, ICC, through an internal interface that is not publicized. An interface he found while digging through the activation process (looking at the network traffic), apparently. The CFAA has no requirements for a lock-and-key system to constitute unauthorized access; without authorization is just what it says on the tin... no "authorization" has been given. (the old "well, they didn't tell me I couldn't" argument.)
Fighter's have radar jamming and other "stealth" technology making them very hard to track. And if you really think someone cannot fly a plane into or out of US airspace without a dozen systems watching them, you are a paranoid freak. This sort of crap happens all the time -- smugglers and drug runners do it often enough. ('tho no one is doing it with a 777 :-))
It's doable with S4, but it's going to be insanely expensive and increasingly harder to find the tapes. LTO 4, 5, or 6 would be a better choice.
*I* use S4 for the high volume systems, but I'm only doing a full dump once per quarter (if that.) The majority of that data never changes. But I need to be able to rebuild any of those systems if they fail. (which is a growing likelihood -- those drives are getting really old.)
(But for archiving stuff that doesn't change, blu-ray is a perfect choice. It's not like he'd be storing 20TB every month.)
Tape vs. hard drive is a wash for the first 20TB. (minus a controller, HD is a bit cheaper) HOWEVER, with tape, capacity scales very cheaply... the next 20TB costs less than a single HD.
DLT-S4, the last generation, holds 800G native. But it's deadend technology now... it hasn't been manufactured in years, and finding actually new tapes is next to impossible. (noone on ebay is selling "new" S4 tapes. I don't give a shit what they claim. The eMAM proves them liars -- any tape without a SN has been bulk erased, RUN away from those.) Also, when you do find "new" (as in never used) tapes, they're old and freakin' expensive.
That's what I was thinking. Legal "hard" copies of all that stuff would be far cheaper than any archival backup technology (tape, blu-ray, etc.)
It would take a lot of blu-ray's, but as the content is entirely static, it wouldn't be that much work to backup. (actually, "archive" is correct term.)
There's only one... ns1.booen.com and ns2.booen.com are the same IP. It's entirely possible comcast's server(s) couldn't get there, but that's a SERVFAIL not NXDOMAIN. And then there's the answer it spits out for www... six identical A's.
Who knows what's actually happening. My money is on comcast having a shit DNS system. (it's the simplest option.)
In this case, it's specific against SSL. But in general, this is another form of differential crypt-analysis. Any credible encryption system takes steps to prevent this. (simply put, a single bit change in either key or plaintext should not have an easily predictable effect on the ciphertext.) As far as I know, no one has tried this method on other crypto methods.
Size alone is a very weak means of mapping content. Almost every modern web application has some variability in the output size at any given URL. Plus it's likely there will be many URLs generating the same size output.
Personally, I was gonna blame the Big Bang. If you're going to make an absurd connection, take. it. all. the. way.