While I consider the exact cause of the accident important, I've seen a few articles here and there hint that engineers concerns don't make it to or get considered properly by NASA management. And while this kind of bungling may just be annoying for most of us, it's not something that should be tolerated when people's live are at stake. In fact we could even draw congress into this mess since they're the ones who cut NASA's budget. So in my humble opinion, the root cause of the problem hasn't changed since the Challenger iccident.
1. This seems like it might be a special case. The samples in question are layerd and thus have a greater chance of being compressable. I wonder how well a tree would do.
2. As far as I can tell they are not pictures of life but rather the effects of life. The results may come out differently when the pictures were of actuall living things.
3. If for some reason an image gets compressed by a lossy compression scheme then the data has to be thrown out.
Sorry Sendmail still sucks. This vast feature set set is why I use sendmail but it still sucks.
1. The sendmail configuration system is outdated. It cryptic from ground 0 and doesn't get any better. Perhaps this what important back in the day but now its just stupid.
2. The documentation is outdated. The defacto source for sendmail information is the O'Rielly Senmail boo, but Sendmail has made a few revs since then. There are important items missing from the book. Although I can and have hunted down the info I need online and in the source, it's a poor substitute.
3. I'm not really fond of the sendmail code in and of itself. It's written in a poor style. If the function is a few screen fulls and there are hidden variable declarations of single character variables used a few sreens down, it sucks. Personnally I believe if a function grows to a few screen fulls it's a sign it needs to be shot.
I think the problem is windows developers are still indoctrinated in the point and click mentality. They seem to think that since a tool requires typing it must be worse. Personally I've found that the bottle neck caused by having to use the mouse so often is crippling. I find that windows desperatlely needs tools like 'find' 'grep' 'sort' and 'bash'. Not to mention the Windows window manager is a bottle neck all of it's own. With a typical window manager I can map each destop to it's on key combo to acces desktops and windows directly rather than sequentially.
I think it says alot that I who still hunt and peck for my typing find the command line to be a faster interface. Ok it's not a pure hunt and peck any more but I can't type without looking.
This really isn't all that hard a problem. Mangle the SAX processor to build a DOM tree for each record and when you get a closing tag call a doSomething function. Put it in a library and now all you have to do is write the proper doSomething functions for your tasks.
Or you could just url encode your XML record and put one per line. It's not very elegant or standard. But it'll work and should be dirt easy to impliment.
1. Use a mail filter. 2. Every once in a while enter the "I'm interested" email address or inlink into a database. 3. Have a junk submission program send it some junk. For Nigerian scams you could forward them all your collected spam.
Basically the idea is to keep out of you inbox and at the same time hurt the Spammer.
I've seen more cases of people bein biased towards scripting languages. If it were up to me I probably wouldn't hire someone who didn't know C or someother language at a similar level. And thats not because I'm against scripting languages, I just feel that learning to deal with languages which don't hold your hand is good mental training. I've found different languages encourage different ways of thinking. The more ways of thinking someone encounters the better their chances of solving a problem.
That having been said I find that Perl is more that sufficient for most tasks. And CPAN is the best thing since sliced bread.
Yeah.. But CGI is EVIL. at least without a decent templating system. And I'm not that big a fan of the source code in HTML model used by things like PHP. Where I work we use XML and XSLT to seperate content , machanics, and formatting. It's enough to make web progamming sexy. Not as sexy as low level bit twiddling but hey what is? Oh yeah.... low level bit twiddling with girls (either context works).
1. possibly 2. oh yeah! I'd be really paranoid about this bit. It would have to be opend source so continuous and wide spread code review was possible. I'd also be happier if cirtical parts if not all of it were proven correct.
Actually making a linux system ready for Joe sixpack isn't that hard. Most of the applications already exist. It's really just a matter tieing it all together. In fact I would argue, Joe Sixpack is actually easier than the "power user".
1. Joe probably won't ever upgrade his OS. 2. A script wrapped around "apt" would handle upgrades fairly well. It could probably be a one click process. 3. You probably don't need too many features or options.
The poeple Linux isn't ready for are the "power users". These are the people who know how to tweak windows to do what they want. Many of these people don't want to learn a new system.
Slashdot Mirror
While I consider the exact cause of the accident important, I've seen a few articles here and there hint that engineers concerns don't make it to or get considered properly by NASA management. And while this kind of bungling may just be annoying for most of us, it's not something that should be tolerated when people's live are at stake. In fact we could even draw congress into this mess since they're the ones who cut NASA's budget. So in my humble opinion, the root cause of the problem hasn't changed since the Challenger iccident.
1. This seems like it might be a special case. The samples in question are layerd and thus have a greater chance of being compressable. I wonder how well a tree would do.
2. As far as I can tell they are not pictures of life but rather the effects of life. The results may come out differently when the pictures were of actuall living things.
3. If for some reason an image gets compressed by a lossy compression scheme then the data has to be thrown out.
Sorry Sendmail still sucks. This vast feature set set is why I use sendmail but it still sucks.
1. The sendmail configuration system is outdated. It cryptic from ground 0 and doesn't get any better. Perhaps this what important back in the day but now its just stupid.
2. The documentation is outdated. The defacto source for sendmail information is the O'Rielly Senmail boo, but Sendmail has made a few revs since then. There are important items missing from the book. Although I can and have hunted down the info I need online and in the source, it's a poor substitute.
3. I'm not really fond of the sendmail code in and of itself. It's written in a poor style. If the function is a few screen fulls and there are hidden variable declarations of single character variables used a few sreens down, it sucks. Personnally I believe if a function grows to a few screen fulls it's a sign it needs to be shot.
I think the problem is windows developers are still indoctrinated in the point and click mentality. They seem to think that since a tool requires typing it must be worse. Personally I've found that the bottle neck caused by having to use the mouse so often is crippling. I find that windows desperatlely needs tools like 'find' 'grep' 'sort' and 'bash'. Not to mention the Windows window manager is a bottle neck all of it's own. With a typical window manager I can map each destop to it's on key combo to acces desktops and windows directly rather than sequentially.
I think it says alot that I who still hunt and peck for my typing find the command line to be a faster interface. Ok it's not a pure hunt and peck any more but I can't type without looking.
This really isn't all that hard a problem. Mangle the SAX processor to build a DOM tree for each record and when you get a closing tag call a doSomething function. Put it in a library and now all you have to do is write the proper doSomething functions for your tasks.
Or you could just url encode your XML record and put one per line. It's not very elegant or standard. But it'll work and should be dirt easy to impliment.
I think there might be an solution here.
1. Use a mail filter.
2. Every once in a while enter the "I'm interested" email address or inlink into a database.
3. Have a junk submission program send it some junk. For Nigerian scams you could forward them all your collected spam.
Basically the idea is to keep out of you inbox and at the same time hurt the Spammer.
I've seen more cases of people bein biased towards scripting languages. If it were up to me I probably wouldn't hire someone who didn't know C or someother language at a similar level. And thats not because I'm against scripting languages, I just feel that learning to deal with languages which don't hold your hand is good mental training. I've found different languages encourage different ways of thinking. The more ways of thinking someone encounters the better their chances of solving a problem.
That having been said I find that Perl is more that sufficient for most tasks. And CPAN is the best thing since sliced bread.
Perhaps it's time credit cards went public key. That way you could sign the transaction rather than just handing out the magic number to you account.
Yeah.. But CGI is EVIL. at least without a decent templating system. And I'm not that big a fan of the source code in HTML model used by things like PHP. Where I work we use XML and XSLT to seperate content , machanics, and formatting. It's enough to make web progamming sexy. Not as sexy as low level bit twiddling but hey what is? Oh yeah.... low level bit twiddling with girls (either context works).
1. possibly
2. oh yeah! I'd be really paranoid about this bit. It would have to be opend source so continuous and wide spread code review was possible. I'd also be happier if cirtical parts if not all of it were proven correct.
Actually making a linux system ready for Joe sixpack isn't that hard. Most of the applications already exist. It's really just a matter tieing it all together. In fact I would argue, Joe Sixpack is actually easier than the "power user".
1. Joe probably won't ever upgrade his OS.
2. A script wrapped around "apt" would handle upgrades fairly well. It could probably be a one click process.
3. You probably don't need too many features or options.
The poeple Linux isn't ready for are the "power users". These are the people who know how to tweak windows to do what they want. Many of these people don't want to learn a new system.