Depends on what you use it for. The current generation is more than twice as fast. If you get work done on it and the speed makes you more productive, it's beyond the time when an upgrade will likely pay for itself. If it isn't, then you'd probably be better off with something cheaper in the first place.
First, airlocks used in space are used a few dozen times at most before being completely overhauled. The docking connector on a train like this would get more than that much use in a single day, probably in a single morning.
If you're thinking of airlocks, then you'd have to depressurise and repressurise the train at every station. If you actually mean a tube connected to equal pressures outside of the tube and inside the train, then you're assuming that the seal of something that can be attached and detached, can handle one side moving as the train bounces up and down slightly as people step on and off, and still will have zero leakage.
As the grandparent said, it depends. In dense cities, using the subway is likely to get you to your destination faster than driving in the congested streets. Take the subway from Wall Street or 5th Avenue in NYC sometime and you'll see a lot of people who could definitely afford to take a car, if it made sense for them to do so. The same is true on pretty much any of the London Underground lines.
Vertical travel is a very different proposition. Compare the energy usage for a person standing at the top of the Empire State Building and a person standing in a helicopter hovering a few metres away. Both are at the same height, but one is having to use fuel (in quite significant amounts) just to stay in the same place. Now have the man in the building go up and down the stairs for an hour and have the helicopter maintain the same height as him. At the end, compare their energy usage.
In contrast, for something like a train the majority of the energy is used in acceleration. Reducing air resistance and rolling resistance give some benefits, but it's not huge. The advantage of the hypothetical maglev vacuum train is that it can keep accelerating for as long as it wants (air resistance increases with speed). This isn't really useful for most trains, although it would be useful for something like a transatlantic or transpacific railway where you'd have a long distance and nowhere where you might want to stop on the way.
For reaching orbit, a space elevator means you don't need to carry as much fuel. Over 90% of the mass of a rocket going into orbit is the fuel required to carry the fuel into orbit. Take that away, and you've made a huge saving. If you can power the climber from the ground, it's even better. Acceleration is also an issue. A rocket must accelerate at more than 1g just to move upwards. Because of this, it must accelerate hard so that it doesn't run out of fuel just maintaining the 1g needed to stay in the same place. A climber can maintain a constant speed or a slow acceleration.
The main reason we haven't built a space elevator is that we've only recently made materials in the lab that are (probably) strong enough to be used for the tether, if we could work out how to mass produce them.
Providing these tubes are not constructed or maintained by an English water board it would suffice to pump them vacuum only once and then enjoy the fun for almost free.
Unless, of course, you want people to be able to get in and out of the trains.
It's also very dependent on the type of game. SNES-style graphics still look great today for a platform game. The 3D stuff in Duke Nukem: Manhattan Project looked better, but not better by a large enough margin to make me care from an enjoyment perspective. On the other hand, the difference between Wolfenstein 3D and Quake 1 was huge.
I'd consider Quake 1 an absolute minimum for FPS-style games if you don't want the graphics to detract from the gameplay, and that's the really important point: good graphics don't add much to the game, but really bad graphics can ruin an otherwise fun game.
Google has 33,077 employees, so the cost of imprisoning Google for one year would be around $2.3bn. This fine is about 3.5 days in prison for Google at that rate.
Note, however, that you are looking at the cost to the state of putting someone in prison, not the cost to the person. People in prison don't earn anything, but still have many of their expenses (mortgage and insurance if they have a house, storage for their possessions if they don't). Google's annual revenue is almost $40bn, so the cost to them of a year's imprisonment would be $40bn. By that metric, this is the equivalent to imprisoning them for just under 5 hours: hardly a fine of sufficient magnitude to provide an incentive not to do it again. On the other hand, I expect that the EU will fine them significantly more.
Also "real programmers" don't have degrees, but public schools require not just bachelors but masters legally to teach
Very few programmers I've met who work at Google had fewer than two degrees. I'm not sure where all of these 'real' programmers are working, but apparently not at Google.
You're certainly missing out on an experience, in much the same way that you are missing out on an experience if you've never accidentally fallen in a river.
Not really. The money Xerox made from licensing the laser printer patents covered the total costs of running PARC (for the entire time Xerox owned it) by itself. There were a few other things that, while they didn't commercialise directly, they did make lots of money from licensing (e.g. Ethernet). In contrast, MSR is largely a money sink. I can't think of anything that it's produced that's generated even $5bn - the cost of operating it for one year.
It doesn't work. Most of the exciting things I've seen from MSR have become products for Microsoft's competitors first. They have cross-licensing deals with pretty much all of the major players in the software arena that allow this.
I'm using a recent version Open Office on the Mac, is Libre Office significantly better?
I have both installed. LibreOffice recently refused to open a Word document claiming it was password protected (it wasn't), while OpenOffice worked fine. So I wouldn't say it works better. The only time I've noticed a difference, it's been worse.
I'm not even aware of viable Citrix virtualization solution.
You do know that Citrix bought XenSource a few years ago, and that most large virtualisation deployments use Xen, right? Last statistics I saw (about 6 months ago) showed Citrix had about 75% of this market.
I am currently doing an internship at Microsoft Research. There are a huge number of very innovative things on the horizon
There always are at MSR.
(which, sadly, I can't talk about),
You probably can. Most of the stuff they do gets published in conferences, journals, and so on. The problem Microsoft has always had (at least, from the early '90s onwards) is that they spend a vast amount on MSR and then only take a tiny fraction of the output and produce products. Apple, in contrast, spends nothing at all on pure research, but is very good at identifying interesting research from elsewhere and turning it into shipping products.
Don't be deceived into thinking that the shiny stuff you see at MSR is somehow new. Pick a random issue of a random computing journal from the last 20 years and you'll probably see at least one interesting paper by someone at MSR, or someone in collaboration with MSR, but you almost certainly won't see any MS products based on it. Given that MS invests about $5bn/year in MSR, I'd be shocked if they didn't produce interesting research, but that's only the first stage in creating a compelling product. The next stages are at least as important.
Oh, and I couldn't let this one pass:
(basically ML, also developed by MSR)
ML comes from Edinburgh in 1973, long before MSR existed. Ocaml, the most commonly used dialect comes from INRIA, in 1996. MSR does a lot more work on Haskell (Simon Peyton-Jones and friends) than ML-family languages.
While interesting from a technical standpoint, it's just more of the same from a business standpoint. Intel's main advantage for the last 20+ years has been being consistently one generation ahead of all competitors in process technology. This let them survive the times (e.g. P4) when their designed turned out to be inferior to the competition, by either ramping up clock speed or using higher yields to lower prices.
The other players largely do pool their resources. This is why AMD no longer has fabs. Spinning them off into Global Foundries meant that GF could get business from other customers (e.g. ARM licensees) and increase the volume to closer to the point where they can invest as much in R&D as Intel. Intel is in a good position because they sell a large volume of relatively high margin chips. If Intel invested 10% of their operating income in R&D, AMD would not be able to match them, even if they invested 100% of theirs.
It will work if SomeProgram is an X program, just as it does on OS X or Windows if you have an X server installed. It won't work if SomeProgram is a Wayland program. Wayland eliminates a number of process boundaries in X, moving the window and compositing managers into the main executable. This is done for performance reasons, presumably by people who have never profiled an X server and therefore not noticed that these round trips are not a bottleneck in modern systems, and at the expense of stability (if your compositing manager crashes in Wayland, your display server also dies, with X11 it can be restarted, usually without any data loss).
noexec only disables things that the kernel runs directly. It doesn't disable scripts if you invoke them via the correct command interpreter and it certainly doesn't protect you against, for example, a libpng or libjpeg exploit and a malicious image.
Nope, that was the StepStone compiler. The initial GCC implementation did not.
Actually, rereading what you said, it was never true:
Not initially actually, initially the implementation was purely CPP macros
Brad Cox's original Portable Object Compiler was written as CPP macros. The first Objective-C compiler was a preprocessor that generated C code, but it was not implemented as CPP macros, it had a custom parser. A C preprocessor macro can not match [a b: c] and turn it into anything.
I read the Smalltalk 80 book a long time ago, but I seem to recall that the state of an object was "public" in the C++ or Java sense of the term
Nope, it's protected. Smalltalk does not provide any syntax for accessing the instance variables of another object. There is no obj.ivar or obj->ivar. Instance variables appear in the symbol table and can only be accessed from the current object. The idea of object orientation is simple: small models of computers that communicate by message passing. Computers can't (usually) see the implementation details of other computers that they communicate with...
A lot of toolkits now generate JavaScript automatically from your server-side code, so the number of people that need to write it by hand decreases, in much the same way that few people need to write assembly by hand now that compilers exist.
Slashdot Mirror
Oracle likes you to buy their products just once. It's only the paying thing that they want you to do as frequently as possible.
Depends on what you use it for. The current generation is more than twice as fast. If you get work done on it and the speed makes you more productive, it's beyond the time when an upgrade will likely pay for itself. If it isn't, then you'd probably be better off with something cheaper in the first place.
First, airlocks used in space are used a few dozen times at most before being completely overhauled. The docking connector on a train like this would get more than that much use in a single day, probably in a single morning.
If you're thinking of airlocks, then you'd have to depressurise and repressurise the train at every station. If you actually mean a tube connected to equal pressures outside of the tube and inside the train, then you're assuming that the seal of something that can be attached and detached, can handle one side moving as the train bounces up and down slightly as people step on and off, and still will have zero leakage.
As the grandparent said, it depends. In dense cities, using the subway is likely to get you to your destination faster than driving in the congested streets. Take the subway from Wall Street or 5th Avenue in NYC sometime and you'll see a lot of people who could definitely afford to take a car, if it made sense for them to do so. The same is true on pretty much any of the London Underground lines.
Vertical travel is a very different proposition. Compare the energy usage for a person standing at the top of the Empire State Building and a person standing in a helicopter hovering a few metres away. Both are at the same height, but one is having to use fuel (in quite significant amounts) just to stay in the same place. Now have the man in the building go up and down the stairs for an hour and have the helicopter maintain the same height as him. At the end, compare their energy usage.
In contrast, for something like a train the majority of the energy is used in acceleration. Reducing air resistance and rolling resistance give some benefits, but it's not huge. The advantage of the hypothetical maglev vacuum train is that it can keep accelerating for as long as it wants (air resistance increases with speed). This isn't really useful for most trains, although it would be useful for something like a transatlantic or transpacific railway where you'd have a long distance and nowhere where you might want to stop on the way.
For reaching orbit, a space elevator means you don't need to carry as much fuel. Over 90% of the mass of a rocket going into orbit is the fuel required to carry the fuel into orbit. Take that away, and you've made a huge saving. If you can power the climber from the ground, it's even better. Acceleration is also an issue. A rocket must accelerate at more than 1g just to move upwards. Because of this, it must accelerate hard so that it doesn't run out of fuel just maintaining the 1g needed to stay in the same place. A climber can maintain a constant speed or a slow acceleration.
The main reason we haven't built a space elevator is that we've only recently made materials in the lab that are (probably) strong enough to be used for the tether, if we could work out how to mass produce them.
Providing these tubes are not constructed or maintained by an English water board it would suffice to pump them vacuum only once and then enjoy the fun for almost free.
Unless, of course, you want people to be able to get in and out of the trains.
It's also very dependent on the type of game. SNES-style graphics still look great today for a platform game. The 3D stuff in Duke Nukem: Manhattan Project looked better, but not better by a large enough margin to make me care from an enjoyment perspective. On the other hand, the difference between Wolfenstein 3D and Quake 1 was huge.
I'd consider Quake 1 an absolute minimum for FPS-style games if you don't want the graphics to detract from the gameplay, and that's the really important point: good graphics don't add much to the game, but really bad graphics can ruin an otherwise fun game.
Google has 33,077 employees, so the cost of imprisoning Google for one year would be around $2.3bn. This fine is about 3.5 days in prison for Google at that rate.
Note, however, that you are looking at the cost to the state of putting someone in prison, not the cost to the person. People in prison don't earn anything, but still have many of their expenses (mortgage and insurance if they have a house, storage for their possessions if they don't). Google's annual revenue is almost $40bn, so the cost to them of a year's imprisonment would be $40bn. By that metric, this is the equivalent to imprisoning them for just under 5 hours: hardly a fine of sufficient magnitude to provide an incentive not to do it again. On the other hand, I expect that the EU will fine them significantly more.
Also "real programmers" don't have degrees, but public schools require not just bachelors but masters legally to teach
Very few programmers I've met who work at Google had fewer than two degrees. I'm not sure where all of these 'real' programmers are working, but apparently not at Google.
You're certainly missing out on an experience, in much the same way that you are missing out on an experience if you've never accidentally fallen in a river.
Not really. The money Xerox made from licensing the laser printer patents covered the total costs of running PARC (for the entire time Xerox owned it) by itself. There were a few other things that, while they didn't commercialise directly, they did make lots of money from licensing (e.g. Ethernet). In contrast, MSR is largely a money sink. I can't think of anything that it's produced that's generated even $5bn - the cost of operating it for one year.
It doesn't work. Most of the exciting things I've seen from MSR have become products for Microsoft's competitors first. They have cross-licensing deals with pretty much all of the major players in the software arena that allow this.
I'm using a recent version Open Office on the Mac, is Libre Office significantly better?
I have both installed. LibreOffice recently refused to open a Word document claiming it was password protected (it wasn't), while OpenOffice worked fine. So I wouldn't say it works better. The only time I've noticed a difference, it's been worse.
I'm not even aware of viable Citrix virtualization solution.
You do know that Citrix bought XenSource a few years ago, and that most large virtualisation deployments use Xen, right? Last statistics I saw (about 6 months ago) showed Citrix had about 75% of this market.
Traditionally, the sequence with regard to MS has been:
Actually, the ??? is probably not needed...
I am currently doing an internship at Microsoft Research. There are a huge number of very innovative things on the horizon
There always are at MSR.
(which, sadly, I can't talk about),
You probably can. Most of the stuff they do gets published in conferences, journals, and so on. The problem Microsoft has always had (at least, from the early '90s onwards) is that they spend a vast amount on MSR and then only take a tiny fraction of the output and produce products. Apple, in contrast, spends nothing at all on pure research, but is very good at identifying interesting research from elsewhere and turning it into shipping products.
Don't be deceived into thinking that the shiny stuff you see at MSR is somehow new. Pick a random issue of a random computing journal from the last 20 years and you'll probably see at least one interesting paper by someone at MSR, or someone in collaboration with MSR, but you almost certainly won't see any MS products based on it. Given that MS invests about $5bn/year in MSR, I'd be shocked if they didn't produce interesting research, but that's only the first stage in creating a compelling product. The next stages are at least as important.
Oh, and I couldn't let this one pass:
(basically ML, also developed by MSR)
ML comes from Edinburgh in 1973, long before MSR existed. Ocaml, the most commonly used dialect comes from INRIA, in 1996. MSR does a lot more work on Haskell (Simon Peyton-Jones and friends) than ML-family languages.
While interesting from a technical standpoint, it's just more of the same from a business standpoint. Intel's main advantage for the last 20+ years has been being consistently one generation ahead of all competitors in process technology. This let them survive the times (e.g. P4) when their designed turned out to be inferior to the competition, by either ramping up clock speed or using higher yields to lower prices.
The other players largely do pool their resources. This is why AMD no longer has fabs. Spinning them off into Global Foundries meant that GF could get business from other customers (e.g. ARM licensees) and increase the volume to closer to the point where they can invest as much in R&D as Intel. Intel is in a good position because they sell a large volume of relatively high margin chips. If Intel invested 10% of their operating income in R&D, AMD would not be able to match them, even if they invested 100% of theirs.
It will work if SomeProgram is an X program, just as it does on OS X or Windows if you have an X server installed. It won't work if SomeProgram is a Wayland program. Wayland eliminates a number of process boundaries in X, moving the window and compositing managers into the main executable. This is done for performance reasons, presumably by people who have never profiled an X server and therefore not noticed that these round trips are not a bottleneck in modern systems, and at the expense of stability (if your compositing manager crashes in Wayland, your display server also dies, with X11 it can be restarted, usually without any data loss).
noexec only disables things that the kernel runs directly. It doesn't disable scripts if you invoke them via the correct command interpreter and it certainly doesn't protect you against, for example, a libpng or libjpeg exploit and a malicious image.
Brad Cox's original Portable Object Compiler
And I should read what I wrote before hitting submit. This should read Object Oriented Precompiler (OOPC), from the 1983 SIGPLAN paper.
Nope, that was the StepStone compiler. The initial GCC implementation did not.
Actually, rereading what you said, it was never true:
Not initially actually, initially the implementation was purely CPP macros
Brad Cox's original Portable Object Compiler was written as CPP macros. The first Objective-C compiler was a preprocessor that generated C code, but it was not implemented as CPP macros, it had a custom parser. A C preprocessor macro can not match [a b: c] and turn it into anything.
Not initially actually, initially the implementation was purely CPP macros.
Nope, that was the StepStone compiler. The initial GCC implementation did not.
Incorrect, at no point is the objective-c code rewritten into C code, it is compiled directly to LLVM IR, not via any other language.
I never said it was in the standard compilation pipeline, I said:
That doesn't, however, alter the grandparent's point. There is a rewriter in clang that will translate Objective-C into C.
If you don't believe me, run clang -rewrite-objc and look at the output. Seriously, I wrote some of this code, I know it exists...
The fact that C function calls are inserted does not magically make it a conversion into C code
The question is whether Objective-C can be implemented in C.
I read the Smalltalk 80 book a long time ago, but I seem to recall that the state of an object was "public" in the C++ or Java sense of the term
Nope, it's protected. Smalltalk does not provide any syntax for accessing the instance variables of another object. There is no obj.ivar or obj->ivar. Instance variables appear in the symbol table and can only be accessed from the current object. The idea of object orientation is simple: small models of computers that communicate by message passing. Computers can't (usually) see the implementation details of other computers that they communicate with...
A lot of toolkits now generate JavaScript automatically from your server-side code, so the number of people that need to write it by hand decreases, in much the same way that few people need to write assembly by hand now that compilers exist.
In Simula, every function was a closure and classes were functions that returned themselves. C++ got a half-arsed attempt at closures last year.