We have, indeed, considered that, but it'd not really buy us anything. Earlier Apaches would sit on a lot of memory while serving large files, but current versions just have a thread sitting in sendfile(), which is just about as lightweight as you get.
Sure, the startup cost of the transaction is higher than for a lightweight HTTP server, but the startup cost of the transaction isn't a big deal for us, and we appreciate the flexibility that Apache offers.
Not exactly. It's actually a BIOS. It replaces your PC BIOS.
That's like saying "this bicycle replaces your car, therefore this bicycle is actually a car." BIOS (formally, the PC CBIOS) isn't just an arbitrary piece of firmware, it's an interface standard, and a fairly complex one at that. The whole point of an interface is that you should be able to rely on it without having to worry about what's on the other side.
The LinuxBIOS webpage itself states:
We'd like it to boot others, but not all OSes can boot under LinuxBIOS...
OSes like FreeBSD make heavy use of BIOS callbacks... and we don't support BIOS callbacks
LinuxBIOS is not a BIOS, it's a non-standard firmware interface.
This is pretty much OK for embedded use, but for anything where you need standard BIOS functionality, it's useless. Worse, the name "LinuxBIOS" implies that it is BIOS functionality, which causes people to try to use it in inappropriate situations.
Actually, the reason the second version came out ahead is probably because you're on an architecture with a penalty-free base+index addressing mode, and the compiler only generated one increment in the second case.
The former is a lot more concise, and conciseness helps getting the *big* concepts down.
Anyone with any familiarity with C will consider the latter form unnecessarily more verbose, and therefore less clear.
There is one exception to that, and that is when "ptr" is in fact a complex expression that it isn't obvious at a glance is a pointer expression. In that case, == NULL or != NULL spells out to the reader of the code "oh, and by the way, it's a pointer." That is the ONLY reason to write this for clarity.
There is a whole category of "bad commenting" in which comments left that are only useful to someone who don't know the programming language actually makes the code a lot harder to read. A comment like:
a += 2;/* Add two to a */
... is not helpful in any shape, way or form, and just provides mental clutter.
Red supergiants may be large, but their density have been described by e.g. Larry Niven as "red-hot vacuum." At least their outer layers are very tenuous at best. Given that the masses are typically only a few orders of magnitude more than the Sun, at most, but that their volumes are enormously much bigger, there can't be that
This means (surface) gravity is low and they can get by with less hydrostatic pressure to maintain their bulk.
The *core* is typically very dense, much denser than the Sun. Higher pressures are needed to support fusion of higher-order elements. Makes the surface layers even less dense, since a lot of the mass is still in the core.
They (e.g. Konrad Zuse) built computers based on electromechanical relays because they were more reliable than vacuum tube circuits. I, like most people, thought that it was due to the vacuum tubes themselves, until I had the opportunity to meet Maurice Wilkes of EDSAC fame. He explained that, no, the tubes were plenty reliable, but the solid-carbon resistors used in those days didn't handle the high voltages used in the tube circuits very well, and thus constantly failed.
Since relays are inherently switching elements as opposed to amplifier elements, they did not need resistors; the only necessary resistance is the one inherent in the relay coils themselves.
... and not just for "the warm sound." They're used because they can be built arbitrarily large much easier than you can build power MOSFETs. You can build them to produce hundreds of megawatts of RF energy with a single klystron; a linear amplifier tube can easily be built to handle megawatts.
I haven't heard of any 1.22 GW vacuum tubes, but they certainly could be built. They'd be large.
WiWith sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.
If you want free design software, try out Eagle from Cadsoft. They have a free-as-in-beer version for small boards (100x80, two layers), and a cheap license for nonprofit use. Native Linux and MacOS support (their software is written using Qt, so it's pretty easy for them to do.)
One of the "silent revolutions" that has happened over the last 10-20 years is the tremendous drop in cost of programmable logic -- highly integrated microcontrollers, CPLDs, and FPGAs. It's really only in the last few years that FPGAs in particular has come down in price to the point where they're feasible to be used in amateur projects. In many ways these have brought back the freedoms that used to exist back when there were no application-specific integrated circuits (ASICs); today, with an FPGA costing in the ballpark of $20 even a hobbyist can build a fairly sophisticated, custom integrated circuit for a project.
Cellphones are banned for interference reasons by the FCC. Cellphones might also be banned for (perceived) safety reasons by any individual airline (or, for that matter, aircraft captain); cell phones are *NOT* banned by the FAA.
Not really. 802.11a operates in the 5 GHz band, and can thus coexist with 802.11b without suffering degradation, unlike 802.11g which does degrade when.11b devices are present -- if nothing else because the.11b devices hog the channel for 5 times as long.
Thus, heavy-use WLANs like corporate installations are frequently A+G, and a lot of current wlan client chips are also A+G.
In the current wlan market, 802.11a is the premium solution; unfortunately both in terms of cost and performance.
Slashdot Mirror
Fortunately, rsync has a compression exclude list.
We have, indeed, considered that, but it'd not really buy us anything. Earlier Apaches would sit on a lot of memory while serving large files, but current versions just have a thread sitting in sendfile(), which is just about as lightweight as you get.
Sure, the startup cost of the transaction is higher than for a lightweight HTTP server, but the startup cost of the transaction isn't a big deal for us, and we appreciate the flexibility that Apache offers.
That's like saying "this bicycle replaces your car, therefore this bicycle is actually a car." BIOS (formally, the PC CBIOS) isn't just an arbitrary piece of firmware, it's an interface standard, and a fairly complex one at that. The whole point of an interface is that you should be able to rely on it without having to worry about what's on the other side.
The LinuxBIOS webpage itself states:
In other words, LinuxBIOS is not a (C)BIOS.
LinuxBIOS is not a BIOS, it's a non-standard firmware interface.
This is pretty much OK for embedded use, but for anything where you need standard BIOS functionality, it's useless. Worse, the name "LinuxBIOS" implies that it is BIOS functionality, which causes people to try to use it in inappropriate situations.
Actually, the reason the second version came out ahead is probably because you're on an architecture with a penalty-free base+index addressing mode, and the compiler only generated one increment in the second case.
if (0!=ptr) is a hideous abortion, because it's not readable.
Also, your statement that "relying on NULL to be compatible with all pointer types is risky" is just plain wrong.
!(x-x) can be true if x is a floating-point variable (in which case it's equivalent to isnan(x)).
Anyone with any familiarity with C will consider the latter form unnecessarily more verbose, and therefore less clear.
There is one exception to that, and that is when "ptr" is in fact a complex expression that it isn't obvious at a glance is a pointer expression. In that case, == NULL or != NULL spells out to the reader of the code "oh, and by the way, it's a pointer." That is the ONLY reason to write this for clarity.
There is a whole category of "bad commenting" in which comments left that are only useful to someone who don't know the programming language actually makes the code a lot harder to read. A comment like:
a += 2;
Bullshit.
Read the C standard about the definition of a null pointer constant.
It should have, which is exactly why it wasn't. After all, the settlement was paid for with campaign contributions.
Rather low? Hydrogen has the highest specific energy of any chemical fuel.
Red supergiants may be large, but their density have been described by e.g. Larry Niven as "red-hot vacuum." At least their outer layers are very tenuous at best. Given that the masses are typically only a few orders of magnitude more than the Sun, at most, but that their volumes are enormously much bigger, there can't be that
This means (surface) gravity is low and they can get by with less hydrostatic pressure to maintain their bulk.
The *core* is typically very dense, much denser than the Sun. Higher pressures are needed to support fusion of higher-order elements. Makes the surface layers even less dense, since a lot of the mass is still in the core.
Since relays are inherently switching elements as opposed to amplifier elements, they did not need resistors; the only necessary resistance is the one inherent in the relay coils themselves.
... and not just for "the warm sound." They're used because they can be built arbitrarily large much easier than you can build power MOSFETs. You can build them to produce hundreds of megawatts of RF energy with a single klystron; a linear amplifier tube can easily be built to handle megawatts.
I haven't heard of any 1.22 GW vacuum tubes, but they certainly could be built. They'd be large.
From this morning...
570 Mbit/s (about 540 Mbit/s of which are mirrors.kernel.org, i.e. mostly Fedora); load average 232.44.
Jan Hubicka, as part of the SuSE team which ported Linux to x86-64.
WiWith sufficient thrust, pigs fly just fine. However, this is not necessarily a
good idea. It is hard to be sure where they are going to land, and it could be
dangerous sitting under them as they fly overhead.
- Ross Callon, editor; RFC 1925
Mandatory reading for the larval geek...
If you want free design software, try out Eagle from Cadsoft. They have a free-as-in-beer version for small boards (100x80, two layers), and a cheap license for nonprofit use. Native Linux and MacOS support (their software is written using Qt, so it's pretty easy for them to do.)
One of the "silent revolutions" that has happened over the last 10-20 years is the tremendous drop in cost of programmable logic -- highly integrated microcontrollers, CPLDs, and FPGAs. It's really only in the last few years that FPGAs in particular has come down in price to the point where they're feasible to be used in amateur projects. In many ways these have brought back the freedoms that used to exist back when there were no application-specific integrated circuits (ASICs); today, with an FPGA costing in the ballpark of $20 even a hobbyist can build a fairly sophisticated, custom integrated circuit for a project.
Cellphones are banned for interference reasons by the FCC. Cellphones might also be banned for (perceived) safety reasons by any individual airline (or, for that matter, aircraft captain); cell phones are *NOT* banned by the FAA.
Either that or they're just dancing around the issue...
M-o-n-e-y
Voting machine pushers are rich and politically well-connected (especially, apparently, with Republicans; or perhaps that's just Diebold.)
No, it's not. EM64T, or IA32e (make up your mind, guys) is Intel's clone of AMD64/x86-64.
You're thinking of PAE.
Not really. 802.11a operates in the 5 GHz band, and can thus coexist with 802.11b without suffering degradation, unlike 802.11g which does degrade when .11b devices are present -- if nothing else because the .11b devices hog the channel for 5 times as long.
Thus, heavy-use WLANs like corporate installations are frequently A+G, and a lot of current wlan client chips are also A+G.
In the current wlan market, 802.11a is the premium solution; unfortunately both in terms of cost and performance.