For example, [in their model] gravity is actually caused by the flat plane of the Earth accelerating. To which, somebody might ask, "Wouldn't we accelerate to the speed of light?" Well, no, because acceleration is asymptotic in their reference frame. What they don't answer is, "Wouldn't you need infinite energy to keep accelerating and where does this energy come from?"
Actually, even in conventional (i.e. Einsteinian) reference frames you can still accelerate at a constant rate for infinitely long because your mass increases asymptotically as your velocity increases towards the speed of light.
Your point about the infinite energy is a good one though.
Linux-based systems offer an entirely different breed of "security through obscurity", but it's still just obscurity.
There is one advantage that Linux-based (and other Unix-based) systems typically have, and it's not the kernel at all. The key is actually two parts: 1) a smaller default service exposure profile, and 2) a long history and culture of minimizing user privileges. Neither are particularly magic, but they do tend to make big differences overall. (There are a few other important bits too, like default non-executability and a tendency among application authors to avoid "throwing stuff over the wall", but they're lesser that the two above.) There is no reason why Windows couldn't be like this by default - Vista's a lot closer to it than previous versions FWIW - but its history tends to mean that many user-desired applications are still forcing a lack of good security practices.
Good security is a matter of defense-in-depth and getting all the bits right. In turn, that means that "inherently secure" is a bogus phrase anyway.
Northern New England corridor : Boston, Montreal, Portland, Springfield, New Haven, Albany
Unlike many of the posters here, I don't think that the Presidency has forgotten the West Coast, given that they identify two corridors in that list...
Hell with high speed. 99.9978% of americans dont need to go from NY to LA via high speed rail.
You are aware that the Obama plan says nothing about high-speed transcontinental railroads? (Yes, I did RTFA.) They're not cost-effective and at that sort of distance the plane makes a bunch of good sense.
OTOH, there are plenty of other trips - trips which many more people do too - where rail damn well should be competitive. Boston and NY are only around 200 miles apart; a 90 minute rail journey should be achievable there and would be very competitive (especially if trivial things like wifi and a restaurant car are added). Indeed, at those distances the competitor isn't the plane, but rather the car. I prefer to take the train to driving, since that leaves me much more relaxed than putting up with heavy traffic would...
Another fun fact: if you started in London and went the same distance it takes to get from Atlanta to New York (750 miles / 1207 km), you'd be halfway to Moscow. That's the difference in scale between Europe and the U.S.!
You mean it'd be a bit like going to Barcelona or Warsaw from London? (And Europe extends a long way east of Moscow, though I don't intend to go that way in a hurry...)
FWIW, the NY/Chicago distance is also of around that order and there's quite a few places of some size in between. Surely there'd be good grounds for the eastern half of the US to do better than at present, especially as there's lots of it that's plenty dense enough. Plus there's got to be smaller scale projects where high-speed rail makes sense: for example, connecting major airports to their cities so that people don't have to suffer traffic or an interminable commuter line. (Chicago, I'm looking at you here. The line to O'Hare is abysmal, and the freeway really isn't much better either.)
Isn't this what the Storm botnet and the conflicker botnet are doing already?
Not really. The supercomputers and high-end clusters used for this sort of service have much better (i.e., lower) inter-node latency than any botnet could ever hope to achieve, and there's a lot of problems out there that need that (only a minority parallelize as well as a typical BOINC task or botnet DDoS attack).
Problem is, that's not actually the URL that goes in the title bar and also isn't the URL that's going to get bookmarked in most cases.
OTOH, I worry that this mechanism (rev=canonical) will be abused by people wanting to stop "deep linking", thinking that just because they want everyone to fight through pages of ads, they have a right to prevent everyone else from jumping straight to the chase. While I appreciate the suggestion from the author of the site, I don't want them hijacking what I actually bookmark.
(BTW, is there a registry of all these various rel/rev types?)
not a url issue. There's no reason they couldn't parameterize it with a more legible url like developers.slashdot.org/comments/119647 by parsing and then interpreting the url.
Stop saying such heresies! They're what sensible people would do rather than exposing the details of how they implement their site to all and sundry. Such thoughts are not permitted otherwise people will start being sensible, cats and dogs will start loving each other, and the world will end in a whimper!
In some countries, people pay for recieving texts. In the UK, normally recieving texts is free, except some online services manage to charge you by sending you texts, not entirely sure how that works.
It's a special service that you have to opt into; you really should know if you're receiving those things and there should be a simple mechanism to turn off reception of them again.
(There are anti-fraud mechanisms built in to the UK system, AIUI mainly a delay of several months between the message getting sent and the cash being disbursed to the sender. That means that if someone tries anything too tricky, the receiver can dispute the charges and the money can be stopped if shenanigans are detected on investigation.)
Park your Civic in the garage tonight, and hit the button that tells it to drive itself to the gas station, fill-up, and return before you wake up in the morning...
Plus, in some parts of the world most of the infrastructure to support at-lot charging is already in place. In much of Sweden, for example, there are electric points in parking lots to allow people to keep their engines warm overnight (an issue in winter) and I'd be startled if nowhere else had this.
Dynamic code and dynamic linking have no meaning. Neither does self-modifying code, although that tends to be rather rare these days.
In important senses, self-modifying code is still in major use. Even with C and C++, it's important as it is the key to how modern debuggers work.
If someone were to take the MMk1 design and add the necessary opcodes and memory, you COULD run Linux (with kernel module support) on it.
Apart from needing a lot more memory, Linux (like all other modern OSes outside the embedded space) also needs virtual memory, which wasn't invented until a few generations of machine - i.e. about a decade - later.
Turing and Kilburn were absolute geniuses in that they did not over-optimize their machine but built something totally generic and then only implemented as much as they needed.
We also shouldn't forget Frederick Williams (a professor of electronic engineering) who was important to its development. It was he who saw what was going on in the USA prior to that and how limited it really was.
And to think that it was really only built to test the memory system they were using (a special kind of CRT tube). It was just a testbed that got out of hand...
If it is just for a temporary cache, wouldn't RAM give you a bigger speed up than Flash?
Sure, but you have the worry about losing it to a backhoe incident. Sure, a UPS is a good idea but getting the data to non-volatile storage sooner lets you complete the database commit faster. (And anyway, a UPS system for a high-end server deployment is a major chunk of hardware anyway, and there's always the worry that the UPS is going to fail at the wrong moment...)
stable. n. resistant to change of position or condition.
Indeed.
Sometimes, stable is good. I prefer having my house built on stable ground, and I prefer standard libraries to have stable ABIs so I don't have to recompile everything every time a system upgrade blows through. OTOH, "stable" is sometimes a codeword for "sclerotic". I suppose ones view on stability depends on whether one has a direct interest in the stable thing or not.
If it's to save money... maybe they should try not leaving all several hundred of our puplic computers on all night, and for the whole summer and winter vacations!
You are aware that those lab machines will probably be running Condor or BOINC during that time? Just because the machine isn't in use by someone sitting at it doesn't mean that it's doing nothing useful.
Not necessarily; there are plenty of application areas where you can easily design your data structures and access rules so that multiple threads accessing them are not a problem. Consider the application I'm currently working on, a parallel artificial neural network trainer. I have one copy of the weights, and 4 threads with a different training set each. Each runs through its training set, totalling changes to make to the weights, then passes [a pointer to] those changes off to a coordinator thread which waits until all 4 have finished before adjusting the weights and then telling them to resume with the next epoch. The weight matrix is in the range of 50-100MB, so we really don't want to have to copy it each time around. This is a much more efficient way of achieving this result than anything I can think of without shared data, and I'd love to know if anyone else can see a better solution.
Sounds like a reasonable medium-scale approach to me - I've done similar things. But you are aware that you're, in effect, using a locking solution? And that shared memory scheme won't scale up to a cluster? (To scale it up, consider whether you can only transmit the diffs to the weight table or change the axis on which you're splitting things up so that you get better data locality. Another possibility might be to compute the weights twice or more in different threads, which trades more computation for less lock contention. Don't know which is right for your case though, since scaling up isn't easy; requires real thought sometimes.)
I suppose it might help you to have a bit more background. In many types of traditional supercomputer, a lot of effort was put into supporting a shared memory model over very large numbers of processors (e.g., a thousand or so). That's really what made them so stupendously expensive, especially through the '90s. (The CPUs themselves weren't that much better than normal desktop ones by comparison; better floating point units typically, but not by that much.) Of course, it wasn't sustainable; the memory hardware was just too much of a bottleneck (in effect there was a lock for every memory access!) so that had to go and the cluster is now king. But to take proper advantage of that, you have to start minimizing the amount of locking and communication of big memory structures; get that right (with clever algorithms, etc.) and you can go up to internet-scale apps, some of which are so big that we don't usually think of them that way.
That's funny, because os.fork() etc. work fine on my version of python.
Yes, but then the overhead of serializing data structures to communicate between your two processes is a killer. Unless you can keep the communication to a minimum (i.e., you're working on an embarassingly parallel problem), this is a serious problem.
It's a problem anyway. If you have structures that are being accessed by two threads at once, you need a lock (or your head examining; your choice) to stop demons from flying out of your nose. Your best approach is to keep as much as possible bound to a single thread, and to only share the minimum, preferably keeping chunks of memory assigned to a single thread or, at least, one at a time. That minimizes the number of nasty global locks.
Be aware that if you want to scale up to systems that do not share memory (e.g. a clustered supercomputer) then you have to think in terms of serializing data structures anyway (or using an MPI library that hides the details); you'll spend your time trying to work out how to minimize the amount of communication you do. Ultimately, the piper must be paid.
Slashdot Mirror
For example, [in their model] gravity is actually caused by the flat plane of the Earth accelerating. To which, somebody might ask, "Wouldn't we accelerate to the speed of light?" Well, no, because acceleration is asymptotic in their reference frame. What they don't answer is, "Wouldn't you need infinite energy to keep accelerating and where does this energy come from?"
Actually, even in conventional (i.e. Einsteinian) reference frames you can still accelerate at a constant rate for infinitely long because your mass increases asymptotically as your velocity increases towards the speed of light.
Your point about the infinite energy is a good one though.
Linux-based systems offer an entirely different breed of "security through obscurity", but it's still just obscurity.
There is one advantage that Linux-based (and other Unix-based) systems typically have, and it's not the kernel at all. The key is actually two parts: 1) a smaller default service exposure profile, and 2) a long history and culture of minimizing user privileges. Neither are particularly magic, but they do tend to make big differences overall. (There are a few other important bits too, like default non-executability and a tendency among application authors to avoid "throwing stuff over the wall", but they're lesser that the two above.) There is no reason why Windows couldn't be like this by default - Vista's a lot closer to it than previous versions FWIW - but its history tends to mean that many user-desired applications are still forcing a lack of good security practices.
Good security is a matter of defense-in-depth and getting all the bits right. In turn, that means that "inherently secure" is a bogus phrase anyway.
In other words, if the speed of traffic is 80 mph and the speed limit is 65 mph, which do they use?
The "haha we gotcha now speeders!" speed-camera sign?
Everyone here is talking about the northeast and midwest, what about the damned west coast?
Karma-whore time! FTA:
Unlike many of the posters here, I don't think that the Presidency has forgotten the West Coast, given that they identify two corridors in that list...
Hell with high speed. 99.9978% of americans dont need to go from NY to LA via high speed rail.
You are aware that the Obama plan says nothing about high-speed transcontinental railroads? (Yes, I did RTFA.) They're not cost-effective and at that sort of distance the plane makes a bunch of good sense.
OTOH, there are plenty of other trips - trips which many more people do too - where rail damn well should be competitive. Boston and NY are only around 200 miles apart; a 90 minute rail journey should be achievable there and would be very competitive (especially if trivial things like wifi and a restaurant car are added). Indeed, at those distances the competitor isn't the plane, but rather the car. I prefer to take the train to driving, since that leaves me much more relaxed than putting up with heavy traffic would...
Another fun fact: if you started in London and went the same distance it takes to get from Atlanta to New York (750 miles / 1207 km), you'd be halfway to Moscow. That's the difference in scale between Europe and the U.S.!
You mean it'd be a bit like going to Barcelona or Warsaw from London? (And Europe extends a long way east of Moscow, though I don't intend to go that way in a hurry...)
FWIW, the NY/Chicago distance is also of around that order and there's quite a few places of some size in between. Surely there'd be good grounds for the eastern half of the US to do better than at present, especially as there's lots of it that's plenty dense enough. Plus there's got to be smaller scale projects where high-speed rail makes sense: for example, connecting major airports to their cities so that people don't have to suffer traffic or an interminable commuter line. (Chicago, I'm looking at you here. The line to O'Hare is abysmal, and the freeway really isn't much better either.)
Poyntee ends can eggsplayn anyfing tu anywun beri beri eezily. Paynfully but eezily.
Explaining a lolcat, not in lolcat.
Isn't this what the Storm botnet and the conflicker botnet are doing already?
Not really. The supercomputers and high-end clusters used for this sort of service have much better (i.e., lower) inter-node latency than any botnet could ever hope to achieve, and there's a lot of problems out there that need that (only a minority parallelize as well as a typical BOINC task or botnet DDoS attack).
http://developers.slashdot.org/comments.pl?sid=1196477
Problem is, that's not actually the URL that goes in the title bar and also isn't the URL that's going to get bookmarked in most cases.
OTOH, I worry that this mechanism (rev=canonical) will be abused by people wanting to stop "deep linking", thinking that just because they want everyone to fight through pages of ads, they have a right to prevent everyone else from jumping straight to the chase. While I appreciate the suggestion from the author of the site, I don't want them hijacking what I actually bookmark.
(BTW, is there a registry of all these various rel/rev types?)
not a url issue. There's no reason they couldn't parameterize it with a more legible url like developers.slashdot.org/comments/119647 by parsing and then interpreting the url.
Stop saying such heresies! They're what sensible people would do rather than exposing the details of how they implement their site to all and sundry. Such thoughts are not permitted otherwise people will start being sensible, cats and dogs will start loving each other, and the world will end in a whimper!
In some countries, people pay for recieving texts. In the UK, normally recieving texts is free, except some online services manage to charge you by sending you texts, not entirely sure how that works.
It's a special service that you have to opt into; you really should know if you're receiving those things and there should be a simple mechanism to turn off reception of them again.
(There are anti-fraud mechanisms built in to the UK system, AIUI mainly a delay of several months between the message getting sent and the cash being disbursed to the sender. That means that if someone tries anything too tricky, the receiver can dispute the charges and the money can be stopped if shenanigans are detected on investigation.)
I say dig up the old Project Orion files and let's start getting serious about space exploration and colonization.
If we're filling the atmosphere with that much post-detonation material, we'll have to be really serious about colonization...
The Hungarian army couldn't take over Heathrow Airport, so that's understandable.
A lesser known fact is that they tried a few years ago, but are still waiting for their bags to arrive...
Park your Civic in the garage tonight, and hit the button that tells it to drive itself to the gas station, fill-up, and return before you wake up in the morning...
Plus, in some parts of the world most of the infrastructure to support at-lot charging is already in place. In much of Sweden, for example, there are electric points in parking lots to allow people to keep their engines warm overnight (an issue in winter) and I'd be startled if nowhere else had this.
My dog is offended. He worked hard to learn how to twitter.
Life's a bitch.
Or at least he hopes it is.
I just can't be more excited. I think I'm going to take my wife this weekend to get some Vindaloo!
That's breakfast sorted then...
Dynamic code and dynamic linking have no meaning. Neither does self-modifying code, although that tends to be rather rare these days.
In important senses, self-modifying code is still in major use. Even with C and C++, it's important as it is the key to how modern debuggers work.
If someone were to take the MMk1 design and add the necessary opcodes and memory, you COULD run Linux (with kernel module support) on it.
Apart from needing a lot more memory, Linux (like all other modern OSes outside the embedded space) also needs virtual memory, which wasn't invented until a few generations of machine - i.e. about a decade - later.
Turing and Kilburn were absolute geniuses in that they did not over-optimize their machine but built something totally generic and then only implemented as much as they needed.
We also shouldn't forget Frederick Williams (a professor of electronic engineering) who was important to its development. It was he who saw what was going on in the USA prior to that and how limited it really was.
And to think that it was really only built to test the memory system they were using (a special kind of CRT tube). It was just a testbed that got out of hand...
If it is just for a temporary cache, wouldn't RAM give you a bigger speed up than Flash?
Sure, but you have the worry about losing it to a backhoe incident. Sure, a UPS is a good idea but getting the data to non-volatile storage sooner lets you complete the database commit faster. (And anyway, a UPS system for a high-end server deployment is a major chunk of hardware anyway, and there's always the worry that the UPS is going to fail at the wrong moment...)
Change your /. prefs. Other than the sometimes lame colors they use, I don't see any of that silliness, once I'm logged in.
Alas, it still sometimes slips through. The firehose and metamoderation interfaces are particularly lame that way.
Solaris is more stable than Linux.
stable. n. resistant to change of position or condition.
Indeed.
Sometimes, stable is good. I prefer having my house built on stable ground, and I prefer standard libraries to have stable ABIs so I don't have to recompile everything every time a system upgrade blows through. OTOH, "stable" is sometimes a codeword for "sclerotic". I suppose ones view on stability depends on whether one has a direct interest in the stable thing or not.
Windows doesn't run on ARM.
Windows CE does.
So, the problem wasn't that God was playing dice with the universe, rather, it's just a nice Julia set?
Actually, it's just that God's dice have a complex number of sides.
If it's to save money... maybe they should try not leaving all several hundred of our puplic computers on all night, and for the whole summer and winter vacations!
You are aware that those lab machines will probably be running Condor or BOINC during that time? Just because the machine isn't in use by someone sitting at it doesn't mean that it's doing nothing useful.
Not necessarily; there are plenty of application areas where you can easily design your data structures and access rules so that multiple threads accessing them are not a problem. Consider the application I'm currently working on, a parallel artificial neural network trainer. I have one copy of the weights, and 4 threads with a different training set each. Each runs through its training set, totalling changes to make to the weights, then passes [a pointer to] those changes off to a coordinator thread which waits until all 4 have finished before adjusting the weights and then telling them to resume with the next epoch. The weight matrix is in the range of 50-100MB, so we really don't want to have to copy it each time around. This is a much more efficient way of achieving this result than anything I can think of without shared data, and I'd love to know if anyone else can see a better solution.
Sounds like a reasonable medium-scale approach to me - I've done similar things. But you are aware that you're, in effect, using a locking solution? And that shared memory scheme won't scale up to a cluster? (To scale it up, consider whether you can only transmit the diffs to the weight table or change the axis on which you're splitting things up so that you get better data locality. Another possibility might be to compute the weights twice or more in different threads, which trades more computation for less lock contention. Don't know which is right for your case though, since scaling up isn't easy; requires real thought sometimes.)
I suppose it might help you to have a bit more background. In many types of traditional supercomputer, a lot of effort was put into supporting a shared memory model over very large numbers of processors (e.g., a thousand or so). That's really what made them so stupendously expensive, especially through the '90s. (The CPUs themselves weren't that much better than normal desktop ones by comparison; better floating point units typically, but not by that much.) Of course, it wasn't sustainable; the memory hardware was just too much of a bottleneck (in effect there was a lock for every memory access!) so that had to go and the cluster is now king. But to take proper advantage of that, you have to start minimizing the amount of locking and communication of big memory structures; get that right (with clever algorithms, etc.) and you can go up to internet-scale apps, some of which are so big that we don't usually think of them that way.
That's funny, because os.fork() etc. work fine on my version of python.
Yes, but then the overhead of serializing data structures to communicate between your two processes is a killer. Unless you can keep the communication to a minimum (i.e., you're working on an embarassingly parallel problem), this is a serious problem.
It's a problem anyway. If you have structures that are being accessed by two threads at once, you need a lock (or your head examining; your choice) to stop demons from flying out of your nose. Your best approach is to keep as much as possible bound to a single thread, and to only share the minimum, preferably keeping chunks of memory assigned to a single thread or, at least, one at a time. That minimizes the number of nasty global locks.
Be aware that if you want to scale up to systems that do not share memory (e.g. a clustered supercomputer) then you have to think in terms of serializing data structures anyway (or using an MPI library that hides the details); you'll spend your time trying to work out how to minimize the amount of communication you do. Ultimately, the piper must be paid.