Watch out - the DirecTivo does not record your OTA broadcast signals. It only records the channels you get from the satellite. So, if you don't get the network channels from your dish, then you won't be able to Tivo them (or, I assume, use the Tivo remote to change to the OTA channels).
True, but that's not as bad as it sounds. I don't really need the OTA broadcast signals, since my local stations (Cincinnati area) are available off the satellite. (Same for 30-40 other local markets already.) Of course, they don't carry the local PBS station, but the national PBS feed is available. They don't carry the WB station, but I never watch that anyway!
Once I found that out, I ended up getting the Sony DNR Tivo system. It interacts perfectly with the Sony SAT-B2 receiver, and my OTA channels. In fact, there is a cable that plugs from the Sony Tivo unit into the Sony sat receiver to control it. My one Tivo remote is thus the only one I have to use to get all the channels. Works perfectly.
I've heard a lot of people complain about picture quality with this kind of setup. When the standalone TiVo records something, it does its own MPEG encoding. MPEG is a lossy compression algorithm, and I've heard that re-encoding a decoded MPEG stream tends to exaggerate that lossiness. I'm told that the quality of TiVo recording from OTA broadcasts is better than the quality of the satellite broadcasts.
With the combined DirecTV/TiVo box, it's true that you no longer have an MPEG encoder, but it's recording the MPEG streams as they come off the satellite, without modification. That means no loss of quality playing back the TiVo recordings as compared to watching the content live -- either way, the exact same MPEG data is being decoded for viewing. Even if your setup looks good to you, there's unquestionably some loss of quality inherent in using multiple passes of a lossy compression algorithm. (But if you don't notice it, that's lucky.)
More significantly, DirecTV probably does a better job of MPEG compression than your standalone TiVo can hope to. They've got professional-grade MPEG encoding equipment, and a strong financial incentive to get the best compression possible. (It's a lot cheaper to get expensive encoders than to launch new satellites!) Also, I've read that DirecTV does MUCH more intensive encoding on pay-per-view movies because they don't have to do it in real time; they can really optimize both quality and compression when it's done in advance. (I don't know if they do the same thing with other movie channels like HBO or not.) DirecTV also knows (more or less) which content needs to have more bandwidth (e.g. sports) or less (e.g. talk shows), and can optimize compression that way. What's it mean for me? In addition to having better quality for the TiVo recordings, it also means that it's probably going to use the available disk space more efficiently, and without my needing to make any decisions about what quality settings to use. I see this as a good thing.
The one bad thing is the lack of an MPEG encoder for recording sources other than the satellite, but this is not an unreasonable tradeoff. Adding that encoder back in might cost another $200 in the unit price, and I'm not sure it's that important to me right now... But if it's important to you, then it sounds like you have the right setup for your needs.
I had thought that having the satellite receiver and Tivo all in one unit would be a good thing, but I've had absolutely no problems with the setup I've got. If you don't yet have a Tivo system, get it! My wife thought we didn't need it at all, but she is totally convinced now.
My wife was adamantly opposed to it; she considers it a waste of money because it seems no better than a VCR to her, and she's tired of clutter around the house (my fault) and the plethora of electronic devices (also my fault). So I've had to lobby for it for a while now. I think she'll let me get it when I'm done cleaning up the house, which I'm almost done with... (Having invested a good 30-40 hours into this project!)
Assuming she relents and lets me get it, I won't be a bit surprised if she changes her mind and becomes a TiVo convert; I've heard of it happening to other people often enough...
Well, I am a legit subscriber with a valid H card, and it was not only knocked out, DTV wants $89 US to replace it!
Well, I didn't say that the ECM didn't knock out any legit subscribers, only that they didn't knock out all of the 'H' cards, legit or not. Perhaps some (but not all) valid subscribers were hit by the ECM, but you wouldn't think they would try to charge you to replace the card! Does DirecTV believe you have a hacked card?
Ummm... bullshit! I know more than one legitimate DirecTV subscriber who was knocked off by these ECMs.
Taking out the hackers in only one of Hughes goals with these ECMS. The other was to destroy ALL H-cards, thus forcing their paying customers into upgrading to the HU cards.
But I'm sure they're _real_ sorry for whatever inconvenience they've caused people.
I don't know where you get your information, but they did not destroy all H cards last Sunday. My trusty old Sony SAT-B2 receiver came with an H card, and it still works fine. But I'm a legitimate paying DirecTV customer. Are you sure your friends were really legit?
As soon as I can convince my wife to allow it, I'm gonna upgrade to the Sony SAT-T60 receiver with TiVo -- recording the MPEG streams straight off the satellite is very cool, and I'm dying for that 14-day advance program guide. (I was very annoyed with DirecTV for cutting the guide from 3 days to under 2!) Maybe I'll sell the old Sony receiver after that; the remote codes may conflict with the new Sony, plus the SAT-T60 actually has two DirecTV tuners in it! (But the second one won't work until TiVo gets their act together and updates their software to handle it...)
Reading through a compressed random-access file may not be as big of a win as you think, since the db will need to decompress things to determine where your data is. OTOH, if you have a fast processor and slower media (CDROM) and plenty of RAM, the drawbacks will disappear after a few spins through due to caching.
The caching won't save you from uncompressing the blocks repeatedly. If you really want to compress the database metadata, you basically need a block-oriented compressed filesystem that allows random access within compressed files. I don't know if such a thing already exists, but it's effectively what you'd be writing to do it...
I'd just use zlib to compress the individual entries and not try to compress the entire database as a whole. I've done this before, and it actually works better than you'd think. Even with data entries as small as 50-100 bytes, you get reasonable compression. Yes, you'd get much better compression across the entire database, but you can't hope to access a fully-compressed database without uncompressing it or doing a lot of work to make random-access possible. (And like I said, at that point you might as well be making a compressed filesystem.)
Some architectures (I believe that this is one of the X86 sticking points) require privileged state in order to modify certain control registers, but provide non-privileged instructions for accessing the contents of those registers.
For non-virtualizing operating systems, this makes sense. By making the instructions to examine the system state non-privileged, you both simplify the job of writing the operating system (because you don't have to emulate those instructions), and you also receive a performance boost (because executing those instructions don't result in exceptions). The tradeoff comes when you try and implement a virtual machine environment, and find that you can't, because even in protected mode, a program can find out "too much" about the actual state of the processor.
Isn't the solution obvious? All you need is a "virtual" flag bit that triggers an exception for all such operations (anything that could expose that you're not running on bare metal), and only generate those extra exceptions when the flag is set. Then you don't pay the performance penalty when running a "normal" operating system, but the processor is easily virtualizable "at the flip of a switch", as it were...
Why was this never added to the 386, 486, Pentium, Pentium Pro, Pentium II, Pentium III, Athlon,...? There's been plenty of opportunities, and programs like vmware and plex86 could take really good advantage of it...
A lot of the code of the guest OS and processes run natively. Plex86 uses exceptions and breakpoints to handle "funny" stuff.
Right. This makes sense to run an OS like Windows, but if you wanted to run (say) Linux under Plex86 (which would be similar to User Mode Linux), the kernel could be modified to make Plex86 API calls directly instead of forcing Plex86 to emulate forbidden operations. This could be much faster, particularly if Plex86 knows that the guest OS won't try any "funny" stuff.
If a guest OS advises Plex86 (through an API call) that a certain type of operation won't be done, then later tries it, it would be quite acceptable if the guest OS is terminated rather rudely (with a useful error message, of course) for lying about it. It would be unacceptable (obviously) for the operation to succeed when it should have failed, so the possibility of some operations may have to be checked for, to maintain security. Apart from security considerations, such advisory API calls could save Plex86 from the extra effort required to emulate correct functioning of forbidden operations...
If the authors of an OS want to cooperate with Plex86, so it runs more efficiently when virtualized, what would you recommend? What (expensive) operations would be best avoided? Will Plex86 have a API available for a faster alternative to emulation?
Every time there's a major new kernel release, there's whining on Slashdot about killing uptime, and how much it sucks to have to reboot to get a new kernel. Well, whine no more.
Erik Hendriks at scyld.com brings us Two Kernel Monte, a 'kernel module which allows Linux to load another kernel image into RAM and restart the machine from that kernel.' The only major limitation appears to be that it will not work with SMP machines. Apparently Erik got the idea from the Linux Bios Project.
This is not an in-place kernel upgrade tool. (That's very difficult, especially without stable data structures and APIs. It's possible, but don't hold your breath.) You are avoiding the BIOS initialization sequence (thus saving some time), but you're still rebooting. The new kernel doesn't know that it was loaded by a Linux system rather than LILO. The old kernel is clobbered (including all its data structures, device drivers, running processes, etc.) and is no longer running. This still kills your uptime and requires a reboot to get a new kernel. (Feel free to keep whining.)
This project is the Linux equivalent to the DOS program LOADLIN, which loads a Linux kernel (like LILO does) and executes it. The kernel then takes over the machine and starts booting. "Two Kernel Monte" does exactly the same thing, complicated by the need to disable paging, relocate the newly-loaded kernel into a contiguous memory block (in protected mode), return to real mode, and ask the video BIOS to reset the video mode to 80x25 text, all before executing the new kernel. As with LOADLIN, the new kernel will take over the machine and begin booting. Whether started by LILO, LOADLIN or Two Kernel Monte, the end result is much the same -- the new kernel ends up with complete control over the machine (without knowing or caring how it got there), and the old OS (if any) is moot.
This may seem useless at first glance, but it's a perfect tool to test a new kernel before installing it. Also, the full power of a running Linux system would be available to obtain (or create!) the kernel image to be booted, which could enable some interesting tricks that would be difficult (or impossible) to implement in LILO. It should also be fairly easy to boot a kernel from a complex filesystem. (e.g. NFS, Coda, AFS, etc.) It might also allow for more complex boot-time decisions, such as dynamically selecting the best kernel based on complex criteria. In principle, it should be as easy to execute alternative operating systems in place of Linux, but I don't know if this works. Any form of compression or encryption (no matter how complex) could potentially be used, even if virtual memory is required to decrypt or uncompress the kernel because of limited RAM! (Try that in LILO!)
In short, this is a cool project, and potentially more useful than it may first appear.
Re:$299 Car MP3 Player: Aiwa CDC-MP3
on
Gifts For Geeks
·
· Score: 2
Kenwood also makes an in-dash MP3 player, the Z919, which should go for around $650. It's in their eXcelon series, so I suspect it has more "audiophile" features than the $300 Aiwa.
I've heard of this one. The thing that surprised me was that the Kenwood, for $650, supposedly doesn't allow you to search within an MP3 song. (You can jump track-to-track, of course.) As far as I know, the Aiwa can search within an MP3 track. So can winamp and xmms. Somehow it seems inexcusable for an "audiophile" system to lack this capability...
$299 Car MP$ Player: Aiwa CDC-MP3
on
Gifts For Geeks
·
· Score: 3
Despite the coolness factor of running Linux in your car stereo, I simply can't imagine spending $1,199 for an Empeg. It seems like a tremendous waste of money to me, and I'm just not in the habit of throwing away money like that...
I'm much more interested in the Aiwa CDC-MP3 system. It's only $299, and can play CD-Rs, CD-RWs and standard CD's, including MP3s. And it's $900 less than the Empeg...
"Wine Is Not An Emulator" can be screamed and shouted every day, all day. The fact is people use it as such. As is Linux users run Quick books on Linux+Wine without Intuit having expended a single coin to port it over. For all practical purposes we have Quick books on Linux now. There is no longer much of a financial incentive for a Linux port.
Yes and no. It's a question of the market dynamics, and in the short term, you're probably right. Intuit can ride on Wine for a while. (Of course, since they've shown no interest in Linux, that's better than nothing!) However, the same argument could have been made for why nobody would ever write Win32 applications for Windows 95, when 16-bit applications would run perfectly well (with no need for porting) and there was already a very large base of Windows 3.11 users to contend with.
In the end, Windows 95 never would have been accepted without the 16-bit compatibility; the installed base was too critical. In fact, that's the only reason Windows 95 was created -- Windows NT wasn't taking the market by storm, and Microsoft realized they needed a stepping stone to get people using 32-bit applications. That much has worked; 32-bit applications are now the norm.
Linux could well follow a similar path as Windows 95 did. First, you need compatibility with existing applications. Since Linux can be had for free, people are encouraged to try it. Since it's more stable and more powerful, people may stick with it. When the compatibility with Windows 95 is near-perfect, there will be no need to keep Windows around any longer. Once the needs of the mainstream users are met, the majority may move to Linux, as they once moved to Windows 95.
If that happens, the mass of the market would start demanding quality native applications that would run better under Linux than emulated Windows applications, much as they demanded higher-quality Win32 applications. Yes, native Linux applications would lock out Windows-only users; companies would maintain two ports if both markets are large enough to be worthwhile, or possibly just the Linux one if it somehow had the majority marketshare by then. (With good Windows 95 compatibility, it could happen -- Microsoft has had trouble getting people to upgrade when they consider Windows 95 good enough for their needs already.)
There's no guarantee that this will happen, but it's certainly possible. (It would certainly take years, if it happens at all.)
I'm sorry, but I have to take issue with the moderation of my posting as "Redundant". I spent about an hour retyping the entire decision for the benefit of those without the ability to read the PDF directly. I did this before the link was added to MSNBC's page with an HTML-ized version of the decision. Unlike that page, I retained italics and block-quote indentation from the original PDF, so this version is more readable than the MSNBC one. Other formatting was lost due to Slashdot's restrictions on HTML in comments.
Lest anyone think the posting was mere karma-whoring, I might point out that I'm already frozen for having a karma rating over 50. (Actually, it just dropped a point because of this unfair moderation, despite the balancing "Informative" moderation...)
The Supreme Court vacated this decision because "there is considerable uncertainty as to the precise grounds for the decision." It was remanded back to the Florida Supreme Court "for further proceedings not inconsistent with this opinion." This means the Florida Supreme Court's decision could be reinstated if they can clarify and justify why they made the decision. The Supreme Court did not review the federal questions asserted, since they were vacating the decision anyway. If the Florida Supreme Court reinstates the decision, then the Supreme Court will consider the federal issues.
Here's my best manual HTML translation (with some necessary formatting changes and perhaps new typos) of the original PDF of the decision:
Per Curiam
NOTICE: This opinion is subject to formal revision before publication in the preliminary print of the United States Reports. Readers are requested to notify the Reporter of Decisions, Supreme Court of the United States, Washington, D.C. 20543, of any typographical or other formal errors, in order that corrections may be made before the preliminary print goes to press.
SUPREME COURT OF THE UNITED STATES No. 00-836GEORGE W. BUSH, PETITIONER v. PALM BEACH COUNTY CANVASSING BOARD ET AL.ON WRIT OF CERTIORARI TO THE FLORIDA SUPREME COURT[December 4, 2000]
PER CURIAM.
The Supreme Court of the State of Florida interpreted its elections statutes in proceedings brought to require manual recounts of ballots, and the certification of the recount results, for votes cast in the quadrennial Presidential election held on November 7, 2000. Governor George W. Bush, Republican candidate for the Presidency, filed a petition for certiorari to review the Florida Supreme Court decision. We granted certiorari on two of the questions presented by petitioner: whether the decision of the Florida Supreme Court, by effectively changing the State's elector appointment procedures after election day, violated the Due Process Clause or 3 U.S.C. 5, and whether the decision of that court changed the manner in which the State's electors are to be selected, in violation of the legislature's power to designate the manner for selection under Art. II, 1, cl. 2 of the United States Contitution. 531 U.S. ____ (2000).
On November 8, 2000, the day following the Presidential election, the Florida Division of Elections reported that Governor Bush had received 2,909,135 votes, and respondent Democrat Vice President Albert Gore, Jr., had received 2,907,351, a margin of 1,784 in Governor Bush's favor. Under Fla. Stat. 102.141(4) (2000), because the margin of victory was equal to or less than one-half of one percent of the votes cast, an automatic machine recount occurred. The recount resulted in a much smaller margin of victory for Governor Bush. Vice President Gore then exercised his statutory right to submit written requests for manual recounts to the canvassing board of any county. See 102.166. He requested recounts in four counties: Volusia, Palm Beach, Broward, and Miami-Dade.
The parties urged conflicting interpretations of the Florida Election Code respecting the authority of the canvassing boards, the Secretary of State (hereinafter Secretary), and the Elections Canvassing Commission. On November 14, in an action brought by Volusia County, and joined by the Palm Beach County Canvassing Board, Vice President Gore, and the Florida Democratic Party, the Florida Circuit Court ruled that the statutory 7-day deadline was mandatory, but that the Volusia board could amend its returns at a later date. The court further ruled that the Secretary, after "considering all attendant facts and circumstances," App. to Pet. for Cert. 49a, could exercise her discretion in deciding whether to include the late amended returns in the statewide certification.
The Secretary responded by issuing a set of criteria by which she would decide whether to allow a late filing. The Secretary ordered that, by 2 p.m. the following day, November 15, any county desiring to forward late returns submit a written statement of the facts and circumstances justifying a later filing. Four counties submitted statements and, after reviewing the submissions, the Secretary determined that none justified an extension of the filing deadline. On November 16, the Florida Democratic Party and Vice President Gore filed an emergency motion in the state court, arguing that the Secretary had acted arbitrarily and in contempt of the court's earlier ruling. The following day, the court denied the motion, ruling that the Secretary had not acted arbitrarily and had exercised her discretion in a reasonable manner consistent with the court's earlier ruling. The Democratic Party and Vice President Gore appealed to the First District Court of Appeal, which certified the matter to the Florida Supreme Court. That court accepted jurisdiction and sua sponte entered an order enjoining the Secretary and the Elections Canvassing Commission from finally certifying the results of the election and declaring a winner until further order of that court.
The Supreme Court, with the expedition requisite for the controversy, issued its decision on November 21, Palm Beach County Canvassing Bd. v. Harris, Nos. SC00-2346, SC00-2348, and SC00-2349 (Nov. 21, 2000), App. to Pet. for Cert. 1a. As the court saw the matter, there were two principal questions: whether a discrepancy between an original machine return and a sample manual recount resulting from the way a ballot has been marked or punched is an "error in vote tabulation" justifying a full manual recount; and how to reconcile what it spoke of as two conflicts in Florida's election laws: (a) between the time frame for conduction a manual recount under Fla. Stat. 102.166 (2000) and the time frame for submitting county returns under 102.111 and 102.112, and (b) between 102.111, which provides that the Secretary "shall... ignor[e]" late election returns, and 102.112, which provides that she "may... ignor[e]" such returns.
With regard to the first issue, the court held that, under the plain text of the statute, a discrepancy between a sample manual recount and machine returns due to the way in which a ballot was punched or marked did constitute an "error in vote tabulation" sufficient to trigger the statutory provisions for a full manual recount.
With regard to the second issue, the court held that the "shall... ignor[e]" provision of 102.111 conflicts with the "may... ignor[e]" provision of 102.112, and that the "may... ignor[e]" provision controlled. The court turned to the questions whether and when the Secretary may ignore late manual recounts. The court relied in part upon the right to vote set forth in the Declaration of Rights of the Florida Constitution in concluding that late manual recounts could be rejected only under limited circumstances. The court then stated: "[B]ecause of our reluctance to rewrite the Florida Election Code, we conclude that we must invoke the equitable powers of this Court to fashion a remedy...." App. to Pet. for Cert. 37a. The court thus imposed a deadline of November 26, at 5 p.m., for a return of ballot counts. The 7-day deadline of 102.111, assuming it would have applied, was effectively extended by 12 days. The court further directed the Secretary to accept manual counts submitted prior to that deadline.
As a general rule, this Court defers to a state court's interpretation of a state statute. But in the case of a law enacted by a state legislature applicable not only to elections to state offices, but also to the selection of Presidential electors, the legislature is not acting solely under the authority given it by the people of the State, but by virtue of a direct grand of authority made under Art. II, 1, cl. 2, of the United States Constitution. That provision reads:
"Each State shall appoint, in such Manner as the Legislature thereof may direct, a Number of Electors, equal to the whole Number of Senators and Representatives to which the State may be entitled in the Congress...."
Although we did not address the same question petitioner raises here, in McPherson v. Blacker, 146 U.S. 1, 25 (1892), we said:
"[Art. II, 1, cl. 2] does not read that the people or the citizens shall appoint, but that `each State shall'; and if the words `in such manner as the legislature thereof may direct,' had been omitted, it would seem that the legislative power of appointment could not have been successfully questioned in the absence of any provision in the state constitution in that regard. Hence the insertion of those words, while operating as a limitation upon the State in respect of any attempt to circumscribe the legislative power, cannot be held to operate as a limitation on that power itself."
There are expressions in the opinion of the Supreme Court of Florida that may be read to indicate that it construed the Florida Election Code without regard to the extent to which the Florida Constitution could, considtent with Art. II, 1, cl. 2, "circumscribe the legislative power." The opinion states, for example, that "[t]o the extent that the Legislature may enact laws regulating the electoral process, those laws are valid only if they impose no `unreasonable or unnecessary' restraints on the right of suffrage" guaranteed by the state constitution. App. to Pet. for Cert. 30a. The opinion also states that "[b]ecause election laws are intended to facilitate the right of suffrage, such laws must be liberally construed in favor of the citizens' right to vote...." Ibid.
In addition, 3 U.S.C. 5 provides in pertinent part:
"If any State shall have provided, by laws enacted prior to the day fixed for the appointment of the electors, for its final determination of any controversy or contest concerning the appointment of all or any of the electors of such State, by judicial or other methods or procedures, and such determination shall have been made at least six days before the time fixed for the meeting of the electors, such determination made pursuant to such law so existing on said day, and made at least six days prior to said time of meeting of the electors, shall be conclusive, and shall govern in the counting of electoral votes as provided in the Constitution, and as herinafter regulated, so far as the ascertainment of the electors appointed by such State is concerned."
The parties before us agree that whatever else may be the effect of this section, it creates a "safe harbor" for a State insofar as congressional consideration of its electoral votes is concerned. If the state legislature has provided for final determination of contests or controversies by a law made prior to election day, that determination shall be conclusive if made at least six days prior to said time of meeting of the electors. The Florida Supreme Court cited 3 U.S.C. 1-10 in a footnote of its opinion, App. to Pet. for Cert. 32a, n. 55, but did not discuss 5. Since 5 contains a principle of federal law that would assure finality of the State's determination if made pursuant to a state law in effect before the election, a legislative wish to take advantage of the "safe harbor" would counsel against any construction of the Election Code the Congress might deem to be a change in the law.
After reviewing the opinion of the Florida Supreme Court, we find "that there is considerable uncertainty as to the precise grounds for the decision." Minnesota v. National Tea Co., 309 U.S. 551, 555 (1940). This is sufficient reason for us to decline at this time to review the federal questions asserted to be present. See ibid.
"It is fundamental that state courts be left free and unfettered by us in interpreting their state constitutions. But it is equally important that ambiguous or obscure adjudications by state courts do not stand as barriers to a determination by this Court of the validity under the federal constitution of state action. Intelligent exercise of our appellate powers compels us to ask for the elimination of the obscurities and ambiguities from the opinions in such cases."
Id., at 557.
Specifically, we are unclear as to the extent to which the Florida Supreme Court saw the Florida Constitution as circumscribing the legislature's authority under Art. II, 1, cl. 2. We are also unclear as to the consideration the Florida Supreme Court accorded to 3 U.S.C. 5. The judgement of the Supreme Court of Florida is therefore vacated, and the case is remanded for further proceedings not inconsistent with this opinion.
Linux needs a good forking. Seriously. Competition is good.
While this may be true, it seems unlikely for such a fork to develop without animosity between the two sides, especially if both are targeting the general marketplace. (Niche markets will be more readily tolerated as forks, especially if they have conflicting needs.) XEmacs vs. GNU Emacs is a good example of this animosity. On the other hand, EGCS did resolve its differences with GCC. (But did they actually achieve their goals as stated?)
That being said, I suspect there is a window of opportunity for someone to attempt to create a mainstream fork of the Linux kernel. Since Linus has eschewed most software engineering suggestions (CVS server, regression testing, etc.) and many people feel this is hampering Linux development, someone dedicated to maintaining a fork with a more engineered development process might actually have a chance at gaining mindshare. Unfortunately, this would almost certainly cause animosity and risk dividing the community. "United we stand; divided we fall." There's a delicate balance between encouraging competition and self-destructive infighting. GNOME and KDE may benefit from competition, but the entire Unix community was damaged by the Unix wars between vendors in the 80's...
How do we strike the proper balance, and should we take the risk?
What drugs is this author smoking? I was reading the Wired Article and ran into this little nugget of "information":
The Domain Name System has not seen the introduction of new generic top-level domains since the mid-1990s when dot-net, dot-com and dot-org were added.
Since then, a number of country code top-level domains (ccTLDs) have been added --.ps for the Palestinian Authority was the latest of these -- but the number of general-purpose TLDs of the dot-com variety has remained static.
Maybe they entered the mainstream consciousness in the mid-1990s, but they were around a decade earlier! RFC 920 (dated October 1984) defined.COM,.ORG and severel others, along with the 2-letter ISO country-code scheme for ccTLDs. Although.NET isn't mentioned, the Network Solutions WHOIS server shows that.NET was created on January 1, 1985 along with.COM and.ORG . The.US domain was created almost immediately afterwards, on February 15, 1985. The international domain.INT was created later, on November 3, 1988.
Created in the mid-1990s, indeed. Try a little fact-checking next time. (I personally remember using sites such as "ftp.sun.com" and "uunet.uu.net" in 1987.)
Sounds like you've never programmed for rapid development or on a budget before. VB is plenty powerful for what most people need and takes a third the time to code in my experience. As someone who started out gung-ho C++ and who writes at least ten lines of Java a day, I feel pretty safe saying that VB is one of the best things that could have come along for businesses that want an application up quickly that performs acceptably.
Maybe you should learn to program in Perl; I find it takes me about a tenth (or less) as much time as C or C++, not merely a third. (No, I'm not exaggerating; if anything, I'm understating.) It's also highly cross-platform, including a GUI (Perl/Tk) that works identically under Linux, Unix and Windows...
I did set up ArsDigita so that every employee got 5 weeks of vacation annually (enough for a 3-week break in the summer plus two one-week breaks). Maybe I should add that to the article.
Compare this against a "normal" 40 hour/week job. Most employers give at least 2 weeks of vacation. If we ignore holidays and the odd extra days beyond an even 52 weeks, that give about 50 weeks, or 2000 hours/year. If you're expecting your employees to work 70 hours/week for 47 weeks, that's 3290 hours/year, 64.5% more total hours. You should aim for the same 2000 hours/year total, if you really want to be fair. Of course, at 70 hours/week, that would mean giving each employee 23-24 weeks of vacation per year (yes, that's over 5 months). The fact that you give them only 5 weeks indicates that you really prefer exploiting your employees. Sure, you may pay well, but there's more to life than work, and time is an irreplacable resource that money cannot truly compensate for.
As long as you employ people who don't have a life outside of work, you may be able to get away with this sort of exploitation. Lucky for you, they'll have a very hard time developing a life outside of work when they're working 70 hours. However, most of them will eventually determine that living only to work isn't much of a life, and they'll find a better job someplace where they won't be exploited so much. At that point, your only hope is to keep finding new youngsters with no life, and try to indoctrinate them into your culture of indentured servitude.
As long as there remains a ready supply of people willing to be exploited, you can probably get away with this for a long time, and you're in the majority with this approach. But don't lie to yourself; you're exploiting your workers for the sake of profits. It's a widespread problem, and much of the industry is equally guilty of the same thing, but it remains exploitation, albeit well-paid exploitation.
This sort of exploitation in the past has fueled the creation of unions in other industries. If employers aren't willing to stop, don't be surprised if programmers start unionizing someday... (And then you'll regret your shortsightedness.)
Actually, one of the other responses to this article claimed that local speed of sound is slower at lower densities, not faster. (And much faster in solid ground.) This makes more sense to me, and if it's true, it makes it much more likely that she'll pass the local speed of sound.
As for why this makes more sense to me, visualize one of those toys with 5 steel balls hanging from strings in a frame. If 4 balls are touching and you drop the fifth into the others, the opposing ball will rebound instantly, but if they have space between them, it will take some time for each intermediate ball to swing to the next ball to pass the energy along -- this seems to agree with the idea that less dense gas would also take longer to transmit the energy (for the sound to travel) because of increased distance between molecules. Maybe the analogy isn't valid, but it seems sound at the moment...
Interesting points. Couldn't she cross the local speed of sound somewhere on the way down as the local speed slows down before the drag can counter the inertia of her accumulated speed?
If she's starting at a height where the atmosphere is so thin that it's considered "suborbital space", will any sound still be transmitted through air so thin?
on another note, most people never exceede the speed of sound in their lifetime. The lucky few are military pilots and those that can afford and justify a ticket on the concord. This lady gets to do it without a plane.
That leads to my question -- what effect will the (presumed) sonic boom have on her without a plane to shield her from it? Is it dangerous to either her body or her hearing, or will she even notice it? Or will there be no sonic boom at all, with so little atmosphere?
What concrete steps will you take to stop corporations from trampling individual rights or interfering with the political process, such as the usurping of the sovereignty of nations by the WTO? Do you believe that the legal fiction of corporations as "persons" is good or bad for our society, in the final analysis? Should corporations have rights, or only biological persons?
Are we to be governed by a government "of the people, by the people, for the people" or by amoral profiteering corporations and the WTO?
The way i see it, unless digital signatures are backed by cryptography, what's to stop me from "signing" something for you? How do you opt in and opt out of this thing? Do you have to show up at a government office and say "yes, i'd like my clicks to be legally binding". Or do you have to show and say "NO! I don't want to participate"? How many forms of ID do you need? Or can this be done via postal mail?
I don't know. You could try reading the text of the law yourself and see if you can figure it out. (Good luck trying to understand it without a lawyer's help!)
Digital signatures are supposed to be HARDER to forge than real ones. Not just more convienient, otherwise we'll be seeing a huge rise in fraud... That means being based on public key encryption (I think), so everyone can verify you, but no one can be you.
The law saws nothing about digital signatures. It gives legal standing to electronic signatures, an extremely vague term. (Probably deliberately so.) Yes, this is vague enough that clicking a button on a license screen or web page might constitute an "electronic signature". Forget what you know about digital signatures; this is a different beast, and a very disturbing one.
I tried to bring attention to this bill before it was signed by the President, but Slashdot rejected my submission:
2000-06-27 20:19:19 UCITA-like e-signature bill will be law soon! (articles,usa) (rejected)
Of course, the bird's already flown the coop now...
Slashdot Mirror
Oh, wow... Could you imagine a Beowulf cluster of these things?
Oh... nevermind!
Watch out - the DirecTivo does not record your OTA broadcast signals. It only records the channels you get from the satellite. So, if you don't get the network channels from your dish, then you won't be able to Tivo them (or, I assume, use the Tivo remote to change to the OTA channels).
True, but that's not as bad as it sounds. I don't really need the OTA broadcast signals, since my local stations (Cincinnati area) are available off the satellite. (Same for 30-40 other local markets already.) Of course, they don't carry the local PBS station, but the national PBS feed is available. They don't carry the WB station, but I never watch that anyway!
Once I found that out, I ended up getting the Sony DNR Tivo system. It interacts perfectly with the Sony SAT-B2 receiver, and my OTA channels. In fact, there is a cable that plugs from the Sony Tivo unit into the Sony sat receiver to control it. My one Tivo remote is thus the only one I have to use to get all the channels. Works perfectly.
I've heard a lot of people complain about picture quality with this kind of setup. When the standalone TiVo records something, it does its own MPEG encoding. MPEG is a lossy compression algorithm, and I've heard that re-encoding a decoded MPEG stream tends to exaggerate that lossiness. I'm told that the quality of TiVo recording from OTA broadcasts is better than the quality of the satellite broadcasts.
With the combined DirecTV/TiVo box, it's true that you no longer have an MPEG encoder, but it's recording the MPEG streams as they come off the satellite, without modification. That means no loss of quality playing back the TiVo recordings as compared to watching the content live -- either way, the exact same MPEG data is being decoded for viewing. Even if your setup looks good to you, there's unquestionably some loss of quality inherent in using multiple passes of a lossy compression algorithm. (But if you don't notice it, that's lucky.)
More significantly, DirecTV probably does a better job of MPEG compression than your standalone TiVo can hope to. They've got professional-grade MPEG encoding equipment, and a strong financial incentive to get the best compression possible. (It's a lot cheaper to get expensive encoders than to launch new satellites!) Also, I've read that DirecTV does MUCH more intensive encoding on pay-per-view movies because they don't have to do it in real time; they can really optimize both quality and compression when it's done in advance. (I don't know if they do the same thing with other movie channels like HBO or not.) DirecTV also knows (more or less) which content needs to have more bandwidth (e.g. sports) or less (e.g. talk shows), and can optimize compression that way. What's it mean for me? In addition to having better quality for the TiVo recordings, it also means that it's probably going to use the available disk space more efficiently, and without my needing to make any decisions about what quality settings to use. I see this as a good thing.
The one bad thing is the lack of an MPEG encoder for recording sources other than the satellite, but this is not an unreasonable tradeoff. Adding that encoder back in might cost another $200 in the unit price, and I'm not sure it's that important to me right now... But if it's important to you, then it sounds like you have the right setup for your needs.
I had thought that having the satellite receiver and Tivo all in one unit would be a good thing, but I've had absolutely no problems with the setup I've got. If you don't yet have a Tivo system, get it! My wife thought we didn't need it at all, but she is totally convinced now.
My wife was adamantly opposed to it; she considers it a waste of money because it seems no better than a VCR to her, and she's tired of clutter around the house (my fault) and the plethora of electronic devices (also my fault). So I've had to lobby for it for a while now. I think she'll let me get it when I'm done cleaning up the house, which I'm almost done with... (Having invested a good 30-40 hours into this project!)
Assuming she relents and lets me get it, I won't be a bit surprised if she changes her mind and becomes a TiVo convert; I've heard of it happening to other people often enough...
Well, I am a legit subscriber with a valid H card, and it was not only knocked out, DTV wants $89 US to replace it!
Well, I didn't say that the ECM didn't knock out any legit subscribers, only that they didn't knock out all of the 'H' cards, legit or not. Perhaps some (but not all) valid subscribers were hit by the ECM, but you wouldn't think they would try to charge you to replace the card! Does DirecTV believe you have a hacked card?
Just realized I should have changed the subject line on that posting. Oh well, consider it retroactively changed. :-)
Ummm... bullshit! I know more than one legitimate DirecTV subscriber who was knocked off by these ECMs.
Taking out the hackers in only one of Hughes goals with these ECMS. The other was to destroy ALL H-cards, thus forcing their paying customers into upgrading to the HU cards.
But I'm sure they're _real_ sorry for whatever inconvenience they've caused people.
I don't know where you get your information, but they did not destroy all H cards last Sunday. My trusty old Sony SAT-B2 receiver came with an H card, and it still works fine. But I'm a legitimate paying DirecTV customer. Are you sure your friends were really legit?
As soon as I can convince my wife to allow it, I'm gonna upgrade to the Sony SAT-T60 receiver with TiVo -- recording the MPEG streams straight off the satellite is very cool, and I'm dying for that 14-day advance program guide. (I was very annoyed with DirecTV for cutting the guide from 3 days to under 2!) Maybe I'll sell the old Sony receiver after that; the remote codes may conflict with the new Sony, plus the SAT-T60 actually has two DirecTV tuners in it! (But the second one won't work until TiVo gets their act together and updates their software to handle it...)
Reading through a compressed random-access file may not be as big of a win as you think, since the db will need to decompress things to determine where your data is. OTOH, if you have a fast processor and slower media (CDROM) and plenty of RAM, the drawbacks will disappear after a few spins through due to caching.
The caching won't save you from uncompressing the blocks repeatedly. If you really want to compress the database metadata, you basically need a block-oriented compressed filesystem that allows random access within compressed files. I don't know if such a thing already exists, but it's effectively what you'd be writing to do it...
I'd just use zlib to compress the individual entries and not try to compress the entire database as a whole. I've done this before, and it actually works better than you'd think. Even with data entries as small as 50-100 bytes, you get reasonable compression. Yes, you'd get much better compression across the entire database, but you can't hope to access a fully-compressed database without uncompressing it or doing a lot of work to make random-access possible. (And like I said, at that point you might as well be making a compressed filesystem.)
Some architectures (I believe that this is one of the X86 sticking points) require privileged state in order to modify certain control registers, but provide non-privileged instructions for accessing the contents of those registers.
...? There's been plenty of opportunities, and programs like vmware and plex86 could take really good advantage of it...
For non-virtualizing operating systems, this makes sense. By making the instructions to examine the system state non-privileged, you both simplify the job of writing the operating system (because you don't have to emulate those instructions), and you also receive a performance boost (because executing those instructions don't result in exceptions). The tradeoff comes when you try and implement a virtual machine environment, and find that you can't, because even in protected mode, a program can find out "too much" about the actual state of the processor.
Isn't the solution obvious? All you need is a "virtual" flag bit that triggers an exception for all such operations (anything that could expose that you're not running on bare metal), and only generate those extra exceptions when the flag is set. Then you don't pay the performance penalty when running a "normal" operating system, but the processor is easily virtualizable "at the flip of a switch", as it were...
Why was this never added to the 386, 486, Pentium, Pentium Pro, Pentium II, Pentium III, Athlon,
A lot of the code of the guest OS and processes run natively. Plex86 uses exceptions and breakpoints to handle "funny" stuff.
Right. This makes sense to run an OS like Windows, but if you wanted to run (say) Linux under Plex86 (which would be similar to User Mode Linux), the kernel could be modified to make Plex86 API calls directly instead of forcing Plex86 to emulate forbidden operations. This could be much faster, particularly if Plex86 knows that the guest OS won't try any "funny" stuff.
If a guest OS advises Plex86 (through an API call) that a certain type of operation won't be done, then later tries it, it would be quite acceptable if the guest OS is terminated rather rudely (with a useful error message, of course) for lying about it. It would be unacceptable (obviously) for the operation to succeed when it should have failed, so the possibility of some operations may have to be checked for, to maintain security. Apart from security considerations, such advisory API calls could save Plex86 from the extra effort required to emulate correct functioning of forbidden operations...
If the authors of an OS want to cooperate with Plex86, so it runs more efficiently when virtualized, what would you recommend? What (expensive) operations would be best avoided? Will Plex86 have a API available for a faster alternative to emulation?
Every time there's a major new kernel release, there's whining on Slashdot about killing uptime, and how much it sucks to have to reboot to get a new kernel. Well, whine no more.
Erik Hendriks at scyld.com brings us Two Kernel Monte, a 'kernel module which allows Linux to load another kernel image into RAM and restart the machine from that kernel.' The only major limitation appears to be that it will not work with SMP machines. Apparently Erik got the idea from the Linux Bios Project.
This is not an in-place kernel upgrade tool. (That's very difficult, especially without stable data structures and APIs. It's possible, but don't hold your breath.) You are avoiding the BIOS initialization sequence (thus saving some time), but you're still rebooting. The new kernel doesn't know that it was loaded by a Linux system rather than LILO. The old kernel is clobbered (including all its data structures, device drivers, running processes, etc.) and is no longer running. This still kills your uptime and requires a reboot to get a new kernel. (Feel free to keep whining.)
This project is the Linux equivalent to the DOS program LOADLIN, which loads a Linux kernel (like LILO does) and executes it. The kernel then takes over the machine and starts booting. "Two Kernel Monte" does exactly the same thing, complicated by the need to disable paging, relocate the newly-loaded kernel into a contiguous memory block (in protected mode), return to real mode, and ask the video BIOS to reset the video mode to 80x25 text, all before executing the new kernel. As with LOADLIN, the new kernel will take over the machine and begin booting. Whether started by LILO, LOADLIN or Two Kernel Monte, the end result is much the same -- the new kernel ends up with complete control over the machine (without knowing or caring how it got there), and the old OS (if any) is moot.
This may seem useless at first glance, but it's a perfect tool to test a new kernel before installing it. Also, the full power of a running Linux system would be available to obtain (or create!) the kernel image to be booted, which could enable some interesting tricks that would be difficult (or impossible) to implement in LILO. It should also be fairly easy to boot a kernel from a complex filesystem. (e.g. NFS, Coda, AFS, etc.) It might also allow for more complex boot-time decisions, such as dynamically selecting the best kernel based on complex criteria. In principle, it should be as easy to execute alternative operating systems in place of Linux, but I don't know if this works. Any form of compression or encryption (no matter how complex) could potentially be used, even if virtual memory is required to decrypt or uncompress the kernel because of limited RAM! (Try that in LILO!)
In short, this is a cool project, and potentially more useful than it may first appear.
Kenwood also makes an in-dash MP3 player, the Z919, which should go for around $650. It's in their eXcelon series, so I suspect it has more "audiophile" features than the $300 Aiwa.
I've heard of this one. The thing that surprised me was that the Kenwood, for $650, supposedly doesn't allow you to search within an MP3 song. (You can jump track-to-track, of course.) As far as I know, the Aiwa can search within an MP3 track. So can winamp and xmms. Somehow it seems inexcusable for an "audiophile" system to lack this capability...
Despite the coolness factor of running Linux in your car stereo, I simply can't imagine spending $1,199 for an Empeg. It seems like a tremendous waste of money to me, and I'm just not in the habit of throwing away money like that...
I'm much more interested in the Aiwa CDC-MP3 system. It's only $299, and can play CD-Rs, CD-RWs and standard CD's, including MP3s. And it's $900 less than the Empeg...
"Wine Is Not An Emulator" can be screamed and shouted every day, all day. The fact is people use it as such. As is Linux users run Quick books on Linux+Wine without Intuit having expended a single coin to port it over. For all practical purposes we have Quick books on Linux now. There is no longer much of a financial incentive for a Linux port.
Yes and no. It's a question of the market dynamics, and in the short term, you're probably right. Intuit can ride on Wine for a while. (Of course, since they've shown no interest in Linux, that's better than nothing!) However, the same argument could have been made for why nobody would ever write Win32 applications for Windows 95, when 16-bit applications would run perfectly well (with no need for porting) and there was already a very large base of Windows 3.11 users to contend with.
In the end, Windows 95 never would have been accepted without the 16-bit compatibility; the installed base was too critical. In fact, that's the only reason Windows 95 was created -- Windows NT wasn't taking the market by storm, and Microsoft realized they needed a stepping stone to get people using 32-bit applications. That much has worked; 32-bit applications are now the norm.
Linux could well follow a similar path as Windows 95 did. First, you need compatibility with existing applications. Since Linux can be had for free, people are encouraged to try it. Since it's more stable and more powerful, people may stick with it. When the compatibility with Windows 95 is near-perfect, there will be no need to keep Windows around any longer. Once the needs of the mainstream users are met, the majority may move to Linux, as they once moved to Windows 95.
If that happens, the mass of the market would start demanding quality native applications that would run better under Linux than emulated Windows applications, much as they demanded higher-quality Win32 applications. Yes, native Linux applications would lock out Windows-only users; companies would maintain two ports if both markets are large enough to be worthwhile, or possibly just the Linux one if it somehow had the majority marketshare by then. (With good Windows 95 compatibility, it could happen -- Microsoft has had trouble getting people to upgrade when they consider Windows 95 good enough for their needs already.)
There's no guarantee that this will happen, but it's certainly possible. (It would certainly take years, if it happens at all.)
Don't worry, I smacked em down in meta moderation.
:-)
Heh. Thanks!
I'm sorry, but I have to take issue with the moderation of my posting as "Redundant". I spent about an hour retyping the entire decision for the benefit of those without the ability to read the PDF directly. I did this before the link was added to MSNBC's page with an HTML-ized version of the decision. Unlike that page, I retained italics and block-quote indentation from the original PDF, so this version is more readable than the MSNBC one. Other formatting was lost due to Slashdot's restrictions on HTML in comments.
Lest anyone think the posting was mere karma-whoring, I might point out that I'm already frozen for having a karma rating over 50. (Actually, it just dropped a point because of this unfair moderation, despite the balancing "Informative" moderation...)
Here's my best manual HTML translation (with some necessary formatting changes and perhaps new typos) of the original PDF of the decision:
Linux needs a good forking. Seriously. Competition is good.
While this may be true, it seems unlikely for such a fork to develop without animosity between the two sides, especially if both are targeting the general marketplace. (Niche markets will be more readily tolerated as forks, especially if they have conflicting needs.) XEmacs vs. GNU Emacs is a good example of this animosity. On the other hand, EGCS did resolve its differences with GCC. (But did they actually achieve their goals as stated?)
That being said, I suspect there is a window of opportunity for someone to attempt to create a mainstream fork of the Linux kernel. Since Linus has eschewed most software engineering suggestions (CVS server, regression testing, etc.) and many people feel this is hampering Linux development, someone dedicated to maintaining a fork with a more engineered development process might actually have a chance at gaining mindshare. Unfortunately, this would almost certainly cause animosity and risk dividing the community. "United we stand; divided we fall." There's a delicate balance between encouraging competition and self-destructive infighting. GNOME and KDE may benefit from competition, but the entire Unix community was damaged by the Unix wars between vendors in the 80's...
How do we strike the proper balance, and should we take the risk?
Created in the mid-1990s, indeed. Try a little fact-checking next time. (I personally remember using sites such as "ftp.sun.com" and "uunet.uu.net" in 1987.)
Sounds like you've never programmed for rapid development or on a budget before. VB is plenty powerful for what most people need and takes a third the time to code in my experience. As someone who started out gung-ho C++ and who writes at least ten lines of Java a day, I feel pretty safe saying that VB is one of the best things that could have come along for businesses that want an application up quickly that performs acceptably.
Maybe you should learn to program in Perl; I find it takes me about a tenth (or less) as much time as C or C++, not merely a third. (No, I'm not exaggerating; if anything, I'm understating.) It's also highly cross-platform, including a GUI (Perl/Tk) that works identically under Linux, Unix and Windows...
I did set up ArsDigita so that every employee got 5 weeks of vacation annually (enough for a 3-week break in the summer plus two one-week breaks). Maybe I should add that to the article.
Compare this against a "normal" 40 hour/week job. Most employers give at least 2 weeks of vacation. If we ignore holidays and the odd extra days beyond an even 52 weeks, that give about 50 weeks, or 2000 hours/year. If you're expecting your employees to work 70 hours/week for 47 weeks, that's 3290 hours/year, 64.5% more total hours. You should aim for the same 2000 hours/year total, if you really want to be fair. Of course, at 70 hours/week, that would mean giving each employee 23-24 weeks of vacation per year (yes, that's over 5 months). The fact that you give them only 5 weeks indicates that you really prefer exploiting your employees. Sure, you may pay well, but there's more to life than work, and time is an irreplacable resource that money cannot truly compensate for.
As long as you employ people who don't have a life outside of work, you may be able to get away with this sort of exploitation. Lucky for you, they'll have a very hard time developing a life outside of work when they're working 70 hours. However, most of them will eventually determine that living only to work isn't much of a life, and they'll find a better job someplace where they won't be exploited so much. At that point, your only hope is to keep finding new youngsters with no life, and try to indoctrinate them into your culture of indentured servitude.
As long as there remains a ready supply of people willing to be exploited, you can probably get away with this for a long time, and you're in the majority with this approach. But don't lie to yourself; you're exploiting your workers for the sake of profits. It's a widespread problem, and much of the industry is equally guilty of the same thing, but it remains exploitation, albeit well-paid exploitation.
This sort of exploitation in the past has fueled the creation of unions in other industries. If employers aren't willing to stop, don't be surprised if programmers start unionizing someday... (And then you'll regret your shortsightedness.)
Actually, one of the other responses to this article claimed that local speed of sound is slower at lower densities, not faster. (And much faster in solid ground.) This makes more sense to me, and if it's true, it makes it much more likely that she'll pass the local speed of sound.
As for why this makes more sense to me, visualize one of those toys with 5 steel balls hanging from strings in a frame. If 4 balls are touching and you drop the fifth into the others, the opposing ball will rebound instantly, but if they have space between them, it will take some time for each intermediate ball to swing to the next ball to pass the energy along -- this seems to agree with the idea that less dense gas would also take longer to transmit the energy (for the sound to travel) because of increased distance between molecules. Maybe the analogy isn't valid, but it seems sound at the moment...
Interesting points. Couldn't she cross the local speed of sound somewhere on the way down as the local speed slows down before the drag can counter the inertia of her accumulated speed?
If she's starting at a height where the atmosphere is so thin that it's considered "suborbital space", will any sound still be transmitted through air so thin?
on another note, most people never exceede the speed of sound in their lifetime. The lucky few are military pilots and those that can afford and justify a ticket on the concord. This lady gets to do it without a plane.
That leads to my question -- what effect will the (presumed) sonic boom have on her without a plane to shield her from it? Is it dangerous to either her body or her hearing, or will she even notice it? Or will there be no sonic boom at all, with so little atmosphere?
Enquiring minds want to know...
What concrete steps will you take to stop corporations from trampling individual rights or interfering with the political process, such as the usurping of the sovereignty of nations by the WTO? Do you believe that the legal fiction of corporations as "persons" is good or bad for our society, in the final analysis? Should corporations have rights, or only biological persons?
Are we to be governed by a government "of the people, by the people, for the people" or by amoral profiteering corporations and the WTO?
I don't know. You could try reading the text of the law yourself and see if you can figure it out. (Good luck trying to understand it without a lawyer's help!)
Digital signatures are supposed to be HARDER to forge than real ones. Not just more convienient, otherwise we'll be seeing a huge rise in fraud... That means being based on public key encryption (I think), so everyone can verify you, but no one can be you.
The law saws nothing about digital signatures. It gives legal standing to electronic signatures, an extremely vague term. (Probably deliberately so.) Yes, this is vague enough that clicking a button on a license screen or web page might constitute an "electronic signature". Forget what you know about digital signatures; this is a different beast, and a very disturbing one.
I tried to bring attention to this bill before it was signed by the President, but Slashdot rejected my submission:
- 2000-06-27 20:19:19 UCITA-like e-signature bill will be law soon! (articles,usa) (rejected)
Of course, the bird's already flown the coop now...