Magnetic disk media is unstable. We work around it by encoding extra redundancy as needed.
IANAQP, but is it not analogous that we can copy quantum state into multiple replicated locations, make the calculations happen multiple times, and compare results to ensure accuracy? This doesn't sound like a showstopper. It just makes it a little harder to design these things.
The point is the same as any other hybrid: Better fuel economy at a given performance level.
The Prius performs like a basic compact car with enough power to merge onto highways without feeling like you're going to be run over, but gets mileage more comparable to an underpowered econobox.
The Accord hybrid has great acceleration for a sedan, but gets gas mileage comparable to a basic 4-banger compact.
So, way back in the day, everyone was outraged that the music industry was trying to fight piracy by litigating away P2P technology, instead of going after the people who were actually breaking the law.
Now they're going after the people who actually break the law, instead of trying to end P2P.
I think that the idea of fair use ought to be extended, but am I supposed to be outraged that this is happening? They're actually going after people who are breaking the law, instead of trying to end technologies with legitimate uses.
...the real overhead is all the nonsense, both on a protocol level and for the server in terms of CPU time, of opening+closing a TCP connection.
Those who do not understand TCP are doomed to reinvent it, poorly. The overhead isn't nonsense, and in any modern IP stack running on a modern CPU, it doesn't require a lot of CPU time.
The bottlenecks that most small sites I've run encounter, in order, are:
1) Upstream bandwidth 2) Application server CPU utilization 3) Firewall state table size 4) Limits on TIME_WAIT states
Look up T/TCP for probably the best example of an improved TCP for small transactions. It has a drawback: it's defenseless againt real DDOSes.
Good luck with your reinvention of layer 4. If you create something with significantly better connection performance, without catastrophic drawbacks, draft an RFC, and you'll go down in geek history.
I see slash is now reporting on Philosophy. The same logic that lets you describe the power network as a single machine lets you also describe the human race as a single organism.
It's all interconnected and has complex interdependencies. But just saying that doesn't make a nice sound bite. So, we get articles about a "vast machine" as if that's somehow profound.
They're not adopting Linux because it's good or bad for OSS. They're adopting Linux because it's good for them.
And in the end, that's what OSS's goal is: making the best software for whoever wants to use it. That includes companies. Even evil companies. And personally, I think that's just fine.
Heh. Well, it's a very different experience being a corporate user from a average home desktop user. I don't care if it has the latest version of X, Gnome, KDE, or Mozilla. Stability (In the "they got this right the first time so I don't have to dick with it every two weeks" sense, not the "it doesn't crash" sense) is far more important to me.
Yes, we know this. The problem is security patches. After Debian EOLs a distribution, you have 3 options:
1) roll your own patches; 2) Upgrade; 3) Ignore security.
We do 2 if possible, and 1 only if necessary. 3 is for insane people / NT admins.
The trouble with #1 is that we cannot possibly QA our patches as well as Debian does.
Debian EOLed 2.1 the moment 2.2 shipped, which was kind of hectic for us (we had to produce our own patches for a while); 2.2 was EOLed about 6 months after 3.0 shipped, which was a little easier on us.
Despite these problems, Debian is still very useful to us. However, this is what keeps it from being our only Linux distro.
I'll GPL it and release it when I get a chance. It'll need a little work to make it generic; right now it's pretty specific to our environment.
To answer your question, though, here's the magic for scripted partitioning. The script is generic; the 'partitons' file in question is designed for raid5 with 2 data and 1 parity.
sfdisk -uM -q/dev/sda >/dev/null <partitions
And then in the partitions file:
,128,fd,* ,2560,fd,- ,-512,fd,-
Our layout is pretty simple. The first partiton is the/boot (128M * 2 disks = 256M). The second is the root partition, where the OS goes (2650M * 2 disks = 5120M); the third partition is the resource partition, which is basically a dedicated data store for whatever the system is used for. (Usually we mount it on/d0, and then symlink in whatever the main system resource is; for example,/var/spool/postfix for a mail server, or/home for a FTP server). -512 means that it leaves 512M free at the end of the disk for slop space. Disk manufacturers are better about it recently, but in the past this was a big problem. Basically, you'd buy a "36 GB" disk, but they were never exactly the same size if you had to go to another brand. So, we leave a little bit of space at the end so we can rebuild the raid if a disk fails, without worrying that the new 36 GB disk is really a 35.9 GB disk. If you're familiar with Solaris Jumpstart, this is kind of like a free hog, followed by 512M free.
Then, we mkraid the raids, mkfs the filesystems, mount them up somewhere, untar the image over it, and run a finish script to configure everything.
We manage consistant, reproducable server installs by NOT using the Debian installer. We install it once, and then make tarballs of the install, which we untar to install the server. We have it all scripted, so we can boot a machine off of a CD, run a script, answer 5 questions and have a server ready to go in about 10 minutes, and have the applications working (also script-installed) in another 10 minutes. We maintain our own OS release numbers (versions of our base tarball), and our own.deb packages of our applications.
For mirroring: We use debmirror. (It's a Debian package, of course.)
When upgrades fail: Go into aptitude, find the package that the upgrade broke, scroll down to the bottom, and highlight the old version, hit + to install it. It'll gracefully downgrade for your convenience. It's a hell of a lot easier than downgrading on, say, Solaris.
I work in a mid-size enterprise, and we're using Debian with great success, for most of our unix needs.
The right distribution is highly dependant on what your specific needs are, though. Here are some things to consider:
1) Debian doesn't provide direct commercial support. Tech support is available from third parties, but by the time you get a support contract that will equal the quality of support you get from Red Hat, it'll probably cost as much as Red Hat (or Solaris, or Windows, or anything for that matter). Saving money is a priority for us, so we simply self-support. We maintain our own baseline install, and take care of certifying our own apps against Debian as needed. It's worked very well for us, but if you need CYA, Debian may not be a good choice.
2) Debian's release cycle is too fast. Yes, I know you hear it from people on/. all the time that Debian is so out of date and how terrible it is that they only get one release out the door per year, if that. However, in the enterprise, upgrading everything once per year is painful. In an enterprise, you can't just change your apt sources and upgrade in place. We get a window - say, one hour - to perform an upgrade. That means that I have to have a machine built and ready to go, other than syncing the data across during my window, and get it back up, and have a way to fail back (still in that window!) if something goes wrong. This means I have to rebuild every Debian box in the company once a year. (Because we standardize our base install, and have scripted all of our application installs, building new machines is extremely fast for us, to the tune of 20 minutes or so, but it's still a lot of work to re-QA our applications once a year.) For this reason, we only use Debian where version upgrades go pretty easily - BIND, Apache, Postfix, FTP servers, etc, where the Debian-supplied versions consistantly work right out of the box. We use Red Hat Enterprise for complicated commercial software (Oracle), where the long support cycle means we only have to go through the fun of upgrades once every several years.
3) Oracle doesn't support Debian. Sure, it installs, sure, it runs fine, but that doesn't mean it's officially supported. This means that when you call their tech support, they will laugh at you the moment they think it's an OS problem. And, despite being head over heels in love with Debian, I think Oracle made the right choice - Enterprise customers who are going to install an application that needs to be in use for several years need to evaluate several other factors than just how easy an OS is to install and even how good the quality of the software is on the OS. I firmly believe that Debian builds a better mouse trap, but for Oracle, I want an OS that has official commercial support and a long life cycle - Red hat Enterprise.
Despite all this, don't think I'm trying to say that Debian is a bad choice. As I said at the beginning, we use it extensively for many functions throughout our enterprise, with tremendous success. Regardless, you need to evaluate your needs against ANY distribution, to see if it's a good match.
I've always viewed email as asynchronous communication. I answer my emails when I have time, several times a day. If I'm in the middle of something, I don't pay attention to it until I can take a break. But other people don't see it that way, notably my management chain at work. They're already trying to sell me on the idea of one of these things so I can get my email outside work. (WTF for? I carry a cell phone for emergencies. Exactly what kind of a network failure do they think I'm going to fix with email? But I digress.)
I certainly don't want to discourage the technology, and there are times when I wish I could just drag a decent web browser (NexTel can bite me) out of my pocket. But I'm just afraid that people are going to lose sight of one of the big advantages of email - the fact that it's asynchronous, which is the only way that I can deal with it when I get over a hundred legitimate emails a day. Having my phone ring a hundred times a day will just make me go insane.
Now I'm going to have to buy a fleet of these, to replace our executives' Blackberries, so they won't get pissed off for losing the digital dick-sizing contest at the country club. Oh, how I love technology.
#1. No. UDP has error checking. The difference between UDP and TCP is that TCP is a connection-based, sequence-enforcing protocol, where UDP is basically raw connectionless datagrams that arrive in any order and you have to handle packet loss and reordering in your application.
#2. RTFA.
#3. They're not getting rid of error checking. It sounds like they're reworking the windows for ACKs in TCP to allow better streaming over high speed, but realistic (IE, slightly lossy) networks. Current TCP aggressively backs off when packet loss is detected, to prevent flooding the weak link in a network connection. It works really well for consumer network speeds, but on very high speed networks (EG, 45 Mbps), even very light packet loss will drop your speed dramatically down. TCP just wasn't meant to scale to these kinds of speeds, and some reengineering needs to be done to make it work smoothly. Many of the current extensions to TCP have made matters a lot better, but it's still going to have trouble scaling to gigabit, high latency networks, and it's best to start dealing with these issues early.
For making DVDs to play on a hardware player: They both work fine. +R and -R both work fine in most DVD players, and virtually all new DVD players.
On a computer: DVD+R has some advantages when used on a computer (it closes sessions much faster), so if you're packet-writing disks, it helps.
The main differences you'll see are media costs. Do your research to know what you'll pay per disc. I use a -R. My main motivation was cheaper media. The gap seems to have closed a lot since we got it, though.
Slashdot Mirror
Magnetic disk media is unstable. We work around it by encoding extra redundancy as needed.
IANAQP, but is it not analogous that we can copy quantum state into multiple replicated locations, make the calculations happen multiple times, and compare results to ensure accuracy? This doesn't sound like a showstopper. It just makes it a little harder to design these things.
The point is the same as any other hybrid: Better fuel economy at a given performance level.
The Prius performs like a basic compact car with enough power to merge onto highways without feeling like you're going to be run over, but gets mileage more comparable to an underpowered econobox.
The Accord hybrid has great acceleration for a sedan, but gets gas mileage comparable to a basic 4-banger compact.
So, way back in the day, everyone was outraged that the music industry was trying to fight piracy by litigating away P2P technology, instead of going after the people who were actually breaking the law.
Now they're going after the people who actually break the law, instead of trying to end P2P.
I think that the idea of fair use ought to be extended, but am I supposed to be outraged that this is happening? They're actually going after people who are breaking the law, instead of trying to end technologies with legitimate uses.
Isn't this exactly what we asked for?
Not pointless.
Even if it's turned off by default, the ability to turn on good crypto is perfectly useful.
Those who do not understand TCP are doomed to reinvent it, poorly. The overhead isn't nonsense, and in any modern IP stack running on a modern CPU, it doesn't require a lot of CPU time.
The bottlenecks that most small sites I've run encounter, in order, are:
1) Upstream bandwidth
2) Application server CPU utilization
3) Firewall state table size
4) Limits on TIME_WAIT states
Look up T/TCP for probably the best example of an improved TCP for small transactions. It has a drawback: it's defenseless againt real DDOSes.
Good luck with your reinvention of layer 4. If you create something with significantly better connection performance, without catastrophic drawbacks, draft an RFC, and you'll go down in geek history.
So many times it'll make your head spin.
In Half-life, the spiders often win. That can't be good for the patient, can it?
I see slash is now reporting on Philosophy. The same logic that lets you describe the power network as a single machine lets you also describe the human race as a single organism.
It's all interconnected and has complex interdependencies. But just saying that doesn't make a nice sound bite. So, we get articles about a "vast machine" as if that's somehow profound.
$0.02.
I think you need to readjust your perspective.
They're not adopting Linux because it's good or bad for OSS. They're adopting Linux because it's good for them.
And in the end, that's what OSS's goal is: making the best software for whoever wants to use it. That includes companies. Even evil companies. And personally, I think that's just fine.
Heh. Well, it's a very different experience being a corporate user from a average home desktop user. I don't care if it has the latest version of X, Gnome, KDE, or Mozilla. Stability (In the "they got this right the first time so I don't have to dick with it every two weeks" sense, not the "it doesn't crash" sense) is far more important to me.
Yes, we know this. The problem is security patches. After Debian EOLs a distribution, you have 3 options:
1) roll your own patches;
2) Upgrade;
3) Ignore security.
We do 2 if possible, and 1 only if necessary. 3 is for insane people / NT admins.
The trouble with #1 is that we cannot possibly QA our patches as well as Debian does.
Debian EOLed 2.1 the moment 2.2 shipped, which was kind of hectic for us (we had to produce our own patches for a while); 2.2 was EOLed about 6 months after 3.0 shipped, which was a little easier on us.
Despite these problems, Debian is still very useful to us. However, this is what keeps it from being our only Linux distro.
I'll GPL it and release it when I get a chance. It'll need a little work to make it generic; right now it's pretty specific to our environment.
/dev/sda >/dev/null <partitions
,128,fd,*
,2560,fd,-
,-512,fd,-
/boot (128M * 2 disks = 256M). The second is the root partition, where the OS goes (2650M * 2 disks = 5120M); the third partition is the resource partition, which is basically a dedicated data store for whatever the system is used for. (Usually we mount it on /d0, and then symlink in whatever the main system resource is; for example, /var/spool/postfix for a mail server, or /home for a FTP server). -512 means that it leaves 512M free at the end of the disk for slop space. Disk manufacturers are better about it recently, but in the past this was a big problem. Basically, you'd buy a "36 GB" disk, but they were never exactly the same size if you had to go to another brand. So, we leave a little bit of space at the end so we can rebuild the raid if a disk fails, without worrying that the new 36 GB disk is really a 35.9 GB disk. If you're familiar with Solaris Jumpstart, this is kind of like a free hog, followed by 512M free.
To answer your question, though, here's the magic for scripted partitioning. The script is generic; the 'partitons' file in question is designed for raid5 with 2 data and 1 parity.
sfdisk -uM -q
And then in the partitions file:
Our layout is pretty simple. The first partiton is the
Then, we mkraid the raids, mkfs the filesystems, mount them up somewhere, untar the image over it, and run a finish script to configure everything.
Hello, enterprise Debian user here. :-)
.deb packages of our applications.
We manage consistant, reproducable server installs by NOT using the Debian installer. We install it once, and then make tarballs of the install, which we untar to install the server. We have it all scripted, so we can boot a machine off of a CD, run a script, answer 5 questions and have a server ready to go in about 10 minutes, and have the applications working (also script-installed) in another 10 minutes. We maintain our own OS release numbers (versions of our base tarball), and our own
For mirroring: We use debmirror. (It's a Debian package, of course.)
When upgrades fail: Go into aptitude, find the package that the upgrade broke, scroll down to the bottom, and highlight the old version, hit + to install it. It'll gracefully downgrade for your convenience. It's a hell of a lot easier than downgrading on, say, Solaris.
--Keepiru
--slashsuckATvegaDOTfurDOTcom
That got moderated funny?
/. all the time that Debian is so out of date and how terrible it is that they only get one release out the door per year, if that. However, in the enterprise, upgrading everything once per year is painful. In an enterprise, you can't just change your apt sources and upgrade in place. We get a window - say, one hour - to perform an upgrade. That means that I have to have a machine built and ready to go, other than syncing the data across during my window, and get it back up, and have a way to fail back (still in that window!) if something goes wrong. This means I have to rebuild every Debian box in the company once a year. (Because we standardize our base install, and have scripted all of our application installs, building new machines is extremely fast for us, to the tune of 20 minutes or so, but it's still a lot of work to re-QA our applications once a year.) For this reason, we only use Debian where version upgrades go pretty easily - BIND, Apache, Postfix, FTP servers, etc, where the Debian-supplied versions consistantly work right out of the box. We use Red Hat Enterprise for complicated commercial software (Oracle), where the long support cycle means we only have to go through the fun of upgrades once every several years.
I work in a mid-size enterprise, and we're using Debian with great success, for most of our unix needs.
The right distribution is highly dependant on what your specific needs are, though. Here are some things to consider:
1) Debian doesn't provide direct commercial support. Tech support is available from third parties, but by the time you get a support contract that will equal the quality of support you get from Red Hat, it'll probably cost as much as Red Hat (or Solaris, or Windows, or anything for that matter). Saving money is a priority for us, so we simply self-support. We maintain our own baseline install, and take care of certifying our own apps against Debian as needed. It's worked very well for us, but if you need CYA, Debian may not be a good choice.
2) Debian's release cycle is too fast. Yes, I know you hear it from people on
3) Oracle doesn't support Debian. Sure, it installs, sure, it runs fine, but that doesn't mean it's officially supported. This means that when you call their tech support, they will laugh at you the moment they think it's an OS problem. And, despite being head over heels in love with Debian, I think Oracle made the right choice - Enterprise customers who are going to install an application that needs to be in use for several years need to evaluate several other factors than just how easy an OS is to install and even how good the quality of the software is on the OS. I firmly believe that Debian builds a better mouse trap, but for Oracle, I want an OS that has official commercial support and a long life cycle - Red hat Enterprise.
Despite all this, don't think I'm trying to say that Debian is a bad choice. As I said at the beginning, we use it extensively for many functions throughout our enterprise, with tremendous success. Regardless, you need to evaluate your needs against ANY distribution, to see if it's a good match.
--Keepiru
--slashsuckATvegaDOTfurDOTcom
Google makes ME be god. Many other system administrators will agree.
Simply untrue. Have you heard of the Morris Worm?
Of course, Windows is a cesspool of viruses when compared to any other operating system, but that's more due to popularity than possibility.
Wow, that explains it. Our DBA isn't human.
Well, that's what I said. I don't have a problem with the technology. I like the technology. I have a problem with the people who don't understand it.
I've always viewed email as asynchronous communication. I answer my emails when I have time, several times a day. If I'm in the middle of something, I don't pay attention to it until I can take a break. But other people don't see it that way, notably my management chain at work. They're already trying to sell me on the idea of one of these things so I can get my email outside work. (WTF for? I carry a cell phone for emergencies. Exactly what kind of a network failure do they think I'm going to fix with email? But I digress.)
I certainly don't want to discourage the technology, and there are times when I wish I could just drag a decent web browser (NexTel can bite me) out of my pocket. But I'm just afraid that people are going to lose sight of one of the big advantages of email - the fact that it's asynchronous, which is the only way that I can deal with it when I get over a hundred legitimate emails a day. Having my phone ring a hundred times a day will just make me go insane.
Now I'm going to have to buy a fleet of these, to replace our executives' Blackberries, so they won't get pissed off for losing the digital dick-sizing contest at the country club. Oh, how I love technology.
#1. No. UDP has error checking. The difference between UDP and TCP is that TCP is a connection-based, sequence-enforcing protocol, where UDP is basically raw connectionless datagrams that arrive in any order and you have to handle packet loss and reordering in your application.
#2. RTFA.
#3. They're not getting rid of error checking. It sounds like they're reworking the windows for ACKs in TCP to allow better streaming over high speed, but realistic (IE, slightly lossy) networks. Current TCP aggressively backs off when packet loss is detected, to prevent flooding the weak link in a network connection. It works really well for consumer network speeds, but on very high speed networks (EG, 45 Mbps), even very light packet loss will drop your speed dramatically down. TCP just wasn't meant to scale to these kinds of speeds, and some reengineering needs to be done to make it work smoothly. Many of the current extensions to TCP have made matters a lot better, but it's still going to have trouble scaling to gigabit, high latency networks, and it's best to start dealing with these issues early.
subreality@underminer:~$ apt-get cure-world-hunger
Your ports tree can't do that. No wonder BSD is dying.
THE'YRE CUTTING THE HARD LINE! Get out now or you'll be trapped in the matrix!
For making DVDs to play on a hardware player: They both work fine. +R and -R both work fine in most DVD players, and virtually all new DVD players.
On a computer: DVD+R has some advantages when used on a computer (it closes sessions much faster), so if you're packet-writing disks, it helps.
The main differences you'll see are media costs. Do your research to know what you'll pay per disc. I use a -R. My main motivation was cheaper media. The gap seems to have closed a lot since we got it, though.