Britain's JANET network has a highly extensive network of web caches. The theory being that one of the biggest loads on the transatlantic link is web traffic, and that the same site is often accessed repeatedly (eg: for University coursework), so that the most efficient solution is to cache everything.
Not any more it doesn't... webcache.ja.net passed away Dec 2002.
I doubt this could happen *easily* (but it's certainly possible). The brake pedal in any car on the roads in the UK is mandated by law to have a direct physical (either hydraulic or pneumatic) connection to the brake system.
Likewise, the clutch on all cars I've seen is a physical connection (i.e. there's no electronics involved in making it work).
You need to read up on the way memory usage gets reported. All those pixmaps that are being displayed on your screen are reported in the memory usage for *each* application that is using them. Same for shared libraries, same for any shared memory that might be being used.
A good example is XMMS. When you run it, it appears to have a number of processes each using a substantial chunk of memory, but the memory is shared between all the processes, and so total memory usage for XMMS is only just over that of one of the processes.
The patents listed on Microsoft's licensing page ( #5,579,517, #5,745,902, #5,758,352, #6,286,013) all seem to relate to the alterations MS made to FAT to support long file names and interoperability between long and short file names.
As I understand it, all the digital cameras that I have seen do not use long file names at all. They present their file names as DSCF0001.JPG etc.
What I don't understand about SCO's excuse of not releasing their source is that if parts of Linux are copies of the SYSV code which contains a trade secret... how can it be considered a "secret" any more? What do SCO gain by not saying what is it? According to them, the source is already out under public scrutiny (presumably doing "damage" as far as SCO are concerned).
I'm convinced they're just trying to piss IBM off enough to buy them out and then ride home with the cash. If they win, SCO's shareholders get lots of cash, if they lose, SCO is most likely to go bust and the shareholders only lose the value of their shares.
This article doesn't mention it, but a few other sites reckon that The Simpsons is to become the longest running sit-com in the world from 2005. Sadly, that crown is held by the BBC's "Last Of The Summer Wine" (1973-2003 still being filmed, 225 episodes). Although, I doubt LOTSW would ever have much political material in it!
Don't joke, I once propped up a Sun Fire F15K with a piece of 2x4 to stop it falling through the raised floor at the lab I used to work in because the floor couldn't cope with the weight!
is for when you have three symbols on the keycap. For example, on my UK keyboard, there is the "4" key, with "4", "$" and (the euro symbol) - Euro is accessed using Alt-GR,4.
Under GNOME, Alt-GR can be used for inputting characters with accents. for example Alt-GR and ' followed by e produces e. Don't know about anything other environments, it might work there too.
The license used to enable them to do this modification isn't the Shared Source License, it's the Microsoft Academic Source License. It's completely different.
Still, This kind of information is going to be in the order of bytes. If the are considering taking frequencies up to "mobile phone frequencies" this indicates around 900MHz+ and I just don't see what kind of applications for RFID need data transfer rates that high.
The article mentions a push for higher data rates...
"The new specifications call for R.F.I.D. systems to operate at an ultrahigh frequency, similar to that used by many cellphones.
"The higher frequency standard would be able to handle much more data."
but... I don't really understand what data needs to be put on these tags. Surely if you have a unique ID for each item, this can be referenced to a DB and then linked back to data there? Can anyone think of a good reason to have (relatively) large amounts of data on the tag itself?
Ahem, I hate to point it out, but the debian stable release of the ssh package isn't even vulnerable. What's wrong with backporting fixes? It seems to be good enough of for Apple and Sun.
If your machine BSOD'd because of a memory error, then either you don't have ECC memory, or you had a multibit error. ECC can only fix single bit memory errors, although it can *detect* multi-bit errors. Parity ram can't reliably detect multi bit errors, and it can never fix errors.
Now, when will we see mirrored ECC memory on PC's? For a while Sun used to use Mirrored E-cache on the UltraSparc II cpus (don't know if new USIIs do this) because of problems with E$ parity errors on USII's. Basically the way it worked is to have mirrored E$ with parity. When one mirror fails its parity check, use and refresh it from the other mirror. Expensive way to fix the manufacturing problem, but it worked.
Slashdot Mirror
Not any more it doesn't... webcache.ja.net passed away Dec 2002.
Hey Ste,
I doubt this could happen *easily* (but it's certainly possible). The brake pedal in any car on the roads in the UK is mandated by law to have a direct physical (either hydraulic or pneumatic) connection to the brake system.
Likewise, the clutch on all cars I've seen is a physical connection (i.e. there's no electronics involved in making it work).
You need to read up on the way memory usage gets reported. All those pixmaps that are being displayed on your screen are reported in the memory usage for *each* application that is using them. Same for shared libraries, same for any shared memory that might be being used.
A good example is XMMS. When you run it, it appears to have a number of processes each using a substantial chunk of memory, but the memory is shared between all the processes, and so total memory usage for XMMS is only just over that of one of the processes.
The patents listed on Microsoft's licensing page ( #5,579,517, #5,745,902, #5,758,352, #6,286,013) all seem to relate to the alterations MS made to FAT to support long file names and interoperability between long and short file names.
As I understand it, all the digital cameras that I have seen do not use long file names at all. They present their file names as DSCF0001.JPG etc.
Actually, the speed record for the TGV is 515.3km/h. They routinely operate at speeds in excess of 400km/h.
What we all want to know is, when do we get to see 106 CPU Opteron systems!? Tiny little 8 cpu systems just don't cut it any more!
What I don't understand about SCO's excuse of not releasing their source is that if parts of Linux are copies of the SYSV code which contains a trade secret... how can it be considered a "secret" any more? What do SCO gain by not saying what is it? According to them, the source is already out under public scrutiny (presumably doing "damage" as far as SCO are concerned).
I'm convinced they're just trying to piss IBM off enough to buy them out and then ride home with the cash. If they win, SCO's shareholders get lots of cash, if they lose, SCO is most likely to go bust and the shareholders only lose the value of their shares.
This article doesn't mention it, but a few other sites reckon that The Simpsons is to become the longest running sit-com in the world from 2005. Sadly, that crown is held by the BBC's "Last Of The Summer Wine" (1973-2003 still being filmed, 225 episodes). Although, I doubt LOTSW would ever have much political material in it!
Don't joke, I once propped up a Sun Fire F15K with a piece of 2x4 to stop it falling through the raised floor at the lab I used to work in because the floor couldn't cope with the weight!
Tell that to the french government (who own a large chunk of Renault).
I don't think it's a "conflict of interest" though.
Get on your segway HT and flatten them pedestrians slow-coaches!
In their press release about their "survey"... they provide a comment from a user about how 404's are a pain.
Agreed, 404's are a pain... but the site finder service did absolutely nothing to prevent them or to help the user when they happened.
I agree... this is a configuration error, not a "bug" in BIND.
BIND is doing whatever it has been configured to do.
looks like my symbols got killed! the e should have a little ^ on it :)
is for when you have three symbols on the keycap. For example, on my UK keyboard, there is the "4" key, with "4", "$" and (the euro symbol) - Euro is accessed using Alt-GR,4.
Under GNOME, Alt-GR can be used for inputting characters with accents. for example Alt-GR and ' followed by e produces e. Don't know about anything other environments, it might work there too.
The license used to enable them to do this modification isn't the Shared Source License, it's the Microsoft Academic Source License. It's completely different.
Still, This kind of information is going to be in the order of bytes. If the are considering taking frequencies up to "mobile phone frequencies" this indicates around 900MHz+ and I just don't see what kind of applications for RFID need data transfer rates that high.
The article mentions a push for higher data rates...
"The new specifications call for R.F.I.D. systems to operate at an ultrahigh frequency, similar to that used by many cellphones.
"The higher frequency standard would be able to handle much more data."
but... I don't really understand what data needs to be put on these tags. Surely if you have a unique ID for each item, this can be referenced to a DB and then linked back to data there? Can anyone think of a good reason to have (relatively) large amounts of data on the tag itself?
Duh, Pico-ATX, Femto-ATX, Atto-ATX, Zepto-ATX and Yocto-ATX
With Nano-ATX being 70% the size of Mini ATX, does that mean...
Pico ATX will be 8.4cm,
Femto ATX will be 5.9cm,
Atto ATX will be 4.1cm,
Zepto ATX will be 2.9cm
and Yocto ATX will be a tiny 2.0cm!
Ahem, I hate to point it out, but the debian stable release of the ssh package isn't even vulnerable. What's wrong with backporting fixes? It seems to be good enough of for Apple and Sun.
If your machine BSOD'd because of a memory error, then either you don't have ECC memory, or you had a multibit error. ECC can only fix single bit memory errors, although it can *detect* multi-bit errors. Parity ram can't reliably detect multi bit errors, and it can never fix errors.
Now, when will we see mirrored ECC memory on PC's? For a while Sun used to use Mirrored E-cache on the UltraSparc II cpus (don't know if new USIIs do this) because of problems with E$ parity errors on USII's. Basically the way it worked is to have mirrored E$ with parity. When one mirror fails its parity check, use and refresh it from the other mirror. Expensive way to fix the manufacturing problem, but it worked.
GCC Segfaulted? Can you say "that's most-likely a GCC or hardware problem"?
Erm, didn't AOL just get rid of the Mozilla developers?
And generally killing it doesn't work either, because most gnome configs have nautilus set to respawn! :)