Slashdot Mirror


User: osu-neko

osu-neko's activity in the archive.

Stories
0
Comments
3,936
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 3,936

  1. Re:Deceased owners on Dark Wallet Will Make Bitcoin Accessible For All — Except the Feds · · Score: 1

    I think you're confused about what exactly pla was saying. As you say, any transaction is secure until someone else gets your password (actually, your private key), then whatever bitcoins you have are now theirs, they can spend what's in your wallet now. So in the future, as pla suggested, a strategy for recovering bitcoins from wallets of dead people will be to capitalize on the fact they haven't been keeping up to date on their encryption, being dead and all, and so you can now figure out their keys (pla's premise being that what was a secure public/private key pair today won't be a decade or two from now, and you'll just determine the private key from the public one). At which point, as you say, whatever bitcoins they had are now yours.

  2. Re:Deflationary spiral, oh my! on Dark Wallet Will Make Bitcoin Accessible For All — Except the Feds · · Score: 1

    (What you've been taught to believe is not logically consistent. Think it through.)

    One should practice what one preaches.

  3. Re:Food in prison is a commodity. It’s curre on Inmates Program Logistics App For Prison · · Score: 1

    With prisons being run by private companies, I can see an incentive to give the prisoners less to increase the profits.

    That's a valid concern, although it should be noted in this case that the prison in the story is one of the public ones. (Oklahoma does have some privately-run prisons, but this isn't one of them.)

  4. Re:For the record on Why Amazon Fights State Sales Tax, But Supports It Nationally · · Score: 1

    The supreme court has already ruled on this in 1992, and their ruling was quite clear. So either Congress gets off their butts and passes a law, or Amazon can just keep fighting it out in district courts for years.

    The Wikipedia article on the case you're referring to indicates there has been some congressional action on the matter, or attempted action at least. I wouldn't count on this congress actually managing to get real legislation done, though...

  5. Re:Very Important Point... on Skunk Works Reveals Proposed SR-71 Successor: the Hypersonic SR-72 · · Score: 1

    Who is the enemy that we need to justify this? I don't suppose it's Afghanistan? It's going to have to be a technologically impressive country a long way away to justify all that cost.

    Expect to see American foreign policy starting to make enemies of Japan, Germany or South Korea. Perhaps Switzerland...?

    Really? "China" didn't even occur to you? Or are you under the delusion that the third country to send men into space isn't "technologically impressive"? From a military technology and manufacturing perspective, it's far more impressive than any of the countries you named. And they even call themselves "Communists" (a bit of untrue propaganda that just happens to work well both for themselves domestically and those who want to demonize them abroad) -- if you were a western military looking for a scary enemy, you couldn't wish for a better one...

  6. Re:Double whammy on Skunk Works Reveals Proposed SR-71 Successor: the Hypersonic SR-72 · · Score: 1

    "Be quick, be quiet, and be on time." Clearly a man from a bygone era...

  7. Re:Already exists or cancelled? on Skunk Works Reveals Proposed SR-71 Successor: the Hypersonic SR-72 · · Score: 1

    You really think *this* government would actually tell us about the latest and greatest?

    They might as well. If they don't do it through official channels, it'll be on Wikileaks shortly anyway.

    I think I had a perfectly accurate plastic model of the F-117A, purchased from the model department of a toy store, a few years before it was officially acknowledged. At some point, you just have to live with the fact that some things can't really be kept secret, not matter how much you might want to.

  8. Re:Please on Skunk Works Reveals Proposed SR-71 Successor: the Hypersonic SR-72 · · Score: 2

    This country can't build a web site. How the fuck are we going to build an SR-72?

    It's a matter of priorities. We can't build a website, but we sure as heck can build a warplane. We have a lot more experience at that, too...

  9. Re:SR-71 needed replacing on Skunk Works Reveals Proposed SR-71 Successor: the Hypersonic SR-72 · · Score: 1

    How would they know which ones to destroy? Are you going to destroy every satellite that tracks over your country?

    Only enemy spy satellites, presumably. This is surprisingly easy information to figure out. Launching things into space isn't exactly subtle (everyone for hundreds of miles around knows every time anyone launches anything into space), orbital mechanics are well understood and easy to work out, and satellites, like aircraft, are kinda out in the open with nothing to hide behind, and quite easy to track, even by amateurs with backyard telescopes (and there are quite a few enthusiasts who do precisely that). Anyone with the capability of shooting down one of our satellites already has a complete and accurate list of them.

  10. Re:SR-71 needed replacing on Skunk Works Reveals Proposed SR-71 Successor: the Hypersonic SR-72 · · Score: 1

    Because if you need realtime intelligence you're not going to get it with satellites now that several countries have the capability of destroying them.

    Um, no. You don't get instant, real-time intelligence from satellites because they're in orbit, not because they can be shot down. You either have to wait until the next time the satellite will pass over the target in its current orbit, which could be days away, or you have to alter the inclination of the orbit so it'll pass over the target on its next orbit, which requires huge amounts of delta-V, more than most satellites have the fuel to do regularly.

  11. Re:Oil Sands on Autonomous Dump Trucks Are Coming To Canada's Oil Sands · · Score: 1

    I've never heard them referred to as such. Also, the United States is a legal entity, an abstraction. It cannot speak, much less "refer" to anything using one particular phrase. That's a rather absurd anthropomorphization. The United States never says anything, and its people say a lot of different things, often contradictory.

    In any case, aside from a few confused individuals, most people I know of understand that oil is a global market, so the question of where the oil is located has little to do with anyone's energy situation. Domestic oil is only more valuable in that extracting it and transporting it creates and supports local jobs. It has no impact on the price you pay for the finished product, that goes to whoever will pay the most for it, anywhere on Earth that can be reached by a tanker.

  12. Re:Missed a step concerning CO2 on How Earth's Biosignature Will Change As the Planet Dies · · Score: 1

    Yeah, the summary is crap. The original paper notes the oceans become more alkaline, contradicting your quoted text regarding them becoming acidic.

  13. Re:Watch them die off? on How Earth's Biosignature Will Change As the Planet Dies · · Score: 1

    Yeah, time travel is hell on verb tenses, and looking out across vast distances of space is like a kind of time travel, as you're looking back in time. But despite that you're looking into the past, you're doing the looking right now. You even though it happened then, you're watching it happen now. It's true that you're watching what happen*ed*, but you're actually watching it happen. You're watching it happen now, even though it's not happening now, because by looking back in time, you're watching then now.

  14. Re:Moore's Law = Statistical Novelty on The Mile Markers of Moore's Law Are Meaningless · · Score: 3, Insightful

    What you're describing is not to much a "prediction" as a "goal". Which is precisely how Moore's "Law" has been used by the industry. They design each new generation with the goal of doubling the transistor density by some means. The only prediction being made is that they'll meet their goal.

  15. Re:easily googleable name on How Your Compiler Can Compromise Application Security · · Score: 1

    "mit stack checker", and it's the first URL returned: css.csail.mit.edu/stack

    I really wonder about people that complain google is unusable and never gives them that for which they are searching. are they lazy? uncreative? semiliterate? Maybe a well constructed online test could discern the truth.

    Yeah, I never have any trouble getting Google to barf up what I'm looking for. Although, as an interesting experiment that came to mind after reading your post, I guessed maybe people aren't very good at being specific in their requests and, to test what would happen, I simply asked Google to "give me what I am searching for". Amusingly, it seems to have concluded that I don't give a F... xD

  16. Re:Well on How Your Compiler Can Compromise Application Security · · Score: 1

    I examine all the code I write with a disassembler (alongside unit testing it), regardless of how time consuming this is, quality goes first. I don't see why others can't do the same?

    Some of us write source code that will eventually be compiled by people other than us on machine architectures we don't even have access to, and using compilers that haven't even been written yet. Your solution requires a massive investment in hardware and a time machine...

  17. Re:and the GCC team wonders why Clang was invented on How Your Compiler Can Compromise Application Security · · Score: 1

    Some of the more complex graph based optimizations require tie-breaking. Generally this is done by using a random number generator (i.e. virtual coin toss) to decide the issue. Randomizing generally produces better results over the long run than arbitrarily picking always A or always B.

    ...and that is a classic example of a false dilemma. One is not forced into choosing always A or always B when eschewing a true RNG. Tie-breaking can be done in a deterministic manner such that the results are effectively "random" over the long run while ensuring two runs over identical source files produce identical object code (even if the same code embedded in a different source file would choose the other option).

  18. Re:The paper gives examples on How Your Compiler Can Compromise Application Security · · Score: 1

    ... It's a fluke that apparently works on Intel platforms, but probably won't on most others.

    Actually, returning a function value in a register is pretty common for C compilers across most platforms. The lucky bit here was that it's the same register that it actually did the arithmetic in, but even that isn't entirely luck -- having the most commonly used arithmetic register also be the one that is used for function return values saves a lot of code moving the result around before returning from a function. Pretty sure the same code would have worked fine on the Motorola 68000 based computer I first learned C programming on. Obviously you do NOT want to depend on that trick, but it wouldn't surprise me if it works on most general purpose computers and most compilers that don't barf on the fact that your non-void function has no return statement (compilers are so fussy these days).

  19. Re:Fix the C standard to not be so silly on How Your Compiler Can Compromise Application Security · · Score: 1

    When was the last time that you used a machine whose integer format was one's complement?

    How would I know? I'm sure there's over a hundred microprocessors in my home (desktop PCs being the tiny minority of computers in the world -- I suspect the most common type of computer is an alarm clock, but who knows, some kitchen appliance might outnumber them for all I know), and I haven't got a clue what kind of integer format 99% of them use. It wouldn't surprise me in the slightest if the majority of computers in the world today use BCD.

  20. Re:Inflammatory Subject on How Your Compiler Can Compromise Application Security · · Score: 1

    "A man's got to know his limitations..."

  21. Re:TFA does a poor job of defining what's happenin on How Your Compiler Can Compromise Application Security · · Score: 1

    Apparently lots of programmers start with "IN-"... although I still haven't decided if Myers-Briggs is insightful analysis or modern astrology. It would help if they could agree with each other (I've been variously told I'm INTP or INFP, depending on the test, or maybe what kind of mood I'm in, or perhaps somehow related to the phases of the Jovian moons)...

  22. Re:TFA does a poor job of defining what's happenin on How Your Compiler Can Compromise Application Security · · Score: 1

    This makes no sense. The dereference is undefined, and therefore sk may be undefined iff tun IS null but not tun.
    I.e. by the time execution reaches the if statement one of the two is true:
    tun != null && sk == {something valid} -or-
    tun == nul && sk == {undefined}
    sk being undefined is possible but that undefined-ness can't be used as a way to infer tun != null--the only thing that causes it is tun == null! It's illogical for the compiler to do what you say and remove the if check. The standard says sk can be undefined, therefore something being in an undefined state is possible, not that the compiler can presume that undefined is impossible to occur and put it's hands over its ears and go la-la-la.

    "sk being undefined"? You misunderstand what "undefined" means in this case. It's not a question of whether "sk" has a defined value or not, because if tun was null, it's not that the value of sk becomes undefined, rather, the behavior of that deference statement is undefined. "By the time execution reaches the if statement"? It may never reach it! Since the behavior of "struct sock *sk = tun->sk" is undefined in the case tun == null, it's perfectly acceptable for that statement to be treated as a "return" statement if tun is null. Or for it to be treated as a command to reformat your hard drive. Or to simply make demons fly out your nose. The if statement can be eliminated, since if the compiler wants to treat it as unreachable code in the event tun == null, it has every right in the world to do so.

  23. Re:TFA does a poor job of defining what's happenin on How Your Compiler Can Compromise Application Security · · Score: 1

    I find it very curious that you'd be prohibited from using the value of the pointer proper.

    Makes sense to me that doing so would have undefined results. Plenty of more sophisticated memory managers will monkey with the contents of pointers from time to time. Once you deallocate the block it pointed to, God only knows what's left in the pointer. Probably the same value for simple memory allocators. Probably...

  24. Re:Arthur C Clarke strikes again! on Is Europa Too Prickly To Land On? · · Score: 1

    What part of "don't you understand" don't you understand? ;)

  25. Re:stfu. on F-Secure's Hypponen: The Internet Is a 'US Colony' · · Score: 2

    To a mad tyrant.

    This was the common propaganda of the time, despite being a bit ridiculous when applied to a parliamentary democracy like Great Britain.