Then the nect package (let's call it app2-1.5) you will be stow'ing to/usr/local wille see that f.x./usr/local/bin allready exits at then link the files from it's own bin-drectory to/usr/local/bin, which result in files from app2-1.5 will be linked to the/usr/local/packages/app-1.4 structure, which will mess up things.
Odd. On my system it will notice that bin is a symlink to a bin dir in a different stow package, remove the symlink, create a dir, then link the contents of *both* packages bin dirs into the new/usr/local/bin.
Think of a typical/usr/local on a multiuser system. These are not typically managed by the native package management system, and have a whole mess of binaries dropped into/usr/local/bin. If you're the unfortunate sysadmin who has to figure out what package a particular binary is from, you're in for a lot of guesswork. With stow all the binaries are symlinks to descriptive package directories, so it's easy to know what files are related. If you want to get rid of something you don't have to go on a research expedition. If you do an upgrade you can simply unlink the old version and link in the new version, then quickly put it back if something breaks. This is good.
The other alternative is to build all your local compiles as rpm's (or sysv packages or whatever), but that's usually more work than just "./configure --prefix=/usr/local/stow/foo-1.2; make; make install" Getting your junior sysadmin to build things into stow repositories is usually easier than trying to get them to handcraft solaris packages for every little program somebody wants installed.
The article does not mention anything about dependencies. In my opinion dependencies are almost as important as keeping track of which file belongs to what application.
Stow doesn't do dependencies. IMO, that's fine for local package management, where dependency handling is often more trouble than it's worth. (A local package will typically be run on a know configuration, and can target that configuration.)
Maybe they should do some more homework and take a look at Gentoo's Portagepackaging system.
Do some homework? You are aware that stow has been around since 1996, right? It's amazing how many gentoo fanboys don't know what else is out there.
We (the Tcl core developers) have had problems in the past with Stow, mainly because it relies on being able to specify the installation process at 'make-install' time instead of normal 'make' time, leading to messed up baked-in paths...
I'm not exactly sure what you're unhappy with, but it sounds like a build problem rather than a stow problem, IMHO. With stow you can build the program to expect either the "real" path, or the "stowed" path, depending on your purposes. (Using the "real" path means that multiple versions can be installed in the stow tree and used simultaneously with an explicit path, while using the "stowed" path means that things like config files are in an expected location like "/usr/local/etc".)
stow is not at all a "package management utility for linux". It's a perl script and runs on almost anything. I've used it to manage local packages on IRIX, Solaris, and various flavors of Linux. IMO, the great strength of stow is exactly local packages--it's a great way to manage a shared/usr/local or such. I suggest thinking of stow as a powerful complement to your native package management scheme.
As a sociologist, I really do need to call "random" people, and can't consider a survey consisting only of telephone owning people who are willing to take a survey and who are clueless as to the do-not-call registry a valid sample space...
Why is it less valid than "people who have a phone, not working when the phone rings, not sleeping when the phone rings, not using a cell phone exclusively, not eating dinner, not in the bathroom (excluding people with bathroom phones), and still willing to take a survey?"
Light doesn't cause this type of interference, so they'd be able to (in theory) apply this to other technologies as well. I don't think it'll be long before we see hard drives using something like it.
I don't. We're nowhere near saturating the potential bandwidth of a fiber with consumer electronics. So there's not a great benefit in putting a bunch of fibers next to each other to aggregate their bandwidth--especially since (regardless of the optical path) the electrical signals going into the electrical-optical converters would be subject to the same high frequency timing issues that're causing the push away from parallel busses in the first place.
The article didn't say much beyond "gee whiz, there's a spam problem!" -- not exactly a revelation. It does hint at technical solutions to the spam problem, but I wonder if that's an approach that will ever work. I think at the heart this is a problem that can only be fixed with legislation (like it or not). Something along the lines of making it illegal to send spam with forged headers would help a lot.
Re:Almost Certain End?
on
The Faded Sun
·
· Score: 1
x86 is a 32-bit architecture. It has a 4G RAM limit which you just can't help. There are ways to put more than that - but you can't have a single process which uses more than that. There are also problems with the fact that x86 doesn't scale well above 4-8 CPU's and others - but this is the main issue. Now days there are simply too many problems which require datasets larger than 4G, both on workstation, and on servers - scientific, database, just to name a few.
That's all well and good, but does nothing to address the point of the article. 1) That market isn't large enough to support a company the size of sun without other markets. 2) Sun isn't the only player in that market, and arguably isn't the best either. IBM, HP, (compaq), SGI, and Intel all have 64 bit products. Some of those predate the Sun offerings (Sun did not invent the 64 bit space, and was actually late out the door with it.) 3) AMD and Intel will continue to improve.
So the question is, can Sun sell nothing but 8+ processor and 4+ GB RAM systems and make enough money to continue to compete with improving pc solutions? The answer is probably no. They'll either have to slim down and focus on the high end, become more competitive on the low end, or die.
Re:The cost of Solaris
on
The Faded Sun
·
· Score: 2, Informative
Do you actually own a Sun? You should probably open it up and compare it to your uber-clocked Althon-space-heater sometime. Their hardware is very high quality. Their support is as well.
Well, you're making the common mistake of lumping all of "sun hardware" together, like it's the same. It's not. Sun has some real junk, designs that never would have gotten out the door at a low cost pc clone maker. (E.g., the Sun Ultra 10, where the drives weren't even on rails and one drive needed to be removed in order to get the other drive out.) Their high end stuff is generally better, but you can't compare that to some "uber-clocked Athlon-space-heater"; if you compare high end sun on one hand you have to compare high end pc on the other--and those are also pretty well designed. A high-end pc server has a lot of hot swap components, internal redundancy, etc. It doesn't have hot-swap processor boards and it doesn't scale past 16p or so, but that's a slim market for sun to live off--and sun isn't the only player there. You can get better scaling from SGI or HP, and you can get better reliability from IBM.
Then there's support. You've made the other mistake of thinking that every one of the thousands of sun techs is equally good. Sometimes you get a good one. Sometimes you don't. I've got some real horror stories about the bad ones--examples where some jerk sent for a million dollar support contract replaces the wrong part on a multimillion dollar system. The point is that the support is only as good as the guy who shows up on your doorstep, and you don't get a lot of control over that. You've got the same problem for pc support, but the machines are so much cheaper that n+1 redundancy is more realistic. I'd much rather have a spare machine than trust that the support monkey will show up in a timely fashion and will manage to fix the problem. (Remember that your contract probably says something like "four hour response" rather than "four hour time to resolve"--that just means they answer the phone within four hours. If you have a time-to-resolve contract you almost certainly have spares on hand, and sun has no advantage there.) I'd really much rather have in-house staff replace the parts, because at least they're responsible to my management chain. With pc makers that isn't usually a problem. Sun really doesn't like unauthorized people working on their expensive hardware. You can get in house staff authorized, but that also costs quite a lot of money (and when they leave you just lost that investment.)
What's your error model? It must be pretty wacky, and therefore unbelievable.
A 128-bit CRC will be exactly as reliable as an MD5 checksum under all common error models.
Thank you for pointing out that crc's are designed to look for errors--since in this application the checksum is used to uniquely identify a block, not to check for errors. You've quite succinctly explained the reason crc's won't work.
This is a problem with the implementation, not with the theory, because it wouldn't be that difficult for the rsync server to cache the MD5 sums so that it only had to calculate them once for each file
rsync wasn't written by a moron.:) I think you'll find that fairly obvious optimization is patented, which is AFAIK why there's no rsync server mode that does it.
The problem is that the typical PC hardware is just not designed for that. Large proprietary Unix or mainframe systems usually have multiple very high speed buses; a single 32-bit PCI bus is rather low-end in comparison.
A single 32 bit PCI bus is anemic these days. That's why high-end servers based on ia32 processors include multiple PCI busses, increasingly PCI-X (133MHz, 64bit). Note that servers based on other processors are increasingly moving away from proprietary busses and using the same PCI you'll find in those intel-based systems.
You're buying into the myth of HT transparency. License issues and "things such as cache issues" aren't the problem--the achilles heel of HT is that in a physical smp system you can schedule two processor intensive tasks on two virtual cpus on the same physical cpu, while the other physical cpu is completely idle. This will lead to unpredictable, unrepeatable, and just plain bad performance. One a system with only one physical cpu this is not an issue, but you'd better make sure you don't run HT on a multi-cpu system without some OS scheduler support.
Re:OT: Thermal management: PC design sucks...
on
New Generation of Cases?
·
· Score: 3, Interesting
No, because in a modern rack you have a plenum between sections, removing the air from the stack.
I'm not sure what you're getting at here. First you talked about passive convection cooling, now something else. Make up your mind about what PC's need to copy. If you look at something like a sun 10k or 15k you'll find a midpoint-to-top airflow but that's got much less to do with convection cooling than with the ability to pull a board out without removing the fans. Once you force enough air through the system the orientation is pretty much irrelevant, and driven by concerns other than cooling.
And rack mounted systems are different from home computer layouts.
As opposed to VME-based telecom equipment?
AND the modern PC design still makes getting good airflow over all components difficult since there are almost no unobstructed straight line paths through the case.
Now that's a relevent argument, and definately a problem in most low-end/home pc's. Rackmount and high-end machines tend to have better airflow due to improved cable management and integrated design.
AND you still benefit from convection, even in a forced air situation, as components in dead air (see point above) get convective cooling.
For which components is this even relevant? Convection cooling is totally inadequate for the hottest part of a modern system. (CPU and HD now, and increasingly other components.) Moving things around so they match an ancient VME design isn't going to change the fact that you'll need a big honkin' fan. More importantly still, the ideal solution just won't have any dead air...
I work on equipment that pumps out the watts. Do you?
Everything from rackmount pc's to multirack storage arrays to liquid-cooled computer systems. Ain't none of that stuff going to benefit from passive convection air cooling.
The backplane board is vertically mounted along the back of the enclosure, and the cards are ALSO vertically mounted into the backplane. Any plugs on each card are on the front of the card. One whole section of the bus is reserved for I/O connections, so standard connections are on the backplane.
As a result, natural convection can move air over the system. If you need forced air, you put a fan at the bottom of the system, pressurizing the cabinet - that way you are moving denser, cold air with the fan.
This is, of course, a silly idea when using modern equipment that's pumping out a few hundred watts per unit. Newfangled rackmount equipment flows front-to-back for a reason--if it flowed bottom-to-top the uppermost units would quickly melt from the combined heat of the lower units. It's not hard to pack 8 or 16 thousand watts into a rack these days, and funneling that much heat through the machine on top is simply not a good idea. Remember, just because somebody did something different 30 years ago doesn't mean the modern engineers are clueless.
Without some details it's impossible to tell either what these results were based on or the specific areas where win2k was found superior to linux. I didn't see a reference to the actual study, so there is no way to gauge the validity of the results. There's just no meat to talk about with this marketing blurb dressed up as a news report.
Why on earth would a researcher be plugged into the same network as time-sensitive patient information? Yes it's expensive, but critical functions should be seperated from non-critical functions. And the critical network needs to be fairly rigidly controlled (i.e., no researchers should "accidentally" plug into it.) Note further information in http://www.nwfusion.com/news/2002/1125bethisrael.h tml
There are entire classes of problems which cannot be solved fast enough on clusters, but only on single-image systems. Anything that cannot be made into a parallel algorithm falls into that category.
Of course, anything that cannot be made into a parallel algorithm isn't going to use more than one processor out of a 512p machine, single system image or not. That's not a target audience for this machine.
When a site is Slashdotted it isn't due to a "lack of bandwidth", you think that someone servers just "run out"? A site which is truely Slashdotted runs out of ram and processing power
Sure that's true, except when it isn't. I've seen a site get/.'d, and the machine was fine--but the entire organization where the machine was located ran out of bandwidth. Local users could acess the web site but traffic to and from the internet was halted. It really depends on your mix of static/dynamic pages, and the average request size. For a static site it's fairly easy to max out a 100Mbit lan--which is more internet bandwidth that most people outside of hosting facilities can easily obtain.
keeping your prices "confidential"(because they're rediculously high?)
Actually, companies in that sort of business often don't like to advertise their prices because the price the customer pays is negotiable, and they don't want one customer to have any idea what other customers are paying. (Because they'd all want the same price, of cours.)
Slashdot Mirror
Odd. On my system it will notice that bin is a symlink to a bin dir in a different stow package, remove the symlink, create a dir, then link the contents of *both* packages bin dirs into the new
Why did this article need a "use gentoo" comment?
Think of a typical /usr/local on a multiuser system. These are not typically managed by the native package management system, and have a whole mess of binaries dropped into /usr/local/bin. If you're the unfortunate sysadmin who has to figure out what package a particular binary is from, you're in for a lot of guesswork. With stow all the binaries are symlinks to descriptive package directories, so it's easy to know what files are related. If you want to get rid of something you don't have to go on a research expedition. If you do an upgrade you can simply unlink the old version and link in the new version, then quickly put it back if something breaks. This is good.
The other alternative is to build all your local compiles as rpm's (or sysv packages or whatever), but that's usually more work than just "./configure --prefix=/usr/local/stow/foo-1.2; make; make install" Getting your junior sysadmin to build things into stow repositories is usually easier than trying to get them to handcraft solaris packages for every little program somebody wants installed.
Stow doesn't do dependencies. IMO, that's fine for local package management, where dependency handling is often more trouble than it's worth. (A local package will typically be run on a know configuration, and can target that configuration.)
Do some homework? You are aware that stow has been around since 1996, right? It's amazing how many gentoo fanboys don't know what else is out there.
I'm not exactly sure what you're unhappy with, but it sounds like a build problem rather than a stow problem, IMHO. With stow you can build the program to expect either the "real" path, or the "stowed" path, depending on your purposes. (Using the "real" path means that multiple versions can be installed in the stow tree and used simultaneously with an explicit path, while using the "stowed" path means that things like config files are in an expected location like "/usr/local/etc".)
stow is not at all a "package management utility for linux". It's a perl script and runs on almost anything. I've used it to manage local packages on IRIX, Solaris, and various flavors of Linux. IMO, the great strength of stow is exactly local packages--it's a great way to manage a shared /usr/local or such. I suggest thinking of stow as a powerful complement to your native package management scheme.
Why is it less valid than "people who have a phone, not working when the phone rings, not sleeping when the phone rings, not using a cell phone exclusively, not eating dinner, not in the bathroom (excluding people with bathroom phones), and still willing to take a survey?"
Well, it might be that you're trying to do something that's not really a good idea. HTML isn't a page layout format--perhaps you should use pdf?
I don't. We're nowhere near saturating the potential bandwidth of a fiber with consumer electronics. So there's not a great benefit in putting a bunch of fibers next to each other to aggregate their bandwidth--especially since (regardless of the optical path) the electrical signals going into the electrical-optical converters would be subject to the same high frequency timing issues that're causing the push away from parallel busses in the first place.
The article didn't say much beyond "gee whiz, there's a spam problem!" -- not exactly a revelation. It does hint at technical solutions to the spam problem, but I wonder if that's an approach that will ever work. I think at the heart this is a problem that can only be fixed with legislation (like it or not). Something along the lines of making it illegal to send spam with forged headers would help a lot.
That's all well and good, but does nothing to address the point of the article. 1) That market isn't large enough to support a company the size of sun without other markets. 2) Sun isn't the only player in that market, and arguably isn't the best either. IBM, HP, (compaq), SGI, and Intel all have 64 bit products. Some of those predate the Sun offerings (Sun did not invent the 64 bit space, and was actually late out the door with it.) 3) AMD and Intel will continue to improve.
So the question is, can Sun sell nothing but 8+ processor and 4+ GB RAM systems and make enough money to continue to compete with improving pc solutions? The answer is probably no. They'll either have to slim down and focus on the high end, become more competitive on the low end, or die.
Well, you're making the common mistake of lumping all of "sun hardware" together, like it's the same. It's not. Sun has some real junk, designs that never would have gotten out the door at a low cost pc clone maker. (E.g., the Sun Ultra 10, where the drives weren't even on rails and one drive needed to be removed in order to get the other drive out.) Their high end stuff is generally better, but you can't compare that to some "uber-clocked Athlon-space-heater"; if you compare high end sun on one hand you have to compare high end pc on the other--and those are also pretty well designed. A high-end pc server has a lot of hot swap components, internal redundancy, etc. It doesn't have hot-swap processor boards and it doesn't scale past 16p or so, but that's a slim market for sun to live off--and sun isn't the only player there. You can get better scaling from SGI or HP, and you can get better reliability from IBM.
Then there's support. You've made the other mistake of thinking that every one of the thousands of sun techs is equally good. Sometimes you get a good one. Sometimes you don't. I've got some real horror stories about the bad ones--examples where some jerk sent for a million dollar support contract replaces the wrong part on a multimillion dollar system. The point is that the support is only as good as the guy who shows up on your doorstep, and you don't get a lot of control over that. You've got the same problem for pc support, but the machines are so much cheaper that n+1 redundancy is more realistic. I'd much rather have a spare machine than trust that the support monkey will show up in a timely fashion and will manage to fix the problem. (Remember that your contract probably says something like "four hour response" rather than "four hour time to resolve"--that just means they answer the phone within four hours. If you have a time-to-resolve contract you almost certainly have spares on hand, and sun has no advantage there.) I'd really much rather have in-house staff replace the parts, because at least they're responsible to my management chain. With pc makers that isn't usually a problem. Sun really doesn't like unauthorized people working on their expensive hardware. You can get in house staff authorized, but that also costs quite a lot of money (and when they leave you just lost that investment.)
Thank you for pointing out that crc's are designed to look for errors--since in this application the checksum is used to uniquely identify a block, not to check for errors. You've quite succinctly explained the reason crc's won't work.
rsync wasn't written by a moron.
No. A CRC won't be reliable enough.
A single 32 bit PCI bus is anemic these days. That's why high-end servers based on ia32 processors include multiple PCI busses, increasingly PCI-X (133MHz, 64bit). Note that servers based on other processors are increasingly moving away from proprietary busses and using the same PCI you'll find in those intel-based systems.
That reason would be the cost of the tests and the fact that most linux hackers don't have pockets as deep as billg's.
You're buying into the myth of HT transparency. License issues and "things such as cache issues" aren't the problem--the achilles heel of HT is that in a physical smp system you can schedule two processor intensive tasks on two virtual cpus on the same physical cpu, while the other physical cpu is completely idle. This will lead to unpredictable, unrepeatable, and just plain bad performance. One a system with only one physical cpu this is not an issue, but you'd better make sure you don't run HT on a multi-cpu system without some OS scheduler support.
I'm not sure what you're getting at here. First you talked about passive convection cooling, now something else. Make up your mind about what PC's need to copy. If you look at something like a sun 10k or 15k you'll find a midpoint-to-top airflow but that's got much less to do with convection cooling than with the ability to pull a board out without removing the fans. Once you force enough air through the system the orientation is pretty much irrelevant, and driven by concerns other than cooling.
As opposed to VME-based telecom equipment?
Now that's a relevent argument, and definately a problem in most low-end/home pc's. Rackmount and high-end machines tend to have better airflow due to improved cable management and integrated design.
For which components is this even relevant? Convection cooling is totally inadequate for the hottest part of a modern system. (CPU and HD now, and increasingly other components.) Moving things around so they match an ancient VME design isn't going to change the fact that you'll need a big honkin' fan. More importantly still, the ideal solution just won't have any dead air...
Everything from rackmount pc's to multirack storage arrays to liquid-cooled computer systems. Ain't none of that stuff going to benefit from passive convection air cooling.
This is, of course, a silly idea when using modern equipment that's pumping out a few hundred watts per unit. Newfangled rackmount equipment flows front-to-back for a reason--if it flowed bottom-to-top the uppermost units would quickly melt from the combined heat of the lower units. It's not hard to pack 8 or 16 thousand watts into a rack these days, and funneling that much heat through the machine on top is simply not a good idea. Remember, just because somebody did something different 30 years ago doesn't mean the modern engineers are clueless.
Without some details it's impossible to tell either what these results were based on or the specific areas where win2k was found superior to linux. I didn't see a reference to the actual study, so there is no way to gauge the validity of the results. There's just no meat to talk about with this marketing blurb dressed up as a news report.
Why on earth would a researcher be plugged into the same network as time-sensitive patient information? Yes it's expensive, but critical functions should be seperated from non-critical functions. And the critical network needs to be fairly rigidly controlled (i.e., no researchers should "accidentally" plug into it.) Note further information in http://www.nwfusion.com/news/2002/1125bethisrael.h tml
Of course, anything that cannot be made into a parallel algorithm isn't going to use more than one processor out of a 512p machine, single system image or not. That's not a target audience for this machine.
Sure that's true, except when it isn't. I've seen a site get
Actually, companies in that sort of business often don't like to advertise their prices because the price the customer pays is negotiable, and they don't want one customer to have any idea what other customers are paying. (Because they'd all want the same price, of cours.)