First, always read employment contracts before signing them. If an employer doesn't want to give you a chance to carefully review the contract or have your lawyer look over it, assume they're trying to pull something sneaky. If you think you really must sign a non-compete, make sure it's very limited in scope.
If you work with computers, chances are that it's very hard to find a job doing the same thing you do now without it competing at some level.
For instance, most of my work over the past several years has been building stuff for use on websites. With a broad non-compete, that means the competition is any company that has any kind of website at all (since the competition is for user attention). There's no way I'd sign an agreement to not work for companies with websites for 2 years after leaving a company; I'd be out of work for 2 years.
Currently I happen to work for a dating site. If the offer to work at this dating site had been attractive enough, I might have been willing to agree not to work for another dating website for 6 months after leaving.
Also, overly broad non-compete agreements probably won't stand up in court because they can restrict you from working in your chosen field at all. So MSFT may not be able to win this suit since they're regarding all software companies as competition. That kind of employment law can vary a lot between states, though; I'm most familiar with California's and I am not a lawyer.
If you are intent on breaking into a machine to which you have no access, a port scan is the first step.
For any kind of attack (whether with guns or with computers), reconnaissance is the first step.
If you're not the DoD, though, I wouldn't worry about portscans. I don't count them as attacks just because they're so common. Besides, if I have a machine that runs several websites (some of which have files available for download), how much of an "attack" is it to scan to see if FTP is open? It could just be somebody who got a partial file download and wants to see if they can finish the download.
Also, with most of your machines, there is *some* kind of legitimate access the public has to it. The SMTP port or HTTP or something like that. For many DoD machines, there is *no* legitimate access for most of the public.
Only 5 a *week*? Wow. That's low. I think the main machine I do any admin for gets that many in an hour.
I'm sure part of it was simply momentum. That is, it was in the classified archives, why dig through them looking for stuff to declassify?
Another part, though, is that after WWII, some British allies were given Enigma machines and some of those were in use until some time in the 70s. (of course, that doesn't explain the other 20+ years, but it gets you more than half way)
And I'm sure when it first got classified, they had absolutely no idea how far computer technology would advance, or probably even if it would ever make it outside of secret government installations.
[...]first thing I did on taking over someone's site admin was change the passwords from plain text in the cookies and db to crypt()[...]
[...]the way I have it currently set up is a problem. Someone could grab a copy of the local encrypted cookie, then use it to connect as the user from then on.
If you have a piece of data that can be used as-is to authenticate, then you have what we usually call "plain text passwords". At least, what you're storing is plaintext. Scrambling it a little to confuse people and not letting people use that password on a web form doesn't really buy you much security. Of course, these days, crypt() and lousy passwords doesn't get you very good security, either...
IOW, your solution doesn't help any. If they get the password db, they can log in. Okay, okay, maybe brain-dead script kiddies can't.
If you don't like the new disclaimer, all you can do is quit.
That's not entirely true. Instead of quitting you can threaten to quit. Or you can write a letter complaining about the situation without including resignation threat.
Quitting fixes the situation outright, by removing yourself from it.
Threatening to quit or complaining (or, preferably, both together) works far better if everybody does it. You can even do things like not show up for work until they agree to stop. One term for it, if you do it all officially, is "forming a union".
Hey, at least they're nice enough to warn; no requirement for that. They could do it legally with no disclaimer.
Well, there's A.root-servers.net through M.root-servers.net, which are hosted all over the world. Usually only DNS servers contact them, and there's already built in "round robin" and retries. So, if A.root-servers.net was to go down, at worst, 1 out of 14 queries to domains that hadn't previously been queried would get delayed by a short period of time. (IOW, if you do a lookup on foo.domain.com, your DNS server would cache domain.com's NS info and your query for bob.domain.com would use that instead of hitting the root nameservers.) However, I think the DNS servers would cache the information about the failure talking to a.root-servers.net and stop asking it things for a while.
In other words, DNS has failover built in.
However, if the server stayed down for an extended period of time, it would probably cause updates not to happen. I suspect they could get a new server in place for that purpose within a reasonably short period of time, though.
First off, databases look for connections to a port, just like any other service like httpd, smtp or ssh. Doing things so that you have failover and/or load-balancing on *that* is easy. There are a large number of solutions, from application level to library level to dedicated hardware to general purpose software (LVS).
That said, database failover is *not* easy.
The basic problem is that you don't just read from a database, you read and write to the database. Database replication is a very non-trivial thing to do. You have to deal with the possibility of data being inserted, updated or removed from any of the servers that are involved. This requires that you have things like global locks, timestamps on everything, primary keys that are generated in a way unique to each replicated version of the database, etc.
Most of the work of replication is handled very nicely by the big commercial databases (but you will find that they want you to pay for it.), but even with those you might have to make minor changes in your application (or maybe just the database structure) in order to handle replication properly...
AFAIK, there's nothing you can get for free that will be able to handle any kind of real-time n to n (or 1 to n and n to 1 simultaneous, even) replication. You can do stuff like have mysql dump a log of everything that's done that changes the database, and then import those changes into another mysql instance someplace else; but that's nowhere near what the big commercial databases can do when it comes to replication.
Given that replication is gonna cost real money, just get your free database running on a good-quality machine with good backups (that you make sure include the database) and maybe things like redundant power supplies. You can make a really robust box for much less than Oracle will charge you to license 2 instances with replication.
(Or hire a team of 10 database programmers to spend a year or 3 adding replication to postgresql. Well... maybe they could do it wrong in a month -- I'm trying to give a wild estimate for doing it vaguely close to right.)
It's actually one very large novel that's split between multiple books. Book bindings can't readily be made that can hold as many pages as it would require.
(Good though -- I've eagerly read every book as soon as I could get my hands on it)
This robot is emulating an ape (such as a gibbon) and not a monkey.
Monkeys generally walk *on* the branches and leap from branch to branch. (Sometimes hanging from the branches to grab things, etc.)
Apes are the critters that brachiate. Brachiation allows the animal moving around in the trees to be larger than if it leapt from branch to branch. (Of course, some of the "greater apes" (orangutan, gorilla, chimpanzee and us...) got big enough that they rarely go up in trees anymore -- a full grown silverback male gorilla would break most trees if it tried to climb them)
I guess "robo-ape" doesn't sound as good as "robo-monkey" -- especially since most people think of gorillas and not gibbons when they hear "ape".
Y2K bug has already hit for some systems -- systems with a need for near-term future dates.
I think we'll see some stuff starting 12 hours before midnight GMT (4am PST) out in the pacific, and some stuff sweeping, hour by hour across the planet, with a spike at midnight GMT due to stuff all over the planet running on GMT and then further stuff happening on the hour as local midnight wanders past more locations...
We'll also see some issues that don't come up until Monday morning when people go to work... Maybe some stuff on March 1 for code that doesn't handle that leap year correctly...
Overall, though, it's likely to just be minor glitches -- rural and third world power outages, but no (or few) major metropolitan areas without power; small airports with problems, but the international airports will be fine... etc. (there's also the terrorists and script-kiddies to worry about, who'll do it whenever they feel like it, likely midnight local time.)
I'd suggest either an Intel EtherExpress Pro or a card based on the DEC Tulip chipset instead of the 3c905 card... The Linux drivers for either of those seem to be better done (especially with SMP, though this is probably fixed now) than the 3com driver.
The reason a corporation goes public is in order to get money that they can use for some purpose. The more money, the better. (Especially if they can make more money without issuing more stock, since issuing stock dilutes the value of current shares of stock)
If a corporation were, say, to go public with 1 million shares of stock and the IPO price is $10, then they get 10 million dollars. If the price then leaps up to $20/share, there's another 10 million dollars that they could have gotten (since that's the market value for the stock and they could have issued at that price instead and sold it all.)
If VA Linux didn't need money for something, they wouldn't issue public stock. VA Linux is doing it to maximize the amount of money they get from investors in order to do something (open more offices? ramp up business? hire new people to develop new products? who knows?) while trying to minimize the dilution of the stock to the current (non-public) shareholders/owners of the company.
However, SCSI drives reserve dead space and move the contents of bad sectors to a reserved sector and remap the bad sector to point at the previously reserved sector.
IOW: SCSI drives hide physical defects on the media from you, where IDE drives require the OS to deal with the problem.
First off, it's not clear from your post how heavily loaded the drives really are.
In particular: load is a measure of how many processes are using or waiting for a resource (such as disk I/O, CPU or network I/O). On a busy mail server that's completely adequate for the job, I'd expect to often see a high load average due to the number of processes that are waiting on the network. That is, due to the number of processes waiting for slow network connections to places halfway around the world.
All you mention is the load averages and a fairly non-specific measure of drives that are "cranking away constantly". If the drives were being used at a current constant 10% of available I/O, they'd tend to "crank constantly" even if they could be hit much harder. (still, given that losing email is considered bad by customers, a RAID 5 solution seems like a good idea anyways and leaves you room to grow and handle sudden increases in email from the holidays or spammers or gradual expansion of business)
As to IDE vs. SCSI -- never go with straight IDE on a server. SCSI has the ability to lie to the OS and silently move data from sectors that have gone bad into sectors reserved for that purpose. Sure, it slows down access to that particular block of data, but it's a lot easier than the OS having to deal with failures directly. However, I'm completely unfamiliar with the strange SCSI - EIDE setup that you're describing -- if it treats them as just physical media and provided the SCSI interface itself, it may be able to do that particular SCSI trick, as well. Physically, SCSI drives and EIDE drives are identical -- as in, you can find the *exact* same drive from certain manufacturers, only one has SCSI and the other EIDE. Reliability of the physical media is the same, IOW. In a normal configuration, *apparent* physical reliability is higher for SCSI due to wonderfully useful trickery.
I don't recall the exact model numbers, but I've seen pretty good results with Mylex RAID controllers before. (more along the lines of database stuff than what you're talking about -- somewhat different needs, but not all *that* different, I suppose.)
I can't see putting two partitions on one RAID device as making a lot of sense -- since things are striped you'd end up running into contention issues.
IOW: I'd guess that option #3 would be the fastest -- it's also probably the most expensive.
If I were you, I'd check more carefully to determine how much of the currently available disk I/O is actually being used... If the budget allows it, the dual-channel RAID solution sounds pretty good. You might want to go with two single-channel RAID cards instead -- makes it easier to stock a backup card in case a card decides to die. Try and get something with hot-swappable drives, too. It makes the RAID stuff so much more useful.
Also, I don't know the details of your setup (of course), but seriously consider breaking the mail serving task into separate pieces and run it on separate machines.
You have: 1) incoming email 2) outgoing email 3) email from customers 4) email customers pick up (POP)
It sounds like you have one machine handling all of these. Breaking these tasks onto separate boxes (If you've made the mistake of telling customers the same thing for #3 and #4 (ie, mail.isp.net instead of mail.isp.net and pop.isp.net) it might be impossible to split those two tasks away from each other)
You can have a setup such as: outgoing1 through outgoingN all behind the single name of "outgoing" that internal machines are told to send email to that they don't know how to deal with mail1 through mailN all behind "mail" that customers are told to have as their outgoing mail server. In particular, it should blindly send off email it doesn't know how to deal with to outgoing. pop (harder to break into separate machines, but possible) incoming1 through incomingN with MX records pointing at them for your domain.
Now, breaking into that many machines is probably silly. Moving outgoing to one machine and everything else to a second machine (and possibly mailing lists off to a third machine) may make a *lot* of sense though. Don't get tied into the idea of a monolithic machine to accomplish everything related to a particular task -- eventually it's much more expensive than many cheaper boxes to handle the same task.
Also, AT&T went through the same thing, got split into the Baby Bells and individually in their own markets they are still a powerful force. There is even talk about some of them merging back together again.
"Talk"? An example: There was once Southern Bell, Western Bell and Pacific Bell. Southern Bell and Western Bell merged a while ago, forming Southwestern Bell. Not all that long ago, they acquired Pacific Bell, so all three "Baby Bells" are now part of one larger company.
If the effect of cell-phone use is fairly small, I'd expect that we wouldn't notice anything.
In particular, there's a 3-way correlation that would make it very hard to study memory loss problems on cell phone users without actually setting up a proper experiment with a control, etc.
1) Cell<->Stress. People with busy (therefore stressful) lives tend to be much more likely to carry cell phones. (Or you could say that cell phone users are the people more likely to be leading stressful lives -- whatever.) I only have anecdotal evidence, but I suspect it could be found to be more general with a little bit of research. Also, Cell phones can be stressful. Either way, increased usage would tend to be associated with increased stress.
2) Stress<->Memory Problems. There is research indicating that stress has a negative effect on memory. (And I've noticed this personally, too)
3) Cell<->Stress<->Memory Problems. So, people with cell phones are likely to have memory loss problems without it being caused by the cell phone. (Instead both cell phone use and memory loss stemming from a stressful lifestyle)
And, note: I don't mean to say that all cell phone users are stressed. Personally, I find that once things like cell phones are recognized as being solely for the convenience of the person carrying it (and therefore it's ignored if inconvenient to answer it or the caller-id shows that it's an annoying person, people that abuse it are beaten until they stop, etc.) a cell phone is a handy convenience.
Here's a sample from their random Echelon jammer message generator:
From: Colonel Robert Worley, 50th Operations Group Commander, USAF
To: Director, Federal Emergency Management Agency
Ussama bin Laden made a broadcast this morning. We just got translation back and they're claiming that they will get agents to insert malicious code in year 2000 fixes Waco next week Additionally, The Commander in the 850th Communications Squadron passed on some new information. Theyve no choice other than to buy some documents from the JNTF contact when she's in Auckland tomorrow. Further to that, We're going to inflict minimal casualties on DoD personnel at London just before changeover to 2000. Finally, If we're to succed in halting the INFOSEC community, theres no better time than now to drive a tanker full of fertiliser and diesel across the border from Mexico then fly out to Manchester next week
I've got a collection of MP3 files (ripped and encoded from my CDs) and I usually listen in random order, skipping a track if it doesn't match the currently desired mood.
The collection includes: Alice In Chains, Ani DiFranco (including more than one album involving Utah Phillips), Annie Lennox, Metallica (and Apocalyptica doing Metallica), a little Beethoven, some Cherry Poppin' Daddies, "Cry Cry Cry", Dar Williams, Dead Can Dance, Deep Forest, Depeche Mode, Eric Clapton, some Eurythmics, Fields Of The Nephilim, Fiona Apple, Front Line Assembly, Garbage, Heather Nova, Hole, Information Society, Joan Osborne, KMFDM, Live, Madonna's latest album, Massive Attack, Ministry, a little Mozart, NIN, PJ Harvey (she's great!), a little Primus, a little REM, Rage Against The Machine, Richard Shindell, Rob Zombie, a little Sade, Sarah McLachlan, Skinny Puppy, Squirrel Nut Zippers, Sting, a small amount of The Cardigans, a couple Toni Braxton songs, Tricky, Tool, and a rather thorough collection of Tori Amos.
In other words, I listen to Industrial, "Rock", Folk, Metal, "Pop", Techno, Swing, some R&B, a little classical (there's also some Wagner that I haven't been listening to much recently, so hasn't made it into the archive yet) with a strong dose of female vocals in there... When I'm busy coding, I'm more likely to stick with the "heavier" or more "active" stuff (Ani DiFranco, Garbage, Hole, Information Society, KMFDM, Massive Attack, Tricky, Metallica, Ministry, NIN, White Zombie, some Tori Amos, etc...)
Would we have then reached the final/ultimate speed limit?
Before that happens, we need to concentrate on our algorythems and develop better compression. Sure people are getting rid of compression just cause there is mode bandwith.
You're doing the same thing that a lot of the general populace does, and getting latency mixed up with bandwidth.
Latency is how long it takes for an individual packet of data to get from one place to another.
Bandwidth is the total amount of data you can get from one place to another.
A little comparison: if you had a large plane that had a top flight speed of about 300 mph (mach 0.4) and could carry 1000 passengers and you also had a jet fighter that could travel at just over mach 4 (3000 mph) and transport a single passenger. Most people would agree that the jet fighter was "faster" in a very real sense than the large plane (by a factor of 10). However, with two cities 1000 miles apart, (ignoring time spent loading, unloading, refueling, etc.) the large plane could transport 2000 passengers in 10 hours (3.3 hours per one-way trip) while the jet fighter could transport 15 passengers. With vehicles, carrying capacity (bandwidth) and speed (low latency) don't get confused. Yet, somehow, when you replace planes with modems, the average consumer gets confused and thinks that speed means something completely different than it means in any other context. Speed is how long it takes to get from here to there (miles per hour, for instance).
Very luckily, however, for big expensive products that aren't aimed at the average consumer, latency is considered very important.
When you compress data that is being sent live, you actually have to slow things down in order to do it. (look above at explanation of what speed means, if you're unclear already) This is because you can't effectively compress a single bit or a single byte, so in order to compress you'd hold onto the data for a little bit before sending it off.
With your average consumer modem, compression slows things down by 15ms or however long it takes to receive a large enough block to send from the user (whichever happens first). With a normal home modem, though, you've already got something like 100ms that's wasted going across that link, so in most instances another 15ms isn't much, and is a good tradeoff for the slight boost in bandwidth.
When you've got a DSL line, however, you've got much lower latency than a normal modem would get, so something like 15ms tacked onto it would be doubling your latency. Double (or worse) latency in exchange for a small increase in bandwidth simply isn't worth it. It would just slow down your overall experience. (The only thing where you might want high bandwidth more than low latency is, basically, if you're downloading a lot of large files (like porn or software), and those are usually already compressed (JPEG, GNU zip, ZIP, etc.))
Improving switching and routing speed is much more important and useful. Adding compression to high-speed lines is a bad idea.
Also, electrical impulses already travel at about 2/3rds the speed of light -- outside of your CPU the speed of light over the speed of electric impulses isn't too much of an issue...
The article doesn't go into detail about how much of the actual fuel is replaced by this technology. It does mention a 20 percent reduction in the overall mass of the rocket, but what does that translate into?
Most rockets are huge canisters of fuel with a teensy little area to hold people and cargo. Doing multiple stages helps, but you're still talking about a vehicle that's mostly fuel. So it's probably a 20% (or some number remarkably close) reduction in fuel with a corresponding 20% reduction in bits of rocket to hold fuel. Or maybe it's a 21% reduction in fuel and a 15% reduction of the rest of the rocket. Either way, the fuel reduction and the overall mass reduction won't be too far apart.
Hey, but maybe we have something useful to send a probe to now past Pluto.
With a distance of almost half a light year, we'd either have to be very patient or come up with a method to send a probe much faster. (And, then, after we've figured that out, we can be about a dozen times as patient and send a probe to the nearest star.)
At the very least, it's far enough away that the fastest way to get there is to spend quite some time coming up with a faster way to send things there. (Orbital rail-gun, anybody?) I mean, seriously -- get something started at about 1800 miles per second (fast enough to get to the sun in 13 hours) and it'd still take you almost 50 years. Take 10 years to come up with something twice as fast and you'd get your probe there 15 years earlier.
In other words, it's a bit distant to be trying to send probes there just yet.
Slashdot Mirror
First, always read employment contracts before signing them. If an employer doesn't want to give you a chance to carefully review the contract or have your lawyer look over it, assume they're trying to pull something sneaky. If you think you really must sign a non-compete, make sure it's very limited in scope.
If you work with computers, chances are that it's very hard to find a job doing the same thing you do now without it competing at some level.
For instance, most of my work over the past several years has been building stuff for use on websites. With a broad non-compete, that means the competition is any company that has any kind of website at all (since the competition is for user attention). There's no way I'd sign an agreement to not work for companies with websites for 2 years after leaving a company; I'd be out of work for 2 years.
Currently I happen to work for a dating site. If the offer to work at this dating site had been attractive enough, I might have been willing to agree not to work for another dating website for 6 months after leaving.
Also, overly broad non-compete agreements probably won't stand up in court because they can restrict you from working in your chosen field at all. So MSFT may not be able to win this suit since they're regarding all software companies as competition. That kind of employment law can vary a lot between states, though; I'm most familiar with California's and I am not a lawyer.
Assume any contract you sign can be upheld.
Yes.
If you are intent on breaking into a machine to which you have no access, a port scan is the first step.
For any kind of attack (whether with guns or with computers), reconnaissance is the first step.
If you're not the DoD, though, I wouldn't worry about portscans. I don't count them as attacks just because they're so common. Besides, if I have a machine that runs several websites (some of which have files available for download), how much of an "attack" is it to scan to see if FTP is open? It could just be somebody who got a partial file download and wants to see if they can finish the download.
Also, with most of your machines, there is *some* kind of legitimate access the public has to it. The SMTP port or HTTP or something like that. For many DoD machines, there is *no* legitimate access for most of the public.
Only 5 a *week*? Wow. That's low. I think the main machine I do any admin for gets that many in an hour.
I'm sure part of it was simply momentum. That is, it was in the classified archives, why dig through them looking for stuff to declassify?
Another part, though, is that after WWII, some British allies were given Enigma machines and some of those were in use until some time in the 70s. (of course, that doesn't explain the other 20+ years, but it gets you more than half way)
And I'm sure when it first got classified, they had absolutely no idea how far computer technology would advance, or probably even if it would ever make it outside of secret government installations.
If you have a piece of data that can be used as-is to authenticate, then you have what we usually call "plain text passwords". At least, what you're storing is plaintext. Scrambling it a little to confuse people and not letting people use that password on a web form doesn't really buy you much security. Of course, these days, crypt() and lousy passwords doesn't get you very good security, either...
IOW, your solution doesn't help any. If they get the password db, they can log in. Okay, okay, maybe brain-dead script kiddies can't.
Though, it would be kinda nice if the spammer could be locked up, too.
That's not entirely true. Instead of quitting you can threaten to quit. Or you can write a letter complaining about the situation without including resignation threat.
Quitting fixes the situation outright, by removing yourself from it.
Threatening to quit or complaining (or, preferably, both together) works far better if everybody does it. You can even do things like not show up for work until they agree to stop. One term for it, if you do it all officially, is "forming a union".
Hey, at least they're nice enough to warn; no requirement for that. They could do it legally with no disclaimer.
A well loaded E10K is several million. $80K is probably the cost of the empty chassis if you qualify for some kind of special deal from Sun.
Well, there's A.root-servers.net through M.root-servers.net, which are hosted all over the world. Usually only DNS servers contact them, and there's already built in "round robin" and retries. So, if A.root-servers.net was to go down, at worst, 1 out of 14 queries to domains that hadn't previously been queried would get delayed by a short period of time. (IOW, if you do a lookup on foo.domain.com, your DNS server would cache domain.com's NS info and your query for bob.domain.com would use that instead of hitting the root nameservers.) However, I think the DNS servers would cache the information about the failure talking to a.root-servers.net and stop asking it things for a while.
In other words, DNS has failover built in.
However, if the server stayed down for an extended period of time, it would probably cause updates not to happen. I suspect they could get a new server in place for that purpose within a reasonably short period of time, though.
First off, databases look for connections to a port, just like any other service like httpd, smtp or ssh. Doing things so that you have failover and/or load-balancing on *that* is easy. There are a large number of solutions, from application level to library level to dedicated hardware to general purpose software (LVS).
That said, database failover is *not* easy.
The basic problem is that you don't just read from a database, you read and write to the database. Database replication is a very non-trivial thing to do. You have to deal with the possibility of data being inserted, updated or removed from any of the servers that are involved. This requires that you have things like global locks, timestamps on everything, primary keys that are generated in a way unique to each replicated version of the database, etc.
Most of the work of replication is handled very nicely by the big commercial databases (but you will find that they want you to pay for it.), but even with those you might have to make minor changes in your application (or maybe just the database structure) in order to handle replication properly...
AFAIK, there's nothing you can get for free that will be able to handle any kind of real-time n to n (or 1 to n and n to 1 simultaneous, even) replication. You can do stuff like have mysql dump a log of everything that's done that changes the database, and then import those changes into another mysql instance someplace else; but that's nowhere near what the big commercial databases can do when it comes to replication.
Given that replication is gonna cost real money, just get your free database running on a good-quality machine with good backups (that you make sure include the database) and maybe things like redundant power supplies. You can make a really robust box for much less than Oracle will charge you to license 2 instances with replication.
(Or hire a team of 10 database programmers to spend a year or 3 adding replication to postgresql. Well... maybe they could do it wrong in a month -- I'm trying to give a wild estimate for doing it vaguely close to right.)
It's actually one very large novel that's split between multiple books. Book bindings can't readily be made that can hold as many pages as it would require.
(Good though -- I've eagerly read every book as soon as I could get my hands on it)
This robot is emulating an ape (such as a gibbon) and not a monkey.
Monkeys generally walk *on* the branches and leap from branch to branch. (Sometimes hanging from the branches to grab things, etc.)
Apes are the critters that brachiate. Brachiation allows the animal moving around in the trees to be larger than if it leapt from branch to branch. (Of course, some of the "greater apes" (orangutan, gorilla, chimpanzee and us...) got big enough that they rarely go up in trees anymore -- a full grown silverback male gorilla would break most trees if it tried to climb them)
I guess "robo-ape" doesn't sound as good as "robo-monkey" -- especially since most people think of gorillas and not gibbons when they hear "ape".
Oh, and for the record, midnight local time I plan on being intoxicated, kissing my SO, out of pager range and not worrying about any such thing.
Y2K bug has already hit for some systems -- systems with a need for near-term future dates.
I think we'll see some stuff starting 12 hours before midnight GMT (4am PST) out in the pacific, and some stuff sweeping, hour by hour across the planet, with a spike at midnight GMT due to stuff all over the planet running on GMT and then further stuff happening on the hour as local midnight wanders past more locations...
We'll also see some issues that don't come up until Monday morning when people go to work... Maybe some stuff on March 1 for code that doesn't handle that leap year correctly...
Overall, though, it's likely to just be minor glitches -- rural and third world power outages, but no (or few) major metropolitan areas without power; small airports with problems, but the international airports will be fine... etc. (there's also the terrorists and script-kiddies to worry about, who'll do it whenever they feel like it, likely midnight local time.)
I'd suggest either an Intel EtherExpress Pro or a card based on the DEC Tulip chipset instead of the 3c905 card... The Linux drivers for either of those seem to be better done (especially with SMP, though this is probably fixed now) than the 3com driver.
It's really quite simple.
The reason a corporation goes public is in order to get money that they can use for some purpose. The more money, the better. (Especially if they can make more money without issuing more stock, since issuing stock dilutes the value of current shares of stock)
If a corporation were, say, to go public with 1 million shares of stock and the IPO price is $10, then they get 10 million dollars. If the price then leaps up to $20/share, there's another 10 million dollars that they could have gotten (since that's the market value for the stock and they could have issued at that price instead and sold it all.)
If VA Linux didn't need money for something, they wouldn't issue public stock. VA Linux is doing it to maximize the amount of money they get from investors in order to do something (open more offices? ramp up business? hire new people to develop new products? who knows?) while trying to minimize the dilution of the stock to the current (non-public) shareholders/owners of the company.
True.
However, SCSI drives reserve dead space and move the contents of bad sectors to a reserved sector and remap the bad sector to point at the previously reserved sector.
IOW: SCSI drives hide physical defects on the media from you, where IDE drives require the OS to deal with the problem.
First off, it's not clear from your post how heavily loaded the drives really are.
In particular: load is a measure of how many processes are using or waiting for a resource (such as disk I/O, CPU or network I/O). On a busy mail server that's completely adequate for the job, I'd expect to often see a high load average due to the number of processes that are waiting on the network. That is, due to the number of processes waiting for slow network connections to places halfway around the world.
All you mention is the load averages and a fairly non-specific measure of drives that are "cranking away constantly". If the drives were being used at a current constant 10% of available I/O, they'd tend to "crank constantly" even if they could be hit much harder. (still, given that losing email is considered bad by customers, a RAID 5 solution seems like a good idea anyways and leaves you room to grow and handle sudden increases in email from the holidays or spammers or gradual expansion of business)
As to IDE vs. SCSI -- never go with straight IDE on a server. SCSI has the ability to lie to the OS and silently move data from sectors that have gone bad into sectors reserved for that purpose. Sure, it slows down access to that particular block of data, but it's a lot easier than the OS having to deal with failures directly. However, I'm completely unfamiliar with the strange SCSI - EIDE setup that you're describing -- if it treats them as just physical media and provided the SCSI interface itself, it may be able to do that particular SCSI trick, as well. Physically, SCSI drives and EIDE drives are identical -- as in, you can find the *exact* same drive from certain manufacturers, only one has SCSI and the other EIDE. Reliability of the physical media is the same, IOW. In a normal configuration, *apparent* physical reliability is higher for SCSI due to wonderfully useful trickery.
I don't recall the exact model numbers, but I've seen pretty good results with Mylex RAID controllers before. (more along the lines of database stuff than what you're talking about -- somewhat different needs, but not all *that* different, I suppose.)
I can't see putting two partitions on one RAID device as making a lot of sense -- since things are striped you'd end up running into contention issues.
IOW: I'd guess that option #3 would be the fastest -- it's also probably the most expensive.
If I were you, I'd check more carefully to determine how much of the currently available disk I/O is actually being used... If the budget allows it, the dual-channel RAID solution sounds pretty good. You might want to go with two single-channel RAID cards instead -- makes it easier to stock a backup card in case a card decides to die. Try and get something with hot-swappable drives, too. It makes the RAID stuff so much more useful.
Also, I don't know the details of your setup (of course), but seriously consider breaking the mail serving task into separate pieces and run it on separate machines.
You have:
1) incoming email
2) outgoing email
3) email from customers
4) email customers pick up (POP)
It sounds like you have one machine handling all of these. Breaking these tasks onto separate boxes (If you've made the mistake of telling customers the same thing for #3 and #4 (ie, mail.isp.net instead of mail.isp.net and pop.isp.net) it might be impossible to split those two tasks away from each other)
You can have a setup such as:
outgoing1 through outgoingN all behind the single name of "outgoing" that internal machines are told to send email to that they don't know how to deal with
mail1 through mailN all behind "mail" that customers are told to have as their outgoing mail server. In particular, it should blindly send off email it doesn't know how to deal with to outgoing.
pop (harder to break into separate machines, but possible)
incoming1 through incomingN with MX records pointing at them for your domain.
Now, breaking into that many machines is probably silly. Moving outgoing to one machine and everything else to a second machine (and possibly mailing lists off to a third machine) may make a *lot* of sense though. Don't get tied into the idea of a monolithic machine to accomplish everything related to a particular task -- eventually it's much more expensive than many cheaper boxes to handle the same task.
(In other words: it's already happened)
If the effect of cell-phone use is fairly small, I'd expect that we wouldn't notice anything.
In particular, there's a 3-way correlation that would make it very hard to study memory loss problems on cell phone users without actually setting up a proper experiment with a control, etc.
1) Cell<->Stress.
People with busy (therefore stressful) lives tend to be much more likely to carry cell phones. (Or you could say that cell phone users are the people more likely to be leading stressful lives -- whatever.) I only have anecdotal evidence, but I suspect it could be found to be more general with a little bit of research. Also, Cell phones can be stressful. Either way, increased usage would tend to be associated with increased stress.
2) Stress<->Memory Problems.
There is research indicating that stress has a negative effect on memory. (And I've noticed this personally, too)
3) Cell<->Stress<->Memory Problems.
So, people with cell phones are likely to have memory loss problems without it being caused by the cell phone. (Instead both cell phone use and memory loss stemming from a stressful lifestyle)
And, note: I don't mean to say that all cell phone users are stressed. Personally, I find that once things like cell phones are recognized as being solely for the convenience of the person carrying it (and therefore it's ignored if inconvenient to answer it or the caller-id shows that it's an annoying person, people that abuse it are beaten until they stop, etc.) a cell phone is a handy convenience.
Promoting the widespread use of crypto is actually one of the expressed goals of this particular publicity stunt.
This is being run by Hacktivism and the URL with all the relevant details for participating is http://www.echelon.wiretapped.net/.
Here's a sample from their random Echelon jammer message generator:
From: Colonel Robert Worley, 50th Operations Group Commander, USAF
To: Director, Federal Emergency Management Agency
Ussama bin Laden made a broadcast this morning. We just got translation back and they're claiming that they will get agents to insert malicious code in year 2000 fixes Waco next week Additionally, The Commander in the 850th Communications Squadron passed on some new information. Theyve no choice other than to buy some documents from the JNTF contact when she's in Auckland tomorrow. Further to that, We're going to inflict minimal casualties on DoD personnel at London just before changeover to 2000. Finally, If we're to succed in halting the INFOSEC community, theres no better time than now to drive a tanker full of fertiliser and diesel across the border from Mexico then fly out to Manchester next week
I've got a collection of MP3 files (ripped and encoded from my CDs) and I usually listen in random order, skipping a track if it doesn't match the currently desired mood.
The collection includes: Alice In Chains, Ani DiFranco (including more than one album involving Utah Phillips), Annie Lennox, Metallica (and Apocalyptica doing Metallica), a little Beethoven, some Cherry Poppin' Daddies, "Cry Cry Cry", Dar Williams, Dead Can Dance, Deep Forest, Depeche Mode, Eric Clapton, some Eurythmics, Fields Of The Nephilim, Fiona Apple, Front Line Assembly, Garbage, Heather Nova, Hole, Information Society, Joan Osborne, KMFDM, Live, Madonna's latest album, Massive Attack, Ministry, a little Mozart, NIN, PJ Harvey (she's great!), a little Primus, a little REM, Rage Against The Machine, Richard Shindell, Rob Zombie, a little Sade, Sarah McLachlan, Skinny Puppy, Squirrel Nut Zippers, Sting, a small amount of The Cardigans, a couple Toni Braxton songs, Tricky, Tool, and a rather thorough collection of Tori Amos.
In other words, I listen to Industrial, "Rock", Folk, Metal, "Pop", Techno, Swing, some R&B, a little classical (there's also some Wagner that I haven't been listening to much recently, so hasn't made it into the archive yet) with a strong dose of female vocals in there... When I'm busy coding, I'm more likely to stick with the "heavier" or more "active" stuff (Ani DiFranco, Garbage, Hole, Information Society, KMFDM, Massive Attack, Tricky, Metallica, Ministry, NIN, White Zombie, some Tori Amos, etc...)
Would we have then reached the final/ultimate speed limit?
Before that happens, we need to concentrate on our algorythems and develop better compression. Sure people are getting rid of compression just cause there is mode bandwith.
You're doing the same thing that a lot of the general populace does, and getting latency mixed up with bandwidth.
Latency is how long it takes for an individual packet of data to get from one place to another.
Bandwidth is the total amount of data you can get from one place to another.
A little comparison: if you had a large plane that had a top flight speed of about 300 mph (mach 0.4) and could carry 1000 passengers and you also had a jet fighter that could travel at just over mach 4 (3000 mph) and transport a single passenger. Most people would agree that the jet fighter was "faster" in a very real sense than the large plane (by a factor of 10). However, with two cities 1000 miles apart, (ignoring time spent loading, unloading, refueling, etc.) the large plane could transport 2000 passengers in 10 hours (3.3 hours per one-way trip) while the jet fighter could transport 15 passengers. With vehicles, carrying capacity (bandwidth) and speed (low latency) don't get confused. Yet, somehow, when you replace planes with modems, the average consumer gets confused and thinks that speed means something completely different than it means in any other context. Speed is how long it takes to get from here to there (miles per hour, for instance).
Very luckily, however, for big expensive products that aren't aimed at the average consumer, latency is considered very important.
When you compress data that is being sent live, you actually have to slow things down in order to do it. (look above at explanation of what speed means, if you're unclear already) This is because you can't effectively compress a single bit or a single byte, so in order to compress you'd hold onto the data for a little bit before sending it off.
With your average consumer modem, compression slows things down by 15ms or however long it takes to receive a large enough block to send from the user (whichever happens first). With a normal home modem, though, you've already got something like 100ms that's wasted going across that link, so in most instances another 15ms isn't much, and is a good tradeoff for the slight boost in bandwidth.
When you've got a DSL line, however, you've got much lower latency than a normal modem would get, so something like 15ms tacked onto it would be doubling your latency. Double (or worse) latency in exchange for a small increase in bandwidth simply isn't worth it. It would just slow down your overall experience. (The only thing where you might want high bandwidth more than low latency is, basically, if you're downloading a lot of large files (like porn or software), and those are usually already compressed (JPEG, GNU zip, ZIP, etc.))
Improving switching and routing speed is much more important and useful. Adding compression to high-speed lines is a bad idea.
Also, electrical impulses already travel at about 2/3rds the speed of light -- outside of your CPU the speed of light over the speed of electric impulses isn't too much of an issue...
The article doesn't go into detail about how much of the actual fuel is replaced by this technology. It does mention a 20 percent reduction in the overall mass of the rocket, but what does that translate into?
Most rockets are huge canisters of fuel with a teensy little area to hold people and cargo. Doing multiple stages helps, but you're still talking about a vehicle that's mostly fuel. So it's probably a 20% (or some number remarkably close) reduction in fuel with a corresponding 20% reduction in bits of rocket to hold fuel. Or maybe it's a 21% reduction in fuel and a 15% reduction of the rest of the rocket. Either way, the fuel reduction and the overall mass reduction won't be too far apart.
Hey, but maybe we have something useful to send a probe to now past Pluto.
With a distance of almost half a light year, we'd either have to be very patient or come up with a method to send a probe much faster. (And, then, after we've figured that out, we can be about a dozen times as patient and send a probe to the nearest star.)
At the very least, it's far enough away that the fastest way to get there is to spend quite some time coming up with a faster way to send things there. (Orbital rail-gun, anybody?) I mean, seriously -- get something started at about 1800 miles per second (fast enough to get to the sun in 13 hours) and it'd still take you almost 50 years. Take 10 years to come up with something twice as fast and you'd get your probe there 15 years earlier.
In other words, it's a bit distant to be trying to send probes there just yet.