Economists have this concept called friction. Basically, it's anything that gets in the way of exchanging goods and services, but the same general idea applies to information.
Email imposes less friction than snail mail.. you don't have to put the letter into the envelope, put a stamp on it, take it out to the mailbox, wait for the postman to come, etc, etc. Open Source imposes less friction than closed source.. you don't have to get involved with lawyers, licensing agreements, and all that sort of thing.
Today's Linux installations still have their share of friction. That doesn't make them evil or hopelessly flawed, but it does limit the rate at which people adopt them.
Individually, the sources of friction in Linux tend to be fairly small. Of course, so is a strand of hair. Put a whole bunch of strands together and the phrase 'wearing a hair shirt' starts to be relevant. Every inconsistency between tools that are otherwise similar (do I need 'make', 'gmake', or 'bmake' to compile this program.. oh, and what version?) is just one more source of friction that limits the spead of OSS.
Now.. I used to be a machinist, so I am deeply familiar with physical devices that are still in the process of being built. We start with a rough-cutting process where you remove 99% of the unwanted material quickly and efficiently, and get something that looks pretty much like the finished piece at a casual glance. But the entire thing is coated with burrs.. the machined surfaces are ridged like tiny files and the edges are miniature saws. That's why we go back and do a second, slow and gentle cut to take off that last tenth of a millimeter. And if you happen to be doing precision work, there are lapping, polishing, and wearing-in phases.. each of which takes longer than the one before.. which can make the phrase 'mirror smooth' seem very unimpressive indeed.
My point is that I see Linux at the 99% point. That's good, but it doesn't mean "we're almost there." It means we have enough big things out of the way that now it's important to spend a whole lot of time and effort getting that last tedious-and-unexciting 1% right.
The things that stand in our way are the "it's good enough" mindset, and the tendency for developers to make up their own standards as they go. Almost all command-line utilities accept '-x' options.. but not all of them. We still have things like 'dd if=some-file of=target'. Some commands use '-x argument' while others use '-xargument'. Some allow option stacking, like 'command -xyz', while others require 'command -x -y -z'. And then there are the '--extended' options.
And that's only the command line. Would you be prepared to bet $100 that all your manpages are in perfect synch with the actual binaries? Can you find the default httpd.conf file under Slackware, Debian, RedHat, FreeBSD and NetBSD? And you'll find similar kinds of roughness all the way up to the desktop.
None of these problems are huge, and none of them are particularly difficult to solve individually. Cleaning them all up would be a huge effort, though, especially when you think about having to polish all the scripts and utilities that rely on the currently-1%-rough standards.
The big question is whether anyone will have the determination to do all the tedious, unrewarding work necessary to bring Linux/OSS up to the next plateau of reduced friction. There's no technical barrier in the way, just a huge gumption barrier.
But I'll make this prediction: If someone does create their own low-friction distro, and the conventions they choose become the new standard, in five years the people who are currently saying Linux/OSS is good enough right now will point back and say what a mess the 'old ways' were.
Okay.. based on your comments, I'm going to assume you haven't studied law.
For those places however, this should be a police matter, and apple should not be in charge of gathering evidence!
It isn't an either/or deal. Let me explain:
Law is about protecting people's rights (and for the sake of legal discussions, corporations like Apple count as 'people'). In general, the law says someone can use their rights as much as they want as long as they don't interfere with someone else's rights in the process. To put that another way, anything that stops a person from using their rights as much as they want, as long as they don't mess with anyone else's rights in the process, might be illegal.
A contract is a deal where people agree to exchange some of their rights, or to limit their freedom to use their rights. An exchange contract would be one where you buy something from me: I give up my 'ownership' of the object in exchange for 'ownership' of the money, and you give up your 'ownership' of the money in exchange for 'ownership' of the object. A limitation contract would be something like an NDA: I agree to let you see my trade-secret information.. which I don't have to do otherwise.. and you agree to limit right to talk to people, specifically by agreeing not to tell anyone what I've shown you.
If one of the people who entered a contract fails to live up to their end of the deal, that's called breach of contract. Breach of contract is a civil matter, because while the person who broke their promise hasn't lived up to the terms of the contract, they haven't broken any actual laws.
Laws are rules that the government makes. They define the rights the government thinks people have, and they explain how people can use their rights without screwing up anyone else's rights. Laws are not some kind of contract, though. They apply to you whether you agree to them or not. When you do something a law says you shouldn't do, you aren't breaking a promise you've made to anyone, you're just doing what the government says you shouldn't. That's called a criminal matter.
Now.. it's entirely possible to break a contract (a civil violation) in a ways that also breaks some kind of law (a criminal violation). When that happens, the person you lied to can sue you for civil damages, and then the government can hit you with criminal penalties.
In such a case, it's entirely legal for the person bringing the civil suit to have their case heard first, and for the government to wait until after the civil suit has been decided before coming after you with criminal charges. In essence, the government is willing to sit back and let the civil plaintiff dig up all the evidence and present that to the court in a civil lawsuit, because the government can then refer back to that evidence during the criminal trial.
However, the root of the rest of your argument and your stolen property argument have one assumption I don't agree with; namely the assumption that information from coming from someone breaking a NDA is somehow unclean. The NDA is a personal contract, and I'm hard-pressed to see why it should carry any relevance anywhere, anytime whatsoever to a third party.
Well, here's how it works:
One of the most basic principles of law is that you can't take someone's rights away without giving them something in return. A contract is only legal if it involves an exchange of what's called consideration. 'Consideration' means either I give you my rights entirely (like when I sell you something), or I agree to put limits on the way I use my rights (like in an NDA).
Breach of contract basically 'rewinds' our rights to where they were before we made the contract. If I agree to buy something from you but don't give you the money, I can't say that you've given up your property rights to the thing I haven't paid for. We just go back t
I appreciate the fact that you've taken the time to restate your opinion in calmer terms, but I still disagree with you for several reasons:
Apple doesn't owe the Linux/Open Source community any more goodwill, thanks, or acknowledgement than the Linux/Open Source community has shown to the GNU project. You know.. the people who created the compiler and development tools that make source distribution of software possible. The folks who wrote all the userland applications that made Linux a full-scale operating system and not just some college student's personal attempt at writing a unix-like kernel. The ones whose projects and goals don't get mindshare because the Linux/Open Source community can't be bothered to say 'GNU/Linux'.
Oh, do some members of the Linux/Open Source community roll their work back into specific GNU projects, and does that count as 'paying our dues'? Well.. that's what Apple is doing.
Porting iTunes to Linux/FreeBSD wouldn't earn Apple shit for respect from the Linux/Open Source community, it would only modulate the bitching to a different key. Instead of people saying:
"The bastards won't give us iTunes,"
we'd have people saying:
"How DARE those bastards try to foist proprietary software off on the virtuous and freedom-loving Linux/Open Source Community!!?? This is the smoking gun, I tell, you.. the smoking gun!! The Apple apologist fanboys can stick their tounges as far up Apple's ass as they want, but now we have absolute proof!! Apple has declared war on Linux/Open Source and is leveraging its iTunes/iPod/iTMS monopoly to extinguish Open Source as we know it!! Apple is just as evil as Microsoft!! Anyone who uses this software is a traitor to Open Source!! If Apple really respected Linux/Open Source, they would have opened the code completely!! We will not rest until the source for iTunes is in our hands!!
And we want Quicktime!! And FairPlay!! And the Sorensen codec! And OpenStep, Quartz, Aqua, and the Finder. And any cool userland apps that catch our interest too.
Oh.. and the Dock.. it sucks, but we want the code anyway.."
Rants like that are superficially similar to RMS's arguments about the disadvantages of non-free software, but they don't have RMS's eloquence, restraint, or broader philosophical justification. They create a smokescreen that lets Bill Gates equate RMS with any dozen greed-driven fuckwits he can pull out of the latest Slashdot postings when he wants to make business and government leaders all over the world think that Open Source == Free Software == communism == the death of intellectual property.
That's how the Linux/Open source community demonstrates its goodwill, thanks, and acknowledgement for everything RMS and the GNU project have given us.
A port wouldn't serve everyone, so we'd still have people bitching that Apple hasn't supported the POS box they built out of parts they scavenged from a dumpster with their own three hands.
Porting iTunes to Linux/*BSD would take a hell of a lot of work. It's a GUI application, so what environment do you want them to use? Gnome? KDE? Enlightenment? plain-old-X with toolkit X, Y, or Z? iTunes is most likely written in Objective-C against the OpenStep framework, with Quicktime for an audio layer, and Aqua nib files for interface specification and invocation. Where will they find support for those in Linux/*BSD without porting the whole lot? Then how will they keep the ports in synch with every OS/GUI/toolset/harware configuration unless they open the source for everything?
Opening the source of iTunes would be very bad for Apple, because the iTMS owes less to code and computer technology than it does to the years of work Apple has invested in developing a working relationship with the DRM-obsessed
Have you noticed that, althought Apple's own operating system owes a lot to the open source movement, and the thousands of developers whose code they use for free, you and I still cannot run iTunes on our Linux desktop to sync an iPod? No money in it for them...
I've written this before, but haven't refreshed it for a while, so here goes: That kind of attitude is the direct opposite of the Open Source mindset. You're making the classic mistake of failing to distinguish between "sharing-as-giving-things-to-other-people" and "sharing-as-taking-things-from-other-people".
Open Source is a development philosophy that makes it easy for people to roll their own work back into the original project. It is not a crowbar to pry somebody else's work away from them, and every person who pumps crap like this into the air just proves Bill Gates right when he calls Open Source anticommercial, anti-property, communist, and any other nasty names he can think of.
NOTHING in any part of the Open Source manifesto says being part of one open project means you're obliged to open everything else you've ever made. Not even the GPL requires that. RMS personally feels that the world would be a better place if all distributed software happened to come with source code that any end user was free to use and modify, but even he tries to state that opinion in reasonably moderate terms.
If you want to know the Open Source attitude about when to open a project, try reading section 10 of The Magic Cauldron, specifically the case study of when it made sense to open Doom.
Whether you like it or not, it does make sense to keep some projects closed until the market matures enough for the benefits of opening the source to pay off. It took four years for that to happen with Doom, and let's face it, the gaming industry moves pretty fast, even for software. The bloom was pretty much off the rose by then.
iTunes/iTMS and the iPod are currently in a state where the benefits of staying closed still outweight the benefits of being open. They don't suffer significant reliability or scalability problems, they don't require independent peer review the way cryptosystems do, they don't create a significant communications infrastructure (though podcasting does create a comms network at the application layer), and they don't rely on standardized key methods at the software level. They have no meaningful competition, they're picking up market like hell, and the untapped market of Windows users and non-computer users is vastly larger than the "I refuse to participate unless I can do it on Linux" market.
In Open Source, 'paying your dues' means giving your modifications back to the original project. Period. Apple does that. And there's fairly good reason to assume that the Linux community would spend a metric fuckload more time and effort porting Apple's crown jewels over to Linux than 'paying its dues' if Apple were crazy enough to open those projects.
If the Open Source community wants business to take it seriously, it has to be deadly serious about adding value to the original project, not pillaging everyone else's technology in the name of Improving Linux like the anti-property assholes Bill Gates wants us to be.
Please.. if you're going to insult me, at least have the courtesy to use an actual name.
It might also help to know something about the subject before playing the PBH "anything I don't understand must be a buzzword" card. If you can cite a reference about entropy that says I'm wrong, fire away.
And the fence who buys stolen property isn't guilty of breaking and entering. He is guilty of receiving stolen property, though, and that also happens to be illegal.
The bloggers may not have agreeed to the NDA, but their sources did. By sharing trade secrets with the bloggers, the sources violated their NDAs. That's a clear breach of contract on the source's part, and in some places the act of breaking a legally binding NDA is also recognized as a criminal action.
By accepting and publishing the information the sources provided, the bloggers failed to perform due diligence in making sure the stuff they posted was actually clean. And unless you can some up with a really compelling argument to show how people who publish rumors about unreleased products can't possibly be expected to consider the chance they might end up getting something covered by an NDA, I'm personally going to call that a stupid oversight.
Now.. Apple's legal department would like to have a little chat with the sources who gave ThinkSecret the information.. you know, the people who did agree to the NDA and did violate said NDA by passing the information to ThinkSecret. Accordingly, Apple's nazgul asked ThinkSecret to identify the sources. ThinkSecret said no, on the not-terribly-convincing assumption that they could claim journalistic privilege.
The current article indicates that the judge didn't find ThinkSecret's argument compelling.
The clustering illusion demonstrates the universal principle of entropy. No matter what random collection of objects you look at, the most common distribution will not be the most evenly dispersed one, but the most evenly dispersed disorganized one.
If we randomly distribute the integers from 1 to 100, it's going to look pretty strange if the first 50 are all even, and the second 50 are all odd. So will a distribution where all the primes come first, or any other detectable order. Entropy acts as a sort of 'inflating' principle which makes less-smoothly-dispersed collections more common than more-smoothly-dispersed ones.
Clustering is inevitable, especially when you take small selections from a large, frequently reshuffled population. In this case, we're talking about a situation equivalent to shuffling the numbers from 1 to 100 and taking the first 10, then shuffling again and taking another 10, etc. If we were to do that 10 times, and found that we'd collected exactly one copy of every value from 1 to 100, that would be very unlikely. If it happened consistently, something would be very wrong with our RNG.
how the heck is a site like this going to be indexed on search engines?
interstitial ads more or less destroy the one thing that makes the web valuable: the ability to link documents together. . the fundamental, underlying concept of the URL is "hey, here's some information.. come and get it." . not only does putting barriers between users and the information they want raise technical problems, but it *really* screws with your ability to make information globally visible.
the kind of interstitial system this author suggests just doesn't synch up with the basic technology of the web. . the web is stateless, so it doesn't know which pages you've already seen. . that means you have three basic options when it comes to the delivery system:
1 - you make the home page of the site an 'entry tunnel', and leave all your actual content on regular webpages, which leaves users free to circumvent your entry tunnel if they can find any other index that links to the content.
2 - you can hide every single page in the site behind some kind of cookie-based 'has this user viewed enough interstitial advertising?' system, and dump a 20-second Flash ad on any page request that doesn't qualify. . and that would turn into an endless loop for users who don't honor cookies.. the page request prompts a redirect to the Flash ad because there's no cookie, then the Flash ad fails to set a cookie and triggers another request for the original page.. which fails because there's no cookie, so you get another Flash ad, ad nauseam.
3 - you can do your whole site in Flash, which makes any content inside your site inaccessible to anyone who doesn't sit through their daily force-feeding of advertising.
search engines will ignore any site that uses option 2 or 3, and will bypass the entry tunnel of any site that uses option 1. . and since search engines are still the single largest source of new eyes for any website, screwing the search engines means screwing any hope of building or expanding a user base.
using a system like that would be actively hostile to linking from outside, because it amounts to the putting the message "click here for a royal waste of your time" on any site that *does* link to your content. . face it.. if it had been impossible to reach the article in question without forcing every/. reader who clicked on the link to sit through a 20-second Flash ad, do you think this story would have been posted? . can you imagine the torrent of complaints that would rain down if such a link had been posted without a warning?
the whole article could be summed up as, "the web makes it *way* to easy for people to get information, and i can't compete with that using my current business model. . but i'm either too stupid or too cowardly to try searching for a new business model, so i want to make the web just as invonvenient and user-UNfriendly as the media i already understand."
before everyone dives into the argument that Apple lost its look-and-feel lawsuit against Microsoft, let's stop to be clear about what the court's decision actually said.
the court decided that intellectual property regarding user interfaces falls into two broad categories: 'protected' elements, and 'non-protected' elements. the term 'non-protected' is a bit misleading, because it doesn't mean 'up for grabs', it just means that elements in that category don't enjoy the *full* protection of copyright.
the court also held that GUIs have to be examined in two contexts: as a collection of widgets, and as an 'assembled' whole.
the conditions for infringement are different for 'protected' and 'non-protected' elements:
- copies of 'protected' elements are illegal if they are 'substantially similar' to the original.
- copies of 'non-protected' elements are only illegal if they're 'virtually identical' to the original.
to decide whether a GUI clone in illegal, you start by breaking the original and the copy into dictionaries of widgets. if we assume that all the standard widgets are non-protected, only widgets that are 'virtually identical to' the Aqua equivalent will be infringing.
even if none of the individual widgets are found to be infringing, though, the whole GUI has to be compared to Aqua to see if the assembly is 'substantially similar' to Aqua. the importatnt point here is that the assembly as a whole can still fall in the 'protected' category, even though the elements that make it up are individually 'non-protected'.
so let's look at the Aqua clones using the test from the lawsuit Apple lost:
break out the widgets and compare them to the Aqua originals. could a normal person tell the original from the copy without resorting to special machinery, like checking the *exact* hex values of the RGB colors? any widget that fails is probably an illegal infringement.
then, even if all the widgets are sufficiently different from the originals that they're non-infringing, is the way they're assembled 'substantially similar' to Aqua? if so, the theme as a whole is still an infringing product, even if the individual widgets aren't.
face it.. the people making Aqua themes are trying to get the best copies they can. they're *trying* to make the widgets 'virtually identical' to the originals, and they're *trying* to make the overall assembly 'substantially similar' to Aqua. that's against the law, as stated by the very look-and-feel case that Apple *lost*.
the original article has its points, but the author is really rejecting the culture of hype which has admittedly grown up around OOP, without really tracing it down to its theoretical roots.
the thing that makes programming hard is that you have to try and reduce a set of ideas in the human mind to a set of operations that can be performed in a Turing-complete computational environment.
that's not easy, because most people don't think in a computationally disciplined manner. . those who did presumably got flattened on my mastodons a few zillion years ago when they experienced the caveman equivalent to a BSOD.
therefore one of the things languages and programming styles do is give programmers ways to keep track of the larger-order logical machinery of their code. . the better a language is at making that logical machinery manageable, the more useful it can be.
structured programming isn't just the programmer's version of brussel's sprouts.. something you have to put up with because people say that it's good for you.. it makes finite automata and pushdown automata immediately visible in your code. . at least, it makes them visible if you know where to look.
here's the trick: every function is a state machine, usually following the pattern:
(acquire data) --> (verify data) --> (calculate new value from data)
with conditionals being there to handle internal branching, like reporting an error when the verification step fails, instead of doing the calculation.
and since each function has its own private scope for data storage, each function can act as a self-contained section of data storage.
when you chain finite automata together, such that one passes a value to the next one, and receives a value in return, you get a pushdown automaton. . therefore, structured programming is really just the art of reducing problems to computational methods that are easily expressed as pushdown automata, and represented as code in which functions with isolated scope pass parameters and return values back and forth.
and that's lovely, but it's not powerful enough to be useful.
pushdown automata have their limits, and there are some problems you just need to handle with a Turing machine.. binary multiplication, for one.
to get around the inherent limits of purely isolated function scopes and parameter/return passing, structured programming languages also support global variables, which make data accessible to any scope, regardless of its connection to the call-return chain of the pushdown automaton.
and that makes structured programming powerful, but it opens up room for all sorts of messes. . the global values that link sections of the program together are harder to keep track of than the calling heirarchy of a structured program, so structured programming isn't quite the best tool for making the logic that holds a program together visible. . then there's the little fact that with two integer counters and a bit of determination, you can implement a fully-functional Turing machine that's all but invisible within the code. . most people don't do that per se, but if you store enough important information in global variables, it becomes difficult *not* to evolve a Turing machine to manage it. . and that Turing machine evolves in a million little corners of the program, none of which seem to have any obvious connection to each other.
OOP makes Turing machines visible, because it gives us the concept of an isolated scope which is larger than a single function, but smaller than the entire program. . other languages have done the same thing.. C's file-scope restrictions, for example.. but OOP is the system that actually puts a name on it and makes it easy to see.
the data structure which forms the visible instantiation of an object can be seen as the tape of a simple Turing machine. . the object's methods manipulate values on that tape, but only those methods have access to that tape. . the rest of the program only communicates with the object (Turing machine) through an i/o interface that doesn't affect the data stored on the tape.
an object-oriented program is a network of Turing machines.
can you fuck that up royally? sure.
can you write well-organized code with other tools? of course.
is one style of programming inherently better than another? hell no.
the reason to care about OOP is that it's convenient.. that's all. . it gives us a nice framework in which to arrange important ideas, so we can get on with the real work of reducing human assumptions to computationally effective logic.
and that's why programmers need to know.. as in 'grok in fullness'.. as many different styles of programming as they get cram in their heads. . each one gives us a convenient way to talk about some other set of important -- and *useful* -- ideas.
forget the physical explanations.. Santa is a macroscopic quantum event.
Santa is the observational manifestation of the Christmas spirit, and all the stockings by the chimney and presents under the tree are really just Schrodinger boxes that contain the superimposed waveforms of both a gift and a lump of coal. . that waveform collapses as soon as you look in the box, and since everyone knows in their heart whether they've been naughty or nice, the fact that you're expecting a particular outcome determines what the contents will be.
this model is strengthened by the fact that Santa takes advantage of the time constraints of a relative universe:
Santa can appear in any number of living rooms at precisely the stroke of midnight, because in a relative universe, you can't prove that the stroke of midnight happens in any two houses at exactly the same time. . each house represents an isolated frame of reference whose time scale can only be measured relative to any other frame of reference, so being able to see Santa in your own living room means that you are fundamentally unable to prove that he was anywhere else at exactly the same time.
any connection between two frames of reference that contain Santa is subject to (at minimum) speed-of-light constraints (or more likely, putting-on-slippers- and-a-coat-and-running-next-door- yelling-hey-guess-what-i-saw- whoa-how-did-YOU- get-here constraints), so if either you or the information can get from one frame of reference to another, Santa can get there, too.
the model is further strengthened by the fact that Santa exhibits uncertainty effects:
you might be looking at Santa, or you might just be looking at some guy in a red suit. . the real Santa is simply the locus of minimal uncertainty (or maximal belief) that you honestly are looking at Santa. . the effect can be demonstrated with a simple thought-experiment:
assume that you're walking down a street that has one Santa on each corner. . the position of the real Santa travels along with your point of observation.
when you're right next to the first Santa, you can be highly confident (assuming you're an optimist) that this one really is Santa. . the one at the other corner is too far away to observe, so the locus of maximal belief occurs at the Santa closest to you.
as you walk down the street toward the next Santa, you lose certainty that the one you just left is still the real Santa, and gain certainty that the one you're approaching is the real Santa. . at the point precisely half way between the two Santas, the locus of maximal belief is equally distributed between both. . thus, as far as you can prove from that position, either one *could* be Santa, and that's all you can say.
as you continue to walk toward the second Santa, you become more confident that this really is the one, until you arrive at the same position as this new Santa, only to discover that this is the real one, too.
the model works just as well for a skeptic, except that the real Santa is always the one on the *other* corner.
> The military, on the other hand, gets crazy with spending.
that's its job. . the military is in the business of preventing disasters, and that kind of operation is inherently wasteful. . you don't measure the cost of what you're spending against the returns you get, you measure the cost of what you're spending against what you'd lose if there *was* a disaster.
that's tough, because if you're doing things right, the disasters never actually happen.
geeks do exactly the same thing when they design networks to handle peak loads, eliminate single points of failure, and all the rest. . all the PHBs see is a pile of expensive and complicated technology that -- in their opinion -- could be replaced by a single computer with a cable modem. . the difference is that one will fall over and emit smoke if it gets Slashdotted, and the other one won't.
but the PHBs don't care.
until the network gets Slashdotted. . then they want everything fixed *now*.
making a profit means using your resources right up to the limits of their capacity. . preventing disasters means making sure you don't run out of anything too soon. . when it comes to fighting wars, the guy who has one bullet left over when everyone else has run out -- wins.
of course, if he has *two* bullets left over, you can bet that someone will call the second one an "unnecessary surplus".
if you need to communicate a bunch of technical information to people who mostly don't give a crap, and it's important that those people remember that information in critical situations, you could do worse than to use military training materials as your guide.
it doesn't matter what your biases are one way or another, anyone who takes a serious look at the military's educational materials will have to admit that they've spent one hell of a lot of time and money finding ways to communicate effectively, and have *tested* those techniques extensively.
> The prospective employee could, of course, choose to enter another
> professions, or start his own company. Or his services might be so
> valuable that he could have the NDA requirement waived. Nevertheless, it
> seems like the little guy who is coming right out of college and into an
> entry level position with a software firm in the United States is
> getting the shaft. Those other options are not attractive, or even
> possible.
question: where did that big company that demands the little guy sign
an NDA come from? . probably from some batch of little guys 15-50 years
ago who chose to take the risks of going out on their own.
your argument stopped being useful when you declared going it alone to
be an undesirable option. . the company with the NDA isn't restricting
the potential employee's freedom, the potential employee is doing that
for himself. . he wants the company to give him a comparatively
risk-free environment and a steady paycheck.
now, if you think about it, the NDA is one of the things the big company
uses to give him that risk-free environment. . what everyone else in this
thread seems to have forgotten is that companies aren't just anonymous
monsters with an endless capacity to absorb abuse. . they're collections
of people, working hard, and trying to be proud of what they do.
the NDA is a way of keeping one employee from fucking over everyone else
in the company. . if a leak kills a project, it's not just the company
that gets hurt, it's all those little guys who were honestly working
hard to build something they believed in.
without NDAs, every little guy in the company is the hostage of whatever
asshole decides his agenda is more important than anyone else's job.
1. the fact that Linux competes strongly against Windows, which ESR
himself describes with the words "shit on ice", doesn't automatically
mean that Linux is better than the Mac OS. . after all, the "shit on
ice" OS ate Apple's lunch because it had a huge market channel,
complements of Microsoft's early ally IBM.
Linux also has a huge market channel. . the whole point of open source
is to eliminate barriers between code and the people who want to use it.
. by those standards, it's hardly surprising that Linux has picked up
a good share of the market.
the fact that Linux is cutting into the Windows market share faster than
the Mac OS doesn't necessarily imply that Linux is better than the Mac
OS, it just says that Linux is less of a "shit on ice" OS than Windows.
when Linux starts eating *Apple's* market share, comparisons between the
two products will be valid.
2. competing Linux desktop standards aren't automatically a good thing.
portability has always been one of the great strengths of unix-based
operating systems. . a piece of code written for one platform can move
effortlessly to a wide range of other platforms. . Metcalfe's law says
that the value of the network increases with the square of its size, and
easy porting makes it easy to expand the unix network.
to the best of my knowledge, the Linux desktop systems aren't so
portable. . Gnome needs Gnome apps, KDE needs KDE apps, and so on. .
what this does is fragment the unix network, and run Metcalfe's Law in
reverse.
3. a single Linux desktop standard isn't automatically a good thing.
GUI programming is hard work. . creating a whole environment of mutually
compatible GUI apps is even more work. . learning the APIs that support
the GUI and make programs compatible with the general environment is a
long, slow process, and the older those APIs get, the longer and slower
it is.
meanwhile, one of the reasons that Linux is every programmer's friend is
that it's easy to code. . the command line is a *much* friendlier
programming environment, because you can just whack out some code and
go. . whenever an OS reaches the point that you have to spend three
weeks reading manuals just to get "hello, world." to run as a standalone
application, that effort curve drives programmers back to some other CLI
environment. . Windows programmers used the DOS shell, for instance,
instead of climbing onto the Windows treadmill.
a single desktop standard for Linux could, at least potentially, turn
into nothing more than an Open Source version of that same treadmill.
myself, i'm not sure whether the Linux development (and community) model
can handle the problems of GUI development at all. . i'm not trying to
slam anyone. . i just think there are some serious issues that need to
be addressed, and the anything-goes nature of the Linux model seems to
offer as many new problems as it does solutions.
thank you for posting a clear, technical, and non-gee-golly response to a solid technical question. . it's really good to see developers saying, "well, this can deifnitely use some work" when that is in fact the case.
> the sites took a gamble, based on the fact that almost nobody in the computer industry takes NDAs seriously.
preemptive correction, here..
what i *meant* was that hardware and software vendors tend to be fairly relaxed about NDA-encumbered information making it out into the trade press. . reporters who go to conventions sign NDAs at the door, then ignore them and write articles about what they saw. . that's technically a no-no, but the vendors tend to overlook it.
i did *not* mean 'nobody' in the broad sense. . by and large, technology companies are indeed highly anal about their IP agreements.
okay, IANAL, but i used to be senior internet geek for a publishing firm
that owned a couple of dozen daily newspapers, and my boss *was* a
lawyer.. one with a very good background in intellectual property.
that said, the idea that publishers should be free to publish anything
they get their hands on, regardlesss of how it was obtained, is simply
bullshit.
okay, inflammatory statement.. i apoligize to anyone i've upset. . i just wanted to put some emphasis behind my main point,
which is that the original poster's opinion is incorrect. . it's 'naieve', in the technical sense, in that it's based on an incomplete undersanding of the
publishing industry.
Apple's NDA doesn't cease to exist the instant
someone chooses to violate it. . the websites in question didn't break
the NDA themselves, but they *do* have a responsibility to steer clear
of publishing information that they think may have been obtained by
breaking an NDA.. or by violating someone's copyright, or by any
other means that put the information under the heading of 'legally encumbered'.
. that's the issue here. .
the question of whether the websites broke the NDA themselves is
irrelevant. . the pertinent question is whether they had reasonable
grounds to assume that the information given to them *had* been obtained
by breaking an NDA, and what they did about *that*.
i think we can all agree that anything related to Apple's internal development track is
probably under some kind of legal protection.. trade secret, NDA, copyright, whatever. . the things Apple wants to
make public come out through an identifiable PR channel. . given both of those facts, i personally
think it would be hard for any of the websites in question to prove they
had absolutely no reason to suspect that the information was legally
encumbered. . they'd have an even harder time with questions like, "if you couldn't find an official PR memo from
Apple, why didn't you contact them and ask?" . and . "did you run this information past legal before putting it online?"
the fact here is that the websites in question published information they had good reason to suspect was illegally obtained. . *that's*
what they're liable for, and that's the basis of Apple's action against
them. .
the sites took a gamble, based on the fact that almost nobody in the
computer industry takes NDAs seriously. . in this case, they ran up
against one of the 'almosts', and now they have to pay up.
it's not like Apple is nailing anyone for publishing actual *rumors*, here.. you know, the unsubstantiated speculation that doesn't come with screen shots from a developer preview CD. . the sites in question were basing their trade on the publication of protected information before it was marked for release by Apple's official PR pipeline. . that's not posting rumors, that's selling leaks. . that's illegal.
rumors are okay. . leaks aren't. . Apple is just reminding everyone where the
line between those two happens to fall, and that they *do* take their NDAs seriously.
> Icon based interfaces are crude and slow, the only reason for their > adoption is that 3 year olds can use them.
icon-based interfaces are designed on the theory that humans have been recognizing shapes and colors for longer than they've been a distinct species, while written language is something that popped up, biologically speaking, about thirty seconds ago. . this is very *old* news in the human-factors community. . every study on the books says that it's both faster and easier to pick out an icon with a distinct color and shape than it is to pick out a text string with specific qualities.
case in point.. time yourself, and count the number of images in the following list:
now translate the list into a set of icons on your computer, associating a specific color and shape with each file type, and do it again. . compare the results. . if you're working with a standard-issue nervous system, the latter will be at least twice as fast.
> We communicate through language and its time to communicate with > computers in our language.
no, we communicate through language when we're trying to convey a small quantity of information that's easy to serialize, and we use visual representations when we need some serious power. . describe the positional elevation of the Rocky Mountains at 100 meter resolution linguistically. . now try doing it in a way that's more efficient than a topo map.
take a look at Edward Tufte's excellent books on graphical communication for more info.
> We need to go in the other direction. "Open my wedding photos." > "Spell-check the latest draft of my current novel." "When did I > receive an e-mail from my publisher with 'foo' in the subject?"
this is a very good point. . the value of extending the human-computer interface is that it makes complicated things easier (or possible), not that it duplicates the existing interface for simple things.
the command-line interface is, broadly speaking, based on a fairly limited model of user behavior and environment. . it assumes the existence of a 'user' who owns a comparatively small number of 'files' (less than a few hundred per directory), and leaves the two big questions: "what's in this file?" and "where's the file that has X?" entirely up to the user. . yes, unix offers utilities like grep, which can do literal text searches, but there's still no good utility for non-literal meta-descriptions, like the ones you describe.
meanwhile, as drive capacity has grown, the assumptions behind the CLI have lost some of their validity. . most people's hard drives are a compost heap of badly-organized information, full of file trees they no longer remember creating. . we need, good, intuitive tools that help us organize tens of thousands of files, not the digital equivalent of half a dozen warehouses full of filing cabinets. . that probably means that we'll have to pass some of the work of organizing things off to background processes (agents), and definitely means that we need a more sophisticated interface for getting at things.
whether natural language has any part in that is still an open question, though.
as others have mentioned, the idea of trying to make a computer interface more like natural language has been tried before. . generally speaking, natural language interfaces have a long and respected history of failing to be the great killer app of human-computer interaction.
the big problem is that, in most cases, people don't really have problems with syntax. . the hard part of programming, or working with computers in general, is deciding what you want to say, not deciding how to say it. . sure, things like regular expressions look intimidating at first glance, but if they behave in a reliable, predictable manner, people tend to get used to them.
fully natural languages would be hideous interfaces, because by nature, they tend to be ambiguous and highly dependent on context. . communication between humans involves a healthy dose of hoping that your listener is working from the same set of basic assumptions you are, and the reliability of that assumption can be seen in the innumerable threads where two people argue endlessly about microscopically different interpretations of some word or phrase.. in most cases, ignoring the larger issues of the subject completely. . there's no reason to assume that machines will be able to read our minds better than other people will, and a fairly good reason to assume that, even if they could, no human would be able to write the code.
that's not to say interface languages *have* to look like line noise, though. . the Zork parser, again, mentioned by other people in this thread, is a good example of an unambiguous, structured language that still looks close enough to natural language that it's comfortable at first glance. . IMO, *that's* where the interesting work in human-computer interaction will be done.
the endless fascination with full natural language imposes a false standard on interface design, by saying that interfaces are either 'natural' or 'mechanical'. . the reality is that there's a sliding scale of values, ranging from completely formal and utterly terse to highly ambiguous and massively redundant. . the really successful breakthroughs in HCI, like the PalmPilot's Graffiti alphabet, try to find a point on that scale which is strict enough for a machine, but still loose enough to be comfortable for the average human.
in the long run, though, no interface will be able to compensate for ignorance and muddy thinking on the part of the person who's using it. . a circular dependency is a circular dependency, whether it's written in C or five pages of Command English (TM). . in my gut, i distrust natural-language-like interfaces, because they tend to be announced by hosts of marketers singing praises that boil down to, "go ahead and remain ignorant. . our interface will do all your thinking for you. . BTW, make sure to enter your credit card number promptly so it can decide what other software you want." . that's not a technology issue per se, but it *is* relevant to the interaction between humans and machines.
> Meaning you've never heard anyone on a Linux board like Slashdot > say that.
you're quite right, my remarks were focused on the Linux/Slashdot crowd.
of course, that simply begs the question as far as Open Source in general is concerned.. Open is Open, come one, come all.
there are plenty of people out there (some of whom can be found here on/.) whose attitude towards an Apple that completely opened its source would be something like "strip off the flesh, shit on the bones, and laugh at the way it all steams."
the nature of the Open Source movement allows those people catch some reflected glory from the really good ('egoless' -- _The Cathedral and the Bazaar_) developers, and lets the good developers get tarred with the brush the bad ones have made so foul.. sucks to be a good guy, i guess.
given the open hostility to Apple (or any commercial software company that doesn't make Quake), and the fact that the Linux community can't even be bothered to acknowledge the source of most of its bundled software [1], the probable loss to free riders is high enough that i'm not sure any reasonable amount of real assistance from the good developers would offset the probable damage from short-sighted, self-serving idiots.
([1] - the true measure of the GPL's success is embodied in the fact that several dozen megs of GNU code are collectively presented to the public as 'Linux'.. anyone care to bet what would be printed on the CDs if Stallman could threaten to rescind those rights somehow?)
that's one of the biggest problems the Open Source community has to address if it wants to make serious inroads with business. our ethic is based on granting responsible people as much freedom to work as possible, but fails to address the problem of dealing with people who aren't quite so virtuous. there's supposed to be a consensus of disapproval for those who behave badly, but that's really controlled by the whim of the masses.. and if we change the masses, we change the whim.
Apple's venture into Open Source poses a serious challenge to the community in general: what do we do when a plurality of the free riders think pillaging someone else's work is acceptable? how does the part of the community that thinks working is a Good Thing offset the shouting of the masses who just want more bread and bigger circuses?
personally, i favor an application of ESR's dictum "show me the code." i don't care what license you use, or how popular the product itself happens to be, if you want to criticize someone else's Open Source effort, you have to tell the world how much work you've contributed to the Bazzar yourself.
RMS has the right to criticize the APSL.. he's paid for it by releasing a huge amount of code under the GPL, and by taking the kicks in the teeth that went with it. i haven't.. i've put maybe 5KLOC of perl code into the general memepool so far, and that's nothing compared to Darwin. i doubt most of the people calling for Apple to hand over its GUI (and griping about the APSL) have even matched my pittance, under any license at all.
therefore, i reserve the right to ignore them completely. if they don't like that, they're welcome to show me some code.
that's supposed to be *R*MS.. and it really was a typo. i have the deepest respect for the work Mr. Stallman has done, and consider his stand on total freedom to be an important part of the ongoing debate about the accessibility of source code. i was not trying to stick my tongue out at him, there.
every time Apple does something that involves open source, someone always says, "now if they'll just open the GUI." to be honest, i'm not sure we deserve that.
now, that's a high-octane statement, so please give me a chance to put it in context before hauling out the flamethrowers..
according to the documents ESR has written, which are arguably the core of the Open Source manifesto, developers have a responsibility to the project from which the code comes. the coin of the Open Source realm is respect for the primary developers, and participation in the project for which the code was originally written.
now, i've never seen anyone say, "if Apple opened their GUI, i'd work to improve the Mac OS." it's always, "if Apple opened their GUI, we could port the good parts to Linux." that's not participation, and it's not respect. it's pillage.
that being the case, i'd suggest everyone take another look at _The Magic Cauldron_, section 6, where ESR discusses reasons to keep source closed:
"The real question is whether your gain from spreading the development load exceeds your loss due to increased competition from the free rider."
in the case of Apple opening the source to its GUI (and all its other crown jewels), i submit that the Linux community shows significantly more interest in causing Apple increased losses through competition than it does in helping spread the development load on Apple's own projects. until that changes, it seems to me that Apple's most rational choice is to keep the source for those projects closed.
if we want that code opened, we have to do more than sit around saying how deserving we are. we have to convince Apple that the community will give enough back to compensate for the inevitable jerks whose only response will be "thanks.. sucker! hey everybody, look what i've got!"
Apple took a lot of heat when they first opened Darwin because people (no less than PMS) considered it "a cynical attempt to leverage the community for free labor." i think there's a risk that people who want Apple to open the GUI and Quartz (and the Sorensen codec, for those of you who want a Linux QT player) may be doing the same thing in reverse. they're shouting 'Open Source' to cynically leverage free work out of private companies, with no intent to repay the original developers, even according to the standards of the Open Source community itself. they want easier competition, not a chance to participate.
i don't think the idea of Open Source can legitimately be used to force someone into a disadvantageous position. if we're not willing to put up a critical mass of developers who'll work to Apple's benefit, i don't think our own standards give us the right to demand more than we're getting.
> My point is that Apple is missing a fairly large market share... >the roll your own crowd.
that market isn't as attractive as you might think. it's composed largely of people who want to buy components on the cheap. the margins there are thin, and strongly susceptible to economies of scale. if you're not one of the really big fish in that market, or one of the hyerspecialized little fish, you're fish food. that's why we're unlikely ever to see a vertically integrated hardware/OS/software vendor in the x86 clone market.
Apple's marketing is strongly based on transparent hardware support and ease of use.. "it works, right out of the box", "this is the manual you get with a Mac", "there is no step three", etc. that requires tight synchronization between hardware and software, and the roll your own crowd could traditionally care less about that. they want to build what's cheap, not bow down before someone's list of officially approved hardware. the last thing Apple needs is to have its brand shot down by a proliferation of nightmare boxes built by people who don't give a damn about Apple specs.
besides, it costs like hell to support umpty-seven different permutations of hardware at all, let alone reliably. Microsoft has trouble doing it, and they're just a tad bigger than Apple is. you even hear occasional stories about Linux users not being able to get a certain hardware configuration to work, and we have a fairly decent amount of support, too.
so when you take the various factors into account.. loss of margins on the hardware side, negative branding from noncompliant hardware in the marketplace, and a geometric increase in the cost of support on the software side.. you'd have to buy a whole lot of Apple-produced software to offset what you'd cost them.
just between you, me, and the fencepost error, i don't think you were planning to spend more than a couple $K on software, were you?
Slashdot Mirror
Economists have this concept called friction. Basically, it's anything that gets in the way of exchanging goods and services, but the same general idea applies to information.
Email imposes less friction than snail mail.. you don't have to put the letter into the envelope, put a stamp on it, take it out to the mailbox, wait for the postman to come, etc, etc. Open Source imposes less friction than closed source.. you don't have to get involved with lawyers, licensing agreements, and all that sort of thing.
Today's Linux installations still have their share of friction. That doesn't make them evil or hopelessly flawed, but it does limit the rate at which people adopt them.
Individually, the sources of friction in Linux tend to be fairly small. Of course, so is a strand of hair. Put a whole bunch of strands together and the phrase 'wearing a hair shirt' starts to be relevant. Every inconsistency between tools that are otherwise similar (do I need 'make', 'gmake', or 'bmake' to compile this program.. oh, and what version?) is just one more source of friction that limits the spead of OSS.
Now.. I used to be a machinist, so I am deeply familiar with physical devices that are still in the process of being built. We start with a rough-cutting process where you remove 99% of the unwanted material quickly and efficiently, and get something that looks pretty much like the finished piece at a casual glance. But the entire thing is coated with burrs.. the machined surfaces are ridged like tiny files and the edges are miniature saws. That's why we go back and do a second, slow and gentle cut to take off that last tenth of a millimeter. And if you happen to be doing precision work, there are lapping, polishing, and wearing-in phases.. each of which takes longer than the one before.. which can make the phrase 'mirror smooth' seem very unimpressive indeed.
My point is that I see Linux at the 99% point. That's good, but it doesn't mean "we're almost there." It means we have enough big things out of the way that now it's important to spend a whole lot of time and effort getting that last tedious-and-unexciting 1% right.
The things that stand in our way are the "it's good enough" mindset, and the tendency for developers to make up their own standards as they go. Almost all command-line utilities accept '-x' options.. but not all of them. We still have things like 'dd if=some-file of=target'. Some commands use '-x argument' while others use '-xargument'. Some allow option stacking, like 'command -xyz', while others require 'command -x -y -z'. And then there are the '--extended' options.
And that's only the command line. Would you be prepared to bet $100 that all your manpages are in perfect synch with the actual binaries? Can you find the default httpd.conf file under Slackware, Debian, RedHat, FreeBSD and NetBSD? And you'll find similar kinds of roughness all the way up to the desktop.
None of these problems are huge, and none of them are particularly difficult to solve individually. Cleaning them all up would be a huge effort, though, especially when you think about having to polish all the scripts and utilities that rely on the currently-1%-rough standards.
The big question is whether anyone will have the determination to do all the tedious, unrewarding work necessary to bring Linux/OSS up to the next plateau of reduced friction. There's no technical barrier in the way, just a huge gumption barrier.
But I'll make this prediction: If someone does create their own low-friction distro, and the conventions they choose become the new standard, in five years the people who are currently saying Linux/OSS is good enough right now will point back and say what a mess the 'old ways' were.
Okay.. based on your comments, I'm going to assume you haven't studied law.
It isn't an either/or deal. Let me explain:
Law is about protecting people's rights (and for the sake of legal discussions, corporations like Apple count as 'people'). In general, the law says someone can use their rights as much as they want as long as they don't interfere with someone else's rights in the process. To put that another way, anything that stops a person from using their rights as much as they want, as long as they don't mess with anyone else's rights in the process, might be illegal.
A contract is a deal where people agree to exchange some of their rights, or to limit their freedom to use their rights. An exchange contract would be one where you buy something from me: I give up my 'ownership' of the object in exchange for 'ownership' of the money, and you give up your 'ownership' of the money in exchange for 'ownership' of the object. A limitation contract would be something like an NDA: I agree to let you see my trade-secret information.. which I don't have to do otherwise.. and you agree to limit right to talk to people, specifically by agreeing not to tell anyone what I've shown you.
If one of the people who entered a contract fails to live up to their end of the deal, that's called breach of contract. Breach of contract is a civil matter, because while the person who broke their promise hasn't lived up to the terms of the contract, they haven't broken any actual laws.
Laws are rules that the government makes. They define the rights the government thinks people have, and they explain how people can use their rights without screwing up anyone else's rights. Laws are not some kind of contract, though. They apply to you whether you agree to them or not. When you do something a law says you shouldn't do, you aren't breaking a promise you've made to anyone, you're just doing what the government says you shouldn't. That's called a criminal matter.
Now.. it's entirely possible to break a contract (a civil violation) in a ways that also breaks some kind of law (a criminal violation). When that happens, the person you lied to can sue you for civil damages, and then the government can hit you with criminal penalties.
In such a case, it's entirely legal for the person bringing the civil suit to have their case heard first, and for the government to wait until after the civil suit has been decided before coming after you with criminal charges. In essence, the government is willing to sit back and let the civil plaintiff dig up all the evidence and present that to the court in a civil lawsuit, because the government can then refer back to that evidence during the criminal trial.
Well, here's how it works:
One of the most basic principles of law is that you can't take someone's rights away without giving them something in return. A contract is only legal if it involves an exchange of what's called consideration. 'Consideration' means either I give you my rights entirely (like when I sell you something), or I agree to put limits on the way I use my rights (like in an NDA).
Breach of contract basically 'rewinds' our rights to where they were before we made the contract. If I agree to buy something from you but don't give you the money, I can't say that you've given up your property rights to the thing I haven't paid for. We just go back t
I appreciate the fact that you've taken the time to restate your opinion in calmer terms, but I still disagree with you for several reasons:
Apple doesn't owe the Linux/Open Source community any more goodwill, thanks, or acknowledgement than the Linux/Open Source community has shown to the GNU project. You know.. the people who created the compiler and development tools that make source distribution of software possible. The folks who wrote all the userland applications that made Linux a full-scale operating system and not just some college student's personal attempt at writing a unix-like kernel. The ones whose projects and goals don't get mindshare because the Linux/Open Source community can't be bothered to say 'GNU/Linux'.
Oh, do some members of the Linux/Open Source community roll their work back into specific GNU projects, and does that count as 'paying our dues'? Well.. that's what Apple is doing.
Porting iTunes to Linux/FreeBSD wouldn't earn Apple shit for respect from the Linux/Open Source community, it would only modulate the bitching to a different key. Instead of people saying:
we'd have people saying:
Rants like that are superficially similar to RMS's arguments about the disadvantages of non-free software, but they don't have RMS's eloquence, restraint, or broader philosophical justification. They create a smokescreen that lets Bill Gates equate RMS with any dozen greed-driven fuckwits he can pull out of the latest Slashdot postings when he wants to make business and government leaders all over the world think that Open Source == Free Software == communism == the death of intellectual property.
That's how the Linux/Open source community demonstrates its goodwill, thanks, and acknowledgement for everything RMS and the GNU project have given us.
A port wouldn't serve everyone, so we'd still have people bitching that Apple hasn't supported the POS box they built out of parts they scavenged from a dumpster with their own three hands.
Porting iTunes to Linux/*BSD would take a hell of a lot of work. It's a GUI application, so what environment do you want them to use? Gnome? KDE? Enlightenment? plain-old-X with toolkit X, Y, or Z? iTunes is most likely written in Objective-C against the OpenStep framework, with Quicktime for an audio layer, and Aqua nib files for interface specification and invocation. Where will they find support for those in Linux/*BSD without porting the whole lot? Then how will they keep the ports in synch with every OS/GUI/toolset/harware configuration unless they open the source for everything?
Opening the source of iTunes would be very bad for Apple, because the iTMS owes less to code and computer technology than it does to the years of work Apple has invested in developing a working relationship with the DRM-obsessed
Have you noticed that, althought Apple's own operating system owes a lot to the open source movement, and the thousands of developers whose code they use for free, you and I still cannot run iTunes on our Linux desktop to sync an iPod? No money in it for them...
I've written this before, but haven't refreshed it for a while, so here goes: That kind of attitude is the direct opposite of the Open Source mindset. You're making the classic mistake of failing to distinguish between "sharing-as-giving-things-to-other-people" and "sharing-as-taking-things-from-other-people".
Open Source is a development philosophy that makes it easy for people to roll their own work back into the original project. It is not a crowbar to pry somebody else's work away from them, and every person who pumps crap like this into the air just proves Bill Gates right when he calls Open Source anticommercial, anti-property, communist, and any other nasty names he can think of.
NOTHING in any part of the Open Source manifesto says being part of one open project means you're obliged to open everything else you've ever made. Not even the GPL requires that. RMS personally feels that the world would be a better place if all distributed software happened to come with source code that any end user was free to use and modify, but even he tries to state that opinion in reasonably moderate terms.
If you want to know the Open Source attitude about when to open a project, try reading section 10 of The Magic Cauldron, specifically the case study of when it made sense to open Doom.
Whether you like it or not, it does make sense to keep some projects closed until the market matures enough for the benefits of opening the source to pay off. It took four years for that to happen with Doom, and let's face it, the gaming industry moves pretty fast, even for software. The bloom was pretty much off the rose by then.
iTunes/iTMS and the iPod are currently in a state where the benefits of staying closed still outweight the benefits of being open. They don't suffer significant reliability or scalability problems, they don't require independent peer review the way cryptosystems do, they don't create a significant communications infrastructure (though podcasting does create a comms network at the application layer), and they don't rely on standardized key methods at the software level. They have no meaningful competition, they're picking up market like hell, and the untapped market of Windows users and non-computer users is vastly larger than the "I refuse to participate unless I can do it on Linux" market.
In Open Source, 'paying your dues' means giving your modifications back to the original project. Period. Apple does that. And there's fairly good reason to assume that the Linux community would spend a metric fuckload more time and effort porting Apple's crown jewels over to Linux than 'paying its dues' if Apple were crazy enough to open those projects.
If the Open Source community wants business to take it seriously, it has to be deadly serious about adding value to the original project, not pillaging everyone else's technology in the name of Improving Linux like the anti-property assholes Bill Gates wants us to be.
Please.. if you're going to insult me, at least have the courtesy to use an actual name.
It might also help to know something about the subject before playing the PBH "anything I don't understand must be a buzzword" card. If you can cite a reference about entropy that says I'm wrong, fire away.
And the fence who buys stolen property isn't guilty of breaking and entering. He is guilty of receiving stolen property, though, and that also happens to be illegal.
The bloggers may not have agreeed to the NDA, but their sources did. By sharing trade secrets with the bloggers, the sources violated their NDAs. That's a clear breach of contract on the source's part, and in some places the act of breaking a legally binding NDA is also recognized as a criminal action.
By accepting and publishing the information the sources provided, the bloggers failed to perform due diligence in making sure the stuff they posted was actually clean. And unless you can some up with a really compelling argument to show how people who publish rumors about unreleased products can't possibly be expected to consider the chance they might end up getting something covered by an NDA, I'm personally going to call that a stupid oversight.
Now.. Apple's legal department would like to have a little chat with the sources who gave ThinkSecret the information.. you know, the people who did agree to the NDA and did violate said NDA by passing the information to ThinkSecret. Accordingly, Apple's nazgul asked ThinkSecret to identify the sources. ThinkSecret said no, on the not-terribly-convincing assumption that they could claim journalistic privilege.
The current article indicates that the judge didn't find ThinkSecret's argument compelling.
The clustering illusion demonstrates the universal principle of entropy. No matter what random collection of objects you look at, the most common distribution will not be the most evenly dispersed one, but the most evenly dispersed disorganized one.
If we randomly distribute the integers from 1 to 100, it's going to look pretty strange if the first 50 are all even, and the second 50 are all odd. So will a distribution where all the primes come first, or any other detectable order. Entropy acts as a sort of 'inflating' principle which makes less-smoothly-dispersed collections more common than more-smoothly-dispersed ones.
Clustering is inevitable, especially when you take small selections from a large, frequently reshuffled population. In this case, we're talking about a situation equivalent to shuffling the numbers from 1 to 100 and taking the first 10, then shuffling again and taking another 10, etc. If we were to do that 10 times, and found that we'd collected exactly one copy of every value from 1 to 100, that would be very unlikely. If it happened consistently, something would be very wrong with our RNG.
how the heck is a site like this going to be indexed on search engines?
/. reader who clicked on the link to sit through a 20-second Flash ad, do you think this story would have been posted? . can you imagine the torrent of complaints that would rain down if such a link had been posted without a warning?
interstitial ads more or less destroy the one thing that makes the web valuable: the ability to link documents together. . the fundamental, underlying concept of the URL is "hey, here's some information.. come and get it." . not only does putting barriers between users and the information they want raise technical problems, but it *really* screws with your ability to make information globally visible.
the kind of interstitial system this author suggests just doesn't synch up with the basic technology of the web. . the web is stateless, so it doesn't know which pages you've already seen. . that means you have three basic options when it comes to the delivery system:
1 - you make the home page of the site an 'entry tunnel', and leave all your actual content on regular webpages, which leaves users free to circumvent your entry tunnel if they can find any other index that links to the content.
2 - you can hide every single page in the site behind some kind of cookie-based 'has this user viewed enough interstitial advertising?' system, and dump a 20-second Flash ad on any page request that doesn't qualify. . and that would turn into an endless loop for users who don't honor cookies.. the page request prompts a redirect to the Flash ad because there's no cookie, then the Flash ad fails to set a cookie and triggers another request for the original page.. which fails because there's no cookie, so you get another Flash ad, ad nauseam.
3 - you can do your whole site in Flash, which makes any content inside your site inaccessible to anyone who doesn't sit through their daily force-feeding of advertising.
search engines will ignore any site that uses option 2 or 3, and will bypass the entry tunnel of any site that uses option 1. . and since search engines are still the single largest source of new eyes for any website, screwing the search engines means screwing any hope of building or expanding a user base.
using a system like that would be actively hostile to linking from outside, because it amounts to the putting the message "click here for a royal waste of your time" on any site that *does* link to your content. . face it.. if it had been impossible to reach the article in question without forcing every
the whole article could be summed up as, "the web makes it *way* to easy for people to get information, and i can't compete with that using my current business model. . but i'm either too stupid or too cowardly to try searching for a new business model, so i want to make the web just as invonvenient and user-UNfriendly as the media i already understand."
feh.
before everyone dives into the argument that Apple lost its look-and-feel lawsuit against Microsoft, let's stop to be clear about what the court's decision actually said.
c ro scope.htm
there's a very good analysis of the decision at:
http://www.fenwick.com/pub/apple_v_microsoft_mi
and the gist of it boils down like so:
the court decided that intellectual property regarding user interfaces falls into two broad categories: 'protected' elements, and 'non-protected' elements. the term 'non-protected' is a bit misleading, because it doesn't mean 'up for grabs', it just means that elements in that category don't enjoy the *full* protection of copyright.
the court also held that GUIs have to be examined in two contexts: as a collection of widgets, and as an 'assembled' whole.
the conditions for infringement are different for 'protected' and 'non-protected' elements:
- copies of 'protected' elements are illegal if they are 'substantially similar' to the original.
- copies of 'non-protected' elements are only illegal if they're 'virtually identical' to the original.
to decide whether a GUI clone in illegal, you start by breaking the original and the copy into dictionaries of widgets. if we assume that all the standard widgets are non-protected, only widgets that are 'virtually identical to' the Aqua equivalent will be infringing.
even if none of the individual widgets are found to be infringing, though, the whole GUI has to be compared to Aqua to see if the assembly is 'substantially similar' to Aqua. the importatnt point here is that the assembly as a whole can still fall in the 'protected' category, even though the elements that make it up are individually 'non-protected'.
so let's look at the Aqua clones using the test from the lawsuit Apple lost:
break out the widgets and compare them to the Aqua originals. could a normal person tell the original from the copy without resorting to special machinery, like checking the *exact* hex values of the RGB colors? any widget that fails is probably an illegal infringement.
then, even if all the widgets are sufficiently different from the originals that they're non-infringing, is the way they're assembled 'substantially similar' to Aqua? if so, the theme as a whole is still an infringing product, even if the individual widgets aren't.
face it.. the people making Aqua themes are trying to get the best copies they can. they're *trying* to make the widgets 'virtually identical' to the originals, and they're *trying* to make the overall assembly 'substantially similar' to Aqua. that's against the law, as stated by the very look-and-feel case that Apple *lost*.
the original article has its points, but the author is really rejecting the culture of hype which has admittedly grown up around OOP, without really tracing it down to its theoretical roots.
the thing that makes programming hard is that you have to try and reduce a set of ideas in the human mind to a set of operations that can be performed in a Turing-complete computational environment.
that's not easy, because most people don't think in a computationally disciplined manner. . those who did presumably got flattened on my mastodons a few zillion years ago when they experienced the caveman equivalent to a BSOD.
therefore one of the things languages and programming styles do is give programmers ways to keep track of the larger-order logical machinery of their code. . the better a language is at making that logical machinery manageable, the more useful it can be.
structured programming isn't just the programmer's version of brussel's sprouts.. something you have to put up with because people say that it's good for you.. it makes finite automata and pushdown automata immediately visible in your code. . at least, it makes them visible if you know where to look.
here's the trick: every function is a state machine, usually following the pattern:
(acquire data) --> (verify data) --> (calculate new value from data)
with conditionals being there to handle internal branching, like reporting an error when the verification step fails, instead of doing the calculation.
and since each function has its own private scope for data storage, each function can act as a self-contained section of data storage.
when you chain finite automata together, such that one passes a value to the next one, and receives a value in return, you get a pushdown automaton. . therefore, structured programming is really just the art of reducing problems to computational methods that are easily expressed as pushdown automata, and represented as code in which functions with isolated scope pass parameters and return values back and forth.
and that's lovely, but it's not powerful enough to be useful.
pushdown automata have their limits, and there are some problems you just need to handle with a Turing machine.. binary multiplication, for one.
to get around the inherent limits of purely isolated function scopes and parameter/return passing, structured programming languages also support global variables, which make data accessible to any scope, regardless of its connection to the call-return chain of the pushdown automaton.
and that makes structured programming powerful, but it opens up room for all sorts of messes. . the global values that link sections of the program together are harder to keep track of than the calling heirarchy of a structured program, so structured programming isn't quite the best tool for making the logic that holds a program together visible. . then there's the little fact that with two integer counters and a bit of determination, you can implement a fully-functional Turing machine that's all but invisible within the code. . most people don't do that per se, but if you store enough important information in global variables, it becomes difficult *not* to evolve a Turing machine to manage it. . and that Turing machine evolves in a million little corners of the program, none of which seem to have any obvious connection to each other.
OOP makes Turing machines visible, because it gives us the concept of an isolated scope which is larger than a single function, but smaller than the entire program. . other languages have done the same thing.. C's file-scope restrictions, for example.. but OOP is the system that actually puts a name on it and makes it easy to see.
the data structure which forms the visible instantiation of an object can be seen as the tape of a simple Turing machine. . the object's methods manipulate values on that tape, but only those methods have access to that tape. . the rest of the program only communicates with the object (Turing machine) through an i/o interface that doesn't affect the data stored on the tape.
an object-oriented program is a network of Turing machines.
can you fuck that up royally? sure.
can you write well-organized code with other tools? of course.
is one style of programming inherently better than another? hell no.
the reason to care about OOP is that it's convenient.. that's all. . it gives us a nice framework in which to arrange important ideas, so we can get on with the real work of reducing human assumptions to computationally effective logic.
and that's why programmers need to know.. as in 'grok in fullness'.. as many different styles of programming as they get cram in their heads. . each one gives us a convenient way to talk about some other set of important -- and *useful* -- ideas.
forget the physical explanations.. Santa is a macroscopic quantum event.
Santa is the observational manifestation of the Christmas spirit, and all the stockings by the chimney and presents under the tree are really just Schrodinger boxes that contain the superimposed waveforms of both a gift and a lump of coal. . that waveform collapses as soon as you look in the box, and since everyone knows in their heart whether they've been naughty or nice, the fact that you're expecting a particular outcome determines what the contents will be.
this model is strengthened by the fact that Santa takes advantage of the time constraints of a relative universe:
Santa can appear in any number of living rooms at precisely the stroke of midnight, because in a relative universe, you can't prove that the stroke of midnight happens in any two houses at exactly the same time. . each house represents an isolated frame of reference whose time scale can only be measured relative to any other frame of reference, so being able to see Santa in your own living room means that you are fundamentally unable to prove that he was anywhere else at exactly the same time.
any connection between two frames of reference that contain Santa is subject to (at minimum) speed-of-light constraints (or more likely, putting-on-slippers- and-a-coat-and-running-next-door- yelling-hey-guess-what-i-saw- whoa-how-did-YOU- get-here constraints), so if either you or the information can get from one frame of reference to another, Santa can get there, too.
the model is further strengthened by the fact that Santa exhibits uncertainty effects:
you might be looking at Santa, or you might just be looking at some guy in a red suit. . the real Santa is simply the locus of minimal uncertainty (or maximal belief) that you honestly are looking at Santa. . the effect can be demonstrated with a simple thought-experiment:
assume that you're walking down a street that has one Santa on each corner. . the position of the real Santa travels along with your point of observation.
when you're right next to the first Santa, you can be highly confident (assuming you're an optimist) that this one really is Santa. . the one at the other corner is too far away to observe, so the locus of maximal belief occurs at the Santa closest to you.
as you walk down the street toward the next Santa, you lose certainty that the one you just left is still the real Santa, and gain certainty that the one you're approaching is the real Santa. . at the point precisely half way between the two Santas, the locus of maximal belief is equally distributed between both. . thus, as far as you can prove from that position, either one *could* be Santa, and that's all you can say.
as you continue to walk toward the second Santa, you become more confident that this really is the one, until you arrive at the same position as this new Santa, only to discover that this is the real one, too.
the model works just as well for a skeptic, except that the real Santa is always the one on the *other* corner.
> The military, on the other hand, gets crazy with spending.
that's its job. . the military is in the business of preventing disasters, and that kind of operation is inherently wasteful. . you don't measure the cost of what you're spending against the returns you get, you measure the cost of what you're spending against what you'd lose if there *was* a disaster.
that's tough, because if you're doing things right, the disasters never actually happen.
geeks do exactly the same thing when they design networks to handle peak loads, eliminate single points of failure, and all the rest. . all the PHBs see is a pile of expensive and complicated technology that -- in their opinion -- could be replaced by a single computer with a cable modem. . the difference is that one will fall over and emit smoke if it gets Slashdotted, and the other one won't.
but the PHBs don't care.
until the network gets Slashdotted. . then they want everything fixed *now*.
making a profit means using your resources right up to the limits of their capacity. . preventing disasters means making sure you don't run out of anything too soon. . when it comes to fighting wars, the guy who has one bullet left over when everyone else has run out -- wins.
of course, if he has *two* bullets left over, you can bet that someone will call the second one an "unnecessary surplus".
it doesn't matter what your biases are one way or another, anyone who takes a serious look at the military's educational materials will have to admit that they've spent one hell of a lot of time and money finding ways to communicate effectively, and have *tested* those techniques extensively.
> The prospective employee could, of course, choose to enter another
> professions, or start his own company. Or his services might be so
> valuable that he could have the NDA requirement waived. Nevertheless, it
> seems like the little guy who is coming right out of college and into an
> entry level position with a software firm in the United States is
> getting the shaft. Those other options are not attractive, or even
> possible.
question: where did that big company that demands the little guy sign an NDA come from? . probably from some batch of little guys 15-50 years ago who chose to take the risks of going out on their own.
your argument stopped being useful when you declared going it alone to be an undesirable option. . the company with the NDA isn't restricting the potential employee's freedom, the potential employee is doing that for himself. . he wants the company to give him a comparatively risk-free environment and a steady paycheck.
now, if you think about it, the NDA is one of the things the big company uses to give him that risk-free environment. . what everyone else in this thread seems to have forgotten is that companies aren't just anonymous monsters with an endless capacity to absorb abuse. . they're collections of people, working hard, and trying to be proud of what they do.
the NDA is a way of keeping one employee from fucking over everyone else in the company. . if a leak kills a project, it's not just the company that gets hurt, it's all those little guys who were honestly working hard to build something they believed in.
without NDAs, every little guy in the company is the hostage of whatever asshole decides his agenda is more important than anyone else's job.
1. the fact that Linux competes strongly against Windows, which ESR himself describes with the words "shit on ice", doesn't automatically mean that Linux is better than the Mac OS. . after all, the "shit on ice" OS ate Apple's lunch because it had a huge market channel, complements of Microsoft's early ally IBM.
Linux also has a huge market channel. . the whole point of open source is to eliminate barriers between code and the people who want to use it. . by those standards, it's hardly surprising that Linux has picked up a good share of the market.
the fact that Linux is cutting into the Windows market share faster than the Mac OS doesn't necessarily imply that Linux is better than the Mac OS, it just says that Linux is less of a "shit on ice" OS than Windows. when Linux starts eating *Apple's* market share, comparisons between the two products will be valid.
2. competing Linux desktop standards aren't automatically a good thing.
portability has always been one of the great strengths of unix-based operating systems. . a piece of code written for one platform can move effortlessly to a wide range of other platforms. . Metcalfe's law says that the value of the network increases with the square of its size, and easy porting makes it easy to expand the unix network.
to the best of my knowledge, the Linux desktop systems aren't so portable. . Gnome needs Gnome apps, KDE needs KDE apps, and so on. . what this does is fragment the unix network, and run Metcalfe's Law in reverse.
3. a single Linux desktop standard isn't automatically a good thing.
GUI programming is hard work. . creating a whole environment of mutually compatible GUI apps is even more work. . learning the APIs that support the GUI and make programs compatible with the general environment is a long, slow process, and the older those APIs get, the longer and slower it is.
meanwhile, one of the reasons that Linux is every programmer's friend is that it's easy to code. . the command line is a *much* friendlier programming environment, because you can just whack out some code and go. . whenever an OS reaches the point that you have to spend three weeks reading manuals just to get "hello, world." to run as a standalone application, that effort curve drives programmers back to some other CLI environment. . Windows programmers used the DOS shell, for instance, instead of climbing onto the Windows treadmill.
a single desktop standard for Linux could, at least potentially, turn into nothing more than an Open Source version of that same treadmill.
myself, i'm not sure whether the Linux development (and community) model can handle the problems of GUI development at all. . i'm not trying to slam anyone. . i just think there are some serious issues that need to be addressed, and the anything-goes nature of the Linux model seems to offer as many new problems as it does solutions.
thank you for posting a clear, technical, and non-gee-golly response to a solid technical question. . it's really good to see developers saying, "well, this can deifnitely use some work" when that is in fact the case.
preemptive correction, here..
what i *meant* was that hardware and software vendors tend to be fairly relaxed about NDA-encumbered information making it out into the trade press. . reporters who go to conventions sign NDAs at the door, then ignore them and write articles about what they saw. . that's technically a no-no, but the vendors tend to overlook it.
i did *not* mean 'nobody' in the broad sense. . by and large, technology companies are indeed highly anal about their IP agreements.
okay, IANAL, but i used to be senior internet geek for a publishing firm that owned a couple of dozen daily newspapers, and my boss *was* a lawyer.. one with a very good background in intellectual property.
that said, the idea that publishers should be free to publish anything they get their hands on, regardlesss of how it was obtained, is simply bullshit.
okay, inflammatory statement.. i apoligize to anyone i've upset. . i just wanted to put some emphasis behind my main point, which is that the original poster's opinion is incorrect. . it's 'naieve', in the technical sense, in that it's based on an incomplete undersanding of the publishing industry.
Apple's NDA doesn't cease to exist the instant someone chooses to violate it. . the websites in question didn't break the NDA themselves, but they *do* have a responsibility to steer clear of publishing information that they think may have been obtained by breaking an NDA.. or by violating someone's copyright, or by any other means that put the information under the heading of 'legally encumbered'. . that's the issue here. . the question of whether the websites broke the NDA themselves is irrelevant. . the pertinent question is whether they had reasonable grounds to assume that the information given to them *had* been obtained by breaking an NDA, and what they did about *that*.
i think we can all agree that anything related to Apple's internal development track is probably under some kind of legal protection.. trade secret, NDA, copyright, whatever. . the things Apple wants to make public come out through an identifiable PR channel. . given both of those facts, i personally think it would be hard for any of the websites in question to prove they had absolutely no reason to suspect that the information was legally encumbered. . they'd have an even harder time with questions like, "if you couldn't find an official PR memo from Apple, why didn't you contact them and ask?" . and . "did you run this information past legal before putting it online?"
the fact here is that the websites in question published information they had good reason to suspect was illegally obtained. . *that's* what they're liable for, and that's the basis of Apple's action against them. . the sites took a gamble, based on the fact that almost nobody in the computer industry takes NDAs seriously. . in this case, they ran up against one of the 'almosts', and now they have to pay up.
it's not like Apple is nailing anyone for publishing actual *rumors*, here.. you know, the unsubstantiated speculation that doesn't come with screen shots from a developer preview CD. . the sites in question were basing their trade on the publication of protected information before it was marked for release by Apple's official PR pipeline. . that's not posting rumors, that's selling leaks. . that's illegal.
rumors are okay. . leaks aren't. . Apple is just reminding everyone where the line between those two happens to fall, and that they *do* take their NDAs seriously.
> Icon based interfaces are crude and slow, the only reason for their
> adoption is that 3 year olds can use them.
icon-based interfaces are designed on the theory that humans have been recognizing shapes and colors for longer than they've been a distinct species, while written language is something that popped up, biologically speaking, about thirty seconds ago. . this is very *old* news in the human-factors community. . every study on the books says that it's both faster and easier to pick out an icon with a distinct color and shape than it is to pick out a text string with specific qualities.
case in point.. time yourself, and count the number of images in the following list:
ball.gif bar.gif box.gif calendar cap.gif cgi1.shtml cgi2.html cgi3.shtml clients.html count count1 demo imap.html imap.map includes.shtml interactive.html last_min.old line.gif logo.gif me.jpg nntp1.html old.tar.gz phone.html pipe.shtml price.html smlogo.gif speil.html storage.html tchotchkes.html threads
now translate the list into a set of icons on your computer, associating a specific color and shape with each file type, and do it again. . compare the results. . if you're working with a standard-issue nervous system, the latter will be at least twice as fast.
> We communicate through language and its time to communicate with
> computers in our language.
no, we communicate through language when we're trying to convey a small quantity of information that's easy to serialize, and we use visual representations when we need some serious power. . describe the positional elevation of the Rocky Mountains at 100 meter resolution linguistically. . now try doing it in a way that's more efficient than a topo map.
take a look at Edward Tufte's excellent books on graphical communication for more info.
> We need to go in the other direction. "Open my wedding photos."
> "Spell-check the latest draft of my current novel." "When did I
> receive an e-mail from my publisher with 'foo' in the subject?"
this is a very good point. . the value of extending the human-computer interface is that it makes complicated things easier (or possible), not that it duplicates the existing interface for simple things.
the command-line interface is, broadly speaking, based on a fairly limited model of user behavior and environment. . it assumes the existence of a 'user' who owns a comparatively small number of 'files' (less than a few hundred per directory), and leaves the two big questions: "what's in this file?" and "where's the file that has X?" entirely up to the user. . yes, unix offers utilities like grep, which can do literal text searches, but there's still no good utility for non-literal meta-descriptions, like the ones you describe.
meanwhile, as drive capacity has grown, the assumptions behind the CLI have lost some of their validity. . most people's hard drives are a compost heap of badly-organized information, full of file trees they no longer remember creating. . we need, good, intuitive tools that help us organize tens of thousands of files, not the digital equivalent of half a dozen warehouses full of filing cabinets. . that probably means that we'll have to pass some of the work of organizing things off to background processes (agents), and definitely means that we need a more sophisticated interface for getting at things.
whether natural language has any part in that is still an open question, though.
as others have mentioned, the idea of trying to make a computer interface more like natural language has been tried before. . generally speaking, natural language interfaces have a long and respected history of failing to be the great killer app of human-computer interaction.
the big problem is that, in most cases, people don't really have problems with syntax. . the hard part of programming, or working with computers in general, is deciding what you want to say, not deciding how to say it. . sure, things like regular expressions look intimidating at first glance, but if they behave in a reliable, predictable manner, people tend to get used to them.
fully natural languages would be hideous interfaces, because by nature, they tend to be ambiguous and highly dependent on context. . communication between humans involves a healthy dose of hoping that your listener is working from the same set of basic assumptions you are, and the reliability of that assumption can be seen in the innumerable threads where two people argue endlessly about microscopically different interpretations of some word or phrase.. in most cases, ignoring the larger issues of the subject completely. . there's no reason to assume that machines will be able to read our minds better than other people will, and a fairly good reason to assume that, even if they could, no human would be able to write the code.
that's not to say interface languages *have* to look like line noise, though. . the Zork parser, again, mentioned by other people in this thread, is a good example of an unambiguous, structured language that still looks close enough to natural language that it's comfortable at first glance. . IMO, *that's* where the interesting work in human-computer interaction will be done.
the endless fascination with full natural language imposes a false standard on interface design, by saying that interfaces are either 'natural' or 'mechanical'. . the reality is that there's a sliding scale of values, ranging from completely formal and utterly terse to highly ambiguous and massively redundant. . the really successful breakthroughs in HCI, like the PalmPilot's Graffiti alphabet, try to find a point on that scale which is strict enough for a machine, but still loose enough to be comfortable for the average human.
in the long run, though, no interface will be able to compensate for ignorance and muddy thinking on the part of the person who's using it. . a circular dependency is a circular dependency, whether it's written in C or five pages of Command English (TM). . in my gut, i distrust natural-language-like interfaces, because they tend to be announced by hosts of marketers singing praises that boil down to, "go ahead and remain ignorant. . our interface will do all your thinking for you. . BTW, make sure to enter your credit card number promptly so it can decide what other software you want." . that's not a technology issue per se, but it *is* relevant to the interaction between humans and machines.
> say that.
you're quite right, my remarks were focused on the Linux/Slashdot crowd.
of course, that simply begs the question as far as Open Source in general is concerned.. Open is Open, come one, come all.
there are plenty of people out there (some of whom can be found here on /.) whose attitude towards an Apple that completely opened its source would be something like "strip off the flesh, shit on the bones, and laugh at the way it all steams."
the nature of the Open Source movement allows those people catch some reflected glory from the really good ('egoless' -- _The Cathedral and the Bazaar_) developers, and lets the good developers get tarred with the brush the bad ones have made so foul.. sucks to be a good guy, i guess.
given the open hostility to Apple (or any commercial software company that doesn't make Quake), and the fact that the Linux community can't even be bothered to acknowledge the source of most of its bundled software [1], the probable loss to free riders is high enough that i'm not sure any reasonable amount of real assistance from the good developers would offset the probable damage from short-sighted, self-serving idiots.
([1] - the true measure of the GPL's success is embodied in the fact that several dozen megs of GNU code are collectively presented to the public as 'Linux'.. anyone care to bet what would be printed on the CDs if Stallman could threaten to rescind those rights somehow?)
that's one of the biggest problems the Open Source community has to address if it wants to make serious inroads with business. our ethic is based on granting responsible people as much freedom to work as possible, but fails to address the problem of dealing with people who aren't quite so virtuous. there's supposed to be a consensus of disapproval for those who behave badly, but that's really controlled by the whim of the masses.. and if we change the masses, we change the whim.
Apple's venture into Open Source poses a serious challenge to the community in general: what do we do when a plurality of the free riders think pillaging someone else's work is acceptable? how does the part of the community that thinks working is a Good Thing offset the shouting of the masses who just want more bread and bigger circuses?
personally, i favor an application of ESR's dictum "show me the code." i don't care what license you use, or how popular the product itself happens to be, if you want to criticize someone else's Open Source effort, you have to tell the world how much work you've contributed to the Bazzar yourself.
RMS has the right to criticize the APSL.. he's paid for it by releasing a huge amount of code under the GPL, and by taking the kicks in the teeth that went with it. i haven't.. i've put maybe 5KLOC of perl code into the general memepool so far, and that's nothing compared to Darwin. i doubt most of the people calling for Apple to hand over its GUI (and griping about the APSL) have even matched my pittance, under any license at all.
therefore, i reserve the right to ignore them completely. if they don't like that, they're welcome to show me some code.
that's supposed to be *R*MS.. and it really was a typo. i have the deepest respect for the work Mr. Stallman has done, and consider his stand on total freedom to be an important part of the ongoing debate about the accessibility of source code. i was not trying to stick my tongue out at him, there.
now, that's a high-octane statement, so please give me a chance to put it in context before hauling out the flamethrowers..
according to the documents ESR has written, which are arguably the core of the Open Source manifesto, developers have a responsibility to the project from which the code comes. the coin of the Open Source realm is respect for the primary developers, and participation in the project for which the code was originally written.
now, i've never seen anyone say, "if Apple opened their GUI, i'd work to improve the Mac OS." it's always, "if Apple opened their GUI, we could port the good parts to Linux." that's not participation, and it's not respect. it's pillage.
that being the case, i'd suggest everyone take another look at _The Magic Cauldron_, section 6, where ESR discusses reasons to keep source closed:
"The real question is whether your gain from spreading the development load exceeds your loss due to increased competition from the free rider."
in the case of Apple opening the source to its GUI (and all its other crown jewels), i submit that the Linux community shows significantly more interest in causing Apple increased losses through competition than it does in helping spread the development load on Apple's own projects. until that changes, it seems to me that Apple's most rational choice is to keep the source for those projects closed.
if we want that code opened, we have to do more than sit around saying how deserving we are. we have to convince Apple that the community will give enough back to compensate for the inevitable jerks whose only response will be "thanks.. sucker! hey everybody, look what i've got!"
Apple took a lot of heat when they first opened Darwin because people (no less than PMS) considered it "a cynical attempt to leverage the community for free labor." i think there's a risk that people who want Apple to open the GUI and Quartz (and the Sorensen codec, for those of you who want a Linux QT player) may be doing the same thing in reverse. they're shouting 'Open Source' to cynically leverage free work out of private companies, with no intent to repay the original developers, even according to the standards of the Open Source community itself. they want easier competition, not a chance to participate.
i don't think the idea of Open Source can legitimately be used to force someone into a disadvantageous position. if we're not willing to put up a critical mass of developers who'll work to Apple's benefit, i don't think our own standards give us the right to demand more than we're getting.
>the roll your own crowd.
that market isn't as attractive as you might think. it's composed largely of people who want to buy components on the cheap. the margins there are thin, and strongly susceptible to economies of scale. if you're not one of the really big fish in that market, or one of the hyerspecialized little fish, you're fish food. that's why we're unlikely ever to see a vertically integrated hardware/OS/software vendor in the x86 clone market.
Apple's marketing is strongly based on transparent hardware support and ease of use.. "it works, right out of the box", "this is the manual you get with a Mac", "there is no step three", etc. that requires tight synchronization between hardware and software, and the roll your own crowd could traditionally care less about that. they want to build what's cheap, not bow down before someone's list of officially approved hardware. the last thing Apple needs is to have its brand shot down by a proliferation of nightmare boxes built by people who don't give a damn about Apple specs.
besides, it costs like hell to support umpty-seven different permutations of hardware at all, let alone reliably. Microsoft has trouble doing it, and they're just a tad bigger than Apple is. you even hear occasional stories about Linux users not being able to get a certain hardware configuration to work, and we have a fairly decent amount of support, too.
so when you take the various factors into account.. loss of margins on the hardware side, negative branding from noncompliant hardware in the marketplace, and a geometric increase in the cost of support on the software side.. you'd have to buy a whole lot of Apple-produced software to offset what you'd cost them.
just between you, me, and the fencepost error, i don't think you were planning to spend more than a couple $K on software, were you?