Actually, a significant number of my pregnant classmates got that way intentionally.
I'd argue that those girls were also being naive.
But that's still a different sort of naivete to getting pregnant because you don't know that that's a potential consequence of having sex. They were knowledgeable enough to know the likely immediate consequences of their actions, and intelligent enough to intend for them to happen, but not wise enough to know that their methods were unlikely to lead to their real goal. That's not really naivete, but rather foolishness, and failure to compute consequences correctly is a very common human failing, enough so that it's possible it should be taken as the normal case...
Cloud Computing generally implies redundancy and non-locality 24/7.
No. It generally implies that you can hire resources (cpu, disk) on short notice and for short amounts of time without costing the earth. You can build high-availability systems on top of that, but HA is not trivial to set up and typically requires significant investment at many levels (hardware, system, application) to attain. Pretend that you can get away with less if you want; I don't care.
"In the cloud" really just means letting someone else be responsible for your data.
There's a bit more to it than that; you also let them run the servers (or even services) that access the data. Of course, it does leave me wondering how much care Apple will take when it comes to privacy laws (EU law is fairly strict in this area, though if the data is encrypted before export those laws are probably satisfied — IANAL of course). I don't expect to figure that out from a patent application.
Remember: there's very little technical innovation in The Cloud; it's virtually all stuff that was there before. The innovation was all on the business side of things (such as permitting rent by the hour instead of by the month; a couple orders of magnitude difference in flexibility).
Patent worthy? Hell, no.
I'd be inclined to agree for the most part. The only really interesting thing would be how they're tuning the systems to cope with the sorts of levels of external I/O; most clouds are terrible at that (well, by comparison with their other capabilities). Yet that's just configuration; anyone properly skilled in the art of system and network administration should be able to spec out how to do that sort of thing.
scp doesn't distract people with popups, doesn't eat resources, tends to be more stable, doesn't require a GUI interface, won't allow people to get distracted with porn and/or Cowboy Neil (or, indeed, porn of Cowboy Neil), is far friendlier to network resources than HTTP (HTTP is =HORRIBLE= for file transfers), and prevents people listening in to what you download.
That all depends on how you've configured your server. The HTTP protocol itself is actually quite reasonable file transfer (we've measured it to be so) and with a reasonable client and not too stupid server you can do things like parallel transfers. It's also quite reasonable when it comes to resource consumption (assuming you're shipping the data as binary). But that's not to say that scp doesn't work (it does, wonderfully). Their use cases are just different.
From a server standpoint, HTTP connections keep connection state information for several minutes. This is a heavy resource drain. Web servers are also fairly heavy beasts - they've got to maintain a lot of internal state, the protocol is heavy, etc.
That depends on the server configuration. There are quite a few HTTP servers that are very lightweight. But then again...
It doesn't take much to exhaust a machine running, say, Apache 2.x of resources.
... there's Apache, which is not lightweight. It's not HTTP itself that's necessarily expensive, it's that it can be configured to support transfer of data in ways that are expensive in terms of server resources. (Dynamic assembly of pages from data scattered all over a disk and database, that's necessarily expensive. Unsurprisingly.)
Are those full coroutines, or gimped ones like in CPython? I ask because Tcl 8.6 (like Lua, where I believe we pinched some implementation concepts from in this area) uses a non-recursive execution engine under the covers so that code doesn't have to know that it's running inside a coroutine context (i.e., if a procedure is running inside a coroutine context, the sub-procedures it calls can yield without the outer procedure having to know anything about it). This contrasts with coroutines as implemented in Python (though maybe not Stackless). I don't know which side of this divide has Javascript; googling just helps me find puffery and arguments, not hard information.
Of course, if you really want threads in Tcl (e.g., so you can fully utilize multiple CPU cores) use the Thread package. Tcl's threads don't share memory by default (which is great, no need for lots of poxy global locks) and instead focus on inter-thread messaging, but you can ask explicitly for a shared variable if you want (which includes all the locking machinery you need).
hashing = encryption, here. they've changed the terminology since the last time i cared.
There's a formal difference. Encryption is reversible (if you have the decryption key) whereas hashing is not (it formally loses information from long input values). Theoretically, hashing is less strong because there could be other values that hash to the same thing (this is one of the principles behind rainbow tables) but with a good crypto hash algorithm, finding two values that collide is really hard.
The attackers gained access to all information on the site, so it's entirely possible that they've got enough information to work at breaking passwords at their leisure. OTOH, the site is using a salted hash for their passwords, so the only approach that can be used is a simple brute-force test, one password at a time, one user at a time. Weak passwords are under threat, but strong ones should be OK (at least for some time).
It's still a good idea for users to change everything that uses the same password to use something else. The most secure option would be to go to using a different password for each site, as that limits the exposure of future breaches, but the downside is that far more passwords need to be remembered...
2. It's practical. Really. (We have full production webservers written in Tcl 8.6. We know from the logs that they get pretty heavily hammered by dumbass hackers wondering whether we use phpMyAdmin behind the scenes. Heh heh.)
So for mortal humans, producing anything with it would take 9 months, require enormous amounts of pain, and afterwards there would be much screaming and being sick?
How is it different? You're still downloading code. There's already architecture dependence in practice (though it's on the Javascript pseudo-architecture). People have been turning up the heat on the frog for years. And yet, the web itself doesn't care. It's just your lame-ass browsers and lame-ass website designers that care.
Doing anything OO in Tcl is simply horrifying. [incr Tcl] doesn't even do garbage collection on objects.
GC's awkward because of some nasty complex interactions. I think I know how to do it (I have some experimental code) but it's currently so incredibly limited that I suggest you don't want to try that particular code branch. (Crashes a lot too. It's truly not yet ready for even experimental use.)
Well, I'm not exactly a fan of TCL, I admit. However I wonder why you say "it can be used for any kind of application". Ok, technically you can use it for anything, sure. However it hardly strikes me as particularly suitable for many tasks.
While it's true that you wouldn't want to write everything in it — heavy-duty math is far better in C or Fortran — there's a substantial ecosystem of extension modules ("packages") that provide lots of useful functionality. There's also a strong habit of engineering for robustness; Tclers assume (with good reason) that anything can be used with anything. Mixing high-quality XML handling with high-quality database access with high-quality threading with high-quality asynchronous I/O? Sure. Not even remarkable. We just do it and get on to the next thing.
It's slow and a line's syntax is not checked before it's executed, so you don't even have minimal formal checks. IMO that alone should exclude TCL from anything but small projects.
Except that the slowness isn't really there (we've got a reasonably decent bytecode engine) and it tends to vanish in large apps anyway; large apps lose lots of time in integration between the various components, and that's where Tcl does extremely well. Moreover, in a large app in most languages, you'll have lots of code just to do type munging, coercing types so that all the unpleasant impedance mismatches don't slay you. Tcl's lack of formal typing suddenly looks like less of a problem once you've dealt with a real large app. (Types are still thoroughly checked at runtime, but they're usually unproblematic for code.)
For all that I say above, Tcl still works very well for integrating bits of C code together. That's considered to be good Tcl usage, and it's the original purpose of the language; a key source of the community's philosophy to problem solving. We've even got a package that allows you to write C code directly inside your Tcl script as the body of a command, which is then compiled and linked into your program at runtime (with a cache, of course). We also have a packaging technology that lets you put whole complex applications together (Tcl code, C code, auxiliary files) into an executable archive, making delivery of products to customers a cinch. There aren't that many other languages/runtimes that work well that way, even now.
Tcl generally lacks a lot of OOP features that might make it more supportable,
Technically, it lacked a blessed one. There are several available as after-market extension modules. But in 8.6, there's a standard one (I wrote it; it's faster than the others and as dynamic as Tcl itself).
but one thing in its favor - it has a very regular syntax. Parsers for Tcl will be easy to write, FWIW.
Funnily enough, that's both true and false. Basic parsers are indeed ridiculously simple. Full parsers (i.e., ones that can extract similar levels of information to what you'd get from many other languages EBNF definitions) are much more complex because Tcl is actually not a context-free language. (I'm a little hazy as to whether it is a context-sensitive language or recursively enumerable, though I suspect the latter.) The simplest possible practical full Tcl parser is a Tcl interpreter, though the language is compilable under some simplifying assumptions (e.g., no runtime redefinition of syntax; addition of new syntax – a fairly common habit of Tcl programmers – is much simpler by comparison).
it seems that we may be going from an architecture-independent web to an architecture-dependent one
There's nothing wrong in principle with the architecture-independent web supporting the downloading of architecture-dependent pieces. It's been happening a lot for ages (I remember downloading Linux distributions onto floppy disk back in 1993).
The main-line Tcl development is not going to be coupled to NaCl. The environment's way too restricted for most developers to be truly interested. Still it's a bit of neat technology.
The new measures will allow for users to be disconnected from the Internet for up to 6 months, based on infringement claims from copyright holders.
Are these claims required to be made under oath? What processes are there in place to allow challenging such claims? After all, allowing restriction of perceived rights on the basis of random unchallengeable allegations by private organizations is just a way to allow corporate fascism.
So, these rich people you hate, when they get a tax cut, have more money, which they buy bonds with. Since there's more money available, more bonds get written, more money gets borrowed, and companies hire more people
Except that the rich don't necessarily buy bonds in companies that have any operations where you live. Why invest in America when investing in China and India gets better returns?
Won't scale up, as it fails to take into account the fact that the world is full of idiots and assholes. Assholes will try to poison the trust web ("for great profit!") and idiots will act in ways that let the assholes do it without any way to get back at them.
The problem with the system of CAs is that nobody seems willing to pull the plug on crap ones. If CAs knew that they'd get kicked out of the magic money farm for screwing up, they'd take the right level of care. (Especially if they'd then have to fend off lawsuits from their erstwhile customers who suddenly find that their HTTPS sites don't work.) Nothing else is enough.
What we need is a way for people to get the keys straight from each other without having intermediate signing authorities, as much as possible. Example, your bank most likely has a secure, brick and mortar branch in your town or near you. So, you could simply go to the branch office and they give you the cert and you install it on your browser, problem solved. The issue is that this is beyond most people's abilities. However, I posit that if you use something like a QR code or multiple QR codes to hold the cert, then people just shoot it with their phone and when they get back they plug their phone into their computer and it updates the certs.
Because everyone only ever wants to talk securely to businesses that have bricks-and-mortar stores in their area, and Bad Guys can't produce QR codes.
Ask the user if he wants to trust other installed certificates.
There's no point in asking a user a security question they don't understand, especially if it has long-lasting subtle consequences. They'll just say "yes" or "no" at random. We saw that with screensaver trojans. We'll see it again here. Any widespread mechanism must not require lots of fiddling around by users; it's got to be as permissive as possible while still being reasonably safe.
Then why don't they show other cars "pretending" to run out of gas and having to be pushed, since it's true that other cars will do that?
They have done, for particularly thirsty vehicles. In particular, I remember Clarkson getting ribbed thoroughly for owning a model that was so thirsty under normal driving conditions it couldn't even make it from his house to the TV studio without a fill-up. (I forget which model of car it was; I wasn't thinking about buying a supercar then, and I'm not now.)
You think a republican majority would not have done the same?
To be fair, the Republicans would have gone for a lawyer from Big Coal or Big Oil rather than Big Media. Not that this makes much difference, you understand.
Slashdot Mirror
Actually, a significant number of my pregnant classmates got that way intentionally.
I'd argue that those girls were also being naive.
But that's still a different sort of naivete to getting pregnant because you don't know that that's a potential consequence of having sex. They were knowledgeable enough to know the likely immediate consequences of their actions, and intelligent enough to intend for them to happen, but not wise enough to know that their methods were unlikely to lead to their real goal. That's not really naivete, but rather foolishness, and failure to compute consequences correctly is a very common human failing, enough so that it's possible it should be taken as the normal case...
This incident illustrates once again why you need to put your stuff on your own servers and not someone else's.
Hosting everything yourself? Can we sell you a contract for us to build you a datacenter? Then there's the ongoing costs of actually operating it.
Or were you thinking that a scavenged rack in a old closet previously only used by the janitor was a substitute?
Cloud Computing generally implies redundancy and non-locality 24/7.
No. It generally implies that you can hire resources (cpu, disk) on short notice and for short amounts of time without costing the earth. You can build high-availability systems on top of that, but HA is not trivial to set up and typically requires significant investment at many levels (hardware, system, application) to attain. Pretend that you can get away with less if you want; I don't care.
"In the cloud" really just means letting someone else be responsible for your data.
There's a bit more to it than that; you also let them run the servers (or even services) that access the data. Of course, it does leave me wondering how much care Apple will take when it comes to privacy laws (EU law is fairly strict in this area, though if the data is encrypted before export those laws are probably satisfied — IANAL of course). I don't expect to figure that out from a patent application.
Remember: there's very little technical innovation in The Cloud; it's virtually all stuff that was there before. The innovation was all on the business side of things (such as permitting rent by the hour instead of by the month; a couple orders of magnitude difference in flexibility).
Patent worthy? Hell, no.
I'd be inclined to agree for the most part. The only really interesting thing would be how they're tuning the systems to cope with the sorts of levels of external I/O; most clouds are terrible at that (well, by comparison with their other capabilities). Yet that's just configuration; anyone properly skilled in the art of system and network administration should be able to spec out how to do that sort of thing.
scp doesn't distract people with popups, doesn't eat resources, tends to be more stable, doesn't require a GUI interface, won't allow people to get distracted with porn and/or Cowboy Neil (or, indeed, porn of Cowboy Neil), is far friendlier to network resources than HTTP (HTTP is =HORRIBLE= for file transfers), and prevents people listening in to what you download.
That all depends on how you've configured your server. The HTTP protocol itself is actually quite reasonable file transfer (we've measured it to be so) and with a reasonable client and not too stupid server you can do things like parallel transfers. It's also quite reasonable when it comes to resource consumption (assuming you're shipping the data as binary). But that's not to say that scp doesn't work (it does, wonderfully). Their use cases are just different.
From a server standpoint, HTTP connections keep connection state information for several minutes. This is a heavy resource drain. Web servers are also fairly heavy beasts - they've got to maintain a lot of internal state, the protocol is heavy, etc.
That depends on the server configuration. There are quite a few HTTP servers that are very lightweight. But then again...
It doesn't take much to exhaust a machine running, say, Apache 2.x of resources.
... there's Apache, which is not lightweight. It's not HTTP itself that's necessarily expensive, it's that it can be configured to support transfer of data in ways that are expensive in terms of server resources. (Dynamic assembly of pages from data scattered all over a disk and database, that's necessarily expensive. Unsurprisingly.)
So, what can you not do with HTML5 that you can do with Flash / Silverlight?
With HTML5, you can't lock yourself in to a big corporation's strategy for hating users in various ways.
Damn you HTML5 for making things open!!! :-)
Are those full coroutines, or gimped ones like in CPython? I ask because Tcl 8.6 (like Lua, where I believe we pinched some implementation concepts from in this area) uses a non-recursive execution engine under the covers so that code doesn't have to know that it's running inside a coroutine context (i.e., if a procedure is running inside a coroutine context, the sub-procedures it calls can yield without the outer procedure having to know anything about it). This contrasts with coroutines as implemented in Python (though maybe not Stackless). I don't know which side of this divide has Javascript; googling just helps me find puffery and arguments, not hard information.
Of course, if you really want threads in Tcl (e.g., so you can fully utilize multiple CPU cores) use the Thread package. Tcl's threads don't share memory by default (which is great, no need for lots of poxy global locks) and instead focus on inter-thread messaging, but you can ask explicitly for a shared variable if you want (which includes all the locking machinery you need).
hashing = encryption, here. they've changed the terminology since the last time i cared.
There's a formal difference. Encryption is reversible (if you have the decryption key) whereas hashing is not (it formally loses information from long input values). Theoretically, hashing is less strong because there could be other values that hash to the same thing (this is one of the principles behind rainbow tables) but with a good crypto hash algorithm, finding two values that collide is really hard.
The attackers gained access to all information on the site, so it's entirely possible that they've got enough information to work at breaking passwords at their leisure. OTOH, the site is using a salted hash for their passwords, so the only approach that can be used is a simple brute-force test, one password at a time, one user at a time. Weak passwords are under threat, but strong ones should be OK (at least for some time).
It's still a good idea for users to change everything that uses the same password to use something else. The most secure option would be to go to using a different password for each site, as that limits the exposure of future breaches, but the downside is that far more passwords need to be remembered...
2. It's practical. Really. (We have full production webservers written in Tcl 8.6. We know from the logs that they get pretty heavily hammered by dumbass hackers wondering whether we use phpMyAdmin behind the scenes. Heh heh.)
[Python] ... would wrap DOM like a womb.
So for mortal humans, producing anything with it would take 9 months, require enormous amounts of pain, and afterwards there would be much screaming and being sick?
How is it different? You're still downloading code. There's already architecture dependence in practice (though it's on the Javascript pseudo-architecture). People have been turning up the heat on the frog for years. And yet, the web itself doesn't care. It's just your lame-ass browsers and lame-ass website designers that care.
Doing anything OO in Tcl is simply horrifying. [incr Tcl] doesn't even do garbage collection on objects.
GC's awkward because of some nasty complex interactions. I think I know how to do it (I have some experimental code) but it's currently so incredibly limited that I suggest you don't want to try that particular code branch. (Crashes a lot too. It's truly not yet ready for even experimental use.)
Can you possibly choose two slower languages (both at parsing and interpreter/JIT speed) for a web language?
Beanshell and IDL. They're both pathetically slow, yet I know of people who use them for web client tasks and use them a lot.
There's no hope for some folks.
Well, I'm not exactly a fan of TCL, I admit. However I wonder why you say "it can be used for any kind of application". Ok, technically you can use it for anything, sure. However it hardly strikes me as particularly suitable for many tasks.
While it's true that you wouldn't want to write everything in it — heavy-duty math is far better in C or Fortran — there's a substantial ecosystem of extension modules ("packages") that provide lots of useful functionality. There's also a strong habit of engineering for robustness; Tclers assume (with good reason) that anything can be used with anything. Mixing high-quality XML handling with high-quality database access with high-quality threading with high-quality asynchronous I/O? Sure. Not even remarkable. We just do it and get on to the next thing.
It's slow and a line's syntax is not checked before it's executed, so you don't even have minimal formal checks. IMO that alone should exclude TCL from anything but small projects.
Except that the slowness isn't really there (we've got a reasonably decent bytecode engine) and it tends to vanish in large apps anyway; large apps lose lots of time in integration between the various components, and that's where Tcl does extremely well. Moreover, in a large app in most languages, you'll have lots of code just to do type munging, coercing types so that all the unpleasant impedance mismatches don't slay you. Tcl's lack of formal typing suddenly looks like less of a problem once you've dealt with a real large app. (Types are still thoroughly checked at runtime, but they're usually unproblematic for code.)
For all that I say above, Tcl still works very well for integrating bits of C code together. That's considered to be good Tcl usage, and it's the original purpose of the language; a key source of the community's philosophy to problem solving. We've even got a package that allows you to write C code directly inside your Tcl script as the body of a command, which is then compiled and linked into your program at runtime (with a cache, of course). We also have a packaging technology that lets you put whole complex applications together (Tcl code, C code, auxiliary files) into an executable archive, making delivery of products to customers a cinch. There aren't that many other languages/runtimes that work well that way, even now.
Tcl generally lacks a lot of OOP features that might make it more supportable,
Technically, it lacked a blessed one. There are several available as after-market extension modules. But in 8.6, there's a standard one (I wrote it; it's faster than the others and as dynamic as Tcl itself).
but one thing in its favor - it has a very regular syntax. Parsers for Tcl will be easy to write, FWIW.
Funnily enough, that's both true and false. Basic parsers are indeed ridiculously simple. Full parsers (i.e., ones that can extract similar levels of information to what you'd get from many other languages EBNF definitions) are much more complex because Tcl is actually not a context-free language. (I'm a little hazy as to whether it is a context-sensitive language or recursively enumerable, though I suspect the latter.) The simplest possible practical full Tcl parser is a Tcl interpreter, though the language is compilable under some simplifying assumptions (e.g., no runtime redefinition of syntax; addition of new syntax – a fairly common habit of Tcl programmers – is much simpler by comparison).
it seems that we may be going from an architecture-independent web to an architecture-dependent one
There's nothing wrong in principle with the architecture-independent web supporting the downloading of architecture-dependent pieces. It's been happening a lot for ages (I remember downloading Linux distributions onto floppy disk back in 1993).
The main-line Tcl development is not going to be coupled to NaCl. The environment's way too restricted for most developers to be truly interested. Still it's a bit of neat technology.
The new measures will allow for users to be disconnected from the Internet for up to 6 months, based on infringement claims from copyright holders.
Are these claims required to be made under oath? What processes are there in place to allow challenging such claims? After all, allowing restriction of perceived rights on the basis of random unchallengeable allegations by private organizations is just a way to allow corporate fascism.
So, these rich people you hate, when they get a tax cut, have more money, which they buy bonds with. Since there's more money available, more bonds get written, more money gets borrowed, and companies hire more people
Except that the rich don't necessarily buy bonds in companies that have any operations where you live. Why invest in America when investing in China and India gets better returns?
For maleware and spam pages
I used to get a lot of spam about wares for males. Especially dodgy "pharmaceuticals".
just fall back on a distributed web of trust
Won't scale up, as it fails to take into account the fact that the world is full of idiots and assholes. Assholes will try to poison the trust web ("for great profit!") and idiots will act in ways that let the assholes do it without any way to get back at them.
The problem with the system of CAs is that nobody seems willing to pull the plug on crap ones. If CAs knew that they'd get kicked out of the magic money farm for screwing up, they'd take the right level of care. (Especially if they'd then have to fend off lawsuits from their erstwhile customers who suddenly find that their HTTPS sites don't work.) Nothing else is enough.
What we need is a way for people to get the keys straight from each other without having intermediate signing authorities, as much as possible. Example, your bank most likely has a secure, brick and mortar branch in your town or near you. So, you could simply go to the branch office and they give you the cert and you install it on your browser, problem solved. The issue is that this is beyond most people's abilities. However, I posit that if you use something like a QR code or multiple QR codes to hold the cert, then people just shoot it with their phone and when they get back they plug their phone into their computer and it updates the certs.
Because everyone only ever wants to talk securely to businesses that have bricks-and-mortar stores in their area, and Bad Guys can't produce QR codes.
Ask the user if he wants to trust other installed certificates.
There's no point in asking a user a security question they don't understand, especially if it has long-lasting subtle consequences. They'll just say "yes" or "no" at random. We saw that with screensaver trojans. We'll see it again here. Any widespread mechanism must not require lots of fiddling around by users; it's got to be as permissive as possible while still being reasonably safe.
Then why don't they show other cars "pretending" to run out of gas and having to be pushed, since it's true that other cars will do that?
They have done, for particularly thirsty vehicles. In particular, I remember Clarkson getting ribbed thoroughly for owning a model that was so thirsty under normal driving conditions it couldn't even make it from his house to the TV studio without a fill-up. (I forget which model of car it was; I wasn't thinking about buying a supercar then, and I'm not now.)
You think a republican majority would not have done the same?
To be fair, the Republicans would have gone for a lawyer from Big Coal or Big Oil rather than Big Media. Not that this makes much difference, you understand.