The next step would probably be hard drives that run in a hard vacuum. Current drives "fly" the head over the surface on an air cushion. A vacuum drive would have to actively measure and servo head height, which is quite feasible. Running in vacuum, drive speeds would no longer be limited by air friction and noise. Ultracentrifuges routinely reach speeds of 100,000 RPM.
But such machinery would require developing a whole new technology, cost far more than a flash drive and wouldn't fit in anything like a PC drive form factor.
My online applications log to a database, not a text file. Multiple applications on different machines can log to the same database table. There's no need for "log rotation"; old entries can be summarized and purged by date on the live database. With appropriate indexed fields, you can find key log entries in huge log files very rapidly.
Even program faults are logged to the database. If the program crashes, the top-level exception handler catches the event, does a traceback, opens a fresh database connection, and logs the traceback.
The MTA is trying to cover up the fact that their system design is very weak. The value of the card is actually stored on the card, and there's no central validation. That's embarrassing, considering that the MTA implemented fare cards quite late, long after other cities.
The NYC MetroCard system, in comparison, is totally paranoid. Cards have unique serial numbers and are validated by the entry gate, the station computer, and central servers at MetroCard HQ. Creating new cards with new IDs won't work. Duplicating cards is possible, but is detected the second time the card is used. NYC is so paranoid that equipment maintenance is performed by an outside company, but NYC employees handle the money and blank cards, so that no single party has full access. The New York City subway system was losing about $20 million a year to token fraud, and when the new system went in, they were determined that would stop. They had some fraud back in 1995, when someone stole a supply of blank cards and was able to encode them, but it turned out to be a rip-off for buyers - the cards only worked once, then were invalidated.
The first fare card system, San Francisco's BART, isn't that secure, but has an big advantage - BART has exit gates. So, while it doesn't have real-time validation against a central database, gate info is being transmitted in background to a central system, and if centralized analysis indicates something funny going on, central control can flag the card, trap the user at the exit gate, and alert station security to check the card.
I'm not seeing any significant decline in spam. Here are my spam log statistics, which combine mail received by
about ten e-mail addresses at five domains:
Graymail for Aug 15, 543 new messages for animats.
Graymail for Aug 14, 631 new messages for animats.
Graymail for Aug 13, 645 new messages for animats.
Graymail for Aug 12, 566 new messages for animats.
Graymail for Aug 11, 469 new messages for animats.
Graymail for Aug 10, 465 new messages for animats.
The "tying product" in this case would be Macintosh computers. Since Psystar doesn't intend to sell Macintosh computers, and Apple doesn't refuse to sell Macintosh computers to them, I really cannot see how this is related to this case.
From Findlaw: "Sellers with more than one product may seek to tie the sale of one (which the customer presumably desires) with that of another (which it presumably does not want). Such tie-ins are governed not only by the general language of the Sherman Act, but the more particular provisions of Section 3 of the Clayton Act, which prohibits such arrangements if the likely result is substantially to lessen competition. Tie-ins are per se unlawful if the seller possesses sufficient market power in the tying product, and coerces the buyer to take the tied product as a condition to obtaining the desired product."
"Sufficient market power in the tying product" means exactly that. It's market power in the specific product, not market power generally, that matters. If a manufacturer has a unique product, they inherently have market power in that product.
Actually, SQLite is in cell phones and PDAs. It's a modest-sized shared library. And, unlike text files, there's indexing. For example, if "getpwnam" uses the database, instead of the current linear search, it speeds up from O(N) to O(log N). So there's a big win on scaling.
Just one observation. I agree about the flakiness of some of the GUI front ends for text file configuration but the fact is there are countless web pages, man pages & sample configuration files around that will guide you through a lot of this stuff if you do a bit of reading first.
UNIX was designed before reliable database programs were widespread. Configuration really should be in database tables, probably managed with SQLite. Using a database gives you fast lookup, consistency checking, locking against race conditions, enforcement of correct structure, dump and load capability, and a standardized interface.
The Windows Registry isn't a database; it's an unstructured tree of key/value pairs. There are no table definitions.
It's worth noting that the two most troublesome applications from a security standpoint in the UNIX/Linux world, BIND and Sendmail, are both applications that need a real database underneath but have some homebrew substitute instead.
That is the difference: Apple doesn't prevent Psystar from selling computers.
That's not the test.
As the Supreme Court said in United States v. Loew's, Inc, "Even absent a showing of market dominance, the crucial economic power may be inferred from the tying product's desirability to consumers or from uniqueness in its attributes." That's a famous case, and broke the power of the movie studios over film distribution.
If Apple had been doing that from the beginning, they might have a case. If they start doing it after the Psystar lawsuit, that could be held as an attempt to evade the legal prohibition on tying.
That's not the issue with tying violations. Read the cited case. Data General wasn't #1 in computers when they lost a tying case. Kodak wasn't #1 in copiers when they lost a tying case.
Psystar is going to win this as long as Apple sells their OS as a boxed product.
Insisting that Apple's separately sold software has to be run on Apple's hardware is an unenforceable and illegal tying arrangement under US antitrust law. This exact issue has come up before in 734 F.2d 1336 DIGIDYNE CORP. v. DATA GENERAL.. The Court of Appeals for the Ninth Circuit ruled: The issue presented for review is whether Data General's refusal to license its NOVA operating system software except to purchasers of its NOVA central processing units (CPUs) is an unlawful tying arrangement under section 1 of the Sherman Act, 15 U.S.C. Sec. 1 (1976) and section 3 of the Clayton Act, 15 U.S.C. Sec. 14 (1976). We conclude that it is.
That's clear enough.
In antitrust tying cases, it's very unusual for a tying provision in a contract to be found legally enforceable. A more common situation is that some victim of a tying arrangement wants a court to compel the company in a monopoly position to do something, like sell them spare parts. Even then, the tying company usually loses.
One major area of research that deals with this issue is Optical Burst-Switching (OBS)
The basic problem is that optical circuit switching components are available, but trying to build packet switches out of them is painful. "Burst switching" is such an attempt. Matisse Networks sells something called EtherBurst, but it's not clear that anyone ever deployed it. This is clearly an interim technology, and few network operators want to commit to it.
What this is all about is finding some way to do short-term optical packet storage in switches.
As yet, there's no optical equivalent of RAM. All-optical gates can be built, and simple logic is possible, but there are no good storage elements. So at present there are optical switches (no queueing), but not optical routers. In order to combine packets from multiple input paths to a single output path, some of the packets need to be delayed until there's free time on the output path. Routers have output queues in RAM to do this. The idea here is to find some way to do this without RAM.
Optical delay lines are simple enough; they're just sections of fibre optic. There are designs for pure optical routers which have little delay loops to which packets can be diverted while waiting for free time on an outgoing line. The delay is fixed, so this sort of thing tends to work better if all the packets are the same size, as in ATM. This new material, where propagation speed varies with light frequency, might be useful as a variable-delay storage medium. Maybe.
This is an area of much active work. Several clever ways have been developed to work around the no-RAM problem. Sort of. None of them are really satisfactory, in the sense of being able to build an optical router that does what an electronic router does now. The network backbone has to be designed around the limitations of the optical technology.
(Note that some optical switches are referred to by their vendors as "routers". They're not. Some of them, the ones with MEMS mirrors, for example, are circuit switches, like a classical phone switch.)
Fibre optic amplifiers have been all-optical for about ten years now. It's a neat technology; there's a section of erbium-doped fibre that's made to almost, but not quite, lase, by pumping the atoms up with an external laser light source that's at a lower frequency than the signal. The signal then pushes the fibre over the threshold where there's laser-type activity, and more photons come out than went in.
If a game needs administrator privileges to install, its DRM is too intrusive. It's just not acceptable to give some no-warranty game the privilege to overwrite your system settings and install hidden software. There's a moderately high probability of hostile code being present,
a strong possibility that the DRM system will open a security hole,
and a high probability that the software will not uninstall fully.
If it won't install with unprivileged user privileges, it's hostile code. Send it back.
Another morbidly obese "programming" book
on
Bash Cookbook
·
· Score: 2, Insightful
598 pages for a book on a shell? Oink!
A little plastic cheat sheet would be far more useful. The important thing is to get the basic ideas and the syntax. That requires a small, tightly written book. In an oinker of a book, the concepts get lost in the verbiage.
US manned spaceflight will end in 2010, when the Shuttle is retired. There won't be any follow-on for at least a decade. The US can't afford it any more.
NASA might be able to sell their interest in the ISS to China or Russia.
I've only seen the trailer for "Clone". Which is awful. It looks like machinema made with some PS2 game. The movement is wooden and the faces are expressionless. It's 1990s 3D animation technology, about at the level of "Reboot". When I first saw the trailer in a theater, I thought it was for a game, not a movie.
Lucas's work is all about production value. As Roger Corman once wrote of Lucas, "George spends a lot of money, but it's all up there on the screen".
Lucas is terrible at dialogue and character development, and mediocre at directing. He's great at production design and managing large-scale effects-heavy films. Which is what the Star Wars franchise is all about. "A new set every minute of film" - that's Lucas. This distracts the audience from the weak characters and dialogue.
So a low-budget cartoon as a product line extension seems like a mistake. This is a killer for Lucas's franchise.
Re:Digitizing rare vinyl with a scanner
on
Digitizing Rare Vinyl
·
· Score: 5, Informative
I was expecting someone putting a record into a flatbed scanner
That's been tried, and it sort of works. But ordinary scanners don't have enough resolution.
The Library of Congress has a scanner that does. They image the disc at a resolution of 1 micro per pixel, which yields 8 GB or so of imagery. Then they have software which can reconstruct the audio from the image.
Not only is this useful for fragile, unique records, but it will work on cracked or scratched ones. It's even possible to reconstruct a broken record if you have all the pieces.
The current scanner only works for horizontal recording; it can't read depth. So it won't work on vertically recorded records (Edison) or stereo (45/45 Westrex has two components 90 degrees apart.) They're working on that.
There's CustomizeGoogle, a Greasemonkey script which will, among other things, randomize the replies to Google's cookies. Unfortunately, it's rather slow, and may result in Javascript "script running too long" errors. Right idea, though.
"The parent is totally wrong - changing the time on the ESX host will _not_ affect the clocks of the guests, provided you go back in time on the host rather than forward."
This depends on configuration and reboot time.
See this
25-page paper on how VMware timekeeping works. The default is that when the VMware host OS is booted, it reads the hardware CMOS time of day clock, the host OS keeps time from that point, and the current host time is exported to the client operating systems via the emulated CMOS time of day clock as they boot in virtual machines.
This default behavior can be modified. You can specify offsets between the host clock and the client clocks. You can change the host clock without changing the client clocks. You can run clock synchronization programs in the clients, and these can sync to some external time source. (NNTP tends to get unhappy because the simulated clock it sees isn't running at a constant speed.) VMWare offers client-side synchronization tools for Windows and Linux, and those won't set the client OS clock backwards during operation. During reboot of a VM, though, if the host time was set backwards, the client times will by default be reset on the next boot. It's possible to configure around this and have explicit clock offsets.
But if you just set the host CPU clock back, things are only OK until the next host reboot. Then everything resyncs to the bogus time.
Remember that in the original article, the issue is about host reboots. If the host doesn't reboot, you're OK with VMware licensing. If it does, then the trouble starts.
As early as 1821, there were restrictions on how much gunpowder you could have around in a city house.
5 lbs was a common limit, and still is.
In New York State, above 5 pounds of black powder, the licensing, reporting, and safety rules
apply; for example, storage within 75 feet of an inhabited building is not permitted.
Modern smokeless powder isn't a major explosion hazard, but black powder is.
VMware is suggesting setting the system time backwards to work around their license manager problem. That's a desperation move. Not only will it mess up everything from Kerberos to
CVS to "make", if you're running certain licensed software, in particular software licensed via FlexLM, that software will stop working. FlexLM will disable your licenses if the clock goes backwards by more than 24 hours. Now your expensive high-end software protected by FlexLM (Rational, Avid, Matlab, National Instruments, ANSYS, Cisco Unity, Clearcase, Nokia network management, etc.) will stop working. Setting the clock forward again may not re-enable it, either; there's tamper detection.
Also, if you have server/client licensing with FlexLM, or multiple license servers, and the clocks disagree significantly, FlexLM gets suspicious and turns licenses off.
Slashdot Mirror
The next step would probably be hard drives that run in a hard vacuum. Current drives "fly" the head over the surface on an air cushion. A vacuum drive would have to actively measure and servo head height, which is quite feasible. Running in vacuum, drive speeds would no longer be limited by air friction and noise. Ultracentrifuges routinely reach speeds of 100,000 RPM.
But such machinery would require developing a whole new technology, cost far more than a flash drive and wouldn't fit in anything like a PC drive form factor.
My online applications log to a database, not a text file. Multiple applications on different machines can log to the same database table. There's no need for "log rotation"; old entries can be summarized and purged by date on the live database. With appropriate indexed fields, you can find key log entries in huge log files very rapidly.
Even program faults are logged to the database. If the program crashes, the top-level exception handler catches the event, does a traceback, opens a fresh database connection, and logs the traceback.
The MTA is trying to cover up the fact that their system design is very weak. The value of the card is actually stored on the card, and there's no central validation. That's embarrassing, considering that the MTA implemented fare cards quite late, long after other cities.
The NYC MetroCard system, in comparison, is totally paranoid. Cards have unique serial numbers and are validated by the entry gate, the station computer, and central servers at MetroCard HQ. Creating new cards with new IDs won't work. Duplicating cards is possible, but is detected the second time the card is used. NYC is so paranoid that equipment maintenance is performed by an outside company, but NYC employees handle the money and blank cards, so that no single party has full access. The New York City subway system was losing about $20 million a year to token fraud, and when the new system went in, they were determined that would stop. They had some fraud back in 1995, when someone stole a supply of blank cards and was able to encode them, but it turned out to be a rip-off for buyers - the cards only worked once, then were invalidated.
The first fare card system, San Francisco's BART, isn't that secure, but has an big advantage - BART has exit gates. So, while it doesn't have real-time validation against a central database, gate info is being transmitted in background to a central system, and if centralized analysis indicates something funny going on, central control can flag the card, trap the user at the exit gate, and alert station security to check the card.
I'm not seeing any significant decline in spam. Here are my spam log statistics, which combine mail received by about ten e-mail addresses at five domains:
% sqlite3 /etc 'select count(*) from passwd'
The "tying product" in this case would be Macintosh computers. Since Psystar doesn't intend to sell Macintosh computers, and Apple doesn't refuse to sell Macintosh computers to them, I really cannot see how this is related to this case.
From Findlaw: "Sellers with more than one product may seek to tie the sale of one (which the customer presumably desires) with that of another (which it presumably does not want). Such tie-ins are governed not only by the general language of the Sherman Act, but the more particular provisions of Section 3 of the Clayton Act, which prohibits such arrangements if the likely result is substantially to lessen competition. Tie-ins are per se unlawful if the seller possesses sufficient market power in the tying product, and coerces the buyer to take the tied product as a condition to obtaining the desired product."
"Sufficient market power in the tying product" means exactly that. It's market power in the specific product, not market power generally, that matters. If a manufacturer has a unique product, they inherently have market power in that product.
Actually, SQLite is in cell phones and PDAs. It's a modest-sized shared library. And, unlike text files, there's indexing. For example, if "getpwnam" uses the database, instead of the current linear search, it speeds up from O(N) to O(log N). So there's a big win on scaling.
Just one observation. I agree about the flakiness of some of the GUI front ends for text file configuration but the fact is there are countless web pages, man pages & sample configuration files around that will guide you through a lot of this stuff if you do a bit of reading first.
UNIX was designed before reliable database programs were widespread. Configuration really should be in database tables, probably managed with SQLite. Using a database gives you fast lookup, consistency checking, locking against race conditions, enforcement of correct structure, dump and load capability, and a standardized interface.
The Windows Registry isn't a database; it's an unstructured tree of key/value pairs. There are no table definitions.
It's worth noting that the two most troublesome applications from a security standpoint in the UNIX/Linux world, BIND and Sendmail, are both applications that need a real database underneath but have some homebrew substitute instead.
Linux in 2012 will look a lot like Linux in 2002.
That is the difference: Apple doesn't prevent Psystar from selling computers.
That's not the test.
As the Supreme Court said in United States v. Loew's, Inc, "Even absent a showing of market dominance, the crucial economic power may be inferred from the tying product's desirability to consumers or from uniqueness in its attributes." That's a famous case, and broke the power of the movie studios over film distribution.
If Apple had been doing that from the beginning, they might have a case. If they start doing it after the Psystar lawsuit, that could be held as an attempt to evade the legal prohibition on tying.
But is Apple in a monopoly position?
That's not the issue with tying violations. Read the cited case. Data General wasn't #1 in computers when they lost a tying case. Kodak wasn't #1 in copiers when they lost a tying case.
Psystar is going to win this as long as Apple sells their OS as a boxed product.
Insisting that Apple's separately sold software has to be run on Apple's hardware is an unenforceable and illegal tying arrangement under US antitrust law. This exact issue has come up before in 734 F.2d 1336 DIGIDYNE CORP. v. DATA GENERAL.. The Court of Appeals for the Ninth Circuit ruled: The issue presented for review is whether Data General's refusal to license its NOVA operating system software except to purchasers of its NOVA central processing units (CPUs) is an unlawful tying arrangement under section 1 of the Sherman Act, 15 U.S.C. Sec. 1 (1976) and section 3 of the Clayton Act, 15 U.S.C. Sec. 14 (1976). We conclude that it is.
That's clear enough.
In antitrust tying cases, it's very unusual for a tying provision in a contract to be found legally enforceable. A more common situation is that some victim of a tying arrangement wants a court to compel the company in a monopoly position to do something, like sell them spare parts. Even then, the tying company usually loses.
One major area of research that deals with this issue is Optical Burst-Switching (OBS)
The basic problem is that optical circuit switching components are available, but trying to build packet switches out of them is painful. "Burst switching" is such an attempt. Matisse Networks sells something called EtherBurst, but it's not clear that anyone ever deployed it. This is clearly an interim technology, and few network operators want to commit to it.
What this is all about is finding some way to do short-term optical packet storage in switches. As yet, there's no optical equivalent of RAM. All-optical gates can be built, and simple logic is possible, but there are no good storage elements. So at present there are optical switches (no queueing), but not optical routers. In order to combine packets from multiple input paths to a single output path, some of the packets need to be delayed until there's free time on the output path. Routers have output queues in RAM to do this. The idea here is to find some way to do this without RAM.
Optical delay lines are simple enough; they're just sections of fibre optic. There are designs for pure optical routers which have little delay loops to which packets can be diverted while waiting for free time on an outgoing line. The delay is fixed, so this sort of thing tends to work better if all the packets are the same size, as in ATM. This new material, where propagation speed varies with light frequency, might be useful as a variable-delay storage medium. Maybe.
This is an area of much active work. Several clever ways have been developed to work around the no-RAM problem. Sort of. None of them are really satisfactory, in the sense of being able to build an optical router that does what an electronic router does now. The network backbone has to be designed around the limitations of the optical technology.
(Note that some optical switches are referred to by their vendors as "routers". They're not. Some of them, the ones with MEMS mirrors, for example, are circuit switches, like a classical phone switch.)
Fibre optic amplifiers have been all-optical for about ten years now. It's a neat technology; there's a section of erbium-doped fibre that's made to almost, but not quite, lase, by pumping the atoms up with an external laser light source that's at a lower frequency than the signal. The signal then pushes the fibre over the threshold where there's laser-type activity, and more photons come out than went in.
If a game needs administrator privileges to install, its DRM is too intrusive. It's just not acceptable to give some no-warranty game the privilege to overwrite your system settings and install hidden software. There's a moderately high probability of hostile code being present, a strong possibility that the DRM system will open a security hole, and a high probability that the software will not uninstall fully.
If it won't install with unprivileged user privileges, it's hostile code. Send it back.
598 pages for a book on a shell? Oink!
A little plastic cheat sheet would be far more useful. The important thing is to get the basic ideas and the syntax. That requires a small, tightly written book. In an oinker of a book, the concepts get lost in the verbiage.
US manned spaceflight will end in 2010, when the Shuttle is retired. There won't be any follow-on for at least a decade. The US can't afford it any more.
NASA might be able to sell their interest in the ISS to China or Russia.
I've only seen the trailer for "Clone". Which is awful. It looks like machinema made with some PS2 game. The movement is wooden and the faces are expressionless. It's 1990s 3D animation technology, about at the level of "Reboot". When I first saw the trailer in a theater, I thought it was for a game, not a movie.
Lucas's work is all about production value. As Roger Corman once wrote of Lucas, "George spends a lot of money, but it's all up there on the screen". Lucas is terrible at dialogue and character development, and mediocre at directing. He's great at production design and managing large-scale effects-heavy films. Which is what the Star Wars franchise is all about. "A new set every minute of film" - that's Lucas. This distracts the audience from the weak characters and dialogue.
So a low-budget cartoon as a product line extension seems like a mistake. This is a killer for Lucas's franchise.
I was expecting someone putting a record into a flatbed scanner
That's been tried, and it sort of works. But ordinary scanners don't have enough resolution. The Library of Congress has a scanner that does. They image the disc at a resolution of 1 micro per pixel, which yields 8 GB or so of imagery. Then they have software which can reconstruct the audio from the image.
Not only is this useful for fragile, unique records, but it will work on cracked or scratched ones. It's even possible to reconstruct a broken record if you have all the pieces.
The current scanner only works for horizontal recording; it can't read depth. So it won't work on vertically recorded records (Edison) or stereo (45/45 Westrex has two components 90 degrees apart.) They're working on that.
There's CustomizeGoogle, a Greasemonkey script which will, among other things, randomize the replies to Google's cookies. Unfortunately, it's rather slow, and may result in Javascript "script running too long" errors. Right idea, though.
"The parent is totally wrong - changing the time on the ESX host will _not_ affect the clocks of the guests, provided you go back in time on the host rather than forward."
This depends on configuration and reboot time. See this 25-page paper on how VMware timekeeping works. The default is that when the VMware host OS is booted, it reads the hardware CMOS time of day clock, the host OS keeps time from that point, and the current host time is exported to the client operating systems via the emulated CMOS time of day clock as they boot in virtual machines.
This default behavior can be modified. You can specify offsets between the host clock and the client clocks. You can change the host clock without changing the client clocks. You can run clock synchronization programs in the clients, and these can sync to some external time source. (NNTP tends to get unhappy because the simulated clock it sees isn't running at a constant speed.) VMWare offers client-side synchronization tools for Windows and Linux, and those won't set the client OS clock backwards during operation. During reboot of a VM, though, if the host time was set backwards, the client times will by default be reset on the next boot. It's possible to configure around this and have explicit clock offsets.
But if you just set the host CPU clock back, things are only OK until the next host reboot. Then everything resyncs to the bogus time.
Remember that in the original article, the issue is about host reboots. If the host doesn't reboot, you're OK with VMware licensing. If it does, then the trouble starts.
As early as 1821, there were restrictions on how much gunpowder you could have around in a city house. 5 lbs was a common limit, and still is. In New York State, above 5 pounds of black powder, the licensing, reporting, and safety rules apply; for example, storage within 75 feet of an inhabited building is not permitted.
Modern smokeless powder isn't a major explosion hazard, but black powder is.
VMware is suggesting setting the system time backwards to work around their license manager problem. That's a desperation move. Not only will it mess up everything from Kerberos to CVS to "make", if you're running certain licensed software, in particular software licensed via FlexLM, that software will stop working. FlexLM will disable your licenses if the clock goes backwards by more than 24 hours. Now your expensive high-end software protected by FlexLM (Rational, Avid, Matlab, National Instruments, ANSYS, Cisco Unity, Clearcase, Nokia network management, etc.) will stop working. Setting the clock forward again may not re-enable it, either; there's tamper detection.
Also, if you have server/client licensing with FlexLM, or multiple license servers, and the clocks disagree significantly, FlexLM gets suspicious and turns licenses off.