It doesn't matter which OS you install, if it's out of date then you're vulnerable.
Actually, no. Most Linux distributions dating from the same vintage as XP will not let you get remotely raped out-of-the-box.
If you start up Apache or rsyncd then you might be in trouble, but merely acting as a client is not enough for somebody to root you. It's been a long long time since there was an attack that could take over a client that's not accepting any connections and is just downloading from trusted servers.
I kind of agree, but I think you are stretching the definition of API a bit too far. From a certain point of view, anything you need can be written on a Turing machine, and they're even older than Unix.
Suppose I want to display nicely rendered multilingual text. Not such an outrageous requirement, I think. But only in the last few years have there been any reasonable Unix APIs to do so. Working unicode support throughout the toolkit and in window managers is only a few years old.
I think the core issue is that Linux doesn't have the "fire and motion" imperative that Microsoft does. Developers do break interfaces from time to time, but they generally only do it when there is a technical imperative, not just because they want to force upgrades.
You have made clear you don't have a solid idea of what C++ code generation looks like.
I don't know about the original poster, but I think I have a moderately good idea. What is different in the code generation between creation of an object on the heap and on the stack? Inquiring minds yearn to know.
Surely the same constructors gets called the same way? The only difference is whether the allocator gets called, or alternatively that the stack registers are frobbed.
Why would you not want objects on the stack? It's not like we're in kernel mode where there is only a small stack. In Linux userspace it is fine to put several k on the stack.
Perhaps you're saying that a large object might have an expensive constructor? But that is equally much of a problem if it's constructed with new/delete. The solution is not to create/destroy it from inside the function. It doesn't matter whether it's on the heap or not.
Agreed, but how much of that "high-end Solaris" is under SCO license restrictions?
Great question. Probably some substantial part of it is covered, if Sun thought it was worth paying $100M for it over the years.
So here's a good question for people looking at Solaris: do you really want to be using a technology licenced from litigious bastards who might try to change the licencing terms, or sue end users at any point, and who believe that "contracts are something you use against partners"? Or would you rather have a nice Unix that's been extensively and expensively proved to be absolutely free of SCO code? The second looks much less risky to me.
Leaving aside the results or whether the benchmark is meaningful, his presentation of the results in the graph is truly awful. The one large spike for Method Call/Server JVM is so large that all the other results are nearly visually indistinguishable.
He admits he couldn't write a script to automate the tests. That does not inspire confidence in his ability to assess programming languages.
I think an even better rule of thumb is to buy one step down from what you can afford. You're likely to suffer a bit less of a novelty premium and it will still last almost as long.
So for example at the moment (in AU) 250GB ATA/SATA drives are affordable, but going down to just 200GB is 35-40% cheaper and only 20% smaller. Either one will likely last two-three years, at which point I'll probably replace it with something in the 500-900GB range.
(Insert tentacle porn reference below this line:) -o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o -o-
A judge told them to stop making outrageous public statements (search Groklaw). Sadly, they complied. Darl in prison for Contempt of Court would have been a happy sight.
Specifically he says lots of copyright infringement happens, but he can't find even one single example of it. Can you? No, I didn't think so.
What KB might have been trying to say is that it's not a fun thought for a corp to make a new piece of software if the OSS community is going to work feverishly to try to make a free substitute.
Boo hoo hoo. If it wasn't open source hackers trying to beat it then it would be Microsoft or some other company. Any successful product attracts competitors. Do you see HP whining about Dell selling printers? Do you think it's fun for Sony that the XBox exists?
If your company can't manage to make something better than what can be produced by hobbyists working on evenings and weekends then you don't deserve to survive.
Hitler produced (mediocre) drawings, and tried to make a living at it. That's a better definition of an artist, than whether they went to art school. Does anyone care whether Hitler went to tyrant school?
Well, in a way you do. Most complex products (cars, ASICs, software, maybe even bridges) are built these days by buying/licensing/borrowing/copying designs from someone else and kludging them together. The added value is in picking the right parts and getting them to work together, just as for open source.
Not that I think the open source market is properly developed. There is no really good way yet for you to pay $x to get the linker quality improved, other than hiring someone or learning it yourself.
I think you mean, "divert attention *from* their own death." Why else make such wacky and schizophrenic pronouncements every month?
As soon as MS made any sign of taking over Sun, McNealy would opensource just about everything... and kill the takeover, thereby losing his golden parachute from Microsoft and opening up a shareholder suit? I don't think so.
I'll just add that any low-G accelerator implies that you'll be launching at a low elevation, unless you plan to dig a shaft hundreds of km into the earth. This increases the distance you have to travel through the atmosphere, and therefore the amount of wasted energy.
It is one thing for a 747 to carry an empty shuttle, and quite another for it to carry one with enough rocket fuel to get from FL100 to orbit, plus its payload and crew.
The takeoff mass of the shuttle is about 2,000 metric tonnes, and the landing mass is only 100 tonnes. (Source: wikipedia). That's a big difference! 1900 tonnes, or 95% of the mass is burnt or otherwise used in getting up there. This is pretty typical of orbital systems: the higher you want to go, the more of your mass you need to burn to get there, and therefore the larger the system needs to be to carry a useful payload. Starting above sea level would help, but you'd still need hundreds of tonnes of fuel.
The shuttle currently needs the external fuel tank and rocket boosters, which are not transported on the 747 and would get in the way of mounting it. Maybe you could do without the boosters if you started from FL100. But I think the shuttle doesn't have much onboard fuel, so you still need the big tank.
The maximum payload of a 747-400 is only 150 tonnes, and that's a more modern plane than the 747-100 currently used as a shuttle carrier. That number is calculated without the extra drag of a whole other aircraft sitting on the back, so I think carrying even an empty shuttle must be close to the limit. Carrying one with even half the required fuel would be impractical. Even if you put the shuttle on a superjumbo, the amount of fuel to drag a shuttle up to launch altitude would be enormous.
While a 747 may be able to fly inverted I don't know if it would be able to do so with a shuttle strapped on the back. Could the shuttle detach and roll upright, while fully loaded with fuel? It's not designed to be the most manueverable aircraft, even when empty. I would suspect it would drop like a stone when fully fuelled.
I think the reason the SpaceShipOne is feasible is that it's a much smaller craft and they don't go all the way to orbit.
I would interpret that as showing that Kodak's attempt was lame, rather than that the idea of a programmable OS is bad.
Making a device programmable tends to be an exercise where if you don't make it good enough, people won't get excited and it will just flop. You need to develop a virtuous cycle where there is a community of developers producing enough interesting stuff to make more people interested.
It's not necessarily exactly cheaper. The hardware does have a significant cost, which is soaked up by the manufacturer unless/until the customer turns it on.
I think the point is more that you can sell it to them immediately when the want it -- a kind of corporate impulse shopping.
If I know that adding more CPUs is going to require ordering them, arranging downtime, bringing the machine down, physically installing the CPUs, bringing it back up and hoping nothing broke then I might think twice, and try to get by without it for a bit longer. If all I need to do is click a button and pay the account at the end of the month, I am that much more likely to just do it. For many of them they don't even physically send you a disk, they just email you the magic number, or you get it yourself over the net.
Another factor is that although the hardware does have a margin cost, it's relatively low. You tend to see this on zseries, ia64, sparc and ppc machines where the manufacturer does not sell an enormous number of them in a year, and they are always trying to recoup their NRE expenses. If they can get a chance at persuading the customer to buy 20 CPUs rather than 10 then it's worth absorbing the cost of having the CPUs sit there for a while before they're sold. The silicon does not cost all that much compared to the R&D.
Amusingly enough Caterpillar also "sells" gianormous earthmoving equipment on a similar scheme, called Power by the Hour. You give them an estimate of how long you want the D10 bulldozer for, and it just turns up.
Both cameras and GPS receivers are commonly available with USB ports. In principle you just need a software hack to make them talk to each other. (Maybe one of them needs to act as a host? But maybe this can already be electronically done by the camera's USB chip.)
Being able to save the GPS coordinates and accurate time as a text tag in each photo could be very useful, or at least very cool.
I know a lot of companies are going to get upset about people doing a kind of arbitrage pricing. Enough other people have ranted about that.
A more interesting point is the positive opportunity this offers for camera manufacturers. Who will be first to ship a programmable and hackable camera, with at least partially open source firmware?
I don't think it's such a crazy idea. There is a fair degree of overlap between digital camera buyers and programmers, or at least people likely to have access to programmers. A pro photographer or press agency might well want to invest a couple of days of programmer time to add some feature they really need. I'm imagining something like the old HP programmable calculators.
There are some ugly edges in the UI of my Minolta camera. It's a great camera in many ways, and the problems are perhaps not serious enough to warrant an official patch from Minolta. But they could be fixed purely in software, and if it were reasonably easy to change it I might do it myself.
There are a few issues you'd need to sort out: hopefully the software shouldn't be able to physically damage the camera, and there needs to be some way to easily get back to the default if you screw it up. I don't think those are impossible to overcome.
What could you add?
- rebind keys to suit the features you most often use
- digital effects on the camera, such as multiple-exposure
- capture coordinates from a GPS or notes from a PDA by bluetooth
- better downsampling
- Probably many more I haven't thought of yet. Look at all the diverse things people have done with Palm devices or MP3 players.
The potential of programmable devices is much larger than even the best hardcoded device.
Yes, writing the first version was fun, but then answering user email messages, or adding little features that I didn't care about got monotonous and boring.
Slashdot Mirror
It doesn't matter which OS you install, if it's out of date then you're vulnerable.
Actually, no. Most Linux distributions dating from the same vintage as XP will not let you get remotely raped out-of-the-box.
If you start up Apache or rsyncd then you might be in trouble, but merely acting as a client is not enough for somebody to root you. It's been a long long time since there was an attack that could take over a client that's not accepting any connections and is just downloading from trusted servers.
I kind of agree, but I think you are stretching the definition of API a bit too far. From a certain point of view, anything you need can be written on a Turing machine, and they're even older than Unix.
Suppose I want to display nicely rendered multilingual text. Not such an outrageous requirement, I think. But only in the last few years have there been any reasonable Unix APIs to do so. Working unicode support throughout the toolkit and in window managers is only a few years old.
I think the core issue is that Linux doesn't have the "fire and motion" imperative that Microsoft does. Developers do break interfaces from time to time, but they generally only do it when there is a technical imperative, not just because they want to force upgrades.
You have made clear you don't have a solid idea of what C++ code generation looks like.
I don't know about the original poster, but I think I have a moderately good idea. What is different in the code generation between creation of an object on the heap and on the stack? Inquiring minds yearn to know.
Surely the same constructors gets called the same way? The only difference is whether the allocator gets called, or alternatively that the stack registers are frobbed.
Why would you not want objects on the stack? It's not like we're in kernel mode where there is only a small stack. In Linux userspace it is fine to put several k on the stack.
Perhaps you're saying that a large object might have an expensive constructor? But that is equally much of a problem if it's constructed with new/delete. The solution is not to create/destroy it from inside the function. It doesn't matter whether it's on the heap or not.
Agreed, but how much of that "high-end Solaris" is under SCO license restrictions?
Great question. Probably some substantial part of it is covered, if Sun thought it was worth paying $100M for it over the years.
So here's a good question for people looking at Solaris: do you really want to be using a technology licenced from litigious bastards who might try to change the licencing terms, or sue end users at any point, and who believe that "contracts are something you use against partners"? Or would you rather have a nice Unix that's been extensively and expensively proved to be absolutely free of SCO code? The second looks much less risky to me.
Leaving aside the results or whether the benchmark is meaningful, his presentation of the results in the graph is truly awful. The one large spike for Method Call/Server JVM is so large that all the other results are nearly visually indistinguishable.
He admits he couldn't write a script to automate the tests. That does not inspire confidence in his ability to assess programming languages.
I think an even better rule of thumb is to buy one step down from what you can afford. You're likely to suffer a bit less of a novelty premium and it will still last almost as long.
o -o-
So for example at the moment (in AU) 250GB ATA/SATA drives are affordable, but going down to just 200GB is 35-40% cheaper and only 20% smaller. Either one will likely last two-three years, at which point I'll probably replace it with something in the 500-900GB range.
(Insert tentacle porn reference below this line:)
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-
20 seconds or it's free.
Watch an awful show made by a liberal to restore cosmic balance.
A judge told them to stop making outrageous public statements (search Groklaw). Sadly, they complied. Darl in prison for Contempt of Court would have been a happy sight.
I think Baystar told them to shut up too.
I think it was "Free University Compiler Kit".
Lots of copying going on in the OSS world.
Specifically he says lots of copyright infringement happens, but he can't find even one single example of it. Can you? No, I didn't think so.
What KB might have been trying to say is that it's not a fun thought for a corp to make a new piece of software if the OSS community is going to work feverishly to try to make a free substitute.
Boo hoo hoo. If it wasn't open source hackers trying to beat it then it would be Microsoft or some other company. Any successful product attracts competitors. Do you see HP whining about Dell selling printers? Do you think it's fun for Sony that the XBox exists?
If your company can't manage to make something better than what can be produced by hobbyists working on evenings and weekends then you don't deserve to survive.
Brown clearly doesn't know his arse from his elbow. I'm sure people tried to explain that point but he didn't understand it.
He's a paid stooge *and also* an idiot.
If he was more intelligent, he would write more credible astroturf. Previous Microsoft FUD has been written to a much higher intellectual standard.
Hitler produced (mediocre) drawings, and tried to make a living at it. That's a better definition of an artist, than whether they went to art school. Does anyone care whether Hitler went to tyrant school?
You don't build bridges with Erector set parts.
Well, in a way you do. Most complex products (cars, ASICs, software, maybe even bridges) are built these days by buying/licensing/borrowing/copying designs from someone else and kludging them together. The added value is in picking the right parts and getting them to work together, just as for open source.
Not that I think the open source market is properly developed. There is no really good way yet for you to pay $x to get the linker quality improved, other than hiring someone or learning it yourself.
I think you mean, "divert attention *from* their own death." Why else make such wacky and schizophrenic pronouncements every month?
... and kill the takeover, thereby losing his golden parachute from Microsoft and opening up a shareholder suit? I don't think so.
As soon as MS made any sign of taking over Sun, McNealy would opensource just about everything
Good post.
I'll just add that any low-G accelerator implies that you'll be launching at a low elevation, unless you plan to dig a shaft hundreds of km into the earth. This increases the distance you have to travel through the atmosphere, and therefore the amount of wasted energy.
It is one thing for a 747 to carry an empty shuttle, and quite another for it to carry one with enough rocket fuel to get from FL100 to orbit, plus its payload and crew.
The takeoff mass of the shuttle is about 2,000 metric tonnes, and the landing mass is only 100 tonnes. (Source: wikipedia). That's a big difference! 1900 tonnes, or 95% of the mass is burnt or otherwise used in getting up there. This is pretty typical of orbital systems: the higher you want to go, the more of your mass you need to burn to get there, and therefore the larger the system needs to be to carry a useful payload. Starting above sea level would help, but you'd still need hundreds of tonnes of fuel.
The shuttle currently needs the external fuel tank and rocket boosters, which are not transported on the 747 and would get in the way of mounting it. Maybe you could do without the boosters if you started from FL100. But I think the shuttle doesn't have much onboard fuel, so you still need the big tank.
The maximum payload of a 747-400 is only 150 tonnes, and that's a more modern plane than the 747-100 currently used as a shuttle carrier. That number is calculated without the extra drag of a whole other aircraft sitting on the back, so I think carrying even an empty shuttle must be close to the limit. Carrying one with even half the required fuel would be impractical. Even if you put the shuttle on a superjumbo, the amount of fuel to drag a shuttle up to launch altitude would be enormous.
While a 747 may be able to fly inverted I don't know if it would be able to do so with a shuttle strapped on the back. Could the shuttle detach and roll upright, while fully loaded with fuel? It's not designed to be the most manueverable aircraft, even when empty. I would suspect it would drop like a stone when fully fuelled.
I think the reason the SpaceShipOne is feasible is that it's a much smaller craft and they don't go all the way to orbit.
It's already been pulled apart here.
I don't think Brown deserves to be taken seriously.
I would interpret that as showing that Kodak's attempt was lame, rather than that the idea of a programmable OS is bad.
Making a device programmable tends to be an exercise where if you don't make it good enough, people won't get excited and it will just flop. You need to develop a virtuous cycle where there is a community of developers producing enough interesting stuff to make more people interested.
It's not necessarily exactly cheaper. The hardware does have a significant cost, which is soaked up by the manufacturer unless/until the customer turns it on.
I think the point is more that you can sell it to them immediately when the want it -- a kind of corporate impulse shopping.
If I know that adding more CPUs is going to require ordering them, arranging downtime, bringing the machine down, physically installing the CPUs, bringing it back up and hoping nothing broke then I might think twice, and try to get by without it for a bit longer. If all I need to do is click a button and pay the account at the end of the month, I am that much more likely to just do it. For many of them they don't even physically send you a disk, they just email you the magic number, or you get it yourself over the net.
Another factor is that although the hardware does have a margin cost, it's relatively low. You tend to see this on zseries, ia64, sparc and ppc machines where the manufacturer does not sell an enormous number of them in a year, and they are always trying to recoup their NRE expenses. If they can get a chance at persuading the customer to buy 20 CPUs rather than 10 then it's worth absorbing the cost of having the CPUs sit there for a while before they're sold. The silicon does not cost all that much compared to the R&D.
Amusingly enough Caterpillar also "sells" gianormous earthmoving equipment on a similar scheme, called Power by the Hour. You give them an estimate of how long you want the D10 bulldozer for, and it just turns up.
Both cameras and GPS receivers are commonly available with USB ports. In principle you just need a software hack to make them talk to each other. (Maybe one of them needs to act as a host? But maybe this can already be electronically done by the camera's USB chip.)
Being able to save the GPS coordinates and accurate time as a text tag in each photo could be very useful, or at least very cool.
I know a lot of companies are going to get upset about people doing a kind of arbitrage pricing. Enough other people have ranted about that.
A more interesting point is the positive opportunity this offers for camera manufacturers. Who will be first to ship a programmable and hackable camera, with at least partially open source firmware?
I don't think it's such a crazy idea. There is a fair degree of overlap between digital camera buyers and programmers, or at least people likely to have access to programmers. A pro photographer or press agency might well want to invest a couple of days of programmer time to add some feature they really need. I'm imagining something like the old HP programmable calculators.
There are some ugly edges in the UI of my Minolta camera. It's a great camera in many ways, and the problems are perhaps not serious enough to warrant an official patch from Minolta. But they could be fixed purely in software, and if it were reasonably easy to change it I might do it myself.
There are a few issues you'd need to sort out: hopefully the software shouldn't be able to physically damage the camera, and there needs to be some way to easily get back to the default if you screw it up. I don't think those are impossible to overcome.
What could you add?
- rebind keys to suit the features you most often use
- digital effects on the camera, such as multiple-exposure
- capture coordinates from a GPS or notes from a PDA by bluetooth
- better downsampling
- Probably many more I haven't thought of yet. Look at all the diverse things people have done with Palm devices or MP3 players.
The potential of programmable devices is much larger than even the best hardcoded device.
Yes, writing the first version was fun, but then answering user email messages, or adding little features that I didn't care about got monotonous and boring.
Don't do it then. Duh.
If it hurts, you're doing it wrong.