No, I managed to take your bitcoin off you by using a quantum computer to predict your crypto
That's not the vulnerability.
There are two relevant cryptographic algorithms in Bitcoin: SHA256 and ECDSA. If quantum computers (or anything else) killed SHA256, there are three possible outcomes, depending on how broken it gets. First, they could dramatically increase the rate at which people can mine, which would have a similar impact to upgrading from CPU mining to GPU mining -- that is, the people with quantum computers can mine much faster, so everyone upgrades to quantum computers, so the difficulty rate gets adjusted and everything's back to normal. Second, it could tip things so dramatically that one entity controls a majority of the computing power, which (I think) leads to that entity being able to forge any transaction they like, and the network being forced to accept it. Third, it could improve things so much that even at the max difficulty level, people get coins faster than they should.
I'm very much not worried about SHA256, because as vlm points out, if 51% of the network agrees that it's sufficiently broken to have compromised the past 24 hours worth of transactions (say), you could roll it back for those 24 hours -- in fact, you could even limit it to anything resulting from a mining operation those 24 hours, since that would likely be the first thing compromised (if they didn't crack ECDSA, they can't forge a transaction from my account). This would suck in all kinds of ways for anyone who happened to be trading that day, but it would work. I do hope people keep an eye on it, though -- a gradual rollout of a new hashing algorithm is very possible, assuming we do it before SHA256 breaks, so I would hope people start doing that as soon as we see a better algorithm.
It would be a pretty shitty situation, though. Unless it was caught when gradual rollout is an option, it's going to suck for everyone involved, including Bitcoin itself -- I can't imagine anyone would trust it if this happened at this point.
Your comment is much more about the other algorithm:
I managed to take your bitcoin off you by using a quantum computer to predict your crypto, and I refuse to roll back my bitcoins to you.
So, I assume ECDSA is just a supposedly-more-secure version of RSA, and it's used to authorized transactions from a given account. If you used a quantum computer to guess my private key, we have a problem, because now you can empty my account into yours without the network really noticing. I'm the only one who notices my bitcoins are gone. And of course, you refuse to roll them back, unless I manage to guess your private key and steal them back the same way you stole them.
The problem is, unlike SHA256, there is no scenario where even a catastrophic "let's forget the last 24 hours worth of transactions" move would work here. Even if no one robs you yet, your funds remain vulnerable until there's not only a better public-key algorithm, but until you've transferred your funds to brand-new accounts generated with said algorithm. And while both are available, there's a window of time during which anyone with a quantum computer could rob anyone who hasn't already converted, depositing the funds into new, actually-secure accounts. The worst part is if someone robs you, there's no reasonable way you can prove that you were robbed, and that it wasn't just you transferring your funds to a more secure account as you should have done in the first place, since the "make my wallet secure again" operation and the "rob this person blind" operation look identical to the network.
The Internet isn't terribly centralized as it is, other than the organization responsible for assigning IP addresses and domain names. BitTorrent and Bitcoin are both distributed protocols which run on top of that.
In fact, it looks as though Bitcoin is even less centralized than BitTorrent -- while both currently use some sort of central tracker to grab a list of peers, it seems as though Bitcoin could operate just as efficiently no matter how it gets its peers. More peers might be better for anonymity, but it also seems like Bitcoin could operate efficiently with a single peer, while BitTorrent wants to connect to many in order to saturate the connection.
If the "internet in a box" connects to the standard Internet, it's a central choke point. If it doesn't, it's a much smaller network on which it's much harder to hide. Connecting to a single network doesn't imply a single, centralized point of control.
Are there plans to deal with quantum computing, or with any of the algorithms used being compromised?
I understand that the hashes wouldn't be terribly devastating for Bitcoin -- worst case, I would think, you roll the entire network back to a snapshot of the transaction history before the first quantum computer started screwing stuff up, and start using a new hashing algorithm. It'd be very bad, but not catastrophic.
But for actual accounts, it looks like we rely on ECDSA -- and it looks like even if Bitcoin offers a quantum-ready algorithm, my wallet is still likely compromised unless I move everything to it before the first viable quantum computer. Still, there doesn't seem to be much noise about this other than a few forum posts, largely dismissed by saying things like "DWave is vaporware."
Do you know that it's a bug in Chrome and not in the website?
Why should I care?... If it renders correctly on IE and Firefox, why should the website rewrite its code to conform to the new kid on the block?
It shouldn't. It should rewrite its code to conform to the very old w3c standards, and then consider browser-specific hacks when something's broken. "Works best on Firefox" is no better than "Works best on IE", and every time a site does that, it's holding back development of the Web and web browsers.
That's why I asked, and that's why you should care. If the bug is in Chrome, then you and this website can safely ignore it, though the Chromium developers would probably appreciate a bug report. If the bug is in the website, particularly if it also relies on bugs in Firefox and IE, then it should be fixed, otherwise the site is likely to break anyway with some future version of Firefox or IE.
In fact I can't remember the last time I had layout problems with firefox.
I can barely remember the last time I had a layout problem with Chrome. I mean...
It doesn't offer me anything that firefox can't already do.
That's a valid reason. Giving up on it because one website would require you to run Firefox seems like a much less valid reason, if you actually saw an advantage to it.
On my system, Chrome boots much faster than Firefox, the multiple processes and JavaScript engine were significantly faster at the time (and does Firefox have out-of-process tabs yet?), the dev tools are as good as or better than Firebug for 90% of what I need as a web developer, and it has all the addons I need and it's easy to write what it doesn't have. It originally won me over when (before Jetpack for Firefox) I realize that I already knew how to write extensions for it, since the Chrome extension API is just a few Chrome-specific JavaScript APIs plus HTML5 -- I went from not knowing how to write an extension for any browser to having written my own functional adblocker in an afternoon.
I'm not trying to convince you to use Chrome, just pointing out -- those would be reasons to use it, and I can see similar reasons to use Firefox, including basic stuff like "print preview" (I honestly hadn't noticed, I don't really print much.) That a website is broken in one or the other is, to me, a reason to have multiple browsers available. I guess it comes down to, if you were on Windows, and forced to use a "Works best in IE6" website, would you run IE as your default browser, or would you run IETab?
But the simple answer to this point is that fiat currencies work, and currencies with limited (and implicitly declining supplies) haven't.
For some value of "work".
I'll admit my ignorance here, but it seems like one inherent advantage of a system like this is that there is no central authority. No one party can simply decide the government needs an additional billion bitcoins and produce them out of thin air -- they'd have to mine or trade, just like anyone else.
There is a lower bound to the number of BTC you can transact.
Not really. While the default client will insert transaction fees for transactions below a certain value, these are optional -- their only purpose is to serve as an incentive for a miner to include your transaction in a block, and not all miners will enforce that. So it may be more difficult to get your transaction confirmed, but it can go quite a ways down -- the more likely problem is with floating-point rounding, since (unfortunately) Bitcoin uses floating-point math, but the actual Bitcoin fractions are decimal.
I said this in another comment but I'll say it here too: BTC should have an expiration date, and be rolled back into the market when they're not used.
They really shouldn't. Can you imagine a more damaging thing for a currency than, "Oh by the way, if you don't spend this, we're going to take your money from you and distribute it to other people!" Forget about putting any sort of savings in Bitcoin, then. I mean, that's a bad idea at the moment because of how new and volatile it is, but why would you add a built-in disincentive to such a thing?
Alternatively the limits on coin creation should be adjusted.
The fact that it's fixed is another part of its credibility -- artificial scarcity. If the limits can just be adjusted, then it's no different than a fiat currency.
It took only a few seconds on Google to find a source -- well, sort of. I definitely remember reading about it in a book somewhere, likely a legitimate expanded universe book.
It still likely wouldn't look like in the movies, but it'd look closer than what you suggest:
Due to the weightlessness of plasma and the strong gyroscopic effect generated by it, lightsabers required a great deal of strength and dexterity to wield, and it was extremely difficult -- and dangerous -- for the untrained to attempt using...
Lightsaber combat was the preferred fighting method used by lightsaber wielders, many of the forms and styles being designed to compensate for the gyroscopic effect inherent in lightsabers, and take advantage of the Force-sensitivity common in most wielders.
I don't remember where I've heard this before, but I've definitely heard it. But there are some very large problems you haven't solved.
First, this is still going to require a large amount of energy. Where does that come from? And if you've got something superheated into a plasma, how do you keep the metal from melting?
Second, as others have pointed out, you haven't actually solved the magnetic-field problem. Basically, any Jedi could have his lightsaber entirely disabled, or even turned back on him, by inducing a magnetic field on the room he's in.
Third, it doesn't explain the part where lightsabers are incredibly difficult to wield, due to weird gyroscopic effects, such that only someone with force-sensitive reflexes should be able to wield them properly. Ok, Han Solo can cut open a tauntaun, but that's a pretty crude motion -- try to swing it around, and if you're not careful, you could end up cutting yourself as easily as your opponent.
Fourth (!), what are blaster bolts, and how does a lightsaber deflect them? It makes very little sense to suppose that a blaster bolt is just some plasma wrapped around a tube in the same way -- that seems awfully complicated compared to alternatives like just firing the plasma as a projectile -- and then, why would they bounce off force fields the way they do, as if they were somehow slowly-moving laser light?
Finally, how do you explain the phenomena in Episode 1... Alright, maybe you want to pretend that didn't exist, but this phenomena is fairly commonly observed and generally accepted as something that it'd be reasonable for a lightsaber to do. Anyway, what about the point where Qui-Gon and Obi-Wan are trying to break into a room by slowly melting the blast door with their lightsabers? I suppose the metal rod could be collapsing, but then I'd expect that when you pull it out, it'll have to slowly extend again -- and it also suggests that lightsabers would collapse entirely too easily. If they're made of light, this makes much more sense, but then we have all the same problems as light.
So, cool idea, but let's just accept that Star Wars is science fantasy. It's enjoyable science fantasy, and there's no shame in wanting to be a jedi, but you'll never have a lightsaber. (Also, there's no Santa. Sorry.)
When I decided to go back to school, I started with a community college. Their wireless network was pretty much open, but for some perverse reason, it worked with the Windows DHCP client, and with udhcpc, but not with dhcpcd (used to be the default on Gentoo) or dhclient (default on Ubuntu/Debian). It seems fairly likely that this was a bug in their server software, and while I wasn't ridiculed, I never did get any help from the university -- I had to figure this out on my own. As much of a Linux geek as I am, I'm really not sure where I got the idea to just try other DHCP clients.
The university didn't really seem to care that I solved it, or how I solved it, and I don't think they ever put it into a FAQ or anything. The networking club did appreciate it, since a few of them were at least playing with Linux. I never tried it with a Mac, and never saw a single Mac while I was there, so I have no idea if that would work.
But it was because of this, and because the next two courses in their "computer programmer" degree (after Mainframe Assembly) were COBOL and Visual Basic, that I got out as soon as I could. After one term, I left for a real university. (Incidentally, one more factor validating my choice is the fact that the community college kicked me off their cyber defense competition team as soon as they realized I wouldn't be there next term, because "that's how it works in the real world" -- the guy running it is of the opinion that as soon as there's a hint you might leave, you get escorted out the door by security.)
So, that brings me to today. The university I'm at now does provide some amount of support for Linux, to the point where some of their FAQ pages include stuff about Linux, and if I ask a question, it's very possible I'll get an actual answer. The wireless uses MAC filtering, but there's no actual requirement that I use any particular software -- and, bonus, if I make sure to uncheck the "use NAT" box when registering my system, I get a real, Internet-routable IP address and dynamic DNS (with a little firewalling; obviously outbound SMTP and inbound Samba are blocked). I could, theoretically, run a webserver on my laptop that'd be accessible from http://serenity-xps.student.iastate.edu/.
The facilities provided are a genuinely heterogeneous mix of Windows, Mac, and Linux everywhere -- that's labs, remote access machines, etc, and they do point out things like rdesktop for the Windows machine. I've avoided getting a copy of MS Office by using rdesktop to connect to the comp sci Windows terminal server (which has a recent MS Office installed) whenever Open/LibreOffice won't work, I've had no issues printing with lpr on the commandline on the Linux remote machine (though sometimes it's easier to convert to a PDF and print from that Windows terminal server).
Individual courses are hit-and-miss, but mostly hit. I've had English classes which met in Mac-powered computer labs (one started on Windows and then switched to checking out Macbooks), an entirely-Java/Eclipse programming course which was just transparently cross-platform, and a programming course which required people to use gcc and graded you based on whether your code ran on a particular Linux machine you had ssh access to, and a Digital Logic course which was just switching to Linux machines in its labs. That last one was a little bumpy -- all the lab instructions were in.docx and not all opened in OpenOffice -- so I got the professor to give us PDFs, so hell yes, Linux was both required and supported.
The most common per-course issue is people still sending doc and docx around (though most accept odf and all accept pdf for anything I write). There was a course which required people to produce a PowerPoint presentation with an audio recording of our narraiton included, which is a PITA even if you have Windows and PowerPoint -- here, I did something ridiculous and built an HTML5 presentation inst
Definitely doesn't do that on Chrome, and I'm surprised it does on Firefox. When I close a tab, or a window, it makes sense to let the page know and give it a small window to react, but it should be killed before I really notice.
Sorry, no. Inflicting a new UI on people as the default and then having it broken very nearly continuously is very much a developer bug.
I like the new system, and I prefer it to the old system, except for the part where it doesn't fucking work. Seriously, Slashdot, this should be more embarrassing to you than the part where you still can't handle Unicode.
Is 24% enough for us to get a UI fix, Slashdot?
on
Google Releases Chrome 12
·
· Score: 3, Interesting
It's getting a bit old that any click within a comment, including within the textarea while I'm trying to reply, gets interpreted as clicking on the "Parent" link, thus requiring me to open the entire thread all the way to the root.
Re:Guys: I need to know diff. between Chromium
on
Google Releases Chrome 12
·
· Score: 3, Informative
I have "heard tell" (no, I can't produce you a quote) that CHROMIUM doesn't store things "up in the GOOGLE CLOUD" like passwords - whereas by way of comparison, Google CHROME, does.
Not quite. I know that Chrome has the option to set up "sync", which allows you to synchronize everything (passwords, bookmarks, etc) between Chrome installations. However, I have that disabled, and unless you can produce a quote or a link to the contrary, it seems much more likely that Chrome simply stores my passwords locally. It even integrates with local secure password stores -- in my case, since I run KDE4, Chrome stores my passwords in KWallet.
NaCl major flaw is its platform dependence. Sure, it covers the most popular platforms today, but it's not future-proof.
I suppose it technically is in the sense that there's always emulation...
Now they also have PNaCl, where the browser downloads LLVM intermediate language (binary-serialized), compiles that to native, and then runs it in a NaCl sandbox. That is precisely the kind of thing needed - a low-level but nonetheless portable target platform that permits efficient implementation of various things.
What I would wonder here is how efficient it is. How much are you giving up by not using pure native code? It looks like PNaCl is included with NaCl, otherwise it's pointless -- if I have to include an LLVM interpreter anyway, and I'm using low-level languages like C anyway, I may as well compile to native.
But if it is included, having this as an option makes sense in another way: Multiple fallbacks. If NaCl is available, but I don't have a binary for the user's platform, I can try PNaCl. If that doesn't work, I can fall back to a JavaScript implementation.
That's why I was talking about a kick in the balls, not a boot to the head.
But for the sake of argument, a boot to the head, depending how solid it is... It might kill me, but I also might be fine in a few minutes. A bad breakup is almost by definition going to hurt for awhile. It won't kill me (short of suicide), but there's also no chance that I'll be fine in ten minutes, or one day, or a week...
If we're allowed to cheat, I'll take the boot to the head because I can probably avoid that a lot more easily than I can avoid a bad breakup. Boot to the head is easy -- step out of the way, or intercept boot. Then twist it and bring them down, twist again until they promise not to try to boot you in the head again.
Breakups? There isn't a good way to avoid that. You could try not to fall in love in the first place, but that's not really up to you. You could try to never break up, but that's not really up to you, either, because now there are two people involved.
I don't know why I'm doing this, though. The correct answer to "Would you rather have your heart broken or take a boot to the head?" is "No."
So, first, if it's Gmail and stuff ends up in Spam, I can still go read it -- I don't get enough spam that I can't at least glance through it to see if anything was classified incorrectly.
Second, I'd do this specifically for those services which can't be resolved in some five minutes of my time. For instance, if it includes a link for me to click on if I'm not the intended recipient, I'll do that, and consider it not to be spam. If it's just a confirmation email and there's no obvious way to deal with it, delete it and ignore it, but not spam. If there's no way to stop receiving them (and hopefully make someone else's life easier) without picking up a phone, it's spam.
Of course, look at my email address -- I don't have this problem at all. I have far more actual spam, because I display my email address unfiltered on Slashdot.
The results you got suggest a large number of people who are truly clueless about email and the Internet. Might I suggest that in your initial "This isn't the website you're looking for" email, you provide a small note to the effect of "I reserve the right to post future correspondence from you publicly."
They managed to fuck up the syntax. They managed to fuck up the semantics.
In a few important ways, sure -- things which are fixable, and things which pale in comparison to other mainstream languages. I'd much prefer JavaScript to C++.
They managed to fuck up prototype-based OO.
In what way? It seems to work well in modern browsers.
They managed to fuck up the equality and inequality operators.
No worse than Perl, and from what I can tell, CoffeeScript deals with that problem.
The fact that you need to hide it as much as possible, whether using something like jQuery or CoffeeScript...
Sorry, what?
jQuery isn't even in the same category. It doesn't change the syntax. It doesn't "hide" anything. It provides a useful library abstracting over the DOM, which is not part of the core JavaScript language, and which has similar problems and solutions in other languages -- the obvious example is Hpricot in Ruby (though the cool kids seem to be using Nokogiri these days), and Ruby has none of the issues you just mentioned with JavaScript.
CoffeeScript deals with the syntax, and makes it easy to generate the good parts of JavaScript -- by, for example, replacing '==' with '===', which does what you'd expect '==' to do. I really can't see anything wrong with this. It's exactly like having a preprocessor for C which makes it hard for you to accidentally do unsafe pointer arithmetic.
JavaScript has no redeeming value. There's nothing good about it.
Bullshit. Here's a list of advantages it has over Java, as a language:
Actual closures.
Functions as first-class variables.
Much easier metaprogramming. (It has 'eval' if all else fails.)
REPL/commandline, so I can try code out a line at a time.
Trivial to implement your own OO inheritance semantics -- just put functions in a hash.
Native syntax for hashes (maps), and much better array syntax.
Setters and getters that look semantically identical to properties.
I'd prefer strongly typed, but I can still pretend it's strongly, dynamically typed. Java forces its anal static type system on me.
Equality is a === b. Sucks, but at least it's not (a != null && a.equals(b) for objects, and a == b for primitives. WTF, Java?
Embeddable. Ok, Java is too, but the JVM is pretty heavyweight to provide scripting for a non-JVM app.
I could go on. Some of that is opinion, I suppose, but a lot of them are big gaping holes in Java, and really nice features that I wish other languages had. And if JavaScript is still the "biggest mistake ever made in the field of computing," what does that make Java?
I mean, just look at Firefox. Who the fuck thinks it's a "good idea" to write huge portions of a desktop app using JavaScript and XML?
A desktop app that spends its entire day showing you web apps, so that's not going to be as much of a performance difference as you suggest. It also makes it a lot easier for web developers to hack on their own browser, which is very useful. Chrome is written mostly in C++, but extensions are still JavaScript+HTML, so you can go from web developer to extension developer in an afternoon.
Oh, and writing in a higher-level language -- I don't know that I like the XML idea, but JavaScript makes sense here. It's that much less of the browser that can possibly have a buffer overflow.
it's supposedly a "lightweight" browser.
I agree with you here. It started out as the "lightweight" alternative. But hey, the fact that it actually pulled that off for a year or two suggests that it's not the JavaScript or the XML that made it bloated. No, it's the feature bloat.
You suggest the W3C standardise on "Basic from the '80s" and don't see the irony in your using a smalltalk inspired language to generate CSS?
Web standards have moved on since then. So has Ruby.
Web standards are inspired by stuff like SGML, which is older than dirt. That's entirely beside the point. The point is that the W3C is standardizing stuff that we've been using for years, almost a decade. This is more like if C only became an official standard today.
However, unless you're going to have your own version of HTML and CSS compile to real HTML and CSS, you lose a lot of the benefits of a web app in the first place. As it is, I don't see the problem with using tools like Haml and Sass. I've generally preferred actual JavaScript to preprocessors, but CoffeeScript looks awesome, I don't think I ever took a good look at it before.
The biggest annoyances of the current Web are all things we can deal with.
JavaScript is almost exactly the sort of language I'd want to work with, and CoffeeScript addresses my biggest annoyance -- the syntax is ugly. Other than that, Chrome's V8 has better boot time and execution speed than other languages I'd want to work with, and I don't need to force the users to download an entire interpreter, all of which makes my pages load faster than if I forced some nativeclient interpreter on them, though it's nice to have that option.
Haml addresses my biggest complaint about HTML, which is also mostly skin-deep -- I really don't like the XML syntax. The fact that I can mix in Ruby to generate more HTML is also useful. I used to think XSLT with a custom XML schema was the answer, but I find Haml is much more pleasant to work with.
CSS does most of what I want. Sass makes it prettier, but I'm never really going to love it. But I'm also not a designer. While it's clear there's room for improvement in CSS, this is mostly just me. On the other hand, CSS is also where you find the most differences between browsers, which is why on any significant project which needs to support open standards and IE, there's an ie.css file somewhere.
And that's the last major annoyance -- differences between browsers. Yet CSS is the only place I still deal with that directly on a regular basis. The HTML is reasonably standard, and the differences in JavaScript are hidden by libraries like jQuery. Putting preprocessors in front of the actual HTML/CSS/JavaScript also makes it possible to fix the portability issues once and then not have to deal with them -- which is great, because aside from IE, I already barely have to deal with them.
I still think Chrome's nativeclient is a good thing, but mostly for performance -- for the same reason that in a language like Python or Ruby, I'd write C extensions to make stuff fast. So, in a web app, if I find one thing that's really costing me in performance, I'd write a nativeclient version.
At least you know the difference -- the author of this blog seems to confuse the two. But I can't agree with this:
there's more point to learning than increasing intelligence,
Intelligence and willingness to learn are far more important, in my opinion, than knowledge itself. Given any problem, it's a lot easier to learn stuff about that problem domain so that I can help solve it than it is to increase my intelligence, or to learn whole new ways of thinking. On the other hand, if I lack the basic intelligence to tackle a problem, there's no amount of learning other than knowing the solution by rote that will help me.
Both make more sense. Learning is important. Learning stuff that may never be relevant is also teaching you different ways of thinking, and this is true even in pure geekdom -- learning truly different programming languages (Lisp, Haskell, Erlang), hardware design, machine code, and actually implementing the basic data structures (like in any CS2 course) all change the way you think about programming, even if you will never do those things again. And I absolutely agree about a well-rounded person.
Kind of like Naruto. Sasuke is a genius. Lee wants to match Sasuke through hard work. Naruto passes both of them by being a hard-working genius.
Still, high intelligence without broad learning gives you the kind of teenage geniuses who contribute so much to open source. Low intelligence with a degree gives you an MBA. I don't know about you, but I think the world needs a lot more open source hackers and a lot fewer MBAs.
I suppose it could be, given a sufficient level of abstraction, but I think when you get to the point I'd want, your code is also reasonably portable to other databases, in which case, why are you bothering with Oracle?
At my Oracle place we weren't permitted to use P/SQL.
So... no triggers? At all? How'd you do autoincrements?
Ok, I guess I'm nitpicking, maybe. I definitely agree with that policy, although it also knocks out another big reason people would want to use Oracle in the first place.
I used a python-esque syntax to have these insanely complex 5-page plus queries, but the catch was they were filled with CTE (common table expressions). I didn't have to give Oracle any hints - it just found them and optimized away 99.99% of the query and executed blazing fast but I could do totally dynamic sorting/searching.
That's kind of cool. Not as cool as maybe not generating that crap in the first place, but I won't deny Oracle has a pretty powerful optimizer.
Still, wouldn't be my first choice. I'd much prefer to start with something like DataMapper -- I get to use Ruby, I get to write Ruby pretty much all the time, I almost never have to touch SQL, yet it's usually fairly intelligent with its queries.
Slashdot Mirror
No, I managed to take your bitcoin off you by using a quantum computer to predict your crypto
That's not the vulnerability.
There are two relevant cryptographic algorithms in Bitcoin: SHA256 and ECDSA. If quantum computers (or anything else) killed SHA256, there are three possible outcomes, depending on how broken it gets. First, they could dramatically increase the rate at which people can mine, which would have a similar impact to upgrading from CPU mining to GPU mining -- that is, the people with quantum computers can mine much faster, so everyone upgrades to quantum computers, so the difficulty rate gets adjusted and everything's back to normal. Second, it could tip things so dramatically that one entity controls a majority of the computing power, which (I think) leads to that entity being able to forge any transaction they like, and the network being forced to accept it. Third, it could improve things so much that even at the max difficulty level, people get coins faster than they should.
I'm very much not worried about SHA256, because as vlm points out, if 51% of the network agrees that it's sufficiently broken to have compromised the past 24 hours worth of transactions (say), you could roll it back for those 24 hours -- in fact, you could even limit it to anything resulting from a mining operation those 24 hours, since that would likely be the first thing compromised (if they didn't crack ECDSA, they can't forge a transaction from my account). This would suck in all kinds of ways for anyone who happened to be trading that day, but it would work. I do hope people keep an eye on it, though -- a gradual rollout of a new hashing algorithm is very possible, assuming we do it before SHA256 breaks, so I would hope people start doing that as soon as we see a better algorithm.
It would be a pretty shitty situation, though. Unless it was caught when gradual rollout is an option, it's going to suck for everyone involved, including Bitcoin itself -- I can't imagine anyone would trust it if this happened at this point.
Your comment is much more about the other algorithm:
I managed to take your bitcoin off you by using a quantum computer to predict your crypto, and I refuse to roll back my bitcoins to you.
So, I assume ECDSA is just a supposedly-more-secure version of RSA, and it's used to authorized transactions from a given account. If you used a quantum computer to guess my private key, we have a problem, because now you can empty my account into yours without the network really noticing. I'm the only one who notices my bitcoins are gone. And of course, you refuse to roll them back, unless I manage to guess your private key and steal them back the same way you stole them.
The problem is, unlike SHA256, there is no scenario where even a catastrophic "let's forget the last 24 hours worth of transactions" move would work here. Even if no one robs you yet, your funds remain vulnerable until there's not only a better public-key algorithm, but until you've transferred your funds to brand-new accounts generated with said algorithm. And while both are available, there's a window of time during which anyone with a quantum computer could rob anyone who hasn't already converted, depositing the funds into new, actually-secure accounts. The worst part is if someone robs you, there's no reasonable way you can prove that you were robbed, and that it wasn't just you transferring your funds to a more secure account as you should have done in the first place, since the "make my wallet secure again" operation and the "rob this person blind" operation look identical to the network.
Seriously, what?
The Internet isn't terribly centralized as it is, other than the organization responsible for assigning IP addresses and domain names. BitTorrent and Bitcoin are both distributed protocols which run on top of that.
In fact, it looks as though Bitcoin is even less centralized than BitTorrent -- while both currently use some sort of central tracker to grab a list of peers, it seems as though Bitcoin could operate just as efficiently no matter how it gets its peers. More peers might be better for anonymity, but it also seems like Bitcoin could operate efficiently with a single peer, while BitTorrent wants to connect to many in order to saturate the connection.
If the "internet in a box" connects to the standard Internet, it's a central choke point. If it doesn't, it's a much smaller network on which it's much harder to hide. Connecting to a single network doesn't imply a single, centralized point of control.
Are there plans to deal with quantum computing, or with any of the algorithms used being compromised?
I understand that the hashes wouldn't be terribly devastating for Bitcoin -- worst case, I would think, you roll the entire network back to a snapshot of the transaction history before the first quantum computer started screwing stuff up, and start using a new hashing algorithm. It'd be very bad, but not catastrophic.
But for actual accounts, it looks like we rely on ECDSA -- and it looks like even if Bitcoin offers a quantum-ready algorithm, my wallet is still likely compromised unless I move everything to it before the first viable quantum computer. Still, there doesn't seem to be much noise about this other than a few forum posts, largely dismissed by saying things like "DWave is vaporware."
According to this review, it's not just that it doesn't compete with Call of Duty -- it doesn't even compete favorably with Duke Nukem 3D.
Do you know that it's a bug in Chrome and not in the website?
Why should I care?... If it renders correctly on IE and Firefox, why should the website rewrite its code to conform to the new kid on the block?
It shouldn't. It should rewrite its code to conform to the very old w3c standards, and then consider browser-specific hacks when something's broken. "Works best on Firefox" is no better than "Works best on IE", and every time a site does that, it's holding back development of the Web and web browsers.
That's why I asked, and that's why you should care. If the bug is in Chrome, then you and this website can safely ignore it, though the Chromium developers would probably appreciate a bug report. If the bug is in the website, particularly if it also relies on bugs in Firefox and IE, then it should be fixed, otherwise the site is likely to break anyway with some future version of Firefox or IE.
In fact I can't remember the last time I had layout problems with firefox.
I can barely remember the last time I had a layout problem with Chrome. I mean...
It doesn't offer me anything that firefox can't already do.
That's a valid reason. Giving up on it because one website would require you to run Firefox seems like a much less valid reason, if you actually saw an advantage to it.
On my system, Chrome boots much faster than Firefox, the multiple processes and JavaScript engine were significantly faster at the time (and does Firefox have out-of-process tabs yet?), the dev tools are as good as or better than Firebug for 90% of what I need as a web developer, and it has all the addons I need and it's easy to write what it doesn't have. It originally won me over when (before Jetpack for Firefox) I realize that I already knew how to write extensions for it, since the Chrome extension API is just a few Chrome-specific JavaScript APIs plus HTML5 -- I went from not knowing how to write an extension for any browser to having written my own functional adblocker in an afternoon.
I'm not trying to convince you to use Chrome, just pointing out -- those would be reasons to use it, and I can see similar reasons to use Firefox, including basic stuff like "print preview" (I honestly hadn't noticed, I don't really print much.) That a website is broken in one or the other is, to me, a reason to have multiple browsers available. I guess it comes down to, if you were on Windows, and forced to use a "Works best in IE6" website, would you run IE as your default browser, or would you run IETab?
In that case, I'd expect IE to be your default browser. Do you know that it's a bug in Chrome and not in the website?
I tend to use Chrome until a website actually breaks in a way that makes me try it in Firefox -- and then, half the time, it still won't work.
But the simple answer to this point is that fiat currencies work, and currencies with limited (and implicitly declining supplies) haven't.
For some value of "work".
I'll admit my ignorance here, but it seems like one inherent advantage of a system like this is that there is no central authority. No one party can simply decide the government needs an additional billion bitcoins and produce them out of thin air -- they'd have to mine or trade, just like anyone else.
There is a lower bound to the number of BTC you can transact.
Not really. While the default client will insert transaction fees for transactions below a certain value, these are optional -- their only purpose is to serve as an incentive for a miner to include your transaction in a block, and not all miners will enforce that. So it may be more difficult to get your transaction confirmed, but it can go quite a ways down -- the more likely problem is with floating-point rounding, since (unfortunately) Bitcoin uses floating-point math, but the actual Bitcoin fractions are decimal.
I said this in another comment but I'll say it here too: BTC should have an expiration date, and be rolled back into the market when they're not used.
They really shouldn't. Can you imagine a more damaging thing for a currency than, "Oh by the way, if you don't spend this, we're going to take your money from you and distribute it to other people!" Forget about putting any sort of savings in Bitcoin, then. I mean, that's a bad idea at the moment because of how new and volatile it is, but why would you add a built-in disincentive to such a thing?
Alternatively the limits on coin creation should be adjusted.
The fact that it's fixed is another part of its credibility -- artificial scarcity. If the limits can just be adjusted, then it's no different than a fiat currency.
It took only a few seconds on Google to find a source -- well, sort of. I definitely remember reading about it in a book somewhere, likely a legitimate expanded universe book.
It still likely wouldn't look like in the movies, but it'd look closer than what you suggest:
Due to the weightlessness of plasma and the strong gyroscopic effect generated by it, lightsabers required a great deal of strength and dexterity to wield, and it was extremely difficult -- and dangerous -- for the untrained to attempt using...
Lightsaber combat was the preferred fighting method used by lightsaber wielders, many of the forms and styles being designed to compensate for the gyroscopic effect inherent in lightsabers, and take advantage of the Force-sensitivity common in most wielders.
I don't remember where I've heard this before, but I've definitely heard it. But there are some very large problems you haven't solved.
First, this is still going to require a large amount of energy. Where does that come from? And if you've got something superheated into a plasma, how do you keep the metal from melting?
Second, as others have pointed out, you haven't actually solved the magnetic-field problem. Basically, any Jedi could have his lightsaber entirely disabled, or even turned back on him, by inducing a magnetic field on the room he's in.
Third, it doesn't explain the part where lightsabers are incredibly difficult to wield, due to weird gyroscopic effects, such that only someone with force-sensitive reflexes should be able to wield them properly. Ok, Han Solo can cut open a tauntaun, but that's a pretty crude motion -- try to swing it around, and if you're not careful, you could end up cutting yourself as easily as your opponent.
Fourth (!), what are blaster bolts, and how does a lightsaber deflect them? It makes very little sense to suppose that a blaster bolt is just some plasma wrapped around a tube in the same way -- that seems awfully complicated compared to alternatives like just firing the plasma as a projectile -- and then, why would they bounce off force fields the way they do, as if they were somehow slowly-moving laser light?
Finally, how do you explain the phenomena in Episode 1... Alright, maybe you want to pretend that didn't exist, but this phenomena is fairly commonly observed and generally accepted as something that it'd be reasonable for a lightsaber to do. Anyway, what about the point where Qui-Gon and Obi-Wan are trying to break into a room by slowly melting the blast door with their lightsabers? I suppose the metal rod could be collapsing, but then I'd expect that when you pull it out, it'll have to slowly extend again -- and it also suggests that lightsabers would collapse entirely too easily. If they're made of light, this makes much more sense, but then we have all the same problems as light.
So, cool idea, but let's just accept that Star Wars is science fantasy. It's enjoyable science fantasy, and there's no shame in wanting to be a jedi, but you'll never have a lightsaber. (Also, there's no Santa. Sorry.)
When I decided to go back to school, I started with a community college. Their wireless network was pretty much open, but for some perverse reason, it worked with the Windows DHCP client, and with udhcpc, but not with dhcpcd (used to be the default on Gentoo) or dhclient (default on Ubuntu/Debian). It seems fairly likely that this was a bug in their server software, and while I wasn't ridiculed, I never did get any help from the university -- I had to figure this out on my own. As much of a Linux geek as I am, I'm really not sure where I got the idea to just try other DHCP clients.
The university didn't really seem to care that I solved it, or how I solved it, and I don't think they ever put it into a FAQ or anything. The networking club did appreciate it, since a few of them were at least playing with Linux. I never tried it with a Mac, and never saw a single Mac while I was there, so I have no idea if that would work.
But it was because of this, and because the next two courses in their "computer programmer" degree (after Mainframe Assembly) were COBOL and Visual Basic, that I got out as soon as I could. After one term, I left for a real university. (Incidentally, one more factor validating my choice is the fact that the community college kicked me off their cyber defense competition team as soon as they realized I wouldn't be there next term, because "that's how it works in the real world" -- the guy running it is of the opinion that as soon as there's a hint you might leave, you get escorted out the door by security.)
So, that brings me to today. The university I'm at now does provide some amount of support for Linux, to the point where some of their FAQ pages include stuff about Linux, and if I ask a question, it's very possible I'll get an actual answer. The wireless uses MAC filtering, but there's no actual requirement that I use any particular software -- and, bonus, if I make sure to uncheck the "use NAT" box when registering my system, I get a real, Internet-routable IP address and dynamic DNS (with a little firewalling; obviously outbound SMTP and inbound Samba are blocked). I could, theoretically, run a webserver on my laptop that'd be accessible from http://serenity-xps.student.iastate.edu/.
The facilities provided are a genuinely heterogeneous mix of Windows, Mac, and Linux everywhere -- that's labs, remote access machines, etc, and they do point out things like rdesktop for the Windows machine. I've avoided getting a copy of MS Office by using rdesktop to connect to the comp sci Windows terminal server (which has a recent MS Office installed) whenever Open/LibreOffice won't work, I've had no issues printing with lpr on the commandline on the Linux remote machine (though sometimes it's easier to convert to a PDF and print from that Windows terminal server).
Individual courses are hit-and-miss, but mostly hit. I've had English classes which met in Mac-powered computer labs (one started on Windows and then switched to checking out Macbooks), an entirely-Java/Eclipse programming course which was just transparently cross-platform, and a programming course which required people to use gcc and graded you based on whether your code ran on a particular Linux machine you had ssh access to, and a Digital Logic course which was just switching to Linux machines in its labs. That last one was a little bumpy -- all the lab instructions were in .docx and not all opened in OpenOffice -- so I got the professor to give us PDFs, so hell yes, Linux was both required and supported.
The most common per-course issue is people still sending doc and docx around (though most accept odf and all accept pdf for anything I write). There was a course which required people to produce a PowerPoint presentation with an audio recording of our narraiton included, which is a PITA even if you have Windows and PowerPoint -- here, I did something ridiculous and built an HTML5 presentation inst
Definitely doesn't do that on Chrome, and I'm surprised it does on Firefox. When I close a tab, or a window, it makes sense to let the page know and give it a small window to react, but it should be killed before I really notice.
Sorry, no. Inflicting a new UI on people as the default and then having it broken very nearly continuously is very much a developer bug.
I like the new system, and I prefer it to the old system, except for the part where it doesn't fucking work. Seriously, Slashdot, this should be more embarrassing to you than the part where you still can't handle Unicode.
It's getting a bit old that any click within a comment, including within the textarea while I'm trying to reply, gets interpreted as clicking on the "Parent" link, thus requiring me to open the entire thread all the way to the root.
I have "heard tell" (no, I can't produce you a quote) that CHROMIUM doesn't store things "up in the GOOGLE CLOUD" like passwords - whereas by way of comparison, Google CHROME, does.
Not quite. I know that Chrome has the option to set up "sync", which allows you to synchronize everything (passwords, bookmarks, etc) between Chrome installations. However, I have that disabled, and unless you can produce a quote or a link to the contrary, it seems much more likely that Chrome simply stores my passwords locally. It even integrates with local secure password stores -- in my case, since I run KDE4, Chrome stores my passwords in KWallet.
NaCl major flaw is its platform dependence. Sure, it covers the most popular platforms today, but it's not future-proof.
I suppose it technically is in the sense that there's always emulation...
Now they also have PNaCl, where the browser downloads LLVM intermediate language (binary-serialized), compiles that to native, and then runs it in a NaCl sandbox. That is precisely the kind of thing needed - a low-level but nonetheless portable target platform that permits efficient implementation of various things.
What I would wonder here is how efficient it is. How much are you giving up by not using pure native code? It looks like PNaCl is included with NaCl, otherwise it's pointless -- if I have to include an LLVM interpreter anyway, and I'm using low-level languages like C anyway, I may as well compile to native.
But if it is included, having this as an option makes sense in another way: Multiple fallbacks. If NaCl is available, but I don't have a binary for the user's platform, I can try PNaCl. If that doesn't work, I can fall back to a JavaScript implementation.
That's why I was talking about a kick in the balls, not a boot to the head.
But for the sake of argument, a boot to the head, depending how solid it is... It might kill me, but I also might be fine in a few minutes. A bad breakup is almost by definition going to hurt for awhile. It won't kill me (short of suicide), but there's also no chance that I'll be fine in ten minutes, or one day, or a week...
If we're allowed to cheat, I'll take the boot to the head because I can probably avoid that a lot more easily than I can avoid a bad breakup. Boot to the head is easy -- step out of the way, or intercept boot. Then twist it and bring them down, twist again until they promise not to try to boot you in the head again.
Breakups? There isn't a good way to avoid that. You could try not to fall in love in the first place, but that's not really up to you. You could try to never break up, but that's not really up to you, either, because now there are two people involved.
I don't know why I'm doing this, though. The correct answer to "Would you rather have your heart broken or take a boot to the head?" is "No."
So, first, if it's Gmail and stuff ends up in Spam, I can still go read it -- I don't get enough spam that I can't at least glance through it to see if anything was classified incorrectly.
Second, I'd do this specifically for those services which can't be resolved in some five minutes of my time. For instance, if it includes a link for me to click on if I'm not the intended recipient, I'll do that, and consider it not to be spam. If it's just a confirmation email and there's no obvious way to deal with it, delete it and ignore it, but not spam. If there's no way to stop receiving them (and hopefully make someone else's life easier) without picking up a phone, it's spam.
Of course, look at my email address -- I don't have this problem at all. I have far more actual spam, because I display my email address unfiltered on Slashdot.
The results you got suggest a large number of people who are truly clueless about email and the Internet. Might I suggest that in your initial "This isn't the website you're looking for" email, you provide a small note to the effect of "I reserve the right to post future correspondence from you publicly."
Then just do what The Pirate Bay does.
Every aspect of your post is flamebait...
They managed to fuck up the syntax. They managed to fuck up the semantics.
In a few important ways, sure -- things which are fixable, and things which pale in comparison to other mainstream languages. I'd much prefer JavaScript to C++.
They managed to fuck up prototype-based OO.
In what way? It seems to work well in modern browsers.
They managed to fuck up the equality and inequality operators.
No worse than Perl, and from what I can tell, CoffeeScript deals with that problem.
The fact that you need to hide it as much as possible, whether using something like jQuery or CoffeeScript...
Sorry, what?
jQuery isn't even in the same category. It doesn't change the syntax. It doesn't "hide" anything. It provides a useful library abstracting over the DOM, which is not part of the core JavaScript language, and which has similar problems and solutions in other languages -- the obvious example is Hpricot in Ruby (though the cool kids seem to be using Nokogiri these days), and Ruby has none of the issues you just mentioned with JavaScript.
CoffeeScript deals with the syntax, and makes it easy to generate the good parts of JavaScript -- by, for example, replacing '==' with '===', which does what you'd expect '==' to do. I really can't see anything wrong with this. It's exactly like having a preprocessor for C which makes it hard for you to accidentally do unsafe pointer arithmetic.
JavaScript has no redeeming value. There's nothing good about it.
Bullshit. Here's a list of advantages it has over Java, as a language:
I could go on. Some of that is opinion, I suppose, but a lot of them are big gaping holes in Java, and really nice features that I wish other languages had. And if JavaScript is still the "biggest mistake ever made in the field of computing," what does that make Java?
I mean, just look at Firefox. Who the fuck thinks it's a "good idea" to write huge portions of a desktop app using JavaScript and XML?
A desktop app that spends its entire day showing you web apps, so that's not going to be as much of a performance difference as you suggest. It also makes it a lot easier for web developers to hack on their own browser, which is very useful. Chrome is written mostly in C++, but extensions are still JavaScript+HTML, so you can go from web developer to extension developer in an afternoon.
Oh, and writing in a higher-level language -- I don't know that I like the XML idea, but JavaScript makes sense here. It's that much less of the browser that can possibly have a buffer overflow.
it's supposedly a "lightweight" browser.
I agree with you here. It started out as the "lightweight" alternative. But hey, the fact that it actually pulled that off for a year or two suggests that it's not the JavaScript or the XML that made it bloated. No, it's the feature bloat.
You suggest the W3C standardise on "Basic from the '80s" and don't see the irony in your using a smalltalk inspired language to generate CSS?
Web standards have moved on since then. So has Ruby.
Web standards are inspired by stuff like SGML, which is older than dirt. That's entirely beside the point. The point is that the W3C is standardizing stuff that we've been using for years, almost a decade. This is more like if C only became an official standard today.
Chrome does, though it's still experimental.
However, unless you're going to have your own version of HTML and CSS compile to real HTML and CSS, you lose a lot of the benefits of a web app in the first place. As it is, I don't see the problem with using tools like Haml and Sass. I've generally preferred actual JavaScript to preprocessors, but CoffeeScript looks awesome, I don't think I ever took a good look at it before.
The biggest annoyances of the current Web are all things we can deal with.
JavaScript is almost exactly the sort of language I'd want to work with, and CoffeeScript addresses my biggest annoyance -- the syntax is ugly. Other than that, Chrome's V8 has better boot time and execution speed than other languages I'd want to work with, and I don't need to force the users to download an entire interpreter, all of which makes my pages load faster than if I forced some nativeclient interpreter on them, though it's nice to have that option.
Haml addresses my biggest complaint about HTML, which is also mostly skin-deep -- I really don't like the XML syntax. The fact that I can mix in Ruby to generate more HTML is also useful. I used to think XSLT with a custom XML schema was the answer, but I find Haml is much more pleasant to work with.
CSS does most of what I want. Sass makes it prettier, but I'm never really going to love it. But I'm also not a designer. While it's clear there's room for improvement in CSS, this is mostly just me. On the other hand, CSS is also where you find the most differences between browsers, which is why on any significant project which needs to support open standards and IE, there's an ie.css file somewhere.
And that's the last major annoyance -- differences between browsers. Yet CSS is the only place I still deal with that directly on a regular basis. The HTML is reasonably standard, and the differences in JavaScript are hidden by libraries like jQuery. Putting preprocessors in front of the actual HTML/CSS/JavaScript also makes it possible to fix the portability issues once and then not have to deal with them -- which is great, because aside from IE, I already barely have to deal with them.
I still think Chrome's nativeclient is a good thing, but mostly for performance -- for the same reason that in a language like Python or Ruby, I'd write C extensions to make stuff fast. So, in a web app, if I find one thing that's really costing me in performance, I'd write a nativeclient version.
At least you know the difference -- the author of this blog seems to confuse the two. But I can't agree with this:
there's more point to learning than increasing intelligence,
Intelligence and willingness to learn are far more important, in my opinion, than knowledge itself. Given any problem, it's a lot easier to learn stuff about that problem domain so that I can help solve it than it is to increase my intelligence, or to learn whole new ways of thinking. On the other hand, if I lack the basic intelligence to tackle a problem, there's no amount of learning other than knowing the solution by rote that will help me.
Both make more sense. Learning is important. Learning stuff that may never be relevant is also teaching you different ways of thinking, and this is true even in pure geekdom -- learning truly different programming languages (Lisp, Haskell, Erlang), hardware design, machine code, and actually implementing the basic data structures (like in any CS2 course) all change the way you think about programming, even if you will never do those things again. And I absolutely agree about a well-rounded person.
Kind of like Naruto. Sasuke is a genius. Lee wants to match Sasuke through hard work. Naruto passes both of them by being a hard-working genius.
Still, high intelligence without broad learning gives you the kind of teenage geniuses who contribute so much to open source. Low intelligence with a degree gives you an MBA. I don't know about you, but I think the world needs a lot more open source hackers and a lot fewer MBAs.
Still fades faster. A solid kick and, what, you feel sick, nauseous, just want to curl up and die?
For how long? Five minutes?
Yeah, a bad breakup can have at least those symptoms, but for weeks, at least.
Oracle + C# is actually pretty fun.
I suppose it could be, given a sufficient level of abstraction, but I think when you get to the point I'd want, your code is also reasonably portable to other databases, in which case, why are you bothering with Oracle?
At my Oracle place we weren't permitted to use P/SQL.
So... no triggers? At all? How'd you do autoincrements?
Ok, I guess I'm nitpicking, maybe. I definitely agree with that policy, although it also knocks out another big reason people would want to use Oracle in the first place.
I used a python-esque syntax to have these insanely complex 5-page plus queries, but the catch was they were filled with CTE (common table expressions). I didn't have to give Oracle any hints - it just found them and optimized away 99.99% of the query and executed blazing fast but I could do totally dynamic sorting/searching.
That's kind of cool. Not as cool as maybe not generating that crap in the first place, but I won't deny Oracle has a pretty powerful optimizer.
Still, wouldn't be my first choice. I'd much prefer to start with something like DataMapper -- I get to use Ruby, I get to write Ruby pretty much all the time, I almost never have to touch SQL, yet it's usually fairly intelligent with its queries.