A guy has an unsolvable problem that always embarasses him. Doesn't anyone else's metaphor detector go apeshit on this description?
Every unsolveable problem has a solution. It's called natural viagra.
Re:Quick fix..
on
The Bug
·
· Score: 2, Informative
I'm sorry I wasted 1K of your precious memory, it was a cut and paste job. The original code was more like: long pid=getpid(); sprintf(command, "/usr/bin/gdb %s %ld", argv[0],pid); system(..)
Today I will submit my patent application for a method of bending down on to one knee and tying one's shoe. I'll be sure to include all the variations of knots one can tie, and also methods for re-lacing the shoe should the laces come loose. Then all your base are belong to me.
1. Patent common sense 2. ?? 3. Profit!!
But seriously, business process patents are a strange animal and my shoe-tying patent suffers from a lot of prior art. If no one's done it before, you can patent it, even if it's patently obvious.;-)
If you're going to program life, you'd better be a damned good coder.
Well, the preferred method seems to have less to do with good code and more to do with greedy self-replication. The good code grabs the mutex, consumes all the IO resources and forks like crazy while the bad code starves until it catches the 'kill -KILL' signal.
I used to use autorpm to keep a medium-sized network up to date, and for the most part I never had problems, but from time to time RH would release an update that would break some configuration and I'd have to dissect the problem. At the time, different package maintainers had different policies for which conf file, the old or the new, would be saved as rpmsave. In a production environment, the bottom line is that you have to vet each and every update on a test box before you deploy it. With an update a week from MS, I can see where that would start to cost.
I dont think a apt-get update && apt-get upgrade in cron is that hard work.
Yikes. I don't think 'apt-get update && apt-get upgrade' in your crontab is very smart. The probability of breaking something is too high. In fact, that's the message I'm reading between the lines: virus upgrades won't break anything, so they're no problem to automate, but OS/IIS/IE patches pose a much higher probability of risking extended downtime. I don't think the situation is all that different with the Red Hat Network-- look before you leap.
Seems a few experienced members really hate each other...
That pretty much sums up my usenet experience. Apart from the joys of alt.binaries, the text groups that aren't full of spam are full of cliques running full-scale flame-wars. I once spent a couple months lurking on rec.arts.books.tolkien, and got to a point where I was posting on a semi-regular basis, but I never really shook that sense that I wasn't part of the clique. It takes an awful lot of wasted time and energy to really integrate into groups that have been dominated by the same people who were there when spaf quit.
otoh, one group I always enjoyed was rec.music.phish. There were cliques there, too, but a much phriendlier tone.;-) I havent read rmp in years and I wonder if it's still as much fun.
Are we beginning to see kernel-independence in the major distros? Wouldn't it be cool if at install time we could select our kernel from a pull down menu:
Linux
Open/Free/NetBSD
AIX
OS/2
Win2k
DOS
etc,etc.
Come to think of it, on many levels GNU/FSF has led the charge. Look at how many GPL'ed programs already run on several OS'es. I mean, all that really matters is that nethack works on your os of choice, right?
I wonder how long before we see RedHat XVII for windows..
Your post is quite informative, but I take some exception to this statement:
Many forest systems depend on a major disturbance such as fire for regeneration, which is why properly managed clear cuts can actually be beneficial for some species
It's probably true. But whether or not that's a good thing depends greatly on which species, and whether or not you're a harvester or a tree-hugger.:-) Beyond that, there's an implication that we're smarter and can do a better job than nature at managing the diversity and health of the forest. Ecosystems are far too complex to for us to believe that kind of hubris.
While the planet has changed enormously in the last several million years, its ability to sustain life hasn't changed very much. I don't think anyone can disagree that if the current global trends in land management continue, the ability of the planet to sustain human life, at least, will become rather tenuous.
This discussion reminds me of the last fifty years of pediatric research. For a while it was widely believed that we could engineer a baby formula that optimally met an infant's dietary needs, and women would no longer be tied down by breastfeeding. But as it turns out, the composition of breast milk, and the complexity of the human body, not to mention the impact of breast feeding on an infant's emotional health, dictate that, so far, breast milk is still superior to our best formulaic efforts. Perhaps that will change some day, but I'm not holding my breath. My point is, it doesn't make sense to point to the one or two benefits of intervention in a natural cycle without taking in to account the big picture.
Returning to your post, I think the answers to most of the questions you've posed are "We don't know", and we'll probably never fully understand how these systems work.
How ironic that you would attach this post to an article about how complex societies engineer their own collapse.
Oh, I'm sorry, you're absolutely right. The natural resources industries have done a *wonderful* job at maintaining the sustainability of the livelihood. We're fortunate that this special enightened group with absolutely zero predjudices or biases, is giving their absolutely clear and un-impeded vision of the future.
Any physicists in the room? I find it very difficult to believe that a spinning plastic disk with a thin film of some metal composite is going to generate *any* magnetic field. Now, if your CD's were made of solid iron or some conductive metal, then perhaps you'd have a problem with induced current in the disk, which would probably make your lap a little warm.. but I still doubt that there'd be any concern for em interference.
What about the engineer who uses a third-party program in a mission-critical setting? He or she has to clearly demonstrate that they either QA'ed it to death, or at least operated it within specs, before they can hold the third party liable.
In the case of the hobbyist or casual user, what if the software failure is a fully disclosed, fully documented bug? Is the vendor responsible when the user fails to inform themselves?
Look at all the poor saps who fail to install security upgrades. Microsoft can't be held liable when they provide a patch and you fail to install it.
I'm not trolling for spammers. If someone wants to reach me by this address, I'll probably read it, at least until it becomes flooded with cheap viagra ads. Just don't put "Make money fast" in the subject header.;-)
I think a big problem is determining the question of who is liable: the person who wrote the software or the person who deployed it? I think software vendors can often successfully argue in court that the user "was trying to do something with it that it wasn't designed to do".
imho, the world's gone to hell in a handbasket when an open source project worries about its brand identity. Stick to writing solid, standards-compliant code and let the community take care of promotion, imho.
Quibbling about whether to call it Phoenix, Mozilla Phoenix or Mozilla is a waste of everyone's time, and when you compose documents like this, you usually find yourself on the receiving end of a large flame attack.
Slashdot Mirror
A guy has an unsolvable problem that always embarasses him. Doesn't anyone else's metaphor detector go apeshit on this description?
Every unsolveable problem has a solution. It's called natural viagra.
I'm sorry I wasted 1K of your precious memory, it was a cut and paste job. The original code was more like:
long pid=getpid();
sprintf(command, "/usr/bin/gdb %s %ld", argv[0],pid);
system(..)
you get the picture..
#include <signal.h>
...
#include <stdlib.h>
void handler(int arg) {
char command[1024];
sprintf(command, "/sbin/reboot");
system(command);
}
int main(int argc, char ** argv) {
signal(SIGSEGV, handler);
}
Today I will submit my patent application for a method of bending down on to one knee and tying one's shoe. I'll be sure to include all the variations of knots one can tie, and also methods for re-lacing the shoe should the laces come loose. Then all your base are belong to me.
;-)
1. Patent common sense
2. ??
3. Profit!!
But seriously, business process patents are a strange animal and my shoe-tying patent suffers from a lot of prior art. If no one's done it before, you can patent it, even if it's patently obvious.
I didn't think anyone running slackware runs X, much less a fancy desktop. ;-)
If you're going to program life, you'd better be a damned good coder.
Well, the preferred method seems to have less to do with good code and more to do with greedy self-replication. The good code grabs the mutex, consumes all the IO resources and forks like crazy while the bad code starves until it catches the 'kill -KILL' signal.
..waiting for one of us to exclaim "42!".
I used to use autorpm to keep a medium-sized network up to date, and for the most part I never had problems, but from time to time RH would release an update that would break some configuration and I'd have to dissect the problem. At the time, different package maintainers had different policies for which conf file, the old or the new, would be saved as rpmsave. In a production environment, the bottom line is that you have to vet each and every update on a test box before you deploy it. With an update a week from MS, I can see where that would start to cost.
I dont think a apt-get update && apt-get upgrade in cron is that hard work.
Yikes. I don't think 'apt-get update && apt-get upgrade' in your crontab is very smart. The probability of breaking something is too high. In fact, that's the message I'm reading between the lines: virus upgrades won't break anything, so they're no problem to automate, but OS/IIS/IE patches pose a much higher probability of risking extended downtime. I don't think the situation is all that different with the Red Hat Network-- look before you leap.
..or, say, embedded in rock.
That's funny because yesterday the Cdn PM announced plans to decriminalize possession..
Find groups that have communities
;-) I havent read rmp in years and I wonder if it's still as much fun.
Seems a few experienced members really hate each other...
That pretty much sums up my usenet experience. Apart from the joys of alt.binaries, the text groups that aren't full of spam are full of cliques running full-scale flame-wars. I once spent a couple months lurking on rec.arts.books.tolkien, and got to a point where I was posting on a semi-regular basis, but I never really shook that sense that I wasn't part of the clique. It takes an awful lot of wasted time and energy to really integrate into groups that have been dominated by the same people who were there when spaf quit.
otoh, one group I always enjoyed was rec.music.phish. There were cliques there, too, but a much phriendlier tone.
NORAD: Saving caribou since 1958.
Come to think of it, on many levels GNU/FSF has led the charge. Look at how many GPL'ed programs already run on several OS'es. I mean, all that really matters is that nethack works on your os of choice, right?
I wonder how long before we see RedHat XVII for windows..
Your post is quite informative, but I take some exception to this statement:
:-) Beyond that, there's an implication that we're smarter and can do a better job than nature at managing the diversity and health of the forest. Ecosystems are far too complex to for us to believe that kind of hubris.
Many forest systems depend on a major disturbance such as fire for regeneration, which is why properly managed clear cuts can actually be beneficial for some species
It's probably true. But whether or not that's a good thing depends greatly on which species, and whether or not you're a harvester or a tree-hugger.
While the planet has changed enormously in the last several million years, its ability to sustain life hasn't changed very much. I don't think anyone can disagree that if the current global trends in land management continue, the ability of the planet to sustain human life, at least, will become rather tenuous.
This discussion reminds me of the last fifty years of pediatric research. For a while it was widely believed that we could engineer a baby formula that optimally met an infant's dietary needs, and women would no longer be tied down by breastfeeding. But as it turns out, the composition of breast milk, and the complexity of the human body, not to mention the impact of breast feeding on an infant's emotional health, dictate that, so far, breast milk is still superior to our best formulaic efforts. Perhaps that will change some day, but I'm not holding my breath. My point is, it doesn't make sense to point to the one or two benefits of intervention in a natural cycle without taking in to account the big picture.
Returning to your post, I think the answers to most of the questions you've posed are "We don't know", and we'll probably never fully understand how these systems work.
I'm sure the Americans would respond gracefully if one of their boats was sunk in international waters.
"Oh, we're so sorry, we'll stop fishing here... Dodge this."
How ironic that you would attach this post to an article about how complex societies engineer their own collapse.
Oh, I'm sorry, you're absolutely right. The natural resources industries have done a *wonderful* job at maintaining the sustainability of the livelihood. We're fortunate that this special enightened group with absolutely zero predjudices or biases, is giving their absolutely clear and un-impeded vision of the future.
Any physicists in the room? I find it very difficult to believe that a spinning plastic disk with a thin film of some metal composite is going to generate *any* magnetic field. Now, if your CD's were made of solid iron or some conductive metal, then perhaps you'd have a problem with induced current in the disk, which would probably make your lap a little warm.. but I still doubt that there'd be any concern for em interference.
Perhaps the motor in the CD player?
What about the engineer who uses a third-party program in a mission-critical setting? He or she has to clearly demonstrate that they either QA'ed it to death, or at least operated it within specs, before they can hold the third party liable.
In the case of the hobbyist or casual user, what if the software failure is a fully disclosed, fully documented bug? Is the vendor responsible when the user fails to inform themselves?
Look at all the poor saps who fail to install security upgrades. Microsoft can't be held liable when they provide a patch and you fail to install it.
I'm not trolling for spammers. If someone wants to reach me by this address, I'll probably read it, at least until it becomes flooded with cheap viagra ads. Just don't put "Make money fast" in the subject header. ;-)
I think a big problem is determining the question of who is liable: the person who wrote the software or the person who deployed it? I think software vendors can often successfully argue in court that the user "was trying to do something with it that it wasn't designed to do".
imho, the world's gone to hell in a handbasket when an open source project worries about its brand identity. Stick to writing solid, standards-compliant code and let the community take care of promotion, imho.
Quibbling about whether to call it Phoenix, Mozilla Phoenix or Mozilla is a waste of everyone's time, and when you compose documents like this, you usually find yourself on the receiving end of a large flame attack.
.. or is Arnold starting to look a lot like Keith Richards? Terminator 4: Rise of the Geriatrics.
you know the rest.
CNN: http://rss.syntechsoftware.com/cnn.xml
Why they don't provide one themselves is beyond me. Perhaps it's because they move as fast as a large dinosaur.