So I wait for AMD to get a bit more
serious about thermal protection and stick with
using cheaper processors as thermal fuses.
So I wait for slashdot posters to actually do a
little research and discover that AMD has listened
to their customers and put thermal diodes in the
Athlon XP line...
Just FYI, we're currently doing extensive
stability testing of ext3 and getting good
results. Part of the reason that ext3 is
still considered beta is that Stephen is
a perfectionist -- which doesn't bother me
in the least!:-)
First, I disagree with teg; in standard use, I
would hope that TUX would serve dynamic
content--that was definitely the intent.
TUX has four ways of handling dynamic
content, and only one, kernel-space TUX
modules, runs in kernel space--and we
recommend that people not implement kernel-space
TUX modules unless they have an overriding
reason to do so. Normal TUX modules are
run entirely in user space and have all
the same security checks as any other user-space
program.
TUX can handle dynamic data on its own in several
ways:
CGI programs, which TUX can call directly
TUX modules in user space
(recommended, no significant performance
penalty relative to kernel space)
TUX modules in kernel space
(not recommended unless there is some
particular reason for kernel integration,
and performance is not an issue)
Pass-through to other servers
(normally used only for modules that
have not been ported to TUX; for example,
mod_php; most of these modules have other
speed constraints so there is not much
reason to port them to the TUX framework)
TUX can serve dynamic content VERY
fast, even running CGIs. Because of
the overhead of dynamic linking, we
recommend that CGIs running under TUX
be linked statically for maximum
performance. (This is, of course,
not an issue for TUX modules, since
they are loaded at server start time,
not at each invocation.)
While TUX does have a fast path that
can serve up static content without ever
reaching user space, there is an option
to send all requests through user space
that only costs a few percent of performance
even in the worst case. This can allow
all sorts of interesting fine-grained
control.
I suppose I'm a pedant, but "endurance" means
time aloft, not distance flown. This plane set
a record for distance flown by a robotic plane,
not the record for time aloft.
I can't see how less than 24 hours en route
qualifies for an endurance record, since a
small (10 foot wingspan) robotic
propeller-driven plane called an "Aerosonde"
crossed the atlantic in August 1998, taking
about 26 hours 45 minutes.
In fact, I seem to
remember that/. carried that story, though
I don't find it in a quick search.
I did find a few other stories from that time,
though, at
ABC and
EXN, and you can always visit
Aerosonde
Robotic Aircraft if you are interested.
I think, but do not know, that there have been
robotic flights longer in duration than that,
but I don't have time to look for them now.:-)
I've put up slides from several talks I have
done on my web page. Several of the talks
are fairly similar to each other, explaining
some of the benefits of Open Source to several
different audiences. There might be useful
material there. FWIW...
I know I shouldn't respond to a troll, but I'll
do it anyway.
Linus's point is that he has asked all the
major Linux houses to (if they had not done so
already -- I expect that most, like Red Hat, had
already started) add their testing
resources to the other testing resources
(i.e. individual users and developers)
already deployed. Different developers
(individuals and corporations) have different
strengths. Your idea that Linux corporations
are not part of the bazaar, not part of the
thousands of eyes, not part of the the Linux
community, is, well, bizarre.:-)
The theoretical framework of the bazaar model
does not imply that all the participants are
not paid for their participation. Just because
Eric Raymond wrote up what he thought the bazaar
model looked like to him, and because his model
was recognized by many people as a good
description of the process, doesn't mean that
his writeup was perfect, nor does it make his
analysis proscriptive; it especially does not
make others' misunderstandings of his model
proscriptive.
Individual users have the widest
variety of hardware -- we as individuals do
the best job of finding the odd hardware
support bug.
However, the Linux development
houses have a major financial interest in
stabilizing 2.4 in ways that are hard to do
without more capital than the average user
has, trying to find corner case bugs both
by code inspection and by hammering on
machines with lots of CPUs and lots of
memory, using stress tests and correctness
tests. I expect that all the other Linux
development houses are doing this; I know for
a fact that we at Red Hat are doing this and,
as an example, we have (through stress testing)
been helping discover elusive memory corruption
issues recently, and (primarily through
inspection) been discovering and fixing many
filesystem race conditions. Those are just a
few examples, and are only from my experience
at Red Hat. I'm sure that developers from other
Linux houses could talk about how their bug
testing work has fit into this model as well.
Relax, we're all in this together! Sit
back, relax, and enjoy the ride...
Actually, TUX (the kernel-accelerated web server
developed by Red Hat) does not offload all
non-static requests to
"Apache/AOLserver/whatever". TUX is capable of
serving complex dynamic requests both with
in-kernel and user-space modules, as well as
directly running CGI executables. TUX can also
forward requests for which no TUX module has
been written to Apache to serve, but unlike
khttpd, it is possible to have a full website
with dynamic content entirely served by TUX.
Forwarding to Apache (or whatever) is most
useful for complex modules that would be difficult
to port to TUXapi. TUXapi is event-driven
instead of connection-oriented, in order to
provide maximum speed. This makes TUX modules
harder to write than Apache modules. Forwarding
to Apache lets you take advantage of the ease
of writing Apache modules when speed for that
particular module is not critical, while
still allowing TUXapi modules to directly handle
speed-critical tasks.
They said that 3 miles was about as high as a
commuter aircraft. Commuter aircraft are
the smaller passenger aircraft generally operated
in the US by regional airlines, and 3 miles is
reasonably close to how high they fly. They
were not talking about the large airliners
that generally fly roughly 6-8 miles high.
Yes, their service/support folks came through
pretty well for me. I tried to write a careful
and detailed bug report, which I hope helped;
the response I got (in less than a day, probably
about 4-5 business hours) was not only correct,
it was courteous and even well-written.
I bought a TRGpro
unit, which has a type 2 Compact Flash slot;
that can hold many sizes of flash memory, the
IBM microdrives, CF ethernet cards, CF modem
cards, CF barcode scanners, etc. It's an
open industry standard, with multiple
manufacturers. Compare that to the sony
memory stick (proprietary technology) and
think about rambus licensing.
I wasn't always so please with my TRGpro;
it came with the now-infamous DRAM bug that
lost data... But with an OS upgrade, that
appears to have been fixed, and I love being
able to back up my palm pilot any time without
even having to be near a computer.:-)
...with the emphasis on art. It's somewhat interesting to note that several patent applications were denied because Jules Verne had already described them in his science fiction novels. The best known case of this was for the periscope, which Verne had described some years earlier in 20,000 Leagues Under the Sea. I have been told that there were other instances of this from Verne's novels, but don't recall what they were.
A few minor corrections...
on
Flying Trains
·
· Score: 2
"the tailwing doesn't create a whole lot of lift" Actually, the tailwing in a conventional aircraft produces negative lift (pushes down), which increases stability. You might visualize it as similar to drilling a hole while both pushing and pulling on a drill to avoid pushing the bit too far through when you get through, as brain surgeons do when drilling holes in skulls. Non-conventional planes, such as canard designs, often have no "tailwing" at all.
"Flipping over backwards" is not typical of overloaded airplanes. The most common thing is to simply not be able to climb out of ground effect. This is most common in hotter, more humid, and higher altitude environments than the pilots are used to, as each of these factors reduces the density of the air; reducing the density of the air then reduces thrust and lift capacity at the same time.
Taking off tail-heavy is very easy will make the aircraft difficult to control, and may cause a stall, particularly at low speed. However, it is more likely to cause a stall at approach to landing, as most aircraft store lots or all of their fuel in the wings, and as they use up fuel their center of gravity shifts slowly backwards. While the horizontal stabilizer ("tailwing") has sufficient effectiveness to prevent at stall at cruise speed, the airplane will be more likely to stall when it slows down for approach to landing, and will be hard to control in any case. Fortunately, certified aircraft generally have significant margin of error.
Finally, I strongly doubt that the fat man you saw put your plane in danger. The crew will feel no compunction about asking folks to move around whenever there is a weight and balance problem; I've been on quite a few flights when this has happened. In this case, he might have been undercounted, but not completely ignored for W&B calculations. There is an "FAA standard passenger" that can be used for these calculations so that they do not have to ask you to stand on a scale, and at a minimum it is likely that he had been accounted in this manner. If they were very close to the W&B envelope, they would have known it and would likely have re-run their calculations.
Folks interested in reading some of the best technical writing ever created and in learning more about the theory of flight should read Stick and Rudder by Wolfgang Langeweische. Only beware, as aviation is an addictive persuit, and you might get hooked.:-)
APM is a horribly broken thing (calling it a standard is suggesting too much); ACPI, while not perfect, does push policy and most implementation into the OS, so we will be less dependent on BIOS implementation quality, and better able to work around bugs.
My Latitude CP runs RedHat without any help from Dell
Not if you are using sound. Dell sent hardware and provided assistance in getting programming information for the Maestro audio chipset. So, while Red Hat developed the Maestro driver, Dell certainly did help.
In the FWIW department: In August of this year, roughly ten years after that 1989 demo you mention, Private Pilot published a flight test review of the MiG 29. (You, too, can conduct your own flight test for only $27,000 or so...) I'll quote a few paragraphs here in what I hope is fair use.
The cockpit's analog "steam gauges" are reminiscent of the cockpits of U.S. fighters of the 1970s. One big drawback of the weapons-management system is the complexity of operating it, requiring the pilot to manually sequence a multitude of settings and divide his time between inside and outside the cockpit.
There is, however, on interesting twist on weapons management: The MiG 29 has a so-called "passive" infrared targeting system, which may also be linked to a helmet-mounted sight. The advantage of this system (effective only in visual conditions) is that it allows MiG 29 pilots to turn off everything "active," such as their radar, that would allow their opponents to acquire a lock on them....
The Mikoyan Design Bureau has been working hard to overcome the airplane's drawbacks... new versions of the fighter have been recently introduced, featuring glass cockpits...
The clever Chinese passive detection system is just one of many passive detection systems...:-)
In general, everything I've heard, which has been common knowledge in the west, has been that the MiG fighters have a very good reputation for engineering. In particular, westerners seem amazed (I was amazed, for one) to learn that the MiGs are not fly-by-wire and are still very easy to fly.
Now would you please ADD some serious multilingual support fast?
I wanna be able to write, read Arabic and view web pages in that language!
As it happens, Owen Taylor, one of the GTK+ hackers and a Red Hat employee, is working on real multi-lingual support in Gtk, including proper right-to-left support. Right-to-left support isn't highly likely at the console any time soon, but I can't imagine monospace arabic lettering looking very good anyway...:-)
Proper multilingual support is most definitely one of the things that Red Hat is putting its people's time into. You might want to see the GNOME I18N information, and in particular, from that page, Owen Taylor's Internationalization in GTK+ whitepaper. To quote:
Future plans include suppport for the Unicode standard and languages written in a right-to-left direction.
We aren't keeping it secret, we just haven't released it yet because there is no product to release. What we have is mostly code that is tied into our internal systems and is not generic. We don't have a product, just a bunch of custom code...
So, we aren't going to keep the server functionality secret, it will just take time to create a release of the pieces you need to build a server. It will be released when it is ready.
In the meantime, the the protocol is documented to some extent.
Red Hat is not creating a forked kernel; we maintain our patches as patches to Linus's kernel, allow anyone to use them, and try to push back everything that is not a customization specific to Red Hat Linux back to Linus on a time scale that he is comfortable with.
Your differentiation between "the normal kernel dev people/the kernel development team" and Red Hat does not make a lot of sense in context, because Red Hat's kernel developers are a subset of "the normal kernel dev people" and, in fact, Alan Cox, who is one of the kernel developers who work for Red Hat, is the one who does most of the kernel patch integration work for the stable kernels for Linus.
In any case, we actively integrate our patches with Linus's kernel. This is done individually by the developers working on their particular areas. The idea of maintaining a truly forked kernel is a nightmare to us, and no one in their right mind would want to do it.
So we are, in this context, just another group of highly-motivated and focused kernel hackers contributing code to the Linux kernel in the normal way, which involves maintaining patches outside the Linux kernel until Linus accepts them.
In a production context, we don't want to add patches to our official products that extend APIs beyond what Linus has blessed. The specter of us blessing an API that was subsequently cursed by the chief penguin himself would haunt us horribly.
I have a religiously held belief that a for-profit organization shouldn't have full rule and rein over a non-profit one.
Funny, the IRS agrees with you.:-) Now you know one of the reasons that Red Hat's representation on the RHCOS board is decidedly minority.
As far as funding goes, I suggest that you take your example and ask the FSF which companies have provided the most financial support to them in the past few years. RHCOS is not a replacement for funding appropriate groups and people, but an addition. Wait until you see what RHCOS does before deciding whether to condemn it.
Yes, you can change the definition of the RPM_OPT_FLAGS on your machine and use rpm --rebuild on the source rpms.
Just be aware that optimization is more tricky than it looks; merely using the -mfoo flag for your processor guarantees neither faster speed nor smaller size.
Slashdot Mirror
Just FYI, we're currently doing extensive stability testing of ext3 and getting good results. Part of the reason that ext3 is still considered beta is that Stephen is a perfectionist -- which doesn't bother me in the least! :-)
TUX has four ways of handling dynamic content, and only one, kernel-space TUX modules, runs in kernel space--and we recommend that people not implement kernel-space TUX modules unless they have an overriding reason to do so. Normal TUX modules are run entirely in user space and have all the same security checks as any other user-space program.
TUX can serve dynamic content VERY fast, even running CGIs. Because of the overhead of dynamic linking, we recommend that CGIs running under TUX be linked statically for maximum performance. (This is, of course, not an issue for TUX modules, since they are loaded at server start time, not at each invocation.)
While TUX does have a fast path that can serve up static content without ever reaching user space, there is an option to send all requests through user space that only costs a few percent of performance even in the worst case. This can allow all sorts of interesting fine-grained control.
$subj
I suppose I'm a pedant, but "endurance" means time aloft, not distance flown. This plane set a record for distance flown by a robotic plane, not the record for time aloft.
I can't see how less than 24 hours en route qualifies for an endurance record, since a small (10 foot wingspan) robotic propeller-driven plane called an "Aerosonde" crossed the atlantic in August 1998, taking about 26 hours 45 minutes. In fact, I seem to remember that /. carried that story, though
I don't find it in a quick search.
I did find a few other stories from that time, though, at ABC and EXN, and you can always visit Aerosonde Robotic Aircraft if you are interested.
I think, but do not know, that there have been robotic flights longer in duration than that, but I don't have time to look for them now. :-)
I've put up slides from several talks I have done on my web page. Several of the talks are fairly similar to each other, explaining some of the benefits of Open Source to several different audiences. There might be useful material there. FWIW...
Linus's point is that he has asked all the major Linux houses to (if they had not done so already -- I expect that most, like Red Hat, had already started) add their testing resources to the other testing resources (i.e. individual users and developers) already deployed. Different developers (individuals and corporations) have different strengths. Your idea that Linux corporations are not part of the bazaar, not part of the thousands of eyes, not part of the the Linux community, is, well, bizarre. :-)
The theoretical framework of the bazaar model does not imply that all the participants are not paid for their participation. Just because Eric Raymond wrote up what he thought the bazaar model looked like to him, and because his model was recognized by many people as a good description of the process, doesn't mean that his writeup was perfect, nor does it make his analysis proscriptive; it especially does not make others' misunderstandings of his model proscriptive.
Individual users have the widest variety of hardware -- we as individuals do the best job of finding the odd hardware support bug.
However, the Linux development houses have a major financial interest in stabilizing 2.4 in ways that are hard to do without more capital than the average user has, trying to find corner case bugs both by code inspection and by hammering on machines with lots of CPUs and lots of memory, using stress tests and correctness tests. I expect that all the other Linux development houses are doing this; I know for a fact that we at Red Hat are doing this and, as an example, we have (through stress testing) been helping discover elusive memory corruption issues recently, and (primarily through inspection) been discovering and fixing many filesystem race conditions. Those are just a few examples, and are only from my experience at Red Hat. I'm sure that developers from other Linux houses could talk about how their bug testing work has fit into this model as well.
Relax, we're all in this together! Sit back, relax, and enjoy the ride...
Feel free to download TUX from ftp://ftp.redhat.com/pub/redhat/tux/Read the README file first, of course. :-)
You are conflating two servers. khttpd is a static-page-only accelerator; TUX does both static and dynamic content.
Forwarding to Apache (or whatever) is most useful for complex modules that would be difficult to port to TUXapi. TUXapi is event-driven instead of connection-oriented, in order to provide maximum speed. This makes TUX modules harder to write than Apache modules. Forwarding to Apache lets you take advantage of the ease of writing Apache modules when speed for that particular module is not critical, while still allowing TUXapi modules to directly handle speed-critical tasks.
Lots more detail is available in the /. interview with Ingo Molnar.
(I'm not dissing khttpd; Arjan (author of khttpd) likes TUX. :-)
They said that 3 miles was about as high as a commuter aircraft. Commuter aircraft are the smaller passenger aircraft generally operated in the US by regional airlines, and 3 miles is reasonably close to how high they fly. They were not talking about the large airliners that generally fly roughly 6-8 miles high.
Yes, their service/support folks came through pretty well for me. I tried to write a careful and detailed bug report, which I hope helped; the response I got (in less than a day, probably about 4-5 business hours) was not only correct, it was courteous and even well-written.
Well, this is a duplicate post but the TRGpro got that part right. You can put an IBM microdrive in it.
I wasn't always so please with my TRGpro; it came with the now-infamous DRAM bug that lost data... But with an OS upgrade, that appears to have been fixed, and I love being able to back up my palm pilot any time without even having to be near a computer. :-)
...with the emphasis on art. It's somewhat interesting to note that several patent applications were denied because Jules Verne had already described them in his science fiction novels. The best known case of this was for the periscope, which Verne had described some years earlier in 20,000 Leagues Under the Sea. I have been told that there were other instances of this from Verne's novels, but don't recall what they were.
"Flipping over backwards" is not typical of overloaded airplanes. The most common thing is to simply not be able to climb out of ground effect. This is most common in hotter, more humid, and higher altitude environments than the pilots are used to, as each of these factors reduces the density of the air; reducing the density of the air then reduces thrust and lift capacity at the same time.
Taking off tail-heavy is very easy will make the aircraft difficult to control, and may cause a stall, particularly at low speed. However, it is more likely to cause a stall at approach to landing, as most aircraft store lots or all of their fuel in the wings, and as they use up fuel their center of gravity shifts slowly backwards. While the horizontal stabilizer ("tailwing") has sufficient effectiveness to prevent at stall at cruise speed, the airplane will be more likely to stall when it slows down for approach to landing, and will be hard to control in any case. Fortunately, certified aircraft generally have significant margin of error.
Finally, I strongly doubt that the fat man you saw put your plane in danger. The crew will feel no compunction about asking folks to move around whenever there is a weight and balance problem; I've been on quite a few flights when this has happened. In this case, he might have been undercounted, but not completely ignored for W&B calculations. There is an "FAA standard passenger" that can be used for these calculations so that they do not have to ask you to stand on a scale, and at a minimum it is likely that he had been accounted in this manner. If they were very close to the W&B envelope, they would have known it and would likely have re-run their calculations.
Folks interested in reading some of the best technical writing ever created and in learning more about the theory of flight should read Stick and Rudder by Wolfgang Langeweische. Only beware, as aviation is an addictive persuit, and you might get hooked. :-)
PPSEL (Private Pilot, Single-Engine Land); Experimental Pulsar N456LT
APM is a horribly broken thing (calling it a standard is suggesting too much); ACPI, while not perfect, does push policy and most implementation into the OS, so we will be less dependent on BIOS implementation quality, and better able to work around bugs.
Not if you are using sound. Dell sent hardware and provided assistance in getting programming information for the Maestro audio chipset. So, while Red Hat developed the Maestro driver, Dell certainly did help.
FWIW
In general, everything I've heard, which has been common knowledge in the west, has been that the MiG fighters have a very good reputation for engineering. In particular, westerners seem amazed (I was amazed, for one) to learn that the MiGs are not fly-by-wire and are still very easy to fly.
Proper multilingual support is most definitely one of the things that Red Hat is putting its people's time into. You might want to see the GNOME I18N information, and in particular, from that page, Owen Taylor's Internationalization in GTK+ whitepaper. To quote:
So, we aren't going to keep the server functionality secret, it will just take time to create a release of the pieces you need to build a server. It will be released when it is ready.
In the meantime, the the protocol is documented to some extent.
Your differentiation between "the normal kernel dev people/the kernel development team" and Red Hat does not make a lot of sense in context, because Red Hat's kernel developers are a subset of "the normal kernel dev people" and, in fact, Alan Cox, who is one of the kernel developers who work for Red Hat, is the one who does most of the kernel patch integration work for the stable kernels for Linus.
In any case, we actively integrate our patches with Linus's kernel. This is done individually by the developers working on their particular areas. The idea of maintaining a truly forked kernel is a nightmare to us, and no one in their right mind would want to do it.
So we are, in this context, just another group of highly-motivated and focused kernel hackers contributing code to the Linux kernel in the normal way, which involves maintaining patches outside the Linux kernel until Linus accepts them.
In a production context, we don't want to add patches to our official products that extend APIs beyond what Linus has blessed. The specter of us blessing an API that was subsequently cursed by the chief penguin himself would haunt us horribly.
Funny, the IRS agrees with you. :-) Now you know one of the reasons that Red Hat's representation on the RHCOS board is decidedly minority.
As far as funding goes, I suggest that you take your example and ask the FSF which companies have provided the most financial support to them in the past few years. RHCOS is not a replacement for funding appropriate groups and people, but an addition. Wait until you see what RHCOS does before deciding whether to condemn it.
Just be aware that optimization is more tricky than it looks; merely using the -mfoo flag for your processor guarantees neither faster speed nor smaller size.