I don't hink your bridge analogy is very good. A walk bridge which can handle a freight train is not well designed. That is about ignoring the requirements, not making the design of a walk bridge as good as possible.
2nd point. I think that trying to maximize software quality can actually save money.
The issue is all about bugs and support, in my view.
Bugs cost money. Lots of money. If each of the users calls into a help line because of a bug in your off-the-shelf software (even just once), then you're going to be losing money big-time. Phone and even e-mail support (if you've got a human reading the e-mails) are expensive.
Bugs can also cost you customers if they run into enough of them. You'll get less word-of-mouth advertising (one of the most cost-effective types), and you'll get less repeat sales.
As far as software design goes, obviously you can go overboard and implement really whizzy new data structures and stuff which take a long time to develop. But putting a lot of effort into designing a product to be as robust and reliable as possible is well spent, in my opinion.
Have you checked Sourceforge or something to make sure nobody has already written the scripts for you?
No, because that's more work too. Also, will the scripts work for my version of Apache? Will they only work with FC3 and haven't been updated for FC4 yet? And so on.
Any time you're maintaining more than a couple machines, you definitely should invest the time to investigate administration tools and set them up for you site. That time is well spent, but it isn't zero either.
Isn't that bad, since if one thing fails, everything fails at once?
If the application is dependant on all the pieces working (database driven web application for example), then if any piece fails, the application fails.
Of course, if you want high uptime, you'll have multiply redundant services (on redundant servers) for each piece of the application. But that isn't exactly what we're talking about (maintaining one machine vs. multiple machines).
If you can reasonably protect a single machine, how can you not be expected to reasonably protect six, or ten, or a hundred?
Installing patches, updating accounts, configuring applications can all be more work. You have to write scripts to do the updates, instead of just editing the config files on one machine.
Well, if I wanted multiple years between re-installs, I'd probably use CentOS.
I think yearly releases would be reasonable for Debian. I was under the impression that most Debian developers wanted releases to occur at a faster rate than they currently are.
And if there's real need for a longer release cycle, you can always skip a release, and talk to people about maintaining the previous release for longer (assuming it did go to a yearly release cycle).
A release cycle of 6 months or less is hard for me to deal with on server systems.
Indeed. It is this discussion of topics like terraforming that disapoint me most about people's ability to think about the future, and understand trends in technology.
Why do we talk about terraforming? To provide a room-temperature environment (air, pressure, water, gravity) to accommodate us meat bags.
But what if we were made of tougher materials? So we don't need to breath O2 at STP. So we don't need gravity to walk around on surfaces. So we are resistant to radiation. So that outer space becomes our natural environment.
Is it easier to change a planet so that it supports Earth-based meat bags? Or change ourselves to accommodate the environment?
... and i think it was one of the best TNG episodes aired.
I'd say it was one of the best episodes of any ST franchise, ever.
Sending the entire crew of Ent-C into a suicide mission, and them accepting it consciously and willing was a fantasic screen moment. Too bad it had to happen in an alternate reality episode, not along the main story arc of the series (what there was of one).
Sometimes I think it would have made a great movie (and it would have been better than any of the TNG movies). But at other times, I like the tight pacing of the 1-shot episode.
I find this entire concept of "age of consent" somewhat tenuous, at best. It seems to imply that there is an age at which one magically is able to make intelligent, rational decisions about their own body and their sexuality, and below that they're just too stupid and/or immature to make any such decision. If that were actually the concern, I know plenty of 30 year olds who aren't able to make said intelligent, rational decisions... and plenty of 12 year olds who are. People mature at different ages. Get over it.
Ugh. You don't seem to understand anything about society engineering. I don't mean social engineering. I mean engineering societies so that they productive and not too screwed up.
Sure, some 12 year olds are more mature than some 30 year olds. That's not the point.
We can't have a society where everyone has to take long, drawn-out tests to allow them to do certain things. Think about applying for a driver's license (including the written and driving tests) for everything adults are allowed to do. Drinking alcohol, voting, signing legally binding contracts, entering the Army, getting a job, buying a firearm (*), owning a house, etc..
Geez, think of the cost. Think of how thick your wallet would be, carrying around all those different ID cards. Then, when you have to move, think about all the change-of-address forms.
So we don't do that kind of stuff. We don't have the time and money to implement comprehensive ability tests for all aspects of adulthood. So we pick a number (14, 18, 21, whatever) and hope for the best.
It is fine to question the rules of society. People don't do that enough. But to dismiss the rules without understanding the reasons for them is folly.
(*) Actually, I think a more comprehensive test for gun ownership is a good idea, but even that's probably not going to happen in the USA.
Our current patent system requires the inventor to publish the details of the invention, allowing society as a whole to be able to benefit from it once the twenty years is up.
That would be great, if reading patents was actually a useful means to learn anything.
With one notable exception, every patent I've read has been written in an obtuse language only other patent lawyers understand. There is no requirement that the inventors write a good HOWTO (written in clear language) on what the patent is actually good for, and its implementation. If that was the case, your argument would have more merit.
Ack. I went to a 3-D theater using this technology a few (like maybe 5) years ago.
About 20 minutes in, massive headache.
I hope they've upped the refresh rate since then. I don't seem to have a problem watching regular 24fps movies in theaters. But anything less than 70Hz with a monitor bothers me.
Indeed. Bugfix releases for Java each get their own entry, while other major and infulential languages (with multiple implementations) get mentions only at major milestones.
Feh.
I suppose the lesson is this: You shouldn't ever expect to compile something like this chart, unless you are also ready to receive a lot of criticism.
That's the uptime for one of our Debian 3.0 servers. It would have been more, except for the office move, and need to install kernel security updates.
That box previous ran Debian 2.2. It has never crashed in 4+ years. Never.
The recipe is simple: solid hardware + a solid distro. (It is a Penguin Computing box, BTW.) I don't often buy from them though, because they are very expensive.
"Do you think it is economical for Linksys/Dlink/whoever to build an os/program for something that will sell for so little?"
Well, I don't know, but the point of my original post was that an OS-less device would be more secure since it would require reverse engineering for many exploits. It's possible that customers might be willing to pay more for a more secure device.
There are tradeoffs either way. If you don't put in an OS, then you're writing a lot of stuff from scratch. Goof up a detail, and you've got a security problem. There is a lot of accumulated wisdom built into some of the older codebases, especially the BSD TCP/IP stack.
As it is, these companies can't afford to do from-scratch development, and they can't afford to buy an OS. So they just use a Linux distro, often uCLinux.
I would like to see people (and companies) put a little more effort into inspecting the FOSS softwaer they have incorporated into their own products, and pushing back upstream any security fixes they make. That would be the best for everyone, except the black hats and skript kiddies.
But the PIC doesn't have built-in Ethernet, either. Sure, you can get a USB Ethernet adapter, but it is one more thing to carry around. An Ethernet chip, balun and connector cost in the neighborhood of $2 USD or less to manufacture, so they could have included it, or made a 2nd model which did for about the same price.
Other things to pay attention to include if it needs a wall wart (a.k.a. AC power adapter). Prolly does, so you kit size just increased again.
They are aiming the device for poor, rural areas, like China outside cities. Many of these places don't have land lines, so they might as well have left off the modem. Maybe put in a PCMCIA slot so that you could use it for Ethernet, modem, or GSM/GPRS modem card.
Decent try by AMD though. If this version sells, someone will do it much better.
In my view, it is a question of what the market wants. The market wants very complex router/firewalls, which support multiple routing algorthms, logging facilities, application proxies, and more.
By the time you start coding up all this stuff, you will need some kind of OS. To not have one is like trying to code with mittens on. Sure you can do it, but it isn't very effective or efficient.
Or you could just "buy" OpenBSD, which has as good a packet filter (pf) as I've seen. But then, I don't get out much, and I haven't dug into how sophisticated the proprietary solutions are. Still, even with OpenBSD, it has more features than I've had time to implement, like putting in a 2nd firewall machine and using CARP to keep the data flowing.
Shuttle, that's real flying too, not spam in a can like the Chinese flights.
No, sorry, they're still spam in a can with the Shuttle. Except that the pilot has to push a button to lower the landing gear. Otherwise, it is all computer controlled.
Don't just believe what you say in a James Bond movie.:-)
The main problem with EVs is (and always has been) the batteries. The batteries weigh a lot, and you need a bunch to get decent range.
The thing that was really supposed to fix the problem was energy storage using flywheels. These carbon-fiber flywheels are suspended using magnetic bearings, and are supposed to go up to 100K RPM. Combined with a high-efficency integrated motor-generator, it was proposed that ~ six of these would be able to power an EV with decent range. Overall, these flywheel systems are supposed to have a much higher energy density than most/any battery system.
But that was 1999. I haven't heard much about them since then. Guess it didn't work out.
I'll need to really read through it carefully. I must admit though, for whatever reason, I was really enamored with the idea that it wasn't the hydrogen which was the primary cause of the Hindenberg disaster. Not really sure why. There is probably a psychology lesson in there too.
My only initial criticism of that paper is that he keeps coming back to the Shuttle's SRBs. As if there aren't other types of solid rocket fuel in common use. I'd have wanted Dessler to refer more to another solid rocket system which had a formulation closer to the Hindenberg's skin composition.
Oh, please don't get me wrong. We definitely need to find better energy souces than digging up fossil fuels. However, terrestial solar power is an expensive option. You also need to consider how much pollution you will generate just to make the solar cells. I personally would like to see the federal government invest in research to make solar cells cheaper and more efficient. Not likely with the current administration, though.
And if you're going to compress hydrogen without liqufying it, that will still take a lot of energy. TANSTAAFL.
Hydrogen makes a poor energy transport because it is much less dense that other molecules.
Slashdot Mirror
I've got a couple points.
I don't hink your bridge analogy is very good. A walk bridge which can handle a freight train is not well designed. That is about ignoring the requirements, not making the design of a walk bridge as good as possible.
2nd point. I think that trying to maximize software quality can actually save money.
The issue is all about bugs and support, in my view.
Bugs cost money. Lots of money. If each of the users calls into a help line because of a bug in your off-the-shelf software (even just once), then you're going to be losing money big-time. Phone and even e-mail support (if you've got a human reading the e-mails) are expensive.
Bugs can also cost you customers if they run into enough of them. You'll get less word-of-mouth advertising (one of the most cost-effective types), and you'll get less repeat sales.
As far as software design goes, obviously you can go overboard and implement really whizzy new data structures and stuff which take a long time to develop. But putting a lot of effort into designing a product to be as robust and reliable as possible is well spent, in my opinion.
Have you checked Sourceforge or something to make sure nobody has already written the scripts for you?
No, because that's more work too. Also, will the scripts work for my version of Apache? Will they only work with FC3 and haven't been updated for FC4 yet? And so on.
Any time you're maintaining more than a couple machines, you definitely should invest the time to investigate administration tools and set them up for you site. That time is well spent, but it isn't zero either.
Isn't that bad, since if one thing fails, everything fails at once?
If the application is dependant on all the pieces working (database driven web application for example), then if any piece fails, the application fails.
Of course, if you want high uptime, you'll have multiply redundant services (on redundant servers) for each piece of the application. But that isn't exactly what we're talking about (maintaining one machine vs. multiple machines).
If you can reasonably protect a single machine, how can you not be expected to reasonably protect six, or ten, or a hundred?
Installing patches, updating accounts, configuring applications can all be more work. You have to write scripts to do the updates, instead of just editing the config files on one machine.
In other words, more work is more work.
Well, if I wanted multiple years between re-installs, I'd probably use CentOS.
I think yearly releases would be reasonable for Debian. I was under the impression that most Debian developers wanted releases to occur at a faster rate than they currently are.
And if there's real need for a longer release cycle, you can always skip a release, and talk to people about maintaining the previous release for longer (assuming it did go to a yearly release cycle).
A release cycle of 6 months or less is hard for me to deal with on server systems.
It would be really nice if Debian started another release process right after the transition to X.org and the C++ ABI are finished.
I really like Debian, and I'd prefer not to wait a couple years for the next release. :-)
Geez, couldn't you at least wait until some good stuff was released on the format before cracking it?
Now the copyright cartel will probably just kill the format, and try again with stronger encryption.
This, of course, is not meant by me to imply that any form of mass-consumer DRM is at all uncrackable. They're all doomed in my view.
So I guess it is more fun this way. Crack it early, and hope they come up with something more interesting. More challenging.
Indeed. It is this discussion of topics like terraforming that disapoint me most about people's ability to think about the future, and understand trends in technology.
Why do we talk about terraforming? To provide a room-temperature environment (air, pressure, water, gravity) to accommodate us meat bags.
But what if we were made of tougher materials? So we don't need to breath O2 at STP. So we don't need gravity to walk around on surfaces. So we are resistant to radiation. So that outer space becomes our natural environment.
Is it easier to change a planet so that it supports Earth-based meat bags? Or change ourselves to accommodate the environment?
I've seen the future, and it isn't Star Trek.
Why can't someone program a replicator to replicate an entire spacecraft, therefore having infinite war time production capabilities?
Heh, they did that in DS9, though it was mines guarding the wormhole, not spaceships.
I'd say it was one of the best episodes of any ST franchise, ever.
Sending the entire crew of Ent-C into a suicide mission, and them accepting it consciously and willing was a fantasic screen moment. Too bad it had to happen in an alternate reality episode, not along the main story arc of the series (what there was of one).
Sometimes I think it would have made a great movie (and it would have been better than any of the TNG movies). But at other times, I like the tight pacing of the 1-shot episode.
I find this entire concept of "age of consent" somewhat tenuous, at best. It seems to imply that there is an age at which one magically is able to make intelligent, rational decisions about their own body and their sexuality, and below that they're just too stupid and/or immature to make any such decision. If that were actually the concern, I know plenty of 30 year olds who aren't able to make said intelligent, rational decisions... and plenty of 12 year olds who are. People mature at different ages. Get over it.
Ugh. You don't seem to understand anything about society engineering. I don't mean social engineering. I mean engineering societies so that they productive and not too screwed up.
Sure, some 12 year olds are more mature than some 30 year olds. That's not the point.
We can't have a society where everyone has to take long, drawn-out tests to allow them to do certain things. Think about applying for a driver's license (including the written and driving tests) for everything adults are allowed to do. Drinking alcohol, voting, signing legally binding contracts, entering the Army, getting a job, buying a firearm (*), owning a house, etc..
Geez, think of the cost. Think of how thick your wallet would be, carrying around all those different ID cards. Then, when you have to move, think about all the change-of-address forms.
So we don't do that kind of stuff. We don't have the time and money to implement comprehensive ability tests for all aspects of adulthood. So we pick a number (14, 18, 21, whatever) and hope for the best.
It is fine to question the rules of society. People don't do that enough. But to dismiss the rules without understanding the reasons for them is folly.
(*) Actually, I think a more comprehensive test for gun ownership is a good idea, but even that's probably not going to happen in the USA.
Our current patent system requires the inventor to publish the details of the invention, allowing society as a whole to be able to benefit from it once the twenty years is up.
That would be great, if reading patents was actually a useful means to learn anything.
With one notable exception, every patent I've read has been written in an obtuse language only other patent lawyers understand. There is no requirement that the inventors write a good HOWTO (written in clear language) on what the patent is actually good for, and its implementation. If that was the case, your argument would have more merit.
Ack. I went to a 3-D theater using this technology a few (like maybe 5) years ago.
About 20 minutes in, massive headache.
I hope they've upped the refresh rate since then. I don't seem to have a problem watching regular 24fps movies in theaters. But anything less than 70Hz with a monitor bothers me.
Those are about the only command line switches I use with rsync.
The only other one I sometimes throw in is --delete. But I try to look things over and think twice about that.
Good luck with that BSD-licensed C compiler. GCC's had/has issues, but that's a big lump of code to replace.
Or you could just use rsync over ssh instead:
And if the rsync dies, you just run the same command again.
Much less typing. :-)
Indeed. Bugfix releases for Java each get their own entry, while other major and infulential languages (with multiple implementations) get mentions only at major milestones.
Feh.
I suppose the lesson is this: You shouldn't ever expect to compile something like this chart, unless you are also ready to receive a lot of criticism.
23:28:02 up 449 days, 8:42, 1 user, load average: 0.00, 0.00, 0.00
That's the uptime for one of our Debian 3.0 servers. It would have been more, except for the office move, and need to install kernel security updates.
That box previous ran Debian 2.2. It has never crashed in 4+ years. Never.
The recipe is simple: solid hardware + a solid distro. (It is a Penguin Computing box, BTW.) I don't often buy from them though, because they are very expensive.
RoBB was a great game, lots of smooth-scrolling fun.
I don't think I ever fully beat it though. The air defense around the last factory was just too tough.
"Do you think it is economical for Linksys/Dlink/whoever to build an os/program for something that will sell for so little?"
Well, I don't know, but the point of my original post was that an OS-less device would be more secure since it would require reverse engineering for many exploits. It's possible that customers might be willing to pay more for a more secure device.
There are tradeoffs either way. If you don't put in an OS, then you're writing a lot of stuff from scratch. Goof up a detail, and you've got a security problem. There is a lot of accumulated wisdom built into some of the older codebases, especially the BSD TCP/IP stack.
As it is, these companies can't afford to do from-scratch development, and they can't afford to buy an OS. So they just use a Linux distro, often uCLinux.
I would like to see people (and companies) put a little more effort into inspecting the FOSS softwaer they have incorporated into their own products, and pushing back upstream any security fixes they make. That would be the best for everyone, except the black hats and skript kiddies.
No, the desktop solution won't fit in your bag.
But the PIC doesn't have built-in Ethernet, either. Sure, you can get a USB Ethernet adapter, but it is one more thing to carry around. An Ethernet chip, balun and connector cost in the neighborhood of $2 USD or less to manufacture, so they could have included it, or made a 2nd model which did for about the same price.
Other things to pay attention to include if it needs a wall wart (a.k.a. AC power adapter). Prolly does, so you kit size just increased again.
They are aiming the device for poor, rural areas, like China outside cities. Many of these places don't have land lines, so they might as well have left off the modem. Maybe put in a PCMCIA slot so that you could use it for Ethernet, modem, or GSM/GPRS modem card.
Decent try by AMD though. If this version sells, someone will do it much better.
That doesn't seem to make any sense to me.
In my view, it is a question of what the market wants. The market wants very complex router/firewalls, which support multiple routing algorthms, logging facilities, application proxies, and more.
By the time you start coding up all this stuff, you will need some kind of OS. To not have one is like trying to code with mittens on. Sure you can do it, but it isn't very effective or efficient.
Or you could just "buy" OpenBSD, which has as good a packet filter (pf) as I've seen. But then, I don't get out much, and I haven't dug into how sophisticated the proprietary solutions are. Still, even with OpenBSD, it has more features than I've had time to implement, like putting in a 2nd firewall machine and using CARP to keep the data flowing.
Shuttle, that's real flying too, not spam in a can like the Chinese flights.
No, sorry, they're still spam in a can with the Shuttle. Except that the pilot has to push a button to lower the landing gear. Otherwise, it is all computer controlled.
Don't just believe what you say in a James Bond movie. :-)
The main problem with EVs is (and always has been) the batteries. The batteries weigh a lot, and you need a bunch to get decent range.
The thing that was really supposed to fix the problem was energy storage using flywheels. These carbon-fiber flywheels are suspended using magnetic bearings, and are supposed to go up to 100K RPM. Combined with a high-efficency integrated motor-generator, it was proposed that ~ six of these would be able to power an EV with decent range. Overall, these flywheel systems are supposed to have a much higher energy density than most/any battery system.
But that was 1999. I haven't heard much about them since then. Guess it didn't work out.
That's a very interesting paper by Dessler.
I'll need to really read through it carefully. I must admit though, for whatever reason, I was really enamored with the idea that it wasn't the hydrogen which was the primary cause of the Hindenberg disaster. Not really sure why. There is probably a psychology lesson in there too.
My only initial criticism of that paper is that he keeps coming back to the Shuttle's SRBs. As if there aren't other types of solid rocket fuel in common use. I'd have wanted Dessler to refer more to another solid rocket system which had a formulation closer to the Hindenberg's skin composition.
Oh, please don't get me wrong. We definitely need to find better energy souces than digging up fossil fuels. However, terrestial solar power is an expensive option. You also need to consider how much pollution you will generate just to make the solar cells. I personally would like to see the federal government invest in research to make solar cells cheaper and more efficient. Not likely with the current administration, though.
And if you're going to compress hydrogen without liqufying it, that will still take a lot of energy. TANSTAAFL.
Hydrogen makes a poor energy transport because it is much less dense that other molecules.