But over-ruling the DMCA was certainly not his job.
The Supreme Court of the United States disagrees with you, as does the vast majority of Constitutional scholars in this country.
Any and every Article III Judge in the United States (and Kaplan is one) has a Constitutional duty to see that the law of the land is upheld.
The nation's highest law is the Constitution. It is therefore the required duty of all Article III judges to review laws which come before them for Constitutionality.
Right. Thanks for the clarification; I *think* I
have relocated my brain now.:-) Indeed, the decision points out that because this was the first constitutional challenge to the DMCA, that
he would not award legal fees to the plaintiffs,
although he could have, under the law as it was
written.
On the other hand, a lot of the decision was about
the applicability of the DMCA to the case of computer code as the access control mechanism, and
other minutia of this case, and I would not suspect that it would have been entirely kosher for Kaplan to have made any broad ruling about the act beyond the parts he decided were relevant to this case. So some other slashdotters points about potential problems with the DMCA probably didn't come up (this wasn't the case for it) or
weren't considered relevant (ditto).
But I do stand by my statement that it was the
fair use angle rather than anything else that Kaplan found most potentially worrisome about the
DMCA.
I followed this case kind of closely, and I don't remember even a shred of the DeCSS defense revolving around the argument that intellectual property should be free to all. The strongest DeCSS argument, in my opinion, was the one that the reverse engineering was specifically legal because it allowed the content to be played on platforms for which there was not a "legitimate" player.
I don't think the defense made that statement in
court, but the plaintiffs were able to convince
the judge that this was, in fact, the case.
Moreover, if you read the judgement (nobody much
here seems to have done this, however), Judge
Kaplan thought the strongest aspect of the defendent's case was not the "legitimate player"
aspect per se, but the possibility that the situation without the availability of DeCSS would
prevent fair use of the copyrighted works encrypted under CSS. Indeed,
Kaplan points out that this kind of argument was one of the biggest controversies involved in the passage of the DMCA, and that the act is a compromise of sorts. But over-ruling the
DMCA was certainly not his job. Kaplan's job was to decide whether the DMCA would apply in
this case (it did), and if the plaintiffs were entitled to any damages if the DMCA had been violated (it was violated, but all he gave them
was court costs rather than attorneys fees).
The presumed appeal here won't be on the facts of
whether or not the DMCA was the correct statute
to use to grant a permanent injunction on the posting of DeCSS , but whether the "compromise" to
fair uses of copyrighted work posed by the DMCA is, in fact, unconstitutional. That would be a
much more interesting case, but not the case the
judge was in any position to decide.
Well, I think so; I am not a lawyer. I'm crossing my fingers that Doc Hawke, Esq., will post something more informative on this.
There was a virtal screen app for OpenStep known as "VirtSpace"... There is nothing that indicates that it would not be possible to port or recreate it for OSX. It's just not going to ship with OS-X.
Thanks for the pointer; I hope you're right.:-)
I'm still a bit worried, though, since the Dock seems to have become such a big deal in MacOS X, that anything that works around that could end up causing problems. (OK, last I heard, you could kill the Dock off, but I didn't hear what you could do, if anything, to replace it or work without it.)
To all the wannabe hacker types who hate Aqua: Stop acting like it is going to cramp your style. You can live in a terminal window if you want; just maximize the window. Then, as a bonus, if you really need to do something graphical, like browse the web with something other than Lynx, you can do it, no fuss. Please stop acting like simply having Aqua on your machine is going to make you unproductive.
OK, so I bought my first Mac in 1984 and my second Mac in 2000. In between, I've mostly been a Unix and Linux user, using X. From the screenshots and reviews I've seen so far of Aqua, I've seen both good points and bad. The worst point I've seen, by far, is the apparent inability to work on multiple virtual screens. My Linux desktop has been three screens wide and three screens tall forever; under gnome, I now have a fairly minimal and unobtrusive tool bar, too. The most important part of my user experience, however, is the fact that I can have 3 different full-screen Xterms, a fully maximized XEmacs session, a Matlab session, 3 full-screen browswer windows and an "extra" blank screen all going at the same time. I'm never more than 4 keystrokes away from anything, and I never have to use the mouse if I don't want to. It's glorious. No overlapping windows, no fonts smaller than 18 points, the focus is always where I want it, and I always know where I am.
But, alas, apparently not currently possible with Aqua, where they seem to believe that people really want to have only one virtual screen on their one physical screen, and really want to keep track of a half-dozen or so "open" (but docked) applications or documents. Feh. To be fair, I only discovered this One True Way since the release of fvwm, and I've never seen anybody use this on a non-unixy platform. But what galls me is that Apple really did have something like this working back in 1986 (I believe) with Andy Hertzfield's "Switcher" when you could "virtualize" your Mac 512K (or above) into 4 (or more) 128K Macs with their own screens. Most people thought this was all about running multiple programs, but it was *really* about eliminating screen clutter. But then the idea got sucked up into the vortex of history, and what got spat out in the end is the lame cooperative multi-tasking set-up that MacOS has been stuck with ever since.
I'd like to like Aqua, but I really must have my virtual screens. Okay?
An emachine certainly does have lower perceived quality than an iMac, and it's not as designer-friendly, but most people nowadays are just looking for the cheapest possible solution.
Oh, come on now. I'm not sure that has ever really been true, unless you make that last statement "People are just looking for the cheapest possible solution to their problem." And, in that case, it's easy enough to see how different computers turn out to be the cheapest solution to somebody's problem, even if it isn't your own. Moreover the history of Apple is pretty simple when viewed in this way: when they have provided good solutions to people's problems, they had healthy margins and moved lots of boxes (whether iMacs, or Mac IIsi's or what have you). When their solutions have sucked (Mac IIvx, anybody?), they're in danger of losing the company.
Nothing ever comes down to just price, but price for what you want. I really wanted a fanless computer that you didn't feel the need to hide in a public space, that my kids liked, and that I could run Linux on when the spirit moved me. Hmm, sounds like an iMac to me.:-)
They never claimed that it was fox. They simply stated that after Toystory 2 did so well in the theater, fox cut back it's staff. In other words: Fox exec's saw the writing on the wall that 3D animation was what is selling in the theater and they couldn't compete with it.
If Fox execs looked at Toy Story 2 and saw that it was 3D animation that was selling in the theater, then they're just a bunch of dumb yutzes. What made Toy Story and Toy Story 2 such wonderful movies was that they were really well-written and well-acted. If I had to condense this down to the simplest possible statement, of why Pixar's films are so good and other people's wannabe things are not, that would be:
John Lasseter is a genius.
If the Fox execs didn't realize that the problem was that Pixar has John Lasseter, and they have no answer to that, then they won't have learned anything.
I think the biggest problem is that they felt they could not just build a *browser* but rather it has to be a "Web browsing desktop environment" that does everything except re-compile your kernel.
You severely underestimate the fine people at Netscape. Check out the xmlterm project. Yup, it provides you with a very cool xml-aware xterm thingie that models your interaction with a shell as a (dynamic) xml document. So you can cat (or xcat) html documents and have them rendered onto standard output...and re-compile your kernel for you in a subshell.
[Note: There may well be syntax errors in the above, as it took me forever just to get everything formatted right. (If you think Perl's bad, try translating Perl into guarded HTML!) I certainly can't run it all through the interpreter to check my translation. And I know there's at least one logic bug in the code.]
I feel...a module coming on. Except that I'm certain that somebody else has already written a chunk of perl code to slashguard (new verb?) an arbitrary chunk of perl code. And then they probably used slashguard.pl to post the contents of slashguard.pl onto slashdot.
Just out of curiosity: how many perl programmers here upgraded old perl scripts to use Perl 5 features when Perl 5 came out? I know that where I work, most scripts are run with perl 5 but are written (with the exception of the occasional chomp) in Perl 4 syntax. Are people fully utilizing new functionality?
I am so old that I straddle the Perl 4/5 boundary.:-) And the answer is, oh, Deity, yes, I use new functionality. Real datastructures in Perl 4 were basically painful, but the references of Perl 5 made almost everything doable; see the perlref manpage.
I really think that one of the reasons that the Perl modules are SO useful is due to the lack of strong typing ala Java.
A PERFECT example of this is the DBI library. In Perl, it's simple. You can even do
($id, $firstname, $lastname) = $sth->fetch_row();
In Java, with the JDBC, you have to do this:
(assuming rs is a ResultSet object) int id = rs.getInteger(1); String firstname = rs.getString(2); String lastname = rs.getString(3);
Perl modules are beautiful things, but the example you cite isn't evidence that strong typing is bad, only that type inference is good. In a strongly-typed functional language like Haskell, it would be clear from the type of, e.g., rs.getString() that it returns a string, hence any variable that gets that return value is...wait for it...a string. So none of those type annotations would be necessary, and, given a decent tupling syntax, the Java code would look like the Perl, modulo typographical conventions.
Indeed, Perl is essentially performing a lot of type inference ("guessing?") behind the scenes, which works gloriously well except when it doesn't.;-)
Now, if you want my personal pet peeve about Perl's Dorkiest Feature, I would say it is the bass ackwwards default of having to say "my" everytime you want a lexical scope, rather than saying, say, "packaged" for the rare time when you really do want a pacakage (or global) variable. My, my, my how the code gets cluttered up...
And then there's the whole matter of slot-loading drives to begin with. They suck, they're stupid, and they don't work.
Spoken like a person who doesn't have a 5 year-old using the computer.:-) Seriously, I did have some concerns about the slot-loading CD/DVD on the iMac DV, but it actually does seem to work just fine. And it does have the benefit that even a 5-year-old knows how it works.
Now, what I *do* fear is a vertically mounted slot like this one is the high probability of a toddler "mailing" things. That's also possible, I suppose, with a horizontal slot, but that could only get worse.
Has Apple never heard of card-discs? Anything other than standard 5" completely circular discs are useless on these things.
Well, the inability to read or use any of those business card disk things is a positive feature, in my opinion.:-)
Oh, wow. What you say might sound so sensible, but, I am afraid, is so very wrong. My point is that once you really do embrace typeful programming (in the sense of Luca Cardelli, or beyond...), then all of these kinds of types might make perfect sense.
This is the kind of thing that scares people away from FP.
What's you're suggesting is pedantic in the extreme. In OOP, the complexity moves from raw code into the class hierarchy. That is, the code may look simple, but there's an elaborate framework that you need to understand as well. In the type of programming you're proposing, the complexity moves into the type system.
Uh, not in the examples *I* gave. Which you ignored, for some reason. None of the examples I gave required any complexity in the typing system. Shoot, I didn't even mention anything that would require type inference, or anything you couldn't do in OO. (Which is, of course, why I gave Cardelli as the reference: he's an OO champion, not a flunky for the flat-earth functionalists.:-))
Maybe a more charitable reading of what you said is that typeful programming could induce complexity in the type hierarchy (rather than the system itself). And I do have some sympathy for that. But one of the nice things about, e.g., Haskell, is that it performs type inference in addition to type checking, so that in many cases, I can gain a lot of the nicest benefits of strict typing for relatively little cost.
Once you've painstakingly developed all the types you need, including algebraic properties and restrictions, then you've done most of the work. The resulting code may look simple, but, again, there's complexity elsewhere.
But, of course, very few people even in functional circles program like that. You really don't have to. But even if I were to concede that programming thoughtfully takes more work, you point out for me that the resulting code may look or be simpler. If for no other reason than the fact that you have cleanly expressed and yet strongly encapsulated the assumptions you are making about the values you are manipulating. Now, if somebody comes along after you and has to modify code you wrote, yes, they will have to absorb some aspects of the design that go beyond the neat and simple functions used to express the answer. But at least they know where to look for this information.
In general, it is a mistake to build up fancy mechanisms for simple tasks. In most programming, the typing is very simple.
In general, I think people over-estimate the simplicity of programming. Indeed, if programming were so simple than we would expect to see a far larger number of accomplished programmers than we do see.
[snip]
Imagine if you couldn't just email a note to someone without diagramming each sentence to show that it is, in fact, grammatically correct.
Now this is the ironic part. Categorical grammarians (among others) have explicitly suggested that we don't have to do this to communicate because the constituents of sentences can be understood to have specific (often higher order) types, known to us all, and that the computation of meaning depends strongly on these types. In other words, we can just knock off an email to somebody in simple language precisely because we are so constrained by some kind of type system. Now, interestingly, research done on what this type system might look like by Aarne Rante suggests it *is* a doozy of a type system. (And is possibly mathematically inconsistent, to boot.)
Programming is not the same as programming language theory. If it were, then no one would ever have been able to write code in C, C++, assembly, or Lisp, as those languages don't force you to specify every step of the way.
Wow. I guess I'm really missing something here. Leaving out Lisp for a moment, the usual argument about C, C++ or assembly is just the opposite of what you say it is. The problem with many procedural languages is precisely that you have to specify every step of the way, every check for a bad value that can't be excluded by the type system, every memory allocation and de-allocation, every decision about sequencing and evaluation order and everything else. You've done all that, but you still might have missed the branch or failed condition that now causes your program to dump core.
Of course, there are reasons for doing this, the key one being execution efficiency, or what we might call inner loop thinking. The irony of this, of course, being that this kind of code is the kind most likely to have been directly transliterated from some kind of mathematical proof or formula, where typing considerations were in effect. So what the programmer did was some kind of fancy translation from a theorem to a nicely optimized block of low-level instructions that are likely to execute perfectly. Meanwhile, that programmer or some other didn't check for an error returned by the 13th fetch of data from disk, leading to a garbage result.
Yes, but that's bad design. You could have different types for co-ordinates, and for lengths. My experience with Haskell and ML has overwhelmingly led me to believe that strict type systems are a good thing.
Yes, but while types are a good thing, there's a limit. No one wants to take this to the extreme, and have a type for odd integers, a type for the number of students in a class (as opposed to the number of books in a library), and so on.
Oh, wow. What you say might sound so sensible, but, I am afraid, is so very wrong. My point is that once you really do embrace typeful programming (in the sense of Luca Cardelli, or beyond...), then all of these kinds of types might make perfect sense.
So, for starters, why not have a type that represents all and only the Odd Integers? One can think of plenty of mathematical situations where functions are defined only (or alternatively) for odd numbers rather than even numbers. In a type-impoverished system, you might have to litter your program with checks like (in pseudocode) "if ((x % 2) == 0) --we're doomed!". In a typeful environment, when you construct X as an odd integer, and use only operations defined for odd integers, then X *stays* odd, dagnab it. And that can be a huge win. Or let me put it this way: if you were programming on an architecture where valid addresses are only even integers (Motorola 68000 comes to mind?), then specialized types guaranteed to be even or odd could save you from doing something naughty.
As for distinguishing the types for numbers of students vs. number of books, again, why not make the distinction if it is important for your problem? I mean, if values of those two types occur in one program, then having them around could make it impossible for you to compute something like "number of students read by each book" when you obviously really meant to do something else.
After a while, being pedantic ceases to pay off. Actually, it ceases to pay off rather quickly, I think.
I'm not as sure as you are. I've seen too much buggy C code where there could have been a type error (but there wasn't) and too much confusion when everything's a string (so convenient until it all goes wrong) to think of anal retentive type use as merely pedantic.
I'm currently doing a stage in the french arm of w3c. CSS1 is not that hard to implement... it's ridiculous that MS, which has so much more resources that the w3c does, is unable to get a working version of CSS1 out. And CSS2... oh boy.
OK, I think I have to take some exception with the statement that CSS1 is "not that hard to implement". When you look at the full scope of the standard, and at some of the stuff in the W3C's own CSS1 Test Suite, I think it's clear there is some very tricky stuff in here, especially if you want to render things as quickly as possible. But, yes, I agree that everybody has had enough time to get this much right by now.
Then the big problem is that there are some notable holes in CSS1 that have been attempted to be filled in CSS2, but then now there's also CSS3 coming down the pike...and it's not the case that stuff in CSS2 and CSS3 is very advanced or special interest stuff. I'm afraid that I must say, however much I might like the W3C, that they have not always done a great job of providing standards that "step up" nicely.
But there is a bright side; I think the idea of style sheets has now, finally, really begun to take hold to the point where everybody will have to support at least the most popular subset of CSS1 and CSS2 in order to be taken seriously. I mean it; if you look at the W3C's CSS web page in IE 5 for the Mac, (and then with Netscape Navigator) you'll immediately understand what I mean here.
Furthermore, I would make sure that the extensions can easily be transformed to existing tags using XSLT. XSLT (frequently referred to as XSL) is a language that essentially allows one XML document to be transformed into another. Simplistically put, you make you're own markup (extensions) and "map" them onto different xml elements (tags).
Unfortunately, this is another side of the Catch 22 that is W3C standards compliance. The XML people on W3C panels are wildly enthusiastic about XSL, which, however, was so ungainly a project, and took so long to get anywhere that they had to split it up into pieces. There is XSLT, as you point out, and there's the part of XSL that actually styles the text into formatting objects. Now, the problem is that while everybody has been going gaga over XSLT, whose widespread use is still well into the future use of CSS via the DOM has slid into a weird twilight zone, even though the CSS/DOM approach actually handles many (if not all) of the problems that XSL* will handle. Meanwhile, of course, Microsoft does have an almost-compliant XSLT to go with their almost-compliant XML parser, and...I think you see where this is going.
For today's web pages, insist on standards-following CSS/DOM (even with your XML), because that is now finally available right now. Yes, XSL* will be cool, whenever it gets here. But don't hold your breath.
Answer this question: Would any of these wonderful things not have been developed if they could not be patented?
The answer to that is, in general, unknowable, in that it's counterfactual. But I am unaware of any evidence that suggests patent systems have slowed the rate of invention, and it's easy to see how they could speed the rate of invention. (Unfortunately, a poorly-run system can also increase the rate of non-invention that you can claim as invention; this is the real problem).
But in the specific case of pharmaceutical research, I think it is very clear that the patent system has sped up the development of new, useful, drugs. In order to market a new drug in the US, you have to prove that it is both safe and effective, and this essentially entails the fact that you provide all of the information about the drug so that somebody skilled in the art could synthesize it. This process of proof, however, is hideously expensive to the point that you have to hold out some possibility for gain, whether it be though the patent system or some other mechanism, to get anybody to engage in the process. (OK, you could try and argue that this should be a governmental function, but then I'd ask you for any evidence that this would be faster or cheaper than the current system.)
And, again, I think this points out what is wrong about the current system: you can too easily get a patent for non-inventions, which helps nobody. There was nothing novel or unobvious about any number of web commerce patents out there (to name a particularly annoying category); the same cannot be said about most drug patents out there. Indeed, we know that this is the case because many clinical trials, even when conducted with strong prior information that a compound should be effective lead to the rejection of the drug in question as a clinically meaningful substance. In otherwords, the result was non-obvious.
Can anyone point to a patent that makes any compelling sense to issue? I cannot think of one. The RAMBUS episode is just the latest example of what patents are really about.
There are tons of these, actually.
Seriously, there are many technological advances that are a huge improvement over the status quo, and where it was far from clear that the device or process in question could work, and, if it did, it was valuable to know how it was built or implemented. This was not the case for things like one-click ordering, of course, but probably was the case for such stunning advances as the polymerase chain reaction (PCR) technique of amplifying DNA samples or some of the great new silicon-on-insulator (SOI) technology in the semiconductor industry.
Moreover, in the world of drug development, patents are almost certainly required to spur investment in the stupendously costly (but necessary in the long run) clinical trials one needs to get a drug certified by the FDA for a particular use.
There is a lot of slop that gets patented, and this is an unfortunate twisting of the ideals behind the patent system. But there are fistfuls of patents for technology that really does matter and for which the availability of patent protection has advanced the state of the art.
re: Sales tax, you're wrong. If the company you're doing does business in the state you purchase in, you need to pay tax. Thus, as long as you live in the same state that the Disney Store you're buying at is in, you have to pay taxes. (actually, you have to pay taxes no matter what, but they rely on you to remit them yourself when the business isn't in a position to do so)
Actually, I know the rule about you voluntarily remitting sales tax not collected by the business you're buying from, but, as we both know, nobody actually does this. (To a first approximation, anyway.) What I was trying to outline was the scenario where you buy the iMac on line, from a kiosk in the Disney store. Now, in that situation, you could argue that the Disney Store in question was in a position to collect the tax (since the web site in question could detect that the kiosk being ordered from was from one of their physical stores), and I suspect that you're right about that. So ignore the part about not having to pay tax on that sale. jking
Look. A couple years ago Apple was in bad shape. There were bankruptsy rumors and takeover rumors. At the time, they were plausable. Barely.
Since then Apple has seen an amazing rebirth and return to amazing profitability. Even in the dark days this sort of crap was barely believable, but now days it is just absurd.
Actually, I think you have it backwards. The reason why Apple nearly went under is that they had a plunging market share, a confusing product line-up, and a niche in an ecosystem where Microsoft seemed to be the unstoppable predator. Who is going to hand over much money for that? Not many people outside the computer industry itself, since Apple itself showed that you couldn't just bring in some soft drink king and build a successful hi-tech company with it.
These days, you have a growing, stylish, up-market computer and software film with close ties to the entertainment and video production industries as well as the closest possible tie-in to a major creator of animated features. Looks way more attractive, especially if the stock for that company trades at a way lower earnings multiple than most of its competition. Or than many of its potential acquirers.
Again, I don't put too much stock in this rumor given the personalities involved, but to claim that it makes no sense from a business perspective, given some of the other deals we've seen recently, is seriously mistaken.
Jobs would have to be CEO over Eisners very dead body. (Which of course would be cryo-froze and put up in the castle along side Walt).
I think that's about right.:-) But do note that Eisner is now 58 years old (I believe) while Jobs is only 45. Jobs waited 14 years (I think) to regain the CEO title at Apple, and, as long as he was given decently free reign over his corner of Disney, probably wouldn't be in any huge hurry to become CEO of Disney. Or, maybe he would, in which case the deal would never happen.
Doubtless fuelled by the Jobs/Pixar Pixar Disney connection and the fact that the Pixar movies , well at least the toy stories represent some of Disneys biggest money spinners of recent years.
I don't think there is any doubt that Disney would be very interested in buying Pixar, since Pixar gets a lot of cash from Disney for those animated features. Plus, Disney only has a 5-film contract with Pixar, and you would have to expect that a renewal, which they should want to start negotiating right about now, is also going to be extremely lucrative. So Pixar has no huge interest in being bought out...except that they do (see below).
As others have pointed out, however, Apple is an entirely different matter. I think some posters underestimate the possible value that Apple holds for Disney, but there is no doubt that Apple stockholders would do extremely well under certain buy-out scenarios, as could Pixar stockholders.
And here's why: Apple and Pixar stocks are both relatively cheap in the market when compared to Disney, at least when measured by P/E ratios; Disney (symbol DIS) has a P/E of over 80, while Apple and Pixar (symbolols AAPL and PIXR respectively, have P/Es stuck in the 25 range. In other words, a dollar of earnings by Disney is thought to be worth over three times as much as a dollar of earnings by Steve Jobs, Inc. This is, of course, a bit absurd, but it does point out that Disney is in a position to offer a very nice premium (say, 50%) over the market price for both companies and still make it look like a win. And, given all the extra earnings Disney could have by effectively voiding their contract with Pixar, this might still be quite an attractive deal, even if Disney has to swallow Apple, too. (And why Apple, too? Most likely because Jobs is CEO of both, hence responsible to the stockholders of both, and could probably get into trouble if he furthered the interests of one over the other in such a high-profile deal.)
But things get even more interesting when you realize one other thing, which is that Disney has a substantial retail presence that would seem almost ideal for selling the iMac. The world's cutest PC, playing the Toy Story 2 DVD-ROM in the Disney store. Oh, wanna buy the iMac? Just click on the "Buy an iMac" icon on the task bar and launch a browser to buy the iMac on line, hence no sales tax (and no need to carry inventory), even though you're standing right there in the store.
None of this means that the deal will happen of course, but the deal does have a larger degree of face plausibility than you'd expect from most stuff you drudge off the web...
On the othe rhand a tax *credit* is dollar for dollar: a $1 tax credit reduces your taxes by $1, and is essentially the government paying it. However, most tax credits are at less than 100% (but we have some popular 100% ones in the US for the middle and lower classes).
I'm not *quite* sure I know which ones you are talking about in that last sentence. The Earned Income Credit (EIC) is refundable, but I had thought that most others were not, in almost any bracket.
And a non-refundable tax credit can only reduce your (income) tax bill to zero. Which might sound pretty good, except that many people pay more in payroll taxes than income taxes, and there ain't no saving throw against those except to avoid earning wages. And that method can be surprisingly lucrative...
(And, yes, I know you know all of these things, unless I messed up and made an error here somewhere.)
We all now know very well that there are not very many web- or internet-based companies that make any money at all. But Yahoo does, because they really can deliver a ton of users. And the reason why Yahoo does so well is that it's fast, simple, and comprehensible. From my dealings with grandmothers and undergraduates and most people in between, it's clear that people like all of these characteristics. But what they really liked was the (admittedly naive) notion that everything on the web fit somewhere in the Yahoo hierarchy, and that somebody had lovingly set up that link with care.
On the other hand, it was becoming clear to me that some of the newer search engines, especially Google, were beginning to do a hideously good job of indexing things in a most-un-Yahooly way. Well, not completely un-Yahooly; Google is fast and simple, too. And people really like that, even if they miss that hierarchical, home-made feel.
Now, I understand that the current agreement is for Yahoo to provide Google results for searches it doesn't do anything useful with, but I would be a bit surprised if they didn't adopt the technology more widely to crunch through the Web, which can really no longer be lovingly indexed by hand. And I predict that people will learn to like it, which is something I would not have predicted a year ago.
But the end result will probably be the same: Yahoo will still make lots of money, while very few other outfits will. And the reason will probably be the same: Yahoo provides what people really want.
It's very funny seeing the die-hard anti-MS people twisting and turning to avoid having to say 'Implement it as COM!'. COM not a bad protocol, people, in fact it's quite clever. And besides that: there are a LOT of com objects around the world, and a LOT of COM developers around the world.
The last thing is certainly true. And it does seem like every major open/free software project has now had a go at (re-)implementing or (re-)inventing either CORBA or COM. Can anybody with real knowledge and experience out there compare and contrast the ups and downs of the KDE, Gnome, Microsoft, and Mozilla (XPCOM) approaches?
And, no, this isn't a troll. I have no idea what such a comparison would conclude and no vested interest in a particular answer, but a lot of interest in seeing the amount of duplicated effort in the world go down some.
What will things be kalled now? e.g.Knapster or Gnapster.
That's easy. Split the difference -- halfway between 'g' and 'k' is 'i'. Ergo it would be the iNapster. Available in five fruity colorschemes.
Actually, you could try to split the difference phonetically./g/ is a voiced velar stop while/k/ is an unvoiced velar stop. Hmm...could be tough. On the other hand, in honor of the friction that exists between the partisans of the two projects, I'd vote for a velar fricative. And we might as well go voiceless, since that's already a German phoneme. And we could spell it as X as in TeX.
Slashdot Mirror
Right. Thanks for the clarification; I *think* I have relocated my brain now. :-) Indeed, the decision points out that because this was the first constitutional challenge to the DMCA, that
he would not award legal fees to the plaintiffs,
although he could have, under the law as it was
written.
On the other hand, a lot of the decision was about the applicability of the DMCA to the case of computer code as the access control mechanism, and other minutia of this case, and I would not suspect that it would have been entirely kosher for Kaplan to have made any broad ruling about the act beyond the parts he decided were relevant to this case. So some other slashdotters points about potential problems with the DMCA probably didn't come up (this wasn't the case for it) or weren't considered relevant (ditto).
But I do stand by my statement that it was the fair use angle rather than anything else that Kaplan found most potentially worrisome about the DMCA.
I don't think the defense made that statement in court, but the plaintiffs were able to convince the judge that this was, in fact, the case.
Moreover, if you read the judgement (nobody much here seems to have done this, however), Judge Kaplan thought the strongest aspect of the defendent's case was not the "legitimate player" aspect per se, but the possibility that the situation without the availability of DeCSS would prevent fair use of the copyrighted works encrypted under CSS. Indeed, Kaplan points out that this kind of argument was one of the biggest controversies involved in the passage of the DMCA, and that the act is a compromise of sorts. But over-ruling the DMCA was certainly not his job. Kaplan's job was to decide whether the DMCA would apply in this case (it did), and if the plaintiffs were entitled to any damages if the DMCA had been violated (it was violated, but all he gave them was court costs rather than attorneys fees).
The presumed appeal here won't be on the facts of whether or not the DMCA was the correct statute to use to grant a permanent injunction on the posting of DeCSS , but whether the "compromise" to fair uses of copyrighted work posed by the DMCA is, in fact, unconstitutional. That would be a much more interesting case, but not the case the judge was in any position to decide.
Well, I think so; I am not a lawyer. I'm crossing my fingers that Doc Hawke, Esq., will post something more informative on this.
Thanks for the pointer; I hope you're right. :-)
I'm still a bit worried, though, since the Dock seems to have become such a big deal in MacOS X, that anything that works around that could end up causing problems. (OK, last I heard, you could kill the Dock off, but I didn't hear what you could do, if anything, to replace it or work without it.)
OK, so I bought my first Mac in 1984 and my second Mac in 2000. In between, I've mostly been a Unix and Linux user, using X. From the screenshots and reviews I've seen so far of Aqua, I've seen both good points and bad. The worst point I've seen, by far, is the apparent inability to work on multiple virtual screens. My Linux desktop has been three screens wide and three screens tall forever; under gnome, I now have a fairly minimal and unobtrusive tool bar, too. The most important part of my user experience, however, is the fact that I can have 3 different full-screen Xterms, a fully maximized XEmacs session, a Matlab session, 3 full-screen browswer windows and an "extra" blank screen all going at the same time. I'm never more than 4 keystrokes away from anything, and I never have to use the mouse if I don't want to. It's glorious. No overlapping windows, no fonts smaller than 18 points, the focus is always where I want it, and I always know where I am.
But, alas, apparently not currently possible with Aqua, where they seem to believe that people really want to have only one virtual screen on their one physical screen, and really want to keep track of a half-dozen or so "open" (but docked) applications or documents. Feh. To be fair, I only discovered this One True Way since the release of fvwm, and I've never seen anybody use this on a non-unixy platform. But what galls me is that Apple really did have something like this working back in 1986 (I believe) with Andy Hertzfield's "Switcher" when you could "virtualize" your Mac 512K (or above) into 4 (or more) 128K Macs with their own screens. Most people thought this was all about running multiple programs, but it was *really* about eliminating screen clutter. But then the idea got sucked up into the vortex of history, and what got spat out in the end is the lame cooperative multi-tasking set-up that MacOS has been stuck with ever since.
I'd like to like Aqua, but I really must have my virtual screens. Okay?
Oh, come on now. I'm not sure that has ever really been true, unless you make that last statement "People are just looking for the cheapest possible solution to their problem." And, in that case, it's easy enough to see how different computers turn out to be the cheapest solution to somebody's problem, even if it isn't your own. Moreover the history of Apple is pretty simple when viewed in this way: when they have provided good solutions to people's problems, they had healthy margins and moved lots of boxes (whether iMacs, or Mac IIsi's or what have you). When their solutions have sucked (Mac IIvx, anybody?), they're in danger of losing the company.
Nothing ever comes down to just price, but price for what you want. I really wanted a fanless computer that you didn't feel the need to hide in a public space, that my kids liked, and that I could run Linux on when the spirit moved me. Hmm, sounds like an iMac to me. :-)
If Fox execs looked at Toy Story 2 and saw that it was 3D animation that was selling in the theater, then they're just a bunch of dumb yutzes. What made Toy Story and Toy Story 2 such wonderful movies was that they were really well-written and well-acted. If I had to condense this down to the simplest possible statement, of why Pixar's films are so good and other people's wannabe things are not, that would be:
John Lasseter is a genius.
If the Fox execs didn't realize that the problem was that Pixar has John Lasseter, and they have no answer to that, then they won't have learned anything.
You severely underestimate the fine people at Netscape. Check out the xmlterm project. Yup, it provides you with a very cool xml-aware xterm thingie that models your interaction with a shell as a (dynamic) xml document. So you can cat (or xcat) html documents and have them rendered onto standard output...and re-compile your kernel for you in a subshell.
I feel...a module coming on. Except that I'm certain that somebody else has already written a chunk of perl code to slashguard (new verb?) an arbitrary chunk of perl code. And then they probably used slashguard.pl to post the contents of slashguard.pl onto slashdot.
So, anybody got that URL handy? :-)
I am so old that I straddle the Perl 4/5 boundary. :-) And the answer is, oh, Deity, yes, I use new functionality. Real datastructures in Perl 4 were basically painful, but the references of Perl 5 made almost everything doable; see the perlref manpage.
Perl modules are beautiful things, but the example you cite isn't evidence that strong typing is bad, only that type inference is good. In a strongly-typed functional language like Haskell, it would be clear from the type of, e.g., rs.getString() that it returns a string, hence any variable that gets that return value is...wait for it...a string. So none of those type annotations would be necessary, and, given a decent tupling syntax, the Java code would look like the Perl, modulo typographical conventions.
Indeed, Perl is essentially performing a lot of type inference ("guessing?") behind the scenes, which works gloriously well except when it doesn't. ;-)
Now, if you want my personal pet peeve about Perl's Dorkiest Feature, I would say it is the bass ackwwards default of having to say "my" everytime you want a lexical scope, rather than saying, say, "packaged" for the rare time when you really do want a pacakage (or global) variable. My, my, my how the code gets cluttered up...
Spoken like a person who doesn't have a 5 year-old using the computer. :-) Seriously, I did have some concerns about the slot-loading CD/DVD on the iMac DV, but it actually does seem to work just fine. And it does have the benefit that even a 5-year-old knows how it works.
Now, what I *do* fear is a vertically mounted slot like this one is the high probability of a toddler "mailing" things. That's also possible, I suppose, with a horizontal slot, but that could only get worse.
Well, the inability to read or use any of those business card disk things is a positive feature, in my opinion. :-)
Uh, not in the examples *I* gave. Which you ignored, for some reason. None of the examples I gave required any complexity in the typing system. Shoot, I didn't even mention anything that would require type inference, or anything you couldn't do in OO. (Which is, of course, why I gave Cardelli as the reference: he's an OO champion, not a flunky for the flat-earth functionalists. :-))
Maybe a more charitable reading of what you said is that typeful programming could induce complexity in the type hierarchy (rather than the system itself). And I do have some sympathy for that. But one of the nice things about, e.g., Haskell, is that it performs type inference in addition to type checking, so that in many cases, I can gain a lot of the nicest benefits of strict typing for relatively little cost.
But, of course, very few people even in functional circles program like that. You really don't have to. But even if I were to concede that programming thoughtfully takes more work, you point out for me that the resulting code may look or be simpler. If for no other reason than the fact that you have cleanly expressed and yet strongly encapsulated the assumptions you are making about the values you are manipulating. Now, if somebody comes along after you and has to modify code you wrote, yes, they will have to absorb some aspects of the design that go beyond the neat and simple functions used to express the answer. But at least they know where to look for this information.
In general, I think people over-estimate the simplicity of programming. Indeed, if programming were so simple than we would expect to see a far larger number of accomplished programmers than we do see.
Now this is the ironic part. Categorical grammarians (among others) have explicitly suggested that we don't have to do this to communicate because the constituents of sentences can be understood to have specific (often higher order) types, known to us all, and that the computation of meaning depends strongly on these types. In other words, we can just knock off an email to somebody in simple language precisely because we are so constrained by some kind of type system. Now, interestingly, research done on what this type system might look like by Aarne Rante suggests it *is* a doozy of a type system. (And is possibly mathematically inconsistent, to boot.)Wow. I guess I'm really missing something here. Leaving out Lisp for a moment, the usual argument about C, C++ or assembly is just the opposite of what you say it is. The problem with many procedural languages is precisely that you have to specify every step of the way, every check for a bad value that can't be excluded by the type system, every memory allocation and de-allocation, every decision about sequencing and evaluation order and everything else. You've done all that, but you still might have missed the branch or failed condition that now causes your program to dump core.
Of course, there are reasons for doing this, the key one being execution efficiency, or what we might call inner loop thinking. The irony of this, of course, being that this kind of code is the kind most likely to have been directly transliterated from some kind of mathematical proof or formula, where typing considerations were in effect. So what the programmer did was some kind of fancy translation from a theorem to a nicely optimized block of low-level instructions that are likely to execute perfectly. Meanwhile, that programmer or some other didn't check for an error returned by the 13th fetch of data from disk, leading to a garbage result.
Oh, wow. What you say might sound so sensible, but, I am afraid, is so very wrong. My point is that once you really do embrace typeful programming (in the sense of Luca Cardelli, or beyond...), then all of these kinds of types might make perfect sense.
So, for starters, why not have a type that represents all and only the Odd Integers? One can think of plenty of mathematical situations where functions are defined only (or alternatively) for odd numbers rather than even numbers. In a type-impoverished system, you might have to litter your program with checks like (in pseudocode) "if ((x % 2) == 0) --we're doomed!". In a typeful environment, when you construct X as an odd integer, and use only operations defined for odd integers, then X *stays* odd, dagnab it. And that can be a huge win. Or let me put it this way: if you were programming on an architecture where valid addresses are only even integers (Motorola 68000 comes to mind?), then specialized types guaranteed to be even or odd could save you from doing something naughty.
As for distinguishing the types for numbers of students vs. number of books, again, why not make the distinction if it is important for your problem? I mean, if values of those two types occur in one program, then having them around could make it impossible for you to compute something like "number of students read by each book" when you obviously really meant to do something else.
I'm not as sure as you are. I've seen too much buggy C code where there could have been a type error (but there wasn't) and too much confusion when everything's a string (so convenient until it all goes wrong) to think of anal retentive type use as merely pedantic.
OK, I think I have to take some exception with the statement that CSS1 is "not that hard to implement". When you look at the full scope of the standard, and at some of the stuff in the W3C's own CSS1 Test Suite, I think it's clear there is some very tricky stuff in here, especially if you want to render things as quickly as possible. But, yes, I agree that everybody has had enough time to get this much right by now.
Then the big problem is that there are some notable holes in CSS1 that have been attempted to be filled in CSS2, but then now there's also CSS3 coming down the pike...and it's not the case that stuff in CSS2 and CSS3 is very advanced or special interest stuff. I'm afraid that I must say, however much I might like the W3C, that they have not always done a great job of providing standards that "step up" nicely.
But there is a bright side; I think the idea of style sheets has now, finally, really begun to take hold to the point where everybody will have to support at least the most popular subset of CSS1 and CSS2 in order to be taken seriously. I mean it; if you look at the W3C's CSS web page in IE 5 for the Mac, (and then with Netscape Navigator) you'll immediately understand what I mean here.
Unfortunately, this is another side of the Catch 22 that is W3C standards compliance. The XML people on W3C panels are wildly enthusiastic about XSL, which, however, was so ungainly a project, and took so long to get anywhere that they had to split it up into pieces. There is XSLT, as you point out, and there's the part of XSL that actually styles the text into formatting objects. Now, the problem is that while everybody has been going gaga over XSLT, whose widespread use is still well into the future use of CSS via the DOM has slid into a weird twilight zone, even though the CSS/DOM approach actually handles many (if not all) of the problems that XSL* will handle. Meanwhile, of course, Microsoft does have an almost-compliant XSLT to go with their almost-compliant XML parser, and...I think you see where this is going.
For today's web pages, insist on standards-following CSS/DOM (even with your XML), because that is now finally available right now. Yes, XSL* will be cool, whenever it gets here. But don't hold your breath.
The answer to that is, in general, unknowable, in that it's counterfactual. But I am unaware of any evidence that suggests patent systems have slowed the rate of invention, and it's easy to see how they could speed the rate of invention. (Unfortunately, a poorly-run system can also increase the rate of non-invention that you can claim as invention; this is the real problem).
But in the specific case of pharmaceutical research, I think it is very clear that the patent system has sped up the development of new, useful, drugs. In order to market a new drug in the US, you have to prove that it is both safe and effective, and this essentially entails the fact that you provide all of the information about the drug so that somebody skilled in the art could synthesize it. This process of proof, however, is hideously expensive to the point that you have to hold out some possibility for gain, whether it be though the patent system or some other mechanism, to get anybody to engage in the process. (OK, you could try and argue that this should be a governmental function, but then I'd ask you for any evidence that this would be faster or cheaper than the current system.)
And, again, I think this points out what is wrong about the current system: you can too easily get a patent for non-inventions, which helps nobody. There was nothing novel or unobvious about any number of web commerce patents out there (to name a particularly annoying category); the same cannot be said about most drug patents out there. Indeed, we know that this is the case because many clinical trials, even when conducted with strong prior information that a compound should be effective lead to the rejection of the drug in question as a clinically meaningful substance. In otherwords, the result was non-obvious.
There are tons of these, actually.
Seriously, there are many technological advances that are a huge improvement over the status quo, and where it was far from clear that the device or process in question could work, and, if it did, it was valuable to know how it was built or implemented. This was not the case for things like one-click ordering, of course, but probably was the case for such stunning advances as the polymerase chain reaction (PCR) technique of amplifying DNA samples or some of the great new silicon-on-insulator (SOI) technology in the semiconductor industry.
Moreover, in the world of drug development, patents are almost certainly required to spur investment in the stupendously costly (but necessary in the long run) clinical trials one needs to get a drug certified by the FDA for a particular use.
There is a lot of slop that gets patented, and this is an unfortunate twisting of the ideals behind the patent system. But there are fistfuls of patents for technology that really does matter and for which the availability of patent protection has advanced the state of the art.
Actually, I know the rule about you voluntarily remitting sales tax not collected by the business you're buying from, but, as we both know, nobody actually does this. (To a first approximation, anyway.) What I was trying to outline was the scenario where you buy the iMac on line, from a kiosk in the Disney store. Now, in that situation, you could argue that the Disney Store in question was in a position to collect the tax (since the web site in question could detect that the kiosk being ordered from was from one of their physical stores), and I suspect that you're right about that. So ignore the part about not having to pay tax on that sale. jking
Actually, I think you have it backwards. The reason why Apple nearly went under is that they had a plunging market share, a confusing product line-up, and a niche in an ecosystem where Microsoft seemed to be the unstoppable predator. Who is going to hand over much money for that? Not many people outside the computer industry itself, since Apple itself showed that you couldn't just bring in some soft drink king and build a successful hi-tech company with it.
These days, you have a growing, stylish, up-market computer and software film with close ties to the entertainment and video production industries as well as the closest possible tie-in to a major creator of animated features. Looks way more attractive, especially if the stock for that company trades at a way lower earnings multiple than most of its competition. Or than many of its potential acquirers.
Again, I don't put too much stock in this rumor given the personalities involved, but to claim that it makes no sense from a business perspective, given some of the other deals we've seen recently, is seriously mistaken.
I think that's about right. :-) But do note that Eisner is now 58 years old (I believe) while Jobs is only 45. Jobs waited 14 years (I think) to regain the CEO title at Apple, and, as long as he was given decently free reign over his corner of Disney, probably wouldn't be in any huge hurry to become CEO of Disney. Or, maybe he would, in which case the deal would never happen.
I don't think there is any doubt that Disney would be very interested in buying Pixar, since Pixar gets a lot of cash from Disney for those animated features. Plus, Disney only has a 5-film contract with Pixar, and you would have to expect that a renewal, which they should want to start negotiating right about now, is also going to be extremely lucrative. So Pixar has no huge interest in being bought out...except that they do (see below).
As others have pointed out, however, Apple is an entirely different matter. I think some posters underestimate the possible value that Apple holds for Disney, but there is no doubt that Apple stockholders would do extremely well under certain buy-out scenarios, as could Pixar stockholders.
And here's why: Apple and Pixar stocks are both relatively cheap in the market when compared to Disney, at least when measured by P/E ratios; Disney (symbol DIS) has a P/E of over 80, while Apple and Pixar (symbolols AAPL and PIXR respectively, have P/Es stuck in the 25 range. In other words, a dollar of earnings by Disney is thought to be worth over three times as much as a dollar of earnings by Steve Jobs, Inc. This is, of course, a bit absurd, but it does point out that Disney is in a position to offer a very nice premium (say, 50%) over the market price for both companies and still make it look like a win. And, given all the extra earnings Disney could have by effectively voiding their contract with Pixar, this might still be quite an attractive deal, even if Disney has to swallow Apple, too. (And why Apple, too? Most likely because Jobs is CEO of both, hence responsible to the stockholders of both, and could probably get into trouble if he furthered the interests of one over the other in such a high-profile deal.)
But things get even more interesting when you realize one other thing, which is that Disney has a substantial retail presence that would seem almost ideal for selling the iMac. The world's cutest PC, playing the Toy Story 2 DVD-ROM in the Disney store. Oh, wanna buy the iMac? Just click on the "Buy an iMac" icon on the task bar and launch a browser to buy the iMac on line, hence no sales tax (and no need to carry inventory), even though you're standing right there in the store.
None of this means that the deal will happen of course, but the deal does have a larger degree of face plausibility than you'd expect from most stuff you drudge off the web...
They'd best not. Everybody knows that mozarella is made out of buffalo milk, not gnu milk. :-)
I'm not *quite* sure I know which ones you are talking about in that last sentence. The Earned Income Credit (EIC) is refundable, but I had thought that most others were not, in almost any bracket.
And a non-refundable tax credit can only reduce your (income) tax bill to zero. Which might sound pretty good, except that many people pay more in payroll taxes than income taxes, and there ain't no saving throw against those except to avoid earning wages. And that method can be surprisingly lucrative...
(And, yes, I know you know all of these things, unless I messed up and made an error here somewhere.)
On the other hand, it was becoming clear to me that some of the newer search engines, especially Google, were beginning to do a hideously good job of indexing things in a most-un-Yahooly way. Well, not completely un-Yahooly; Google is fast and simple, too. And people really like that, even if they miss that hierarchical, home-made feel.
Now, I understand that the current agreement is for Yahoo to provide Google results for searches it doesn't do anything useful with, but I would be a bit surprised if they didn't adopt the technology more widely to crunch through the Web, which can really no longer be lovingly indexed by hand. And I predict that people will learn to like it, which is something I would not have predicted a year ago.
But the end result will probably be the same: Yahoo will still make lots of money, while very few other outfits will. And the reason will probably be the same: Yahoo provides what people really want.
The last thing is certainly true. And it does seem like every major open/free software project has now had a go at (re-)implementing or (re-)inventing either CORBA or COM. Can anybody with real knowledge and experience out there compare and contrast the ups and downs of the KDE, Gnome, Microsoft, and Mozilla (XPCOM) approaches?
And, no, this isn't a troll. I have no idea what such a comparison would conclude and no vested interest in a particular answer, but a lot of interest in seeing the amount of duplicated effort in the world go down some.
Actually, you could try to split the difference phonetically. /g/ is a voiced velar stop while /k/ is an unvoiced velar stop. Hmm...could be tough. On the other hand, in honor of the friction that exists between the partisans of the two projects, I'd vote for a velar fricative. And we might as well go voiceless, since that's already a German phoneme. And we could spell it as X as in TeX.
Xnapster: the sounds of a Xnew generation.