That is precisely when the SEC would step in. Burn your company to the ground, no problem. Profit from it while disadvantaging shareholders and you win a 2 year stay at club Fed.
Oh wait, Dubya's still in the whitehouse. Never mind.
I just had a cheery (?) vision of SCO's legal team as an army of the Undead, lashed to the case they had started, and unable to find the peace of the grave until the case is over.
It was quite disturbing, and funny at the same time.
I hear a few of the drug companies are negotiating with IBM to begin medical tests using excess members of their legal department. The reasons are threefold:
Lab rats of good pedegree are becoming scarce, there is no shortage of lawyers at IBM.
Technicians sometimes develop an attachment an emotional attachment to the rats. This should not be the case for lawyers.
There are some things a rat just won't do.
Yeah, just a rebadge lawyer joke. The Jargon file has an amusing entry about Lion Food
Two lions who, escaping from the zoo, split up to increase their chances but agree to meet after 2 months. When they finally meet, one is skinny and the other overweight. The thin one says: "How did you manage? I ate a human just once and they turned out a small army to chase me -- guns, nets, it was terrible. Since then I've been reduced to eating mice, insects, even grass." The fat one replies: "Well, I hid near an IBM office and ate a manager a day. And nobody even noticed!"
Reminds me of the idiot in the monster movie who makes faces at the creature when he think's its penned up, only to spend the next scene screaming their head off in terror before snuffing it horribly.
Come on, in this instance at least there's no need to kick creationists. If someone told you that creationists don't believe things can adapt or mutate then they're stupid, that isn't the case at all, and that really isn't evolving. The only time creationists would have a problem is when that dandelion mutates to the point that it is not infact a dandelion any longer, which creationist would argue is impossible to occur.
To their credit, Monsanto DID voluntarily declare they wouldn't use the terminator genes. For an undeclared period. But they've have been granted the patents on them, so it's an ace they can still play.
Seriously, I can write a kernel in a day, in x86 assembly. Give me a week and I can make it do proper multitasking and write a shell and a few proof of concept apps. What's keeping them?
Probably the fact they thought they could write the kernel in a day and it was only going to take a week to write...
I program for a living. Writing something in a week doesn't impress me. Writing something that is useful for more than a week, that is what seperates the mental fappers from the real programmers.
little Endian addressing, 8 registers to play with, backward compadibility to an 8 bit processor, Intel has always been known as the first with the worst.
But if you have the budget to be building something that requires precise timing, you have the budget to use a processor with a real-live MMU.
uCLinux is designed for the hobbiest for whom the concept of "realtime" is a little more fluid, or for low-cost appliances where price trumps performance.
As far as aircraft navigation systems go, it's right up there with Nuclear reactor control on the "Don't Go There" list for just about every consumer device manufactured. The Windows operating system has warnings about it in the EULA.
First off, servers take SATA or SCSI, not the cheepy IDE drives you find on the net. Second, even if you could find equivilent sizes for equivilent prices for server-grade stuff, I can't speak for everyone, but users don't store anything on my network that isn't on a RAID. 2 drives for a RAID-1, 3 (at least) for RAID-5.
Assuming that cost isn't an issue, and you have a miraculaous RAID controller that is easy to program, you run into the problem of how to hook up the new drives. If you don't have enough bays and connectors you have to drop your old hard drives to tape, plug in your new drives, and restore.
The last time I did a restore of 160GB it took 48 hours with a DLT autoloader. AIT might cut that down to 12 hours. But that's still a long time to be without data.
I'll save the isues about premature failure on these uber-mega drives for another discussion.
Now I insist our users use IMAP for email. Too many bad experiences of desktops croaking and taking all of a user's POP mailboxes with it. Making your system catalogue several gigabytes of email per user is going to slow things to a crawl, unless you are using something enlightened like maildir. Even then, you are going to be hell bent to find a file system that effiently handles both uber-mega attachments AND a few million tiny text files for individual messages.
All for what? So some user doesn't have to be bothered to clean out their mailbox?
No problem, except the next thing El' numbnuts is going to ask for is a tool to actually FIND something in all that mess.
As a network administrator I just have to do a paternalistic scowel at you.
2.3 gig of email. Dear god our server only has a 20 gig hard drive. I'd be camped out at your office (or send a coop to camp in your office.) and make disparaging remarks about "bloat" until you trimmed up a bit.
If everything is important, nothing is important. 32,000 messages means you aren't real picky.
"Realtime" to a human operator is half a second. That's eternity to even the slowest modern processor. The fastest someone can double click a button is about 0.17 seconds.
"Realtime" to an HVAC system is 5 minutes. (Furnaces and AC units can't safely handle changes in smaller increments.)
"Realtime" to a weather station is 15 minutes. (Weather doesn't change much faster than that.)
Considering most embedded apps are one-trick ponies, not a whole lot. Vending machines, security cameras, most robotics projects, they are even driven tasks. You are running an app that quietly waits for an interrupt event (a keystroke, a signal on one of it's inputs to change) and then respond as quickly as possible.
I wouldn't run any kind of graphical application. Assuming you could outfit the things with a video card. They would also make crummy real-time processing units. (Real-time OS's ration processor time so that you can gaurentee the sensors are checked exactly at x interval.)
In short, they can't walk and chew gum at the same time.
Of I'm not writing code for space missions, just medical devices.
Yup. And you don't want to be naked in the wind in a product liability suit. Say what you will about commercial software, every one of them washes their hands of product liability.
Much better to go with something that can be repeatably tested and eternally supported. A stack of real-live tests trumps any gaurantee from the manufacturer.
Slashdot Mirror
Oh wait, Dubya's still in the whitehouse. Never mind.
It was quite disturbing, and funny at the same time.
IBM's legal team aren't called the Nazgul for nothing.
Yeah, just a rebadge lawyer joke. The Jargon file has an amusing entry about Lion Food
Two lions who, escaping from the zoo, split up to increase their chances but agree to meet after 2 months. When they finally meet, one is skinny and the other overweight. The thin one says: "How did you manage? I ate a human just once and they turned out a small army to chase me -- guns, nets, it was terrible. Since then I've been reduced to eating mice, insects, even grass." The fat one replies: "Well, I hid near an IBM office and ate a manager a day. And nobody even noticed!"
Reminds me of the idiot in the monster movie who makes faces at the creature when he think's its penned up, only to spend the next scene screaming their head off in terror before snuffing it horribly.
Ok. So at what point did dogs stop being wolves?
I was actually saving my Roundup-Resistant crabgrass for that.
Patents expire, you know.
Don't blame me, I voted for Kodos.
Yup. You can dry hump a crucifix on network TV, but god help you if you flash some nipple.
He was hoping a Zion ship would pick him up.
He has been living in his head for so long, he thinks the CC in "success" is a K sound.
Be on the lookout of the CG dinosaurs in every scene too.
My wife hated it, but then again, she hated Blade Runner too.
She is addicted to CivIII, and there is no Linux port. She behaves after that for a few months...
Seriously, I can write a kernel in a day, in x86 assembly. Give me a week and I can make it do proper multitasking and write a shell and a few proof of concept apps. What's keeping them?
Probably the fact they thought they could write the kernel in a day and it was only going to take a week to write...
I program for a living. Writing something in a week doesn't impress me. Writing something that is useful for more than a week, that is what seperates the mental fappers from the real programmers.
little Endian addressing, 8 registers to play with, backward compadibility to an 8 bit processor, Intel has always been known as the first with the worst.
Well, the Mach kernel is available for x86, the Linux kernel is available for PPC. Run the same app under BSD and Linux on both architectures. QED.
But if you have the budget to be building something that requires precise timing, you have the budget to use a processor with a real-live MMU.
uCLinux is designed for the hobbiest for whom the concept of "realtime" is a little more fluid, or for low-cost appliances where price trumps performance.
As far as aircraft navigation systems go, it's right up there with Nuclear reactor control on the "Don't Go There" list for just about every consumer device manufactured. The Windows operating system has warnings about it in the EULA.
First off, servers take SATA or SCSI, not the cheepy IDE drives you find on the net. Second, even if you could find equivilent sizes for equivilent prices for server-grade stuff, I can't speak for everyone, but users don't store anything on my network that isn't on a RAID. 2 drives for a RAID-1, 3 (at least) for RAID-5.
Assuming that cost isn't an issue, and you have a miraculaous RAID controller that is easy to program, you run into the problem of how to hook up the new drives. If you don't have enough bays and connectors you have to drop your old hard drives to tape, plug in your new drives, and restore.
The last time I did a restore of 160GB it took 48 hours with a DLT autoloader. AIT might cut that down to 12 hours. But that's still a long time to be without data.
I'll save the isues about premature failure on these uber-mega drives for another discussion.
Now I insist our users use IMAP for email. Too many bad experiences of desktops croaking and taking all of a user's POP mailboxes with it. Making your system catalogue several gigabytes of email per user is going to slow things to a crawl, unless you are using something enlightened like maildir. Even then, you are going to be hell bent to find a file system that effiently handles both uber-mega attachments AND a few million tiny text files for individual messages.
All for what? So some user doesn't have to be bothered to clean out their mailbox?
No problem, except the next thing El' numbnuts is going to ask for is a tool to actually FIND something in all that mess.
2.3 gig of email. Dear god our server only has a 20 gig hard drive. I'd be camped out at your office (or send a coop to camp in your office.) and make disparaging remarks about "bloat" until you trimmed up a bit.
If everything is important, nothing is important. 32,000 messages means you aren't real picky.
"Realtime" to a human operator is half a second. That's eternity to even the slowest modern processor. The fastest someone can double click a button is about 0.17 seconds.
"Realtime" to an HVAC system is 5 minutes. (Furnaces and AC units can't safely handle changes in smaller increments.)
"Realtime" to a weather station is 15 minutes. (Weather doesn't change much faster than that.)
I'm thinking of a Linux box in the shell of my old TI-85. It was a pretty chunky calculator, and I've always wanted to use it as a PDA.
I wouldn't run any kind of graphical application. Assuming you could outfit the things with a video card. They would also make crummy real-time processing units. (Real-time OS's ration processor time so that you can gaurentee the sensors are checked exactly at x interval.)
In short, they can't walk and chew gum at the same time.
Yup. And you don't want to be naked in the wind in a product liability suit. Say what you will about commercial software, every one of them washes their hands of product liability.
Much better to go with something that can be repeatably tested and eternally supported. A stack of real-live tests trumps any gaurantee from the manufacturer.