But the cost of the followup war in Afghanistan, war in Iraq, DHS, etc have toppled our already shaky economy.
Actually, it was the collective stupidity of millions of people that did that. And yes, believing that house prices would always go up in real terms (or that you'd at least be able to guarantee to get out without burning yourself when they stopped) is most certainly stupidity. On the other hand, as long as everyone believed, it almost worked; the only problem was this inconvenient thing called reality...
And if your child DOES have heart problems, sooner or later he or she will need to see a physician, who will be sure to inform the insurance company of the condition.
Seeing a doctor may also have the side effect of saving their life if they do have an arrhythmia. Having the opportunity to get health insurance later does them no good if they drop dead due to a treatable heart condition first.
Yes, but think of how terrible it will be if bacteria ever do develop resistance to those disinfectants.
Terrible, but unlikely. Disinfectants are very powerful substances and/or processes. It'd be a bit like you developing cellular immunity to being chopped apart with a chainsaw.
Plus, you eventually end up with a system where all applications have to be approved by the BOFH. Then, when a developer/techie who knows what he's doing needs to use a new tool to solve a problem it ends up in a 6-month queue for "approval".
What actually happens is that the user complains to Heap Big Boss (board-level or equivalent) and they instruct the poor BOFH to approve their pet project immediately or find another job. It's a really bad idea to be the person who says "no" to another person doing their job, especially if they have the ear of higher up (and most users will only deliberately use a new app if it is something dictated from on high; the rest of the time they'll cling to old stuff far more than a BOFH would).
A language with too much checking will be slow (Java has a much better security name in this department than C for instance)
The best way to do this is to have all the requirements and guarantees written in the code, right down to the low-level, and then to have a compiler that can remove explicit checks once it proves that they're not necessary. This is the sort of idea behind a language like Eiffel. (And the cost of checking at runtime for buffer overflow and other things like that is actually not that high. A lot of the time, you can compensate by building/using a proper high-quality buffer management lib rather than rolling your own hack each time round. "Do It Right, Once" is an excellent rule to follow.)
and while seeing if my machine is sending mystery emails out to my friends would be good, what kind of transparency lets me "see" a buffer overflow caused by a Flash movie writing arbitrary code???
Oh god! I just thought of using tubgirl as the visualization of that... Now to get that image out of my mind; where's the brain-bleach?
Maybe on Linux PHP is no harm to the OS, but on MS boxes that is not a safe assumption to make.
PHP is a problem, but if you're properly paranoid you can avoid most of the problems. Removing from your production webserver all things like wget that can download a rootkit is a good start. You also don't want to have compilers on those systems. It also helps if you crucify any web developer who puts an "email a friend" form up. (Careful firewalling can help detect when such idiots have been about; you don't have to wait for your server to appear in one of the spam blacklists...)
The lack of any managed repository of vetted and verified software is, to me, the number one reason Windows sucks so hard.
So you're advocating the iPhone-style app store, with obscure fascist rules determining who is blessed and who is not? I'm assuming you're not suggesting that Microsoft should be the only source of all possible software for running on Windows; that most definitely won't work due to the diversity of things that people do with computers. Well, thinking about it you might actually be advocating that, in the misguided belief that the Linux Distributor model works well; it only does if you want OSS - not always a great option, alas - and if you're content with being stuck with old versions. In short, if you need commercial software then you're still downloading executables (or other packages).
There are 4 models possible:
Central distributor of only code done by distributor
Central distributor of third-party code
Distributed distribution with digital signatures
Distributed distribution without signatures
The central model doesn't scale too well, especially when apps get really big, so the real choice for me is between whether you require signatures or not. Ho hum.
Actually, hardware accelerated advertisements would improve the user experience, compared to regular advertisements.
I find that closing my eyes improves the user experience compared with most regular ads on the web. (And on the TV too for that matter.) It's the obnoxiousness that I object to, and the added indignity of ads too often being such horrendous messes that they impact browsing of unrelated sites with common browsers, though NoScript is rather a good response to that (and good for other things too).
"This is the only reason I can think of for some of the upgrades I've seen at major websites the past year or so - websites that were previously functional, easy to use, fast, etc. and are now buggy, overladen with crap, etc."
Here's looking at you,/.
To be fair, the slashcode team haven't screwed the pooch as thoroughly as the bunch of morons that do the site design for SourceForge. (And yes, I know they're all part of the same company. But the SF webdevs have the oddest grasp of "usable" I've encountered for a few years; making it worse than now would require <BLINK> and <MARQUEE>...)
Further, why did Apple invent a new syntax for 'Blocks' instead of using the one already proposed for C++0x.
Because Apple (largely) don't use C++ at all, and so don't feel any need to follow what's going on there. (And "[&]" as a syntactic element for C++'s lambdas? Ick. Is that really so, or did my google-fu lead me astray?)
Skype is much cheaper than a landline for international calls since it routes the call over the internet and then dials out from the country you're calling.
You are aware that that's what some telcos do with your call anyway? Of course, they then charge you full rate anyway...
Actually Python is pretty slow, about 50 times slower than C++, but that's usually ok since you can put the bottleneck into a C++ module.
It's not quite as simple as that, since you also have to consider all the other factors involved (like amount of effort to stabilize the production solution, flexibility of the solution, etc.) Speed is only one - important - aspect.
And if you're in an I/O bound process, it matters not at all; you're going to be waiting for devices to do their stuff anyway...
"Universities are not intended to provide vocational training."
Why do so many people seem to have forgotten this?
On the other hand, CryEngine can be used as an exemplar case-study of the class of 3D world models, allowing study of the capabilities and trade-offs involved in their design and use. That is academically meaningful.
Keeping binary compatibility limits infrastructure improvements that can be made. You're limited in what you can do to the kernel because of drivers that are sitting out there that expect binary compatibility.
On the other hand, having a stable ABI (well KernelBI) means that you're disconnecting the development of the drivers from the development of the kernel, making it far easier for non-kernel people (including hardware manufacturers) to develop and support drivers, and that generally improves support for hardware. Which benefits lots of people.
Note that having a stable KBI doesn't prevent evolution of the interface. You just need to have a (stable, versioned) mechanism for the driver to get access to a table of function pointers that implement a particular interface version, which it can grab at the point when the driver is loaded. There's a slight performance hit, but that could be avoided by using a more complex rewriting scheme (but I'd rather use well-known techniques than hacky rewriting if possible). Some care is needed on the part of kernel developers to ensure that they don't break particular KBIs by accident (this is analogous to the costs you refer to, but less crippling) and driver authors also need care, so that they don't go badly wrong and instead fail in a neatly controlled fashion if their favorite KBI isn't available.
It's not technically hard to do (and userland code has done this for years). But it does take someone to say "spending a little performance on this is a good tradeoff"; too often that's not an attitude heard in kernel circles.
The problem here is that you need to store [nuclear waste] somewhere safe for thousand of years.
No you don't. You can reprocess the fuel and there's been quite a bit of research on how to make the rest less hazardous (IIRC it's typically by exposing it to a high neutron flux; that tends to make it more radioactive so everything cools down more rapidly).
What about during summer? Or are German summers much cooler than they are in the Mid-Atlantic states of the USA?
How efficient will it be to run the gas generator, using the waste heat on your hot water heater, then crank up the air conditioner when it gets too hot?
Summers are much cooler in NW Europe than in the Mid East Coast states. Like 30F cooler on average. Because of that difference of climate, AC is really not common in homes (those that have it probably do so for its dehumidifying properties FWIW) and peak power demand comes in the winter.
this program licenses every possible program under the GPL3 - thus every non-GPL3 program from now on infringes the intellectual property of this program...
Actually not. Quite apart from the fact that the license on code depends on the provenance of the code (so your "trick" doesn't count for jack anyway) it will also take a very long time to generate the programs I'm thinking of (doubly long because you're using C++, which is very slow to compile) and you'll run into problems with trademarks and patents. To cap it all, good luck with proving that any output from the program is a creative work.
Plus many of the programs will of course have the BSD license clearly there in the source at the top of the file, together with a note that the comment at the end is a lie...
And then again, 6510 assembly sucked big time when compared to my Speccy's Z80 assembly!:-)
Having written a fair amount of both Z80 and 6502 assembly (6510 asm is very similar) I can assure you that Z80 was nicer to think about. Of the 8-bit machines, the BBC had the nicest actual assembler (though I never had a Z80 module for one, so I had to make do with 6502's limitations).
Still don't want to go back to writing either though, as it was a pain overall even with an assembler. I'm determined to try to write nothing lower-level than C ever again...
Even if you protect your idea, other people will figure it out anyway.
It's not the idea that succeeds though, it's what's done with it. That's the bit that's called a "business plan" and those really are important. It's very much like saying it's not the idea for a computer program that's important (the ideas for most programs sound really stupid and trivial really) but rather how you actually go about implementing it in code. Implementation matters!
You just happened to stumble into a book/journal catalog organized by a centuries old and previously very well known method. The error wasn't in the card catalog or the way it was organized, but in that no one ever told you about these ancient methods in your library course.
The real issue to note here is that one thing computers are much better at than what went before is maintaining indices of cataloged data and performing searching of it. Sure GIGO rules still, but it's now practical to be able to search for a work on any facet of its metadata or even on automatically extracted information from the work itself. That's massively beyond what libraries used to offer. (I've had occasion to use card catalogs, and the biggest problem with them is the restricted number of axes on which you can search, and the fact that you're restricted as to which order to perform the search.)
there's never been a set, for instance, where you build a replica assault rifle that fires real projectiles.
Of course there was! But you had to be really inventive to put it together right, and the muzzle velocity wasn't exactly that high even then. Not even enough to break a glass door. (Thankfully...:-)) The best approach was probably to do something a bit like a tennis machine, except with smaller projectiles. Lego men heads worked a treat!
Slashdot Mirror
But the cost of the followup war in Afghanistan, war in Iraq, DHS, etc have toppled our already shaky economy.
Actually, it was the collective stupidity of millions of people that did that. And yes, believing that house prices would always go up in real terms (or that you'd at least be able to guarantee to get out without burning yourself when they stopped) is most certainly stupidity. On the other hand, as long as everyone believed, it almost worked; the only problem was this inconvenient thing called reality...
And if your child DOES have heart problems, sooner or later he or she will need to see a physician, who will be sure to inform the insurance company of the condition.
Seeing a doctor may also have the side effect of saving their life if they do have an arrhythmia. Having the opportunity to get health insurance later does them no good if they drop dead due to a treatable heart condition first.
Yes, but think of how terrible it will be if bacteria ever do develop resistance to those disinfectants.
Terrible, but unlikely. Disinfectants are very powerful substances and/or processes. It'd be a bit like you developing cellular immunity to being chopped apart with a chainsaw.
Plus, you eventually end up with a system where all applications have to be approved by the BOFH. Then, when a developer/techie who knows what he's doing needs to use a new tool to solve a problem it ends up in a 6-month queue for "approval".
What actually happens is that the user complains to Heap Big Boss (board-level or equivalent) and they instruct the poor BOFH to approve their pet project immediately or find another job. It's a really bad idea to be the person who says "no" to another person doing their job, especially if they have the ear of higher up (and most users will only deliberately use a new app if it is something dictated from on high; the rest of the time they'll cling to old stuff far more than a BOFH would).
A language with too much checking will be slow (Java has a much better security name in this department than C for instance)
The best way to do this is to have all the requirements and guarantees written in the code, right down to the low-level, and then to have a compiler that can remove explicit checks once it proves that they're not necessary. This is the sort of idea behind a language like Eiffel. (And the cost of checking at runtime for buffer overflow and other things like that is actually not that high. A lot of the time, you can compensate by building/using a proper high-quality buffer management lib rather than rolling your own hack each time round. "Do It Right, Once" is an excellent rule to follow.)
and while seeing if my machine is sending mystery emails out to my friends would be good, what kind of transparency lets me "see" a buffer overflow caused by a Flash movie writing arbitrary code???
Oh god! I just thought of using tubgirl as the visualization of that... Now to get that image out of my mind; where's the brain-bleach?
Maybe on Linux PHP is no harm to the OS, but on MS boxes that is not a safe assumption to make.
PHP is a problem, but if you're properly paranoid you can avoid most of the problems. Removing from your production webserver all things like wget that can download a rootkit is a good start. You also don't want to have compilers on those systems. It also helps if you crucify any web developer who puts an "email a friend" form up. (Careful firewalling can help detect when such idiots have been about; you don't have to wait for your server to appear in one of the spam blacklists...)
The lack of any managed repository of vetted and verified software is, to me, the number one reason Windows sucks so hard.
So you're advocating the iPhone-style app store, with obscure fascist rules determining who is blessed and who is not? I'm assuming you're not suggesting that Microsoft should be the only source of all possible software for running on Windows; that most definitely won't work due to the diversity of things that people do with computers. Well, thinking about it you might actually be advocating that, in the misguided belief that the Linux Distributor model works well; it only does if you want OSS - not always a great option, alas - and if you're content with being stuck with old versions. In short, if you need commercial software then you're still downloading executables (or other packages).
There are 4 models possible:
The central model doesn't scale too well, especially when apps get really big, so the real choice for me is between whether you require signatures or not. Ho hum.
Actually, hardware accelerated advertisements would improve the user experience, compared to regular advertisements.
I find that closing my eyes improves the user experience compared with most regular ads on the web. (And on the TV too for that matter.) It's the obnoxiousness that I object to, and the added indignity of ads too often being such horrendous messes that they impact browsing of unrelated sites with common browsers, though NoScript is rather a good response to that (and good for other things too).
"This is the only reason I can think of for some of the upgrades I've seen at major websites the past year or so - websites that were previously functional, easy to use, fast, etc. and are now buggy, overladen with crap, etc."
Here's looking at you, /.
To be fair, the slashcode team haven't screwed the pooch as thoroughly as the bunch of morons that do the site design for SourceForge. (And yes, I know they're all part of the same company. But the SF webdevs have the oddest grasp of "usable" I've encountered for a few years; making it worse than now would require <BLINK> and <MARQUEE>...)
And said organization is stockpiling all your posts to be used in the inevitable Irony War of 2012.
So, we're all safe here then?
Further, why did Apple invent a new syntax for 'Blocks' instead of using the one already proposed for C++0x.
Because Apple (largely) don't use C++ at all, and so don't feel any need to follow what's going on there. (And "[&]" as a syntactic element for C++'s lambdas? Ick. Is that really so, or did my google-fu lead me astray?)
Should it still be named C++0x? The final draft is slated for 2010 and it isn't going to be published until 2011.
Sure. "C++0xa" and "C++0xb" are both perfectly acceptable...
Skype is much cheaper than a landline for international calls since it routes the call over the internet and then dials out from the country you're calling.
You are aware that that's what some telcos do with your call anyway? Of course, they then charge you full rate anyway...
Actually Python is pretty slow, about 50 times slower than C++, but that's usually ok since you can put the bottleneck into a C++ module.
It's not quite as simple as that, since you also have to consider all the other factors involved (like amount of effort to stabilize the production solution, flexibility of the solution, etc.) Speed is only one - important - aspect.
And if you're in an I/O bound process, it matters not at all; you're going to be waiting for devices to do their stuff anyway...
"Universities are not intended to provide vocational training."
Why do so many people seem to have forgotten this?
On the other hand, CryEngine can be used as an exemplar case-study of the class of 3D world models, allowing study of the capabilities and trade-offs involved in their design and use. That is academically meaningful.
That's more than my net pay.
You're in the wrong job there.
Keeping binary compatibility limits infrastructure improvements that can be made. You're limited in what you can do to the kernel because of drivers that are sitting out there that expect binary compatibility.
On the other hand, having a stable ABI (well KernelBI) means that you're disconnecting the development of the drivers from the development of the kernel, making it far easier for non-kernel people (including hardware manufacturers) to develop and support drivers, and that generally improves support for hardware. Which benefits lots of people.
Note that having a stable KBI doesn't prevent evolution of the interface. You just need to have a (stable, versioned) mechanism for the driver to get access to a table of function pointers that implement a particular interface version, which it can grab at the point when the driver is loaded. There's a slight performance hit, but that could be avoided by using a more complex rewriting scheme (but I'd rather use well-known techniques than hacky rewriting if possible). Some care is needed on the part of kernel developers to ensure that they don't break particular KBIs by accident (this is analogous to the costs you refer to, but less crippling) and driver authors also need care, so that they don't go badly wrong and instead fail in a neatly controlled fashion if their favorite KBI isn't available.
It's not technically hard to do (and userland code has done this for years). But it does take someone to say "spending a little performance on this is a good tradeoff"; too often that's not an attitude heard in kernel circles.
The problem here is that you need to store [nuclear waste] somewhere safe for thousand of years.
No you don't. You can reprocess the fuel and there's been quite a bit of research on how to make the rest less hazardous (IIRC it's typically by exposing it to a high neutron flux; that tends to make it more radioactive so everything cools down more rapidly).
What about during summer? Or are German summers much cooler than they are in the Mid-Atlantic states of the USA?
How efficient will it be to run the gas generator, using the waste heat on your hot water heater, then crank up the air conditioner when it gets too hot?
Summers are much cooler in NW Europe than in the Mid East Coast states. Like 30F cooler on average. Because of that difference of climate, AC is really not common in homes (those that have it probably do so for its dehumidifying properties FWIW) and peak power demand comes in the winter.
this program licenses every possible program under the GPL3 - thus every non-GPL3 program from now on infringes the intellectual property of this program...
Actually not. Quite apart from the fact that the license on code depends on the provenance of the code (so your "trick" doesn't count for jack anyway) it will also take a very long time to generate the programs I'm thinking of (doubly long because you're using C++, which is very slow to compile) and you'll run into problems with trademarks and patents. To cap it all, good luck with proving that any output from the program is a creative work.
Plus many of the programs will of course have the BSD license clearly there in the source at the top of the file, together with a note that the comment at the end is a lie...
And then again, 6510 assembly sucked big time when compared to my Speccy's Z80 assembly! :-)
Having written a fair amount of both Z80 and 6502 assembly (6510 asm is very similar) I can assure you that Z80 was nicer to think about. Of the 8-bit machines, the BBC had the nicest actual assembler (though I never had a Z80 module for one, so I had to make do with 6502's limitations).
Still don't want to go back to writing either though, as it was a pain overall even with an assembler. I'm determined to try to write nothing lower-level than C ever again...
If [Ben Franklin] lived today, he would be a pony-tailed uberhacker.
He'd also be 303 years old, and still a match for even Bruce Schneier.
Even if you protect your idea, other people will figure it out anyway.
It's not the idea that succeeds though, it's what's done with it. That's the bit that's called a "business plan" and those really are important. It's very much like saying it's not the idea for a computer program that's important (the ideas for most programs sound really stupid and trivial really) but rather how you actually go about implementing it in code. Implementation matters!
You just happened to stumble into a book /journal catalog organized by a centuries old and previously very well known method. The error wasn't in the card catalog or the way it was organized, but in that no one ever told you about these ancient methods in your library course.
The real issue to note here is that one thing computers are much better at than what went before is maintaining indices of cataloged data and performing searching of it. Sure GIGO rules still, but it's now practical to be able to search for a work on any facet of its metadata or even on automatically extracted information from the work itself. That's massively beyond what libraries used to offer. (I've had occasion to use card catalogs, and the biggest problem with them is the restricted number of axes on which you can search, and the fact that you're restricted as to which order to perform the search.)
there's never been a set, for instance, where you build a replica assault rifle that fires real projectiles.
Of course there was! But you had to be really inventive to put it together right, and the muzzle velocity wasn't exactly that high even then. Not even enough to break a glass door. (Thankfully... :-)) The best approach was probably to do something a bit like a tennis machine, except with smaller projectiles. Lego men heads worked a treat!