This sounds kind of nice but why should this make it any easier to write parallel programs for it? You still have to manage hundreds if not thousands of threads, right? This will not magically turn it into a computer for the masses, I guarantee you that. I have said it elswhere but parallel computing will not come of age until they do away with multithreading and the traditional CPU core. There is a way to build and program parallel computers that does not involve the use of threads or CPUs. This is the only way to solve the parallel programming crisis. Until then, supercomputing will continue to be a curiosity that us mainstream programmers and users can only dream about.
You're wildly mistaken, but for interesting reasons. While SIMD architectures are indeed interesting and do very well on some types of problem (I believe that weather simulation is good) on other problems it is far easier to express them as either MIMD or something more exotic. A real system that needs to handle a mix of codes needs to be implemented as a hybrid: e.g. a cycle-scavenged Condor pool for high-availability, a traditional cluster with a better interconnect, and a supercomputer for those times when you really need the grunt-power. Sure that's not a one-size-fits-all situation, but since when did any reasonable software engineer ever expect that to be the case?
(I don't remember exactly where I read it, but there was a paper fairly recently that characterized 13 fundamentally different types of computation, from embarrassingly parallel to embarrassingly sequential. Hardware architectures that are tuned for one of those cases can do really badly on others.)
Am I just being too cynical, or will putting everything in a password-protected ZIP file and then sending that, together with the password, will satisfy the rules?
When you look at the direction the iPhone has taken, it scares me to think what future technologies like cloud computing could end up as, if they developed from this same context.
You are right to be scared. The cloud vendors are almost all busy trying to (quietly) lock as many customers as possible to their platforms, making it impossible to escape, and they're using a lot of failing to talk about the hard issues of service guarantees and escape clauses to hide the fact that they're being thoroughly evil. It's the old IBM strategy. To be fair, there are a few exceptions, typically because they are selling a platform with less value-add; I'd expect it to be far easier to migrate away from using Amazon Web Services than Salesforce.com (to pick examples where I know somewhat more about the details) since one is offering a virtual-machine running service and the other a CRM solution; guess which it is easier to recover from if things go south?
My advice? Worry about this. These clouds are booby-trapped! And it isn't just techies that should care; management needs to care too.
(Damnit, I hope this message doesn't hurt my future career, but it's too important for cowering behind ACism...)
In particular, if you think it's significantly harder to admin 100 desktops instead of 10 desktops then you're not competent.
The big problem with large-scale desktop admin is that vendors won't supply you matched hardware, even if you have a contract that says they have to. (Dell, I'm looking at you!) That makes constructing the shared desktop images much harder than it ought to be. (I believe we're in the ten to twenty thousand range for installations there, so don't claim we don't know about scaling up; that stuff works.) But it's not that awful otherwise as you can give everyone the same thing and put the user-level differences in network-space. Servers are more awkward because they have different life cycles and more demanding performance requirements.
Your 'web site down' scenario is laughable; I can think of at least a dozen ways to insure the integrity of a main website while still allowing users to get things done immediately and without wasting time on useless paperwork, everything from having a hot clone to swap to if the main web site goes down to putting the user's part of the web site on a separate box to defining privileges so the user can't touch/harm the main part of the website.
We're already running a replicated virtualized server farm to support the website. (Actually around 500 independent domains the last time I checked, but that was a long while ago now.) The key problems relate to people wanting different major versions of modules (well, PHP to be exact) in use on the same website. It doesn't help when you have critical public-facing webapps which need some weird old version of something. (Yes, that's amazingly stupid. No, that's not the admins' fault in any way. I don't feel like discussing institutional politics.)
The "separate box" idea is nice, except that getting academics to properly resource such a thing is like extracting blood from a stone, and the chances are if it's not part of the main system, then it won't be patched regularly and will get hacked in a few months, causing more trouble. (Of course, a good few people do have separate boxes and do very well, as they understand the need to patch and audit. Those folks aren't the problem. But that's really not for everyone; some people really need to let the admins handle these things for them for their own best interests.)
Don't get me wrong. We've got incompetents. Our ticketing and backup systems... I don't want to think about it. But web, email and networking all function right and that's what I need to actually work. Which brings me back to my point earlier: there are competent admins about who aren't prima donnas (even if they're not a majority). I'm sorry for you if you've been stuck with the other kinds.
There are approximately 15 admins in the world who actually do their job the way it should be done.
I didn't know we employed the whole world supply of competent admins here!
Here's why admins get stroppy. Explaining to the Vice Chancellor (or CEO) why the main website went down for 2 days is never easy, and when the explanation comes down to some lowly physics grad student wanting things done without heed for consequences, the experience is excruciating. Hence admins tend to prefer very strongly to keep things working that are currently working, and they dislike that most users have absolutely no idea what actually constitutes a "small change" on a highly-shared system.
OTOH, most users aren't a problem. If you're getting strop in your direction, maybe just maybe it's you that ought to reconsider?
In most cases it would not help loading Web pages. Thanks to TCP slow start, at the very beginning of a TCP connection the limiting factor in the transfer rate is latency, not bandwidth. You have to be transferring for a while before you manage to actually hit full bandwidth. Most Web pages are so tiny that the download is finished before your TCP window ever fully opens up. Same deal with most relatively small images--each image on a page is opened as a totally separate HTTP GET request.
You're wrong. Did you know that when multiple GETs are sent to the same site (common for images) they can be sent on the same TCP connection? Without pipelining of HTTP/1.1 we'd be back in the bad old days when downloading a page took ages exactly because of the phenomenon you describe. (It'd be even worse for secure connections; the SSL handshake is quite slow even when carried out locally, and it's critically dependent on latency precisely because it is a handshake...)
Let's see how well you do with 2 kids and a week's worth of groceries.
In my home city, many people use public transport in exactly that way. What they do is this: they go with a friend (and kids and friend's kids) on public transport to the store, and take a taxi back. The sharing of the cost of the taxi makes it more cost-effective.
Of course, they're doing this because they're poor and don't have the money to put into a car, not because they want to save the environment. But even so.
what point is 1GB to the home, when the site you're downloading from is limited to 300KBit/S
That site is unlikely to stay at 300kb/s if customers are faster (except in the US) and not all sites are the same. You're making the same type of mistake as the "640k is enough for anyone" blooper. Demand increases, and higher capacities enable new applications.
But if you're willing to accept one instruction per clock, and a 2X code bloat over x86 (making all the instructions the same length means the register-to-register instructions take more bytes than they need), it's a simple way to build a CPU.
One of the main interesting things about RISC architectures is that all instructions are the same length, which means that the memory management circuitry can be much simpler. Variable length instructions add a lot of complexity. OTOH, what really got rid of the advantage of RISC was increased L1 cache sizes and the way that the memory bus didn't get faster nearly as quickly as CPUs did. (I know someone who designed a superscalar RISC processor, and the real complexity of going superscalar was dealing with register dependencies as I understand it.)
I personally have always got a kick out of this particular clause from the iTunes EULA:
You also agree that you will not use these products for any purposes prohibited by United States law, including, without limitation, the development, design, manufacture or production of nuclear, missiles, or chemical or biological weapons.
So don't go using iTunes to download the Nuclear Weapon Design Details Podcast, OK?
I simply don't understand the whole breed of scripted languages that tossed out any kind of strong typing. I guess I can understand some quick-and-dirty batch language, and maybe that's where it comes from. Maybe they're all just descendants of csh.
It's good for sticking bits together. Those bits can be written in whatever strongly-typed language you want (I admit I like using C, but tastes vary and there's not a lot to read into the fact) but when you're making the glue to turn everything into an application, those fancy strong types tend to get more in the way than not. Use the right tool for the task and save yourself a lot of grief. (And don't forget to strongly verify the type constraints when moving from the un-/loosely-typed world of the glue to the strictly-typed world of the components.)
Language | PiTA when version X.x is no longer supported and you need to upgrade? Tcl | yes
[...]
I haven't actually used Tcl, but I've read about it, and it's been around a long time. Perhaps this one is the most stable, but who uses it for major web sites?
It certainly used to power the main AOL site for many years (instead of that slow rubbish called Apache:-)). And indeed you're doing Tcl a disservice, since it's generally possible to upgrade from X.x to X.y (xy) without having to recompile anything at all (!) or change scripts. Stuff from 10 years ago still works just fine. (OK, it still looks like stuff from 10 years ago. But at least upgrading the language doesn't force you to rebuild the rest of the world...)
What sort of sucessful cheaper air coniditoning solutions have you come up with?
You've already found the cheap option. Your best bet is to not skimp (unless you like cooking hardware, assuming a reasonable growth rate in computing power under your care) though some of the steps you can take (e.g. hot/cold aisles) are really just rearranging your existing kit and adding some sheet metal work. But that doesn't allow you to skimp on getting adequate cooling. (If you want to know what "adequate cooling" is, ask a real expert; the answer depends on lots of facts you've not revealed.)
Be aware that in large datacenters, the cost of keeping them cool will usually dominate. Really. Be prepared to be your A/C salesman's good customer...
If you design a web site, you want it to show up looking roughly the same on most browsers. For simplicity's sake, most people use the standard fonts (and Mac equivalents).
That's deeply foolish, you know. Users can (and do) set their own style sheets, and they are even more likely to change the size of the fonts in use. Expecting a page to look exactly as someone designed it to be is silly; "web designers" need to get used to the fact (and I've been going on about this on and off since before such a job description existed).
Most natural gas plants are small and use a lot of fuel per megawatt in comparison to things that use steam.
The UK uses quite a few gas combined cycle plants these days, due to having reasonably large gas reserves, and the fact that that those plants have really rather good efficiencies. Mind you, there's no reason why the principle of combined cycle plants can't be used with other fuels either, such as syngas, though it's probably not currently cost-effective to do so.
For if Apple wanted, they could simply ignore the ASA's ruling. Most carriers would probably refuse to run the adverts, but it's most certainly not a "government decision".
Apple could try that, but they'd find that "most carriers" would include all TV and radio stations, print media, the big hoardings, and the vast majority of web channels too. Given that, it's much more effective for Apple to recast their advert to be at least free of outright lies than anything else.
Have you considered that it maybe that the alignment of cows south to north is what causes the earth to have magnetic pole on the first place?
That's an indirect effect, since cows are not particularly magnetic. It's the alignment of the cows that imparts a spin to the planet, and that in turn generates the magnetic field. See? Much more logical!
Slashdot Mirror
This sounds kind of nice but why should this make it any easier to write parallel programs for it? You still have to manage hundreds if not thousands of threads, right? This will not magically turn it into a computer for the masses, I guarantee you that. I have said it elswhere but parallel computing will not come of age until they do away with multithreading and the traditional CPU core. There is a way to build and program parallel computers that does not involve the use of threads or CPUs. This is the only way to solve the parallel programming crisis. Until then, supercomputing will continue to be a curiosity that us mainstream programmers and users can only dream about.
You're wildly mistaken, but for interesting reasons. While SIMD architectures are indeed interesting and do very well on some types of problem (I believe that weather simulation is good) on other problems it is far easier to express them as either MIMD or something more exotic. A real system that needs to handle a mix of codes needs to be implemented as a hybrid: e.g. a cycle-scavenged Condor pool for high-availability, a traditional cluster with a better interconnect, and a supercomputer for those times when you really need the grunt-power. Sure that's not a one-size-fits-all situation, but since when did any reasonable software engineer ever expect that to be the case?
(I don't remember exactly where I read it, but there was a paper fairly recently that characterized 13 fundamentally different types of computation, from embarrassingly parallel to embarrassingly sequential. Hardware architectures that are tuned for one of those cases can do really badly on others.)
Am I just being too cynical, or will putting everything in a password-protected ZIP file and then sending that, together with the password, will satisfy the rules?
When you look at the direction the iPhone has taken, it scares me to think what future technologies like cloud computing could end up as, if they developed from this same context.
You are right to be scared. The cloud vendors are almost all busy trying to (quietly) lock as many customers as possible to their platforms, making it impossible to escape, and they're using a lot of failing to talk about the hard issues of service guarantees and escape clauses to hide the fact that they're being thoroughly evil. It's the old IBM strategy. To be fair, there are a few exceptions, typically because they are selling a platform with less value-add; I'd expect it to be far easier to migrate away from using Amazon Web Services than Salesforce.com (to pick examples where I know somewhat more about the details) since one is offering a virtual-machine running service and the other a CRM solution; guess which it is easier to recover from if things go south?
My advice? Worry about this. These clouds are booby-trapped! And it isn't just techies that should care; management needs to care too.
(Damnit, I hope this message doesn't hurt my future career, but it's too important for cowering behind ACism...)
In particular, if you think it's significantly harder to admin 100 desktops instead of 10 desktops then you're not competent.
The big problem with large-scale desktop admin is that vendors won't supply you matched hardware, even if you have a contract that says they have to. (Dell, I'm looking at you!) That makes constructing the shared desktop images much harder than it ought to be. (I believe we're in the ten to twenty thousand range for installations there, so don't claim we don't know about scaling up; that stuff works.) But it's not that awful otherwise as you can give everyone the same thing and put the user-level differences in network-space. Servers are more awkward because they have different life cycles and more demanding performance requirements.
Your 'web site down' scenario is laughable; I can think of at least a dozen ways to insure the integrity of a main website while still allowing users to get things done immediately and without wasting time on useless paperwork, everything from having a hot clone to swap to if the main web site goes down to putting the user's part of the web site on a separate box to defining privileges so the user can't touch/harm the main part of the website.
We're already running a replicated virtualized server farm to support the website. (Actually around 500 independent domains the last time I checked, but that was a long while ago now.) The key problems relate to people wanting different major versions of modules (well, PHP to be exact) in use on the same website. It doesn't help when you have critical public-facing webapps which need some weird old version of something. (Yes, that's amazingly stupid. No, that's not the admins' fault in any way. I don't feel like discussing institutional politics.)
The "separate box" idea is nice, except that getting academics to properly resource such a thing is like extracting blood from a stone, and the chances are if it's not part of the main system, then it won't be patched regularly and will get hacked in a few months, causing more trouble. (Of course, a good few people do have separate boxes and do very well, as they understand the need to patch and audit. Those folks aren't the problem. But that's really not for everyone; some people really need to let the admins handle these things for them for their own best interests.)
Don't get me wrong. We've got incompetents. Our ticketing and backup systems... I don't want to think about it. But web, email and networking all function right and that's what I need to actually work. Which brings me back to my point earlier: there are competent admins about who aren't prima donnas (even if they're not a majority). I'm sorry for you if you've been stuck with the other kinds.
That's why you supplement the solar power with wind power. Haven't you watched any of those greenie off-the-grid shows?
I know what, you could supplement it with wave power from the Sea of Tranquility.
There are approximately 15 admins in the world who actually do their job the way it should be done.
I didn't know we employed the whole world supply of competent admins here!
Here's why admins get stroppy. Explaining to the Vice Chancellor (or CEO) why the main website went down for 2 days is never easy, and when the explanation comes down to some lowly physics grad student wanting things done without heed for consequences, the experience is excruciating. Hence admins tend to prefer very strongly to keep things working that are currently working, and they dislike that most users have absolutely no idea what actually constitutes a "small change" on a highly-shared system.
OTOH, most users aren't a problem. If you're getting strop in your direction, maybe just maybe it's you that ought to reconsider?
In most cases it would not help loading Web pages. Thanks to TCP slow start, at the very beginning of a TCP connection the limiting factor in the transfer rate is latency, not bandwidth. You have to be transferring for a while before you manage to actually hit full bandwidth. Most Web pages are so tiny that the download is finished before your TCP window ever fully opens up. Same deal with most relatively small images--each image on a page is opened as a totally separate HTTP GET request.
You're wrong. Did you know that when multiple GETs are sent to the same site (common for images) they can be sent on the same TCP connection? Without pipelining of HTTP/1.1 we'd be back in the bad old days when downloading a page took ages exactly because of the phenomenon you describe. (It'd be even worse for secure connections; the SSL handshake is quite slow even when carried out locally, and it's critically dependent on latency precisely because it is a handshake...)
Let's see how well you do with 2 kids and a week's worth of groceries.
In my home city, many people use public transport in exactly that way. What they do is this: they go with a friend (and kids and friend's kids) on public transport to the store, and take a taxi back. The sharing of the cost of the taxi makes it more cost-effective.
Of course, they're doing this because they're poor and don't have the money to put into a car, not because they want to save the environment. But even so.
what point is 1GB to the home, when the site you're downloading from is limited to 300KBit/S
That site is unlikely to stay at 300kb/s if customers are faster (except in the US) and not all sites are the same. You're making the same type of mistake as the "640k is enough for anyone" blooper. Demand increases, and higher capacities enable new applications.
Hey, timothy... Why is this on developers.slashdot.org? It doesn't belong here as it's not to do with software development; it belongs in YRO...
But if you're willing to accept one instruction per clock, and a 2X code bloat over x86 (making all the instructions the same length means the register-to-register instructions take more bytes than they need), it's a simple way to build a CPU.
One of the main interesting things about RISC architectures is that all instructions are the same length, which means that the memory management circuitry can be much simpler. Variable length instructions add a lot of complexity. OTOH, what really got rid of the advantage of RISC was increased L1 cache sizes and the way that the memory bus didn't get faster nearly as quickly as CPUs did. (I know someone who designed a superscalar RISC processor, and the real complexity of going superscalar was dealing with register dependencies as I understand it.)
I personally have always got a kick out of this particular clause from the iTunes EULA:
You also agree that you will not use these products for any purposes prohibited by United States law, including, without limitation, the development, design, manufacture or production of nuclear, missiles, or chemical or biological weapons.
So don't go using iTunes to download the Nuclear Weapon Design Details Podcast, OK?
It says I'm hungry...
Should I get a lawyer?
Better to get some shark. They're closely related, but taste better.
I simply don't understand the whole breed of scripted languages that tossed out any kind of strong typing. I guess I can understand some quick-and-dirty batch language, and maybe that's where it comes from. Maybe they're all just descendants of csh.
It's good for sticking bits together. Those bits can be written in whatever strongly-typed language you want (I admit I like using C, but tastes vary and there's not a lot to read into the fact) but when you're making the glue to turn everything into an application, those fancy strong types tend to get more in the way than not. Use the right tool for the task and save yourself a lot of grief. (And don't forget to strongly verify the type constraints when moving from the un-/loosely-typed world of the glue to the strictly-typed world of the components.)
Language | PiTA when version X.x is no longer supported and you need to upgrade?
Tcl | yes
[...]
I haven't actually used Tcl, but I've read about it, and it's been around a long time. Perhaps this one is the most stable, but who uses it for major web sites?
It certainly used to power the main AOL site for many years (instead of that slow rubbish called Apache :-)). And indeed you're doing Tcl a disservice, since it's generally possible to upgrade from X.x to X.y (xy) without having to recompile anything at all (!) or change scripts. Stuff from 10 years ago still works just fine. (OK, it still looks like stuff from 10 years ago. But at least upgrading the language doesn't force you to rebuild the rest of the world...)
Unlike the rest of you, I am not an elitist.
You're totally above all that sort of thing and like to leave it to the hoi polloi, don't you?
That's sad.
[...]
Who in American industry is still doing basic research?
GE still is up at Niskayuna, NY.
What sort of sucessful cheaper air coniditoning solutions have you come up with?
You've already found the cheap option. Your best bet is to not skimp (unless you like cooking hardware, assuming a reasonable growth rate in computing power under your care) though some of the steps you can take (e.g. hot/cold aisles) are really just rearranging your existing kit and adding some sheet metal work. But that doesn't allow you to skimp on getting adequate cooling. (If you want to know what "adequate cooling" is, ask a real expert; the answer depends on lots of facts you've not revealed.)
Be aware that in large datacenters, the cost of keeping them cool will usually dominate. Really. Be prepared to be your A/C salesman's good customer...
If you design a web site, you want it to show up looking roughly the same on most browsers. For simplicity's sake, most people use the standard fonts (and Mac equivalents).
That's deeply foolish, you know. Users can (and do) set their own style sheets, and they are even more likely to change the size of the fonts in use. Expecting a page to look exactly as someone designed it to be is silly; "web designers" need to get used to the fact (and I've been going on about this on and off since before such a job description existed).
Every prime number has a prime number of digits in some base.
Can you prove that?
Every prime, p, consists of p digits in unary.
they'll sue eachother when the other guy builds a huge damn.
They will?
"DAMN!"
(Sue that, or remember that water is not held back by cursing...)
Most natural gas plants are small and use a lot of fuel per megawatt in comparison to things that use steam.
The UK uses quite a few gas combined cycle plants these days, due to having reasonably large gas reserves, and the fact that that those plants have really rather good efficiencies. Mind you, there's no reason why the principle of combined cycle plants can't be used with other fuels either, such as syngas, though it's probably not currently cost-effective to do so.
For if Apple wanted, they could simply ignore the ASA's ruling. Most carriers would probably refuse to run the adverts, but it's most certainly not a "government decision".
Apple could try that, but they'd find that "most carriers" would include all TV and radio stations, print media, the big hoardings, and the vast majority of web channels too. Given that, it's much more effective for Apple to recast their advert to be at least free of outright lies than anything else.
The better concern should be why pick on Apple when some much other false advertising get through the system...
The ASA only investigate when someone complains (usually a competitor, but could be anyone).
Have you considered that it maybe that the alignment of cows south to north is what causes the earth to have magnetic pole on the first place?
That's an indirect effect, since cows are not particularly magnetic. It's the alignment of the cows that imparts a spin to the planet, and that in turn generates the magnetic field. See? Much more logical!