Outlawing unsecured WiFi is not being attempted, as you suggest, because people are using unsecured WiFi to generate plausible deniability.
The primary reasons corporations are atempting to get it outlawed are that outlawing them ensures each apartment in a complex pays for a link, rather than some subset, and because it competes with the business models which attempt to sell "hot spot" access, either as a marketing technique (e.g. Starbucks), or as a direct seller of the access itself (i.e. you can't sell what someone else is giving away for free).
It has nothing to do with RIAA and everything to do with increasing revenue without addign additional real value.
Disk Image: not a ".dmg", but a bit-for-bit copy of the raw disk into a file that is then treated as a raw disk.
Note that I don't condone piracy, but you should probably be more aware of the capabilities of your OS, as delivered by it's manufacturer, to do legal and legitimate operations on raw devices and files.
Since you are a Mac person, to get at the raw device or associate a raw device with a file without opening it, you are actually looking for "hdiutil -nomount" and "hdiutil -create -srcdevice".
In FreeBSD, you'd be looking for "mdconfig".
In Windows, Linux, Solaris, and so on, there are other ways of making the OS treat a file on one FS as a raw device; a little digging in the documentation on any given OS should enable you to find what you're looking for.
-- Terry
DVD encryption is about old bandwidth assumptions
on
RIAA vs Linux and DVDs
·
· Score: 3, Insightful
DVD encryption is about old bandwidth assumptions.
You can rip DVD's without breaking the encryption; the only thing ripping them does is rduce the overall payload size.
It's perfectly functional to image copy a DVD to another DVD (which is what the pirates do, when they are not simply shutting down the legal assembly line production at 6 PM, and running off another 20,000 copies between 8 PM and 12 AM from the legal masters).
It's also perfectly functional to make something that looks to the system like a DVD drive driver, but actually operates from a disk image instead of real DVD hardware, so you can take the image copies of a DVD and feed them into your completely legal commercial DVD player software.
The *ONLY* thing that DVD encryption does is:
(1) make it hard to decide which bits you need to move from machine A to machine B so you can watch the whole movie, and
(2) defeats compression of the cleartext DVD contents (which is minimal, since it's already a compressed format), and
(3) prevents transcoding to an alternate lossy format to reduce the transfer size (which is *supposedly* something the MPAA et. al. don't care about anyway, as they are apparently not concerned with digital-analog-digital copying, which the DVD encryption can't prevent in the first place)
In other words, it's about keeping the bandwidth required to move DVD content from point A to point B as high as possible to adjust the economics of digital copying to artifically inflate the costs relative to the benefits.
And guess what? These bandwidth assumptions are no longer valid.
If you are willing to take the approach of the pseudo-DVD device driver, you don't need DeCSS, and that converts everything from a DMCA violation to a simple copyright violation.
Just install a local cell phone cell @ $9.00/min.; it'd be a microcell, so it would effectively be premises-only; anyone loiters around and uses their cell phone, you're talking $$$. Hell, you can sit on my front porch, if you're willing to pay me $9.00/min. for the privilege... I'll even let you borrow a cane and yell "get out of my yard!" at all your friends.
I've considered suggesting this to various movie theaters as well - would you have your phone on in a movie if every time it rang or you got a text message, it cost you $9.00?
Another option is a ring generator - just make any phone that roams into the micro-cell ring periodically. Works for movie theaters (maybe ring them on the way in the door, or three times during the previews, etc.); also works for drugstores where kids with cell phones loiter, etc.: no signal = no loiter.
Read the linked articles; in the last one it says:
"The proposed design of the machines calls for a 500MHz processor, 1GB of memory and an innovative dual-mode display that can be used in full-color mode, or in a black-and-white sunlight-readable mode."
There are plenty of other articles out there. In May, they were spec'ing it at 256M (not the 128M being claimed in this thread - that was last December), and in July this went up to 512M; now it's 1G. If you can read Kanji, there's several sites that actually have more information on the current specifications that they are looking at using.
This is to be expected if the main storage is flash memory - due to the limited (though larger than in the past) number of write cycles, they are not going to be able to swap to their main storage, so everything will need to fit in memory - hence the need for more memory.
If they dropped X11 and went direct to the video card instead, they could thin things down more; I actually expect that they will in fact do this, since most of the office packages under Linux these days are absurd memory hogs, and with X11 overhead on both ends on top of that, plus a window manager separate from the display server, they are going to be looking at exhausting their memory budget very quickly, even with as much as 1G of RAM.
These boxes are Flash + USB + keyboard + display + WiFi/Cell + 1G of RAM. No CD/DVD drive, not floppy drive, no removable storage interface at all, apart from the USB.
The way you'll have to go about the initial OS load is to either put it on the flash parts using another process, or sucking it in using boot-from-USB (the networking won't work until you have the software for it).
In other words, they're just not going to have the equipment available to (re)image the flash in the things in the field, unless someone happens to have more complete equipment than just the laptops themselves.
So the OS choice is all or nothing (personally, I'd say they'd be better off with OS X, and not just because I'm a kernel engineer for Apple), and you will need to pretty much pick one and stick with whatever's pre-loaded.
If they are smart, they can maybe make them self-heal in the field using another laptop, but it doesn't look like that's the plan. The alternative is probably to write-protect the area of the flash containing the OS bits to keep them from getting stomped - basically, two partittions, with the base OS partition being mounted read-only. Any other approach means that it becomes a doorstop, and it's unrecoverable without someone with a big machine or a USB dongle that can cause the system to be reloaded.
OS X does make more sense for these things in general, just because it's better UI, but I can respect their decision.
Even so, it'll be really rare (perhaps impossible) for the end user to tinker with the OS kernel itself, even going with full Open Source like Linux; it's highly unlikely there will be enough storage in the flash to hold the entire OS source code anyway, so you'd (again) need compute resources that you're not making available for people to download and build their own kernel, and (re)image one of the flash parts with a newer version of Linux.
Practically, this means the Open Source nature of things isn't really going to buy the end users anything, unless they have sufficient resources that they likely didn't need the laptop in the first place (or didn't qualify for it).
Not that "tinkerable" - I expect that the source code for everything won't come loaded on the machine.
According to several recent articles, the machine has a bunch of USB ports, Wireless mesh-topology networking, 1G of RAM and no hard disk; the storage will all be flash.
"Hello, welcome to Mutual of Omaha's Wild Kingdom!"...
"Jim Fowler will be attaching these harmless radio collars to the employees before they are released. This will allow us to track them as they find new homes in the wild. Hopefully this information can be used by scientists to ensure a healthy and growing employee population."
"If your family is healthy and growing, you should consider purchasing insurance from Mutual of Omaha to help with all of life's little mishaps."
-- Marlin Perkins
-- Terry
Picking a nit about "LATA" definition and trunking
on
Ma Bell is Back
·
· Score: 1
Picking a nit about "LATA" definition and trunking
Sorry... but LATA stands for "local access and transport area"; inter-LATA describes an interconnect between transport areas, which is not the same thing as being a different area code.
Many states had one area code, but many LATAs for a long time; for example, Utah had area code 801 for the entire state, but many switching centers, and there were what AT&T (later, Mountain Bell) called "Regional Calling areas", which effectively meant "beyond the locally dense switching center interconnect", or in layman's terms, "not very many trunk lines between these two sets of switches".
State like California, which had multiple area codes early on, did so because they had the poulation density requiring it: more than 10,000,000 people (effectively a lot less than that, since the switching centers were sparsely committed).
The proliferation of area codes since the bell breakup has *not* been a result of having more LATAs, it's been because, until very recently, by FCC mandate, trunking could only be done for 10,000 phone numbers at a time, and the proliferation of small phone companies with only 100 or 200 total customers meant that each of them burned at least one area code + prefix pair, and when you ran out of prefixes, you needed a new area code (sort of like the IPv4 class A,B,C,D network address space problem, when netmasks could only be specified on a tuple boundary). Today in the US, to connect to the public network, switches are required to support trunking on a per-phone number basis (hence "phone number portability", and we could probably undo the area code debacle, but of course, now it's too late).
Correct prediction keeps your instruction pipeline full. This is particularly important for code with long pipelines.
Incorrect prediction results in having to back out CPU state from the speculative execution that has already taken place (this is called "squashing" the mispredicted instructions), and effectively this loses the pipeline slots that were used to perform the mispredicted execution. From an outside perspective, these lost slots look like a pipeline latency.
(insert rude comment about GCC #pragma branch hinting and [lack of] basic block reordering to avoid cache busting on PPC here)
Everything you will need for 12 days, plus everything you will be bringing on top of that to help out. This includes food, water, shelter, fuel, a spare tire for the U-Haul, etc..
The very worst thing you could do would be to arrive there and become part of the problem instead of part of the solution.
It might also help if you got an invitation from officialdom, with some idea of where they think they need to put resources first, so that you maximize your value, and have written official sanction to even be in the area you can show to the guards at the blockades.
-- Terry
For optical media, it's very easy...
on
The Digital Dark Age
·
· Score: 2, Interesting
For optical media, it's very easy... assuming the media actually survives, it's the same way this guy plays vynil LP's using a flatbed scanner:
Obviously, in the future, ultra-high resolution optical input will put the current scanning/video technology to shame; they will just need to scan the thing in and run a program against the data to get the contents of the media back.
Plainer English: MySQL is broken.
on
BSD Usage Survey
·
· Score: 1
Plainer English: MySQL is broken.
Linux could score about 20-30% better on these benchmarks by fixing MySQL.
FreeBSD et. al. would tend to score about 50%+ better if these same fixes were made to MySQL.
I don't know how comparable the performance would be, but a simple test with a cache in the client library (one of the fixes MySQL needs) show about a 20% performance improvement for a BSD-based system.
Maybe you don't care about MySQL performance being better overall, but the MySQL people should.
Well, I'm not the original poster, but I'll take a shot at discrediting the current crop of MySQL benchmarks.
What will likely become quickly obvious after DTrace is ported to FreeBSD is that MySQL has a number of architectural issues that lead to poor performance on non-Linux platforms because of certain assumption about the system call overhead, scheduler behaviour, scheduling priority, and two relatively major problems that would actually result in even better Linux performance, if they were resolved. Everyone else would also benefit, although it would likely be proprtionately more benefit on non-Linux platforms.
The primary reasons for this are:
(1) because of LMBench, Linux has always valued low individual system call overhead, sometimes at the expense of other aspects of the system. Because of this, there's a wrong-minded idea in some of the basic design decisions that "system calls are free". Any place they aren't as or more cheap than Linux suffers disproportionately poorer performance.
(2) the Linux thread scheduler does not try to attempt to provide any degree of fairness in thread scheduling in a multithreaded program like MySQL; as a result, you tend to get individual threads running all their tasks to completion at the exclusion of other work, whereas other systems end up with significant context switch overhead as they attempt to provide the fairness that Linux does not. You could easily whack the FreeBSD or DragonFly scheduler over the head with a large "don't context switch while there is still work to do in the queue" mallet and get similar performance, at the cost of really scattered latencies, just like Linux(+)
(3) the priorities that are set via pthread_setschedparam() are incorrectly scaled for most non-Linux systems, and assume that all implementation have the same bounded range of priorities; this tends to actually drop the server threads in favor of the client and other processes on the system (even cron).
(4) the MySQL server associates a single thread with a single client, rather than using a statite and scheduling work from various clients to the worker threads in thread-LIFO order. Yes, the conversion from a per-connection thread to a work-to-do model would be difficult, but arguably well worth the effort, and would significantly lessen the apparent performance advanatage of #2, while at the same time improving Linux performance as well. When we switched to this model in NetWare, it got us about a 25% performance improvement.
(5) the MySQL client library pays a very high system call overhead, which is mitigated somewhat by #1; however even Linux would *greatly* benefit by batching the calls. This would be done by ensuring that the client library performs larger reads, rather than a 4 byte read followed by another message-type specific read, followed by a 4 byte read on the other end, and another message-type specific read on the other end(*)
Overall, MySQL benchmarks are actually pretty useless as a measure of relative system performance, and will remain so, at least until the performance issues inherent in its architecture have been addressed.
(+) At this point, the question "what about mean measured transaction latency and standard deviation?" should be occurring to someone to include in a future MySQL benchmark.
(*) actually, an even more efficient mechanism could be had here, given that client caching on the server side of things won't work because of the per-connection threading model; the model that would work would be a modified "accept filter" approach, to ensure that the client or server connection only received whole request/response messsages that could then be processed to completion, rather than stalling the work pipeline on partial packets in the face of long messages or intermediate fragmentation.
One of the worst products I ever worked on was one that was "designed" by a "designer" who wouldn't have known "third normal form" if it came up and bit her on the ass and said "Hello, I'm third normal form".
It was a web-based UI that was "designed" by someone using Visual BASIC as their design tool, and then we had the "opportunity" to try and build the damn thing in Java in a browser-portable way.
I'd rather walk on broken glass than work with that person again.
The UI we ended up with bore no relationship to the underlying data organization, and was basically all over the map when it came to unrelated items glommed together. Gee, it was pretty, but it was also totally unusable.
I'd have to disagree with you - it *completely* matters for a designer to understand what they are designing for; if they don't, the result is going to suck, and suck hard.
This is not to say it's not a hell of a lot more useful than not being able to do disconnected writes at all, but pre-insertion of write barriers instead of post insertion via scheduling is really a poor-man's version of I/O concurrency.
Unless you go out of your way to do a FUA (Force Unit Access), on SATA, there is no guarantee that write data has been committed to stable storage, rather than just cache.
In SCSI tagged command queueing, you can be guaranteed that the write has been committed to stable storage before the write is acknowledges as completed (yes, it's optional to turn this off in mode page 2, but only idiots do it).
The upshot of this is that the OS must issue FUA on writes and stall the pipeline for other writes that don't require a commitment to stable storage (e.g. FUA for metadata and journalling, no-FUA for other data).
This is (effectively) the difference between DOW (Delayed Ordered Writes) and SU (Soft Updates), which is what makes SU so much more effective than DOW.
Further, it means that the OS can't use the acknowledgement to schedule future operations on the disk, without knowing ahead of time the FUA is necessary for a given write.
The issue here is that if I'm, for example, updating the contents in a single directory entry block on disk in two different processes, instead of deciding to delay the second update until I know the first one has completed (via the acknowledgement), I must issue the first one as an FUA command, and then the second one as an FUA command, which adds latency to my pipeline.
"Mr. SATA, I've worked with Mr. SCSI, and you're no Mr. SCSI".
When movies are made these days, it's almost always the same production team for the movie, the web site, the video game (if the movie isn't being made from an existing game plot line), the action figures, the Happy Meal(tm) boxes, and so on.
Movie production in general is nothing more than one big marketing department. It doesn't give me hope that the content will match up to any standards of rigor when it comes to how accurate the movie ends up being. Particularly when they suggest that you are going to be able to feel what the astronauts who actually went there as part of your "IMax Experience(tm)".
Maybe I'm just being a downer, and if you asked a bunch of random 20-something year olds to "name someone from the Apollo 13 mission", they'd actually say "Lovell" or "Haise" or "Swigert", instead of the majority of them saying "Tom Hanks".
It's going to screw up the facts in people's minds.
This is just like the experiments on observer accuracy, where you first demonstrate an incident on film, and then show still images not actually from the film, with some details changed, and then ask the observers questions about the original film version of events.
So far I am not at all impressed with their production values or fact checking anyway... if you go to the web site, click on "Education", click the button in the top right corner, and go to the first "factoid", you will find this beauty:
"The Astronaut's Spacesuits: The astronaut's spacesuits were designed to withstand the moon's average daylight temperature of 300 degrees Fahrenheit (100 degrees Centigrade)."
Say Google, Microsoft, and Yahoo got together and cut Australia off for one day with a black screen of "Search Unavailable Today; Contact the Australian the Department of Communications, Information Technology and the Arts for more information".
One button does not suffer from right-handed-ness. I think it's as simple as that.
It'd be really easy to design a multibutton mouse that doesn't have the problem of handed-ness, but no one has designed on yet.
This comes down to ease-of-use for people unfamiliar with the machine: are you going to make the learning curve as steep as having to be able to know enough to get to the system configuration options to make the machine usable for the 20% of the world that's left-handed, or aren't you?
Even if you get to the system preferences, all of the documentation would still suffer from handed-ness: "right click the icon" or "left click the icon to get the properties menu".
I think this comes down the the original human factors decisions in the Macintosh, arising from the primary design goal of "the machine for the rest of us".
Also, given the professions which tend to use Macintosh computers are creative professions, and creative professions have more than their share of south-paws, it's pretty obvious that the button bias and documentation bias would be issues.
Slashdot Mirror
Outlawing unsecured WiFi is not being attempted, as you suggest, because people are using unsecured WiFi to generate plausible deniability.
The primary reasons corporations are atempting to get it outlawed are that outlawing them ensures each apartment in a complex pays for a link, rather than some subset, and because it competes with the business models which attempt to sell "hot spot" access, either as a marketing technique (e.g. Starbucks), or as a direct seller of the access itself (i.e. you can't sell what someone else is giving away for free).
It has nothing to do with RIAA and everything to do with increasing revenue without addign additional real value.
-- Terry
Disk Image: not a ".dmg", but a bit-for-bit copy of the raw disk into a file that is then treated as a raw disk.
Note that I don't condone piracy, but you should probably be more aware of the capabilities of your OS, as delivered by it's manufacturer, to do legal and legitimate operations on raw devices and files.
Since you are a Mac person, to get at the raw device or associate a raw device with a file without opening it, you are actually looking for "hdiutil -nomount" and "hdiutil -create -srcdevice".
In FreeBSD, you'd be looking for "mdconfig".
In Windows, Linux, Solaris, and so on, there are other ways of making the OS treat a file on one FS as a raw device; a little digging in the documentation on any given OS should enable you to find what you're looking for.
-- Terry
DVD encryption is about old bandwidth assumptions.
You can rip DVD's without breaking the encryption; the only thing ripping them does is rduce the overall payload size.
It's perfectly functional to image copy a DVD to another DVD (which is what the pirates do, when they are not simply shutting down the legal assembly line production at 6 PM, and running off another 20,000 copies between 8 PM and 12 AM from the legal masters).
It's also perfectly functional to make something that looks to the system like a DVD drive driver, but actually operates from a disk image instead of real DVD hardware, so you can take the image copies of a DVD and feed them into your completely legal commercial DVD player software.
The *ONLY* thing that DVD encryption does is:
(1) make it hard to decide which bits you need to move from machine A to machine B so you can watch the whole movie, and
(2) defeats compression of the cleartext DVD contents (which is minimal, since it's already a compressed format), and
(3) prevents transcoding to an alternate lossy format to reduce the transfer size (which is *supposedly* something the MPAA et. al. don't care about anyway, as they are apparently not concerned with digital-analog-digital copying, which the DVD encryption can't prevent in the first place)
In other words, it's about keeping the bandwidth required to move DVD content from point A to point B as high as possible to adjust the economics of digital copying to artifically inflate the costs relative to the benefits.
And guess what? These bandwidth assumptions are no longer valid.
If you are willing to take the approach of the pseudo-DVD device driver, you don't need DeCSS, and that converts everything from a DMCA violation to a simple copyright violation.
-- Terry
Just install a local cell phone cell @ $9.00/min.; it'd be a microcell, so it would effectively be premises-only; anyone loiters around and uses their cell phone, you're talking $$$. Hell, you can sit on my front porch, if you're willing to pay me $9.00/min. for the privilege... I'll even let you borrow a cane and yell "get out of my yard!" at all your friends.
I've considered suggesting this to various movie theaters as well - would you have your phone on in a movie if every time it rang or you got a text message, it cost you $9.00?
Another option is a ring generator - just make any phone that roams into the micro-cell ring periodically. Works for movie theaters (maybe ring them on the way in the door, or three times during the previews, etc.); also works for drugstores where kids with cell phones loiter, etc.: no signal = no loiter.
-- Terry
Ornette Coleman - Present and accounted for
I don't know which store you're looking at, but the ITMS has a ton of Ornette Coleman (21 albums) & Rasahn Roland Kirk (10 albums).
-- Terry
Read the linked articles; in the last one it says:
"The proposed design of the machines calls for a 500MHz processor, 1GB of memory and an innovative dual-mode display that can be used in full-color mode, or in a black-and-white sunlight-readable mode."
There are plenty of other articles out there. In May, they were spec'ing it at 256M (not the 128M being claimed in this thread - that was last December), and in July this went up to 512M; now it's 1G. If you can read Kanji, there's several sites that actually have more information on the current specifications that they are looking at using.
This is to be expected if the main storage is flash memory - due to the limited (though larger than in the past) number of write cycles, they are not going to be able to swap to their main storage, so everything will need to fit in memory - hence the need for more memory.
If they dropped X11 and went direct to the video card instead, they could thin things down more; I actually expect that they will in fact do this, since most of the office packages under Linux these days are absurd memory hogs, and with X11 overhead on both ends on top of that, plus a window manager separate from the display server, they are going to be looking at exhausting their memory budget very quickly, even with as much as 1G of RAM.
-- Terry
Actually, it'll be very hard to load another OS.
These boxes are Flash + USB + keyboard + display + WiFi/Cell + 1G of RAM. No CD/DVD drive, not floppy drive, no removable storage interface at all, apart from the USB.
The way you'll have to go about the initial OS load is to either put it on the flash parts using another process, or sucking it in using boot-from-USB (the networking won't work until you have the software for it).
In other words, they're just not going to have the equipment available to (re)image the flash in the things in the field, unless someone happens to have more complete equipment than just the laptops themselves.
So the OS choice is all or nothing (personally, I'd say they'd be better off with OS X, and not just because I'm a kernel engineer for Apple), and you will need to pretty much pick one and stick with whatever's pre-loaded.
If they are smart, they can maybe make them self-heal in the field using another laptop, but it doesn't look like that's the plan. The alternative is probably to write-protect the area of the flash containing the OS bits to keep them from getting stomped - basically, two partittions, with the base OS partition being mounted read-only. Any other approach means that it becomes a doorstop, and it's unrecoverable without someone with a big machine or a USB dongle that can cause the system to be reloaded.
OS X does make more sense for these things in general, just because it's better UI, but I can respect their decision.
Even so, it'll be really rare (perhaps impossible) for the end user to tinker with the OS kernel itself, even going with full Open Source like Linux; it's highly unlikely there will be enough storage in the flash to hold the entire OS source code anyway, so you'd (again) need compute resources that you're not making available for people to download and build their own kernel, and (re)image one of the flash parts with a newer version of Linux.
Practically, this means the Open Source nature of things isn't really going to buy the end users anything, unless they have sufficient resources that they likely didn't need the laptop in the first place (or didn't qualify for it).
-- Terry
Not that "tinkerable" - I expect that the source code for everything won't come loaded on the machine.
v ing-5/113030655622200.xml
According to several recent articles, the machine has a bunch of USB ports, Wireless mesh-topology networking, 1G of RAM and no hard disk; the storage will all be flash.
See also:
http://laptop.media.mit.edu/faq.html
http://www.nola.com/living/t-p/index.ssf?/base/li
-- Terry
You need to install the Java 2 SE 5.0 release 1
s e50release1.html ...and then select it as your default Java.
http://www.apple.com/downloads/macosx/apple/java2
-- Terry
The machine is 500MHz, has no disk, a 1 megapixel dual mode display, and 1G of RAM (*not* 128M, as you claim here).
o +reality/2100-1044_3-5884683.html
Specifications were gathered from these sources:
http://laptop.media.mit.edu/faq.html
http://www.engadget.com/entry/1234000120060924/
http://www.worldchanging.com/archives/003707.html
http://news.com.com/The+100+laptop+moves+closer+t
-- Terry
"Hello, welcome to Mutual of Omaha's Wild Kingdom!" ...
"Jim Fowler will be attaching these harmless radio collars to the employees before they are released. This will allow us to track them as they find new homes in the wild. Hopefully this information can be used by scientists to ensure a healthy and growing employee population."
"If your family is healthy and growing, you should consider purchasing insurance from Mutual of Omaha to help with all of life's little mishaps."
-- Marlin Perkins
-- Terry
Picking a nit about "LATA" definition and trunking
Sorry... but LATA stands for "local access and transport area"; inter-LATA describes an interconnect between transport areas, which is not the same thing as being a different area code.
Many states had one area code, but many LATAs for a long time; for example, Utah had area code 801 for the entire state, but many switching centers, and there were what AT&T (later, Mountain Bell) called "Regional Calling areas", which effectively meant "beyond the locally dense switching center interconnect", or in layman's terms, "not very many trunk lines between these two sets of switches".
State like California, which had multiple area codes early on, did so because they had the poulation density requiring it: more than 10,000,000 people (effectively a lot less than that, since the switching centers were sparsely committed).
The proliferation of area codes since the bell breakup has *not* been a result of having more LATAs, it's been because, until very recently, by FCC mandate, trunking could only be done for 10,000 phone numbers at a time, and the proliferation of small phone companies with only 100 or 200 total customers meant that each of them burned at least one area code + prefix pair, and when you ran out of prefixes, you needed a new area code (sort of like the IPv4 class A,B,C,D network address space problem, when netmasks could only be specified on a tuple boundary). Today in the US, to connect to the public network, switches are required to support trunking on a per-phone number basis (hence "phone number portability", and we could probably undo the area code debacle, but of course, now it's too late).
-- Terry
The Flying Spaghetti Monster http://www.venganza.org/, Of Course!
-- Terry
Correct prediction keeps your instruction pipeline full. This is particularly important for code with long pipelines.
Incorrect prediction results in having to back out CPU state from the speculative execution that has already taken place (this is called "squashing" the mispredicted instructions), and effectively this loses the pipeline slots that were used to perform the mispredicted execution. From an outside perspective, these lost slots look like a pipeline latency.
(insert rude comment about GCC #pragma branch hinting and [lack of] basic block reordering to avoid cache busting on PPC here)
-- Terry
Everything you will need for 12 days, plus everything you will be bringing on top of that to help out. This includes food, water, shelter, fuel, a spare tire for the U-Haul, etc..
The very worst thing you could do would be to arrive there and become part of the problem instead of part of the solution.
It might also help if you got an invitation from officialdom, with some idea of where they think they need to put resources first, so that you maximize your value, and have written official sanction to even be in the area you can show to the guards at the blockades.
-- Terry
For optical media, it's very easy... assuming the media actually survives, it's the same way this guy plays vynil LP's using a flatbed scanner:
7 769,00.html
http://wired-vig.wired.com/news/digiwood/0,1412,5
Obviously, in the future, ultra-high resolution optical input will put the current scanning/video technology to shame; they will just need to scan the thing in and run a program against the data to get the contents of the media back.
Plainer English: MySQL is broken.
Linux could score about 20-30% better on these benchmarks by fixing MySQL.
FreeBSD et. al. would tend to score about 50%+ better if these same fixes were made to MySQL.
I don't know how comparable the performance would be, but a simple test with a cache in the client library (one of the fixes MySQL needs) show about a 20% performance improvement for a BSD-based system.
Maybe you don't care about MySQL performance being better overall, but the MySQL people should.
-- Terry
Well, I'm not the original poster, but I'll take a shot at discrediting the current crop of MySQL benchmarks.
What will likely become quickly obvious after DTrace is ported to FreeBSD is that MySQL has a number of architectural issues that lead to poor performance on non-Linux platforms because of certain assumption about the system call overhead, scheduler behaviour, scheduling priority, and two relatively major problems that would actually result in even better Linux performance, if they were resolved. Everyone else would also benefit, although it would likely be proprtionately more benefit on non-Linux platforms.
The primary reasons for this are:
(1) because of LMBench, Linux has always valued low individual system call overhead, sometimes at the expense of other aspects of the system. Because of this, there's a wrong-minded idea in some of the basic design decisions that "system calls are free". Any place they aren't as or more cheap than Linux suffers disproportionately poorer performance.
(2) the Linux thread scheduler does not try to attempt to provide any degree of fairness in thread scheduling in a multithreaded program like MySQL; as a result, you tend to get individual threads running all their tasks to completion at the exclusion of other work, whereas other systems end up with significant context switch overhead as they attempt to provide the fairness that Linux does not. You could easily whack the FreeBSD or DragonFly scheduler over the head with a large "don't context switch while there is still work to do in the queue" mallet and get similar performance, at the cost of really scattered latencies, just like Linux(+)
(3) the priorities that are set via pthread_setschedparam() are incorrectly scaled for most non-Linux systems, and assume that all implementation have the same bounded range of priorities; this tends to actually drop the server threads in favor of the client and other processes on the system (even cron).
(4) the MySQL server associates a single thread with a single client, rather than using a statite and scheduling work from various clients to the worker threads in thread-LIFO order. Yes, the conversion from a per-connection thread to a work-to-do model would be difficult, but arguably well worth the effort, and would significantly lessen the apparent performance advanatage of #2, while at the same time improving Linux performance as well. When we switched to this model in NetWare, it got us about a 25% performance improvement.
(5) the MySQL client library pays a very high system call overhead, which is mitigated somewhat by #1; however even Linux would *greatly* benefit by batching the calls. This would be done by ensuring that the client library performs larger reads, rather than a 4 byte read followed by another message-type specific read, followed by a 4 byte read on the other end, and another message-type specific read on the other end(*)
Overall, MySQL benchmarks are actually pretty useless as a measure of relative system performance, and will remain so, at least until the performance issues inherent in its architecture have been addressed.
(+) At this point, the question "what about mean measured transaction latency and standard deviation?" should be occurring to someone to include in a future MySQL benchmark.
(*) actually, an even more efficient mechanism could be had here, given that client caching on the server side of things won't work because of the per-connection threading model; the model that would work would be a modified "accept filter" approach, to ensure that the client or server connection only received whole request/response messsages that could then be processed to completion, rather than stalling the work pipeline on partial packets in the face of long messages or intermediate fragmentation.
-- Terry
One of the worst products I ever worked on was one that was "designed" by a "designer" who wouldn't have known "third normal form" if it came up and bit her on the ass and said "Hello, I'm third normal form".
It was a web-based UI that was "designed" by someone using Visual BASIC as their design tool, and then we had the "opportunity" to try and build the damn thing in Java in a browser-portable way.
I'd rather walk on broken glass than work with that person again.
The UI we ended up with bore no relationship to the underlying data organization, and was basically all over the map when it came to unrelated items glommed together. Gee, it was pretty, but it was also totally unusable.
I'd have to disagree with you - it *completely* matters for a designer to understand what they are designing for; if they don't, the result is going to suck, and suck hard.
-- Terry
SATA NCQ does *NOT* give SCSI performance.
This is not to say it's not a hell of a lot more useful than not being able to do disconnected writes at all, but pre-insertion of write barriers instead of post insertion via scheduling is really a poor-man's version of I/O concurrency.
Unless you go out of your way to do a FUA (Force Unit Access), on SATA, there is no guarantee that write data has been committed to stable storage, rather than just cache.
In SCSI tagged command queueing, you can be guaranteed that the write has been committed to stable storage before the write is acknowledges as completed (yes, it's optional to turn this off in mode page 2, but only idiots do it).
The upshot of this is that the OS must issue FUA on writes and stall the pipeline for other writes that don't require a commitment to stable storage (e.g. FUA for metadata and journalling, no-FUA for other data).
This is (effectively) the difference between DOW (Delayed Ordered Writes) and SU (Soft Updates), which is what makes SU so much more effective than DOW.
Further, it means that the OS can't use the acknowledgement to schedule future operations on the disk, without knowing ahead of time the FUA is necessary for a given write.
The issue here is that if I'm, for example, updating the contents in a single directory entry block on disk in two different processes, instead of deciding to delay the second update until I know the first one has completed (via the acknowledgement), I must issue the first one as an FUA command, and then the second one as an FUA command, which adds latency to my pipeline.
"Mr. SATA, I've worked with Mr. SCSI, and you're no Mr. SCSI".
-- Terry
It's likely the same production team.
When movies are made these days, it's almost always the same production team for the movie, the web site, the video game (if the movie isn't being made from an existing game plot line), the action figures, the Happy Meal(tm) boxes, and so on.
Movie production in general is nothing more than one big marketing department. It doesn't give me hope that the content will match up to any standards of rigor when it comes to how accurate the movie ends up being. Particularly when they suggest that you are going to be able to feel what the astronauts who actually went there as part of your "IMax Experience(tm)".
Maybe I'm just being a downer, and if you asked a bunch of random 20-something year olds to "name someone from the Apollo 13 mission", they'd actually say "Lovell" or "Haise" or "Swigert", instead of the majority of them saying "Tom Hanks".
But I doubt it. 8-(.
-- Terry
It's going to screw up the facts in people's minds.
a ges/image_pop_r2c2-2.jpg )
This is just like the experiments on observer accuracy, where you first demonstrate an incident on film, and then show still images not actually from the film, with some details changed, and then ask the observers questions about the original film version of events.
So far I am not at all impressed with their production values or fact checking anyway... if you go to the web site, click on "Education", click the button in the top right corner, and go to the first "factoid", you will find this beauty:
"The Astronaut's Spacesuits: The astronaut's spacesuits were designed to withstand the moon's average daylight temperature of 300 degrees Fahrenheit (100 degrees Centigrade)."
(direct link here: http://www.imax.com/magnificentdesolation/pops/im
If they can't even do a temperature conversion, they are unlikely to produce anything more than inaccurate eye candy for "the masses".
-- Terry
Anyone else sick of this stuff?
Say Google, Microsoft, and Yahoo got together and cut Australia off for one day with a black screen of "Search Unavailable Today; Contact the Australian the Department of Communications, Information Technology and the Arts for more information".
-- Terry
One button does not suffer from right-handed-ness. I think it's as simple as that.
It'd be really easy to design a multibutton mouse that doesn't have the problem of handed-ness, but no one has designed on yet.
This comes down to ease-of-use for people unfamiliar with the machine: are you going to make the learning curve as steep as having to be able to know enough to get to the system configuration options to make the machine usable for the 20% of the world that's left-handed, or aren't you?
Even if you get to the system preferences, all of the documentation would still suffer from handed-ness: "right click the icon" or "left click the icon to get the properties menu".
I think this comes down the the original human factors decisions in the Macintosh, arising from the primary design goal of "the machine for the rest of us".
Also, given the professions which tend to use Macintosh computers are creative professions, and creative professions have more than their share of south-paws, it's pretty obvious that the button bias and documentation bias would be issues.
-- Terry
That's because the left side is a USGS satellite image, and the right side is a color aeriel photo, instead of a satellite.
-- Terry