Amazing how many reactionaries come out of the woodwork when they hear words like "RedHat is dropping Fedora". Never mind the fine print, noooooooo that doesn't matter at all. The headlines will do them just fine. Fedora will be dead by the end of the week, end of story.
Of course, for those who bothered to read RedHat's open letter, they will know that Fedora will continue to live on, "business as usual" as far as the average user is concerned. All that's changed is the organisational/support structure that RedHat has been providing which deals with open source and which serves as a central point for all those open source patents. It hasn't worked, so they're going for a simpler approach.
Yes, I'm oversimplifying, and generalising, so sue me for having a contrary view. Too many people seem to be doing just the opposite... </rant>
As for RedHat trying to do anything evil... would anybody who reckons they are like to try to guess how many patches they've contributed just to the Linux kernel tree as a result of bug reports for their enterprise products, say in the last year? Anyone?
No, IMHO from what I've seen IBM doesn't really push Linux in Australia. They push hardware and expensive applications, plain and simple. They even give away licenses to software that could have been expensive in order to sell expensive machines with support contracts. Linux can quite easily sell itself, but unless bigger Australian businesses are shown an expensive support contract with what appears to be solid support, they're usually not interested in giving it a go[1]. Smaller businesses tend to be more sensible/flexible, relying on talent over an SLA. Maybe there's an element of financial position influencing policy on keeping it that way.
As for the Australasian reference, the article only mentions Australia and New Zealand as the countries surveyed. Asian countries are not necessarily inferred by the term - the term "Asia-Pacific region" may be preferred to bring them into it. I doubt most Asian cultures are nearly as afraid of OSS as big business in Australia and NZ.
[1] Ok, so this may be a slight exaggeration, but it takes a lot of convincing to talk management into using OSS.:)
A guy I used to know developed a product in Australia, and could not sell the product or the business to anyone.
So he moved his family and business to America. Some 3 years later the product was being sold by his American company to Australians, amongst others, and his business was purchased by one of the bigger companies for $US 20 million.
Then he and his family moved back to Australia.
It seems for some stupid reason that Australian businesses want to buy products from overseas companies, America being a popular choice. It also seems that obviously they don't want "free" stuff, because there's "no such thing as a free lunch" down-under. As a culture, we are wary of gotchas, too much for our own good. I believe it to be nothing more than an over-cautious approach to new things without obviously proven major backing.
I'm interested in hearing other peoples' takes on this...
Put Bruce Willis on the probe. The minor detail of whether or not to include an air supply can be left to the engineers.
Re:I was at the conference and was in the audience
on
Open Source Not That Open?
·
· Score: 2, Interesting
Just a quick response to the points, having seen the boats if not necessarily been in them...
1. RedHat's distros come with (backward) compat libraries and compilers packages (optional to install) with their enterprise products. I believe the that between the two you have most things covered. The compat libraries are typically required by Oracle...
2. You might get away with core upgrades, if it lives on an extras disk. I haven't explored them... anyone? However, if people complain loudly enough and the change isn't that major, they have been known to include things that were intended for a future release, or were even being deliberately excluded. A good example is their reluctant support for the features of QLogic FC HBAs. It took months to get them to stick it into EL3. AFAIK no clients actually paid for it (all they really had to do was incorporate the vendor's own code, and that doesn't taint the kernel), and even though the vendor's drivers were eventually compiled in, the user had to know what symbolic links and modules.conf changes to make to get it to work... before that I was downloading the source and compiling in the vendor's driver. RedHat wouldn't have supported any I/O related issues to those disks, I'm sure, but they would still support configuration of the web server!
3. RedHat have deliberately left lots of things they will refuse to support out of their kernel releases. Reiserfs is a good example of this. If you want it, you have to install the source rpm, reinstate the config and compile the modules for yourself. I do however find it very annoying that we need to in the first place. But then if you don't like it, you can always go with SuSE.
The downs may seem very significant, but the only issues this causes to the likes of me is when the hardware compatibility matrix is affected. I like to be able to dial 1-800-REDHAT and have the expectation of a reasonable answer to a reasonable question in a reasonable amount of time. Now if only they could get the answers right more often!:)
OSTG may terminate a user's account in OSTG's absolute discretion and for any reason. OSTG is especially likely to terminate for reasons that include, but are not limited to, the following: (1) violation of these Terms; (2) abuse of site resources or attempt to gain unauthorized entry to the site or site resources; (3) use of an OSTG Site in a manner inconsistent with the Purpose; (4) a user's request for such termination; or (4) as required by law, regulation, court or governing agency order ; or (4) for being a smarty-pants and pointing out that this clause of the OSTG license was written by someone who couldn't count up to 4... errr.
It strikes me that this should be determined by a standardised (probably much bouncier than what we use) pogo stick of some kind... perhaps a small bang-bang rocket?
The first is if you can use a pogo stick on the body, but can't escape the gravitational pull with it, then it's a planet. If that "planet" is the minor influence orbiting another planet (massive or otherwise) then it's downgraded to moon.
If such a planetary or moon sized body is part of a field, then due to gravitational forces you may be able to escape one to get to another pretty easily. This would change its classification to not a planet or moon, since due to its surrounding influences, you can escape its surface (those properties would then label it as an asteroid, or simple debris if it is orbiting some category of planet).
Second: If you can't use a pogo stick then it's a massive planet.
Third: If the pogo stick (composition of the stick needs to be standardised) melts then you're getting into the category of stars...
Sensor registers a change in pressure or temperature, passes it up the line. Simultaneous changes amongst several sensors should be sent to higher levels, those with highest magnitude of change or threatening acceptable thresholds given highest priority. Above threshold signals could be fast-tracked to a release actuator's processor like a pain reflex, which could then make the decision to "bear with the pain" or "let go", depending on how important the burden is, whether it's holding a baby or a bowling ball.:)
So if your robot hand grips a raw egg, it quickly registers the pressure of the grip so it can stop, but it is not bothered by further "status quo" sensor readings. Of course, a sudden drop in pressure could mean one of two things:- egg has been dropped, or it's just cracked under the pressure. That's where you need to check the goo sensor matrix...
If us humans continuously tracked the output of everyone of our sensory nerves at a higher level, we'd forever be in sensory overload and would always be contemplation the need to react to the environment. My point is that such high volumes of sensory data should be manageable by programming sensor matrices to pay more attention to feeding back deltas and thresholds than continuously reading inputs.
This is the most unfortunate aspect of operating system expectations to date. Barring a genuine hardware problem, all users should expect that their operating system will never crash.
Now the vast majority is so well conditioned, that halving the frequency of crashes on their system is seen as a benefit, when they shouldn't have been allowed to happen in the first place.
I've worked with someone who has high praise for SGI. I've not played with their OS myself, but from what I've heard they're a company that takes responsibility for it. As I understand it the bug policy is along the lines of "If your application can cause a problem with our OS, it's our fault, and we will fix it, at no cost to you." They believe in your right to trust that their OS is bullet-proof, providing of course that the hardware is maintained.
When will Microsoft and other commercial vendors to offer that kind of stability? When can we expect a crash-free OS to be the norm rather than the exception?
It's a lot more than that. There may be a distro or 2 out there that offers a variety of tuning profiles, but the fact is that one distro will typically be tuned for one style of hardware profile. If it's half decent you'll get enough documentation to tune it yourself, but you'll probably still have to look for it...
Fact: RedHat EL3's default httpd configuration is AWFUL for busy websites on high end machines, compared to say Windows/IIS defaults, though on cheap/low powered hardware running with a 300MHz CPU it would probably benchmark better. Back at the high end, tweak 4-6 settings to make more serving threads available and it will make use of that little extra RAM, and put you back ahead of the game. If you want more than that though, look at a Web Performance Tuning book.
I've also heard of tools out there which can look at your system performance (eg if you run sar) and tell you what kernel parameters you need to alter to reduce bottlenecks and improve utilisation of underused system resources. You may have to pay for such a tool, but chances are it can delay the need for upgrading to meet growth of demand.
I'm hoping for better, as it's the only flavour of Multipathing that RedHat will support! Where I work we use QLogic's 2300 series HBAs - single adapters with dual paths for test, dual adapters with dual paths for production. They are very VERY sweet, and once you start playing with SANSurfer, you discover the power of SAN disk configuration that users of "big iron" would typically take for granted.
The catch is, you need to install the vendor's HBA drivers (remember to fix RedHat's broken qla2300_conf module link, rewrite the HBA config to the module, and recreate your initrd!) and figure out how to configure the pathing optimally.
The biggest downside is that, looking at the GPFS benchmarks in IBM's redpaper on intel clusters vs the virtualisable P series, clustering filesystems on intel hardware simply does not seem to scale I/O at all well compared to the high end equipment like IBM's P690 or 595, which are pretty close to linear.
The other downside is that RedHat will not support it. But then RedHat also prefer you to boot off your lone internal IDE drive rather than off your SAN (which appears to be flatly unsupported).
Yes, I will bitch about RedHat a bit, as I have had to deal with their support for some time now, but all in all IMHO they're still good for Linux. Hopefully they will pull through with building Enterprise quality generic multipathing support into EL4 through the dm and md...
So... the claims of tying it into the principles of teleportation suggest to me (the quantum physics ignoramus) that the key is to know exactly what the teleported object/person is, but not where it is?
Then at the moment we are able to perfectly reconstruct the item, it could be nowhere, or anywhere? Sounds like it's already been done to me, in the Heart of Gold!
But more seriously, anyone care to try to laymanise how the existence of negative quantum information can help with research into teleportation?
In short, specify what the time offset usually is relative to UTC, how much yer DST shifts the time by, when it starts and ends (time/day/month). It is flexible enough to define "the nth {day of week} of the month" such as 1st Sunday, 2nd... or last. Wheeeeee! Updates will surely follow in a GNU libc update in the near future.
Big planets make their suns wobble more, little planets make them wobble less, but they all have their own impact on the same body at the same time, which will generate a cumulative result.
By observing the harmonics in the wobble for any star for long enough we should be able to determine how many bodies are orbiting it and their period. The only limitations on this are how long we observe for and how sensitive our equipment is at watching it.
On a stellar scale, we "listen" to the details of wobble of the sun, in 1 dimension from our perspective - the variations in its velocity away from us. Then we extract the harmonics of the wobble - the wobbles within the wobble - a range of frequencies at distinct volumes would be observed. Frequency of a particular harmonic would reveal the length of the planet's year, and amplitude would be a result of the planet's relative mass. Nothing that basic Fourier analysis can't sort out, as long as the samples are accurate enough. SETI@home could probably be altered to look for this, but I fear there wouldn't be enough work units to go around!
Unfortunately, if we were looking down upon an orbital plane, we would probably see no doppler shift of the star. The other problem is that observing the "signal" to be sure of the result would ideally take at least 1 complete orbit of the furthest planet around the body (anyone care to correct that as my theory is rusty?) Measuring Uranus' period would be possible by measuring our Sun's wobble, taking into account the interference caused by the inner planets, but could take a while, unless using really sensitive equipment which can accurately measure and extrapolate the orbit from a small segment of a sinusoidal wobble.
The real problem with a typical Apache install on a typical RedHat platform, is that the configuration is really badly tuned. The preforking is configured for a 486 class computer! The default config is suitable for being a serious webserver the same way as an old-fashioned musket is suitable for use as a machine gun. Spawning new processes takes time. If you take 1000 hits in the same second, then your box had better be configured to keep up with necessary fork and exec calls.
The first thing you should do as a web administrator on your P4 class RH box running Apache is tune the following settings. Whether you use a tool, or edit directly depends on what kind of support you expect when you mess it up. The below is one of many possible solutions depending on available memory, processor speed, SMP capabilities/kernel version, and whether you anticipate a high rate of connections or a larger amount of CGI type work:
StartServers - typical default is 2. If you're half serious about your web server being able to respond to requests from the completion of startup, try 10. That's just to get the ball rolling.
MaxClients - 150 is a typical value. Try 1000 so you're prepared for incoming connections.
MinSpareThreads - 25 may be ok usually, but if you get a surge of benchmark style incoming connections, you're bound to be caught out not ready to accept some. Try 100, or 200 if you have a little memory to burn.
MaxSpareThreads - 75 might seem decent, your SMP box will be much more responsive with 200, perhaps a better idea being 500. Even 2000 if you can see memory usage isn't a problem.
ThreadsPerChild - 25 is ok in my book. You probably don't want each process responsible for too much, especially if they do uninterruptible things. But you may be able to up it for a purely static site.
Remember, if you are running a web server, you should be tuning it to use all available resources, without thrashing your swap space. Look at the numbers and tune it. Expect any modern PC running Linux/Apache to take 5000 static hits per second sustained on an SMP box without breaking a sweat. If during a peak time you can see a resource underutilised, then tweak and tune it - any good admin should be able to squeeze orders of magnitude better performance out of it over the default config. Using half the memory and bugger all swap? Up the threads by 50% or more...
Once you have your web serving building block optimised, virtual services can then be used to load-balance traffic for extreme peaks, and taking boxes down for essential maintenance without impacting on the users. That's the cool thing about
RHEL4 has issues to be ironed out... IMO I wouldn't expect it to be worthy of an Enterprise hardware setup until Update 2 is released at the minimum. Hardware certifications are way behind where EL3 got to, and they've made a couple of IMHO stupid backward steps.
One detailed example: after much ado, RH capitulated to user demand last year and included the config module in EL3 for QLogic HBAs (in a semi-broken way) so users could FINALLY take advantage of the multi-pathing feature of the cards. Better still, if you have multiple cards, thus multiple physical paths from the system to the fabric switch, and then multiple paths from the fabric switch to your SAN disk, pull any cable anywhere, and things just keep working. Once this is properly set up you can recable your SAN fabric one fibreoptic cable at a time without downtime. Mission critical anyone?
With the release of EL4, RedHat have chosen to drop this driver support for their own software MD support for multipathing. I will admit that their MD system looks pretty nice. There are however just a couple of issues - it's 6 months away at least from being mature enough for our needs, and boot times due to the pathing failovers required during boot blow out from 2ish to 5-10ish minutes, depending on the number of LUNs and the number of virtual paths (hint: multiply them together for the number of failover switches detected by the fabric and the number of seconds it takes to perform this LIP operation cleanly).
Anaconda on the installation side also has a few issues like wiping/initialising partition tables that it believes to be empty already, instead of leaving them alone, and the install does not like USB CDROM drives, such as in the IBM bladecenter (which EL3 had no problems with). I believe the latter is a certification issue, and it's just a matter of waiting for it to happen.
Point of the parent noted, but just a little too knee-jerk. The majority of the cost of RedHat products is in support, and maybe the box. If support from an external source is not what you're after, then RedHat is not for you.
Remember RedHat 5, 6, 7, 8 and 9? I know with 7 8 and 9 there was a different release cycle, free download of ISOs of one of many mirrors, free off-peak access (paying customers got priority when demand was high), and no enterprise level support. That's what you bought RH AS2.1 for.
By using CentOS (to me it looks to be the most aggressively updated), or another clone, you get a configuration which Oracle and other enterprise partners support. The trade-off is a conscious decision that you won't get any enterprise level support if something goes wrong. To many people, and some organisations, this is simply not an issue. To my workplace, it is an issue, so we have licenses. Horses for courses folks.
Besides, you'll probably find there's a lot of insight returned from the users of EL clones - this might not happen nearly as much if the cash-strapped but expertise-rich hackers couldn't get into the product. RedHat must get something out of it in better and more useful feedback, if not money.
Re:Ok, I'm buying Guild wars for real, for one rea
on
Guild Wars Launches
·
· Score: 3, Interesting
More so, I'd say it's refreshing that updates are on-the-fly and in the background. It does not appear that the server(s) need be down at all for patches! They just trickle updates to your client as they are committed...
This has always been the number one problem in Australia with EQ - a 6 hour downtime for patching during Australian prime time, followed by minimum 5 minutes, sometimes half an hour of downloading, and then your P4 3GHz PC takes its time logging you in. Then you're on for half an hour, there's a little network problem, and you come back (after another couple of minutes) to find you've just died and you're not exactly sure which way you were running when you were disconnected...
Or better still, like a friend of mine - sitting on the boat, and during a bit of lag ending up stranded on an island that the boat passed through, with some pretty mean looking goblins eyeing you over. Care to spend an hour or three swimming out of trouble - if you can avoid the sharks??? And no, despite petitioning, there was no divine assistance offered to the victim of a bug.
At least on GW if you suffer from a bug (I got stuck under the stairs I should have bee on during the last beta weekend), you can close the client, log back in and 5 seconds later... it's like the bug never happened.
If you want continuity, to me it looks like GW will provide it. I'm checking the funds, and most likely buying a key tonight.
I'm sure everybody's dealt with this sort of thing before, but yes we certainly do get rushed for time, at times, and of course it will be documentation that suffers.
However, no matter what it is, and how rushed you are, at the very least I find the minimal documentation should at least outline the functional methodology, and accompany it with purpose - ie even something simple like this can save ages figuring out why a code fragment is where it is:
/* Now we've finished the insert, free up the kludgy locks for siblings to fight over */
delete(foo);
delete(bar);
If the code itself is also self-documenting then you're nearly there. I don't often have problems going back to years-old code where I've done this, but of course it could be easier! Having said that, there's still no substitute for textbook documentation to save time and money.
Slashdot Mirror
Of course, for those who bothered to read RedHat's open letter, they will know that Fedora will continue to live on, "business as usual" as far as the average user is concerned. All that's changed is the organisational/support structure that RedHat has been providing which deals with open source and which serves as a central point for all those open source patents. It hasn't worked, so they're going for a simpler approach.
Yes, I'm oversimplifying, and generalising, so sue me for having a contrary view. Too many people seem to be doing just the opposite... </rant>
As for RedHat trying to do anything evil... would anybody who reckons they are like to try to guess how many patches they've contributed just to the Linux kernel tree as a result of bug reports for their enterprise products, say in the last year? Anyone?
As for the Australasian reference, the article only mentions Australia and New Zealand as the countries surveyed. Asian countries are not necessarily inferred by the term - the term "Asia-Pacific region" may be preferred to bring them into it. I doubt most Asian cultures are nearly as afraid of OSS as big business in Australia and NZ.
[1] Ok, so this may be a slight exaggeration, but it takes a lot of convincing to talk management into using OSS. :)
A guy I used to know developed a product in Australia, and could not sell the product or the business to anyone.
So he moved his family and business to America. Some 3 years later the product was being sold by his American company to Australians, amongst others, and his business was purchased by one of the bigger companies for $US 20 million.
Then he and his family moved back to Australia.
It seems for some stupid reason that Australian businesses want to buy products from overseas companies, America being a popular choice. It also seems that obviously they don't want "free" stuff, because there's "no such thing as a free lunch" down-under. As a culture, we are wary of gotchas, too much for our own good. I believe it to be nothing more than an over-cautious approach to new things without obviously proven major backing.
I'm interested in hearing other peoples' takes on this...
Put Bruce Willis on the probe. The minor detail of whether or not to include an air supply can be left to the engineers.
1. RedHat's distros come with (backward) compat libraries and compilers packages (optional to install) with their enterprise products. I believe the that between the two you have most things covered. The compat libraries are typically required by Oracle ...
2. You might get away with core upgrades, if it lives on an extras disk. I haven't explored them... anyone? However, if people complain loudly enough and the change isn't that major, they have been known to include things that were intended for a future release, or were even being deliberately excluded. A good example is their reluctant support for the features of QLogic FC HBAs. It took months to get them to stick it into EL3. AFAIK no clients actually paid for it (all they really had to do was incorporate the vendor's own code, and that doesn't taint the kernel), and even though the vendor's drivers were eventually compiled in, the user had to know what symbolic links and modules.conf changes to make to get it to work... before that I was downloading the source and compiling in the vendor's driver. RedHat wouldn't have supported any I/O related issues to those disks, I'm sure, but they would still support configuration of the web server!
3. RedHat have deliberately left lots of things they will refuse to support out of their kernel releases. Reiserfs is a good example of this. If you want it, you have to install the source rpm, reinstate the config and compile the modules for yourself. I do however find it very annoying that we need to in the first place. But then if you don't like it, you can always go with SuSE.
The downs may seem very significant, but the only issues this causes to the likes of me is when the hardware compatibility matrix is affected. I like to be able to dial 1-800-REDHAT and have the expectation of a reasonable answer to a reasonable question in a reasonable amount of time. Now if only they could get the answers right more often! :)
OK OK already! Maybe it was written by someone who couldn't SAY 4... errr.
OSTG may terminate a user's account in OSTG's absolute discretion and for any reason. OSTG is especially likely to terminate for reasons that include, but are not limited to, the following: (1) violation of these Terms; (2) abuse of site resources or attempt to gain unauthorized entry to the site or site resources; (3) use of an OSTG Site in a manner inconsistent with the Purpose; (4) a user's request for such termination; or (4) as required by law, regulation, court or governing agency order ; or (4) for being a smarty-pants and pointing out that this clause of the OSTG license was written by someone who couldn't count up to 4... errr.
It's all just smoke and mirrors...
The first is if you can use a pogo stick on the body, but can't escape the gravitational pull with it, then it's a planet. If that "planet" is the minor influence orbiting another planet (massive or otherwise) then it's downgraded to moon.
If such a planetary or moon sized body is part of a field, then due to gravitational forces you may be able to escape one to get to another pretty easily. This would change its classification to not a planet or moon, since due to its surrounding influences, you can escape its surface (those properties would then label it as an asteroid, or simple debris if it is orbiting some category of planet).
Second: If you can't use a pogo stick then it's a massive planet.
Third: If the pogo stick (composition of the stick needs to be standardised) melts then you're getting into the category of stars...
Ok, so you lot come up with something better! :p
Sensor registers a change in pressure or temperature, passes it up the line. Simultaneous changes amongst several sensors should be sent to higher levels, those with highest magnitude of change or threatening acceptable thresholds given highest priority. Above threshold signals could be fast-tracked to a release actuator's processor like a pain reflex, which could then make the decision to "bear with the pain" or "let go", depending on how important the burden is, whether it's holding a baby or a bowling ball. :)
So if your robot hand grips a raw egg, it quickly registers the pressure of the grip so it can stop, but it is not bothered by further "status quo" sensor readings. Of course, a sudden drop in pressure could mean one of two things:- egg has been dropped, or it's just cracked under the pressure. That's where you need to check the goo sensor matrix...
If us humans continuously tracked the output of everyone of our sensory nerves at a higher level, we'd forever be in sensory overload and would always be contemplation the need to react to the environment. My point is that such high volumes of sensory data should be manageable by programming sensor matrices to pay more attention to feeding back deltas and thresholds than continuously reading inputs.
This is the most unfortunate aspect of operating system expectations to date. Barring a genuine hardware problem, all users should expect that their operating system will never crash.
Now the vast majority is so well conditioned, that halving the frequency of crashes on their system is seen as a benefit, when they shouldn't have been allowed to happen in the first place.
I've worked with someone who has high praise for SGI. I've not played with their OS myself, but from what I've heard they're a company that takes responsibility for it. As I understand it the bug policy is along the lines of "If your application can cause a problem with our OS, it's our fault, and we will fix it, at no cost to you." They believe in your right to trust that their OS is bullet-proof, providing of course that the hardware is maintained.
When will Microsoft and other commercial vendors to offer that kind of stability? When can we expect a crash-free OS to be the norm rather than the exception?
Fact: RedHat EL3's default httpd configuration is AWFUL for busy websites on high end machines, compared to say Windows/IIS defaults, though on cheap/low powered hardware running with a 300MHz CPU it would probably benchmark better. Back at the high end, tweak 4-6 settings to make more serving threads available and it will make use of that little extra RAM, and put you back ahead of the game. If you want more than that though, look at a Web Performance Tuning book.
I've also heard of tools out there which can look at your system performance (eg if you run sar) and tell you what kernel parameters you need to alter to reduce bottlenecks and improve utilisation of underused system resources. You may have to pay for such a tool, but chances are it can delay the need for upgrading to meet growth of demand.
The biggest downside is that, looking at the GPFS benchmarks in IBM's redpaper on intel clusters vs the virtualisable P series, clustering filesystems on intel hardware simply does not seem to scale I/O at all well compared to the high end equipment like IBM's P690 or 595, which are pretty close to linear.
The other downside is that RedHat will not support it. But then RedHat also prefer you to boot off your lone internal IDE drive rather than off your SAN (which appears to be flatly unsupported).
Yes, I will bitch about RedHat a bit, as I have had to deal with their support for some time now, but all in all IMHO they're still good for Linux. Hopefully they will pull through with building Enterprise quality generic multipathing support into EL4 through the dm and md...
Then at the moment we are able to perfectly reconstruct the item, it could be nowhere, or anywhere? Sounds like it's already been done to me, in the Heart of Gold!
But more seriously, anyone care to try to laymanise how the existence of negative quantum information can help with research into teleportation?
In short, specify what the time offset usually is relative to UTC, how much yer DST shifts the time by, when it starts and ends (time/day/month). It is flexible enough to define "the nth {day of week} of the month" such as 1st Sunday, 2nd... or last. Wheeeeee! Updates will surely follow in a GNU libc update in the near future.
By observing the harmonics in the wobble for any star for long enough we should be able to determine how many bodies are orbiting it and their period. The only limitations on this are how long we observe for and how sensitive our equipment is at watching it.
On a stellar scale, we "listen" to the details of wobble of the sun, in 1 dimension from our perspective - the variations in its velocity away from us. Then we extract the harmonics of the wobble - the wobbles within the wobble - a range of frequencies at distinct volumes would be observed. Frequency of a particular harmonic would reveal the length of the planet's year, and amplitude would be a result of the planet's relative mass. Nothing that basic Fourier analysis can't sort out, as long as the samples are accurate enough. SETI@home could probably be altered to look for this, but I fear there wouldn't be enough work units to go around!
Unfortunately, if we were looking down upon an orbital plane, we would probably see no doppler shift of the star. The other problem is that observing the "signal" to be sure of the result would ideally take at least 1 complete orbit of the furthest planet around the body (anyone care to correct that as my theory is rusty?) Measuring Uranus' period would be possible by measuring our Sun's wobble, taking into account the interference caused by the inner planets, but could take a while, unless using really sensitive equipment which can accurately measure and extrapolate the orbit from a small segment of a sinusoidal wobble.
Ok so consensus would have us leaning toward a really cool name like "Deathstar". Sorry for stating the obvious!
(end of previous :)
The first thing you should do as a web administrator on your P4 class RH box running Apache is tune the following settings. Whether you use a tool, or edit directly depends on what kind of support you expect when you mess it up. The below is one of many possible solutions depending on available memory, processor speed, SMP capabilities/kernel version, and whether you anticipate a high rate of connections or a larger amount of CGI type work:
- StartServers - typical default is 2. If you're half serious about your web server being able to respond to requests from the completion of startup, try 10. That's just to get the ball rolling.
- MaxClients - 150 is a typical value. Try 1000 so you're prepared for incoming connections.
- MinSpareThreads - 25 may be ok usually, but if you get a surge of benchmark style incoming connections, you're bound to be caught out not ready to accept some. Try 100, or 200 if you have a little memory to burn.
- MaxSpareThreads - 75 might seem decent, your SMP box will be much more responsive with 200, perhaps a better idea being 500. Even 2000 if you can see memory usage isn't a problem.
- ThreadsPerChild - 25 is ok in my book. You probably don't want each process responsible for too much, especially if they do uninterruptible things. But you may be able to up it for a purely static site.
Remember, if you are running a web server, you should be tuning it to use all available resources, without thrashing your swap space. Look at the numbers and tune it. Expect any modern PC running Linux/Apache to take 5000 static hits per second sustained on an SMP box without breaking a sweat. If during a peak time you can see a resource underutilised, then tweak and tune it - any good admin should be able to squeeze orders of magnitude better performance out of it over the default config. Using half the memory and bugger all swap? Up the threads by 50% or more...Once you have your web serving building block optimised, virtual services can then be used to load-balance traffic for extreme peaks, and taking boxes down for essential maintenance without impacting on the users. That's the cool thing about
One detailed example: after much ado, RH capitulated to user demand last year and included the config module in EL3 for QLogic HBAs (in a semi-broken way) so users could FINALLY take advantage of the multi-pathing feature of the cards. Better still, if you have multiple cards, thus multiple physical paths from the system to the fabric switch, and then multiple paths from the fabric switch to your SAN disk, pull any cable anywhere, and things just keep working. Once this is properly set up you can recable your SAN fabric one fibreoptic cable at a time without downtime. Mission critical anyone?
With the release of EL4, RedHat have chosen to drop this driver support for their own software MD support for multipathing. I will admit that their MD system looks pretty nice. There are however just a couple of issues - it's 6 months away at least from being mature enough for our needs, and boot times due to the pathing failovers required during boot blow out from 2ish to 5-10ish minutes, depending on the number of LUNs and the number of virtual paths (hint: multiply them together for the number of failover switches detected by the fabric and the number of seconds it takes to perform this LIP operation cleanly).
Anaconda on the installation side also has a few issues like wiping/initialising partition tables that it believes to be empty already, instead of leaving them alone, and the install does not like USB CDROM drives, such as in the IBM bladecenter (which EL3 had no problems with). I believe the latter is a certification issue, and it's just a matter of waiting for it to happen.
Remember RedHat 5, 6, 7, 8 and 9? I know with 7 8 and 9 there was a different release cycle, free download of ISOs of one of many mirrors, free off-peak access (paying customers got priority when demand was high), and no enterprise level support. That's what you bought RH AS2.1 for.
By using CentOS (to me it looks to be the most aggressively updated), or another clone, you get a configuration which Oracle and other enterprise partners support. The trade-off is a conscious decision that you won't get any enterprise level support if something goes wrong. To many people, and some organisations, this is simply not an issue. To my workplace, it is an issue, so we have licenses. Horses for courses folks.
Besides, you'll probably find there's a lot of insight returned from the users of EL clones - this might not happen nearly as much if the cash-strapped but expertise-rich hackers couldn't get into the product. RedHat must get something out of it in better and more useful feedback, if not money.
This has always been the number one problem in Australia with EQ - a 6 hour downtime for patching during Australian prime time, followed by minimum 5 minutes, sometimes half an hour of downloading, and then your P4 3GHz PC takes its time logging you in. Then you're on for half an hour, there's a little network problem, and you come back (after another couple of minutes) to find you've just died and you're not exactly sure which way you were running when you were disconnected...
Or better still, like a friend of mine - sitting on the boat, and during a bit of lag ending up stranded on an island that the boat passed through, with some pretty mean looking goblins eyeing you over. Care to spend an hour or three swimming out of trouble - if you can avoid the sharks??? And no, despite petitioning, there was no divine assistance offered to the victim of a bug.
At least on GW if you suffer from a bug (I got stuck under the stairs I should have bee on during the last beta weekend), you can close the client, log back in and 5 seconds later ... it's like the bug never happened.
If you want continuity, to me it looks like GW will provide it. I'm checking the funds, and most likely buying a key tonight.
However, no matter what it is, and how rushed you are, at the very least I find the minimal documentation should at least outline the functional methodology, and accompany it with purpose - ie even something simple like this can save ages figuring out why a code fragment is where it is:
delete(foo);
delete(bar);
If the code itself is also self-documenting then you're nearly there. I don't often have problems going back to years-old code where I've done this, but of course it could be easier! Having said that, there's still no substitute for textbook documentation to save time and money.
The (pick one of the nationals) says: (what?)
The (pick one of the remaining nationals) says: (what?)
The (insert remaining national here) then says: (punch line).
Anyone???