Re:only one tiny gripe
on
Broken Angels
·
· Score: 1
No, and in this context quantum "encryption" is something of a misnomer.
Basically what happens is that no matter what, if you're observing the "remote" end of the entanglement, you will get apparently random gibberish that requires additional context, transferred over classical channels from the "sender", to interpret meaningfully.
Re:only one tiny gripe
on
Broken Angels
·
· Score: 1
The catch is that you don't know which way they were "spinning" beforehand, until you measure them and break the entanglement. So you have to "compare notes" with the recipient on the other end to learn what was communicated (via a slower, convential channel).
Things at the quantum level really don't make intuitive sense.
I think Mozilla, OpenOffice, and the like being available cross-platform do help in a different way, though...
Right now there are Windows users who browse with Firefox, produce documents with OpenOffice, read their email with Thunderbird, and talk to their friends with GAIM.
At that point, what's stopping them from switching to Linux? When they reach the other side they can simply carry on with all the same applications. They still need a "why" to switch, but it needn't be as compelling a reason anymore: the barrier to switching has been lowered.
Now, imagine if none of those applications were available on Windows. Leaving not only Windows, but Internet Explorer, Word, Excel, Powerpoint, Outlook and Trillian behind all at the same time would be more than a little traumatic. You could expect quite a lot of pushback.
For the history buffs, I think COBOL was one attempt to bridge spoken "Businessese" and computer code. I don't know a ton about it but I think it might ultimately be an underrated attempt... (for a while, all computers were financial (base 10 for its math, usually) or scientific (binary)...over time, the scientific approach 'won out', probably because it was easier for the scientific side to emulate the business side than vice versa, or maybe because the attention span of geeks is more important than who's writing big checks.
Unfortunately it's because COBOL is excrutiatingly bad at expressing the sorts of things programmers need to express. It's not so hot for expressing business information either.
I am reminded of the attempts to cross horses with zebras -- it worked, but the hybrid inherited the worst traits of each animal.
So, serious question... NNTP servers are still out there and not totally dead... what's to stop an implementatino of RSS-over-NNTP now, while we still have the infrastructure?
(subscripts/superscripts omitted because of dumb slashdot HTML limitations)
If all the hydrogen atoms were knocked loose and took their electrons with them, you'd get:
2NH3 => N2 + 3H2
So, hydrogen and nitrogen.
Maybe more likely though you'll just lose a hydrogen ion and end up with an NH2- ion, which could recombine with other compounds in the atmosphere to form various amines (which themselves would be subject to breakdown in UV).
Generally whatever happens you're likely to be left with molecular nitrogen and some other stuff eventually.
The site's underlying HTML is really b0rked if you want to use a screenreader or similar technology, even in conjunction with IE.
Trying a site in lynx (if you use an older version without table support, or disable tables support) will give you a (rough) sense of what a blind user using a screen reader or specialized browser would have to cope with.
The design of such sites being hostile to "ordinary" (Mozilla/Opera/Firefox/whatever) alternate browsers is just a common side-effect.
Well, I know with metal containers one of the problems is that hydrogen tends to work itself into the crystal lattices of the metal over time, embrittling it.
There may be similar problems with other materials.
What I think they should do is embrace and extend the the.NET framework *NOW*, add features and support for things that the Windows.NET does not have. But also bring the extended version to Windows itself.
That's precisely what they've been doing all along. Until recently, they've just been very quiet about it...
You'll notice lately that Miguel's been talking about "API stacks" -- i.e. Gtk# et al versus Microsoft's SWF et al., both built on the safe substrate of the ECMA standard. They've been working on that stuff all along, but until recently not talking about it separately.
I guess there's a certain truth to what he says, depending on how you approach it.
The thing is, you really _don't_ want to be in the business of having to worry about platform-specific concerns for more than one platform in your own code.
If you try, you'll either end up essentially writing your own meta-platform (building and debugging it from scratch, consuming development time better spent elsewhere), or your code will become a mess of #ifdefs and specializations which can only ever be built or tested on obscure platforms (meaning most platforms will always be moderately broken).
What you want to do is pick a platform that lets you run on a range of systems -- i.e. "leave it to your system software".
Inkscape's "platform", for example, is for the most part not POSIX nor Linux nor Win32, it's Glib/Gtk+/Pango/Gdk + libxml + STL.
We still have a number of platform-specific subclasses and #ifdefs (many inherited from Sodipodi), but we're actively working to reduce (ideally eliminate) them.
For example, most recently (in CVS), we replaced the typography subsystem we inherited from Sodipodi with a little bit of glue code on top of Pango.
In the process, we gained a lot of features that Lauris never had time to implement or debug in Sodipodi's private typography library, like using the kerning information specified in fonts, and the hardest parts of support for rendering "interesting" non-Western scripts.
Just be sure that the set of libraries (your platform) which you write to is widespread and well-tested on the systems you care about.
I guess given the systems David's employer cares about supporting, his choice of Microsoft platforms shouldn't be altogether surprising.
Slashdot Mirror
No, and in this context quantum "encryption" is something of a misnomer.
Basically what happens is that no matter what, if you're observing the "remote" end of the entanglement, you will get apparently random gibberish that requires additional context, transferred over classical channels from the "sender", to interpret meaningfully.
The catch is that you don't know which way they were "spinning" beforehand, until you measure them and break the entanglement. So you have to "compare notes" with the recipient on the other end to learn what was communicated (via a slower, convential channel).
Things at the quantum level really don't make intuitive sense.
I think Mozilla, OpenOffice, and the like being available cross-platform do help in a different way, though...
Right now there are Windows users who browse with Firefox, produce documents with OpenOffice, read their email with Thunderbird, and talk to their friends with GAIM.
At that point, what's stopping them from switching to Linux? When they reach the other side they can simply carry on with all the same applications. They still need a "why" to switch, but it needn't be as compelling a reason anymore: the barrier to switching has been lowered.
Now, imagine if none of those applications were available on Windows. Leaving not only Windows, but Internet Explorer, Word, Excel, Powerpoint, Outlook and Trillian behind all at the same time would be more than a little traumatic. You could expect quite a lot of pushback.
I am not able to rightly ascertain the confusion of ideas that would result in such an understanding of error correction codes, or rounding error.
In both cases, the initial data is still "good".
Unfortunately it's because COBOL is excrutiatingly bad at expressing the sorts of things programmers need to express. It's not so hot for expressing business information either.
I am reminded of the attempts to cross horses with zebras -- it worked, but the hybrid inherited the worst traits of each animal.
Interested? I'm toying with the idea of doing just that, but I can't do it on my own, and you seem to have a much deeper knowledge of NNTP than I.
So, serious question ... NNTP servers are still out there and not totally dead... what's to stop an implementatino of RSS-over-NNTP now, while we still have the infrastructure?
NNTP already has all the issues solved pat.
H2O would be the fate of two of those "liberated" hydrogen atoms if they met some oxygen in other compounds. That'd fall under "other stuff".
Interestingly, kids who go through those programs are statistically more likely to experiment with drugs than kids who don't.
IIRC mono also runs Java apps (subject to the limitations of GNU Classpath, which it uses).
(subscripts/superscripts omitted because of dumb slashdot HTML limitations)
If all the hydrogen atoms were knocked loose and took their electrons with them, you'd get:
2NH3 => N2 + 3H2
So, hydrogen and nitrogen.
Maybe more likely though you'll just lose a hydrogen ion and end up with an NH2- ion, which could recombine with other compounds in the atmosphere to form various amines (which themselves would be subject to breakdown in UV).
Generally whatever happens you're likely to be left with molecular nitrogen and some other stuff eventually.
The site's underlying HTML is really b0rked if you want to use a screenreader or similar technology, even in conjunction with IE.
Trying a site in lynx (if you use an older version without table support, or disable tables support) will give you a (rough) sense of what a blind user using a screen reader or specialized browser would have to cope with.
The design of such sites being hostile to "ordinary" (Mozilla/Opera/Firefox/whatever) alternate browsers is just a common side-effect.
It was a calculated risk. They took it through the most debris-free part of the ring gap and hoped for the best.
Ignore me. I think slibling poster knows what he's talking about.
Many orders of magnitude faster.
90% of everything is crap.
Also, crap is relative.
Well, I know with metal containers one of the problems is that hydrogen tends to work itself into the crystal lattices of the metal over time, embrittling it.
There may be similar problems with other materials.
Whatever it is, it goes back long, long before movies. Think Prometheus, Daedalus, or Pandora.
As I recall, they're already recycling SSNs.
Apparently. Sorry about that. I'm not having a good day.
In case you haven't been following the news, they ARE.
I do think the GP's explanation is a little overly simplistic though, but the basic point has merit.
That's precisely what they've been doing all along. Until recently, they've just been very quiet about it...
You'll notice lately that Miguel's been talking about "API stacks" -- i.e. Gtk# et al versus Microsoft's SWF et al., both built on the safe substrate of the ECMA standard. They've been working on that stuff all along, but until recently not talking about it separately.
See also this post.
I believe they're offering packages without any of the Microsoft-specific bits now (to make e.g. Debian happy). And yes, this stuff works on Windows.
I don't think Microsoft quite realizes what's hit them yet. Embrace and extend again, but this time it's Microsoft on the receiving end.
That's what they'd been doing in the past. The problem is that the accumulated weight gets nontrivial relatively fast.
I guess there's a certain truth to what he says, depending on how you approach it.
The thing is, you really _don't_ want to be in the business of having to worry about platform-specific concerns for more than one platform in your own code.
If you try, you'll either end up essentially writing your own meta-platform (building and debugging it from scratch, consuming development time better spent elsewhere), or your code will become a mess of #ifdefs and specializations which can only ever be built or tested on obscure platforms (meaning most platforms will always be moderately broken).
What you want to do is pick a platform that lets you run on a range of systems -- i.e. "leave it to your system software".
Inkscape's "platform", for example, is for the most part not POSIX nor Linux nor Win32, it's Glib/Gtk+/Pango/Gdk + libxml + STL.
We still have a number of platform-specific subclasses and #ifdefs (many inherited from Sodipodi), but we're actively working to reduce (ideally eliminate) them.
For example, most recently (in CVS), we replaced the typography subsystem we inherited from Sodipodi with a little bit of glue code on top of Pango.
In the process, we gained a lot of features that Lauris never had time to implement or debug in Sodipodi's private typography library, like using the kerning information specified in fonts, and the hardest parts of support for rendering "interesting" non-Western scripts.
Just be sure that the set of libraries (your platform) which you write to is widespread and well-tested on the systems you care about.
I guess given the systems David's employer cares about supporting, his choice of Microsoft platforms shouldn't be altogether surprising.