You probably noticed this, but I meant to write "Because each wants something different, the fair way to handle it is to simply put it down (or up) as required. Men put it up, women put it down. The distribution of labor is fair, everyone has to put it up or down sometimes and not at other times."
Somehow I reversed the emphasized. Sorry, should have previewed.
I don't mean whether you leave it up or down, I mean the argument. I've run into women who are adamant about having the toilet seat down, and I just can't wrap my head around it. Obviously, if it's her apartment or otherwise constitutes her space (as opposed to a shared space between the two of you) then she gets to make policy on all things, no matter how inane -- when you're in someone else's home, regardless of how intimately connected to them you may be, it's just rude to do things in contravention of their preferences.
However, if you are living together and sharing a space, then insisting that the toilet seat be down (or up, for that matter, although I've never encountered that) is simply a selfish insistence that your needs are more important than your partner's. Consider: when a man wants to pee, if the toilet seat is down, he must first put it up, or the seat will end up with drops of urine on it, which no one (including the man) wants. When a woman wants to pee, if the toilet seat is up, she must put it down, because she cannot sit on the rim.
Because each wants something different, the fair way to handle it is to simply put it down (or up) as required. Men put it down, women put it up. The distribution of labor is fair, everyone has to put it up or down sometimes and not at other times.
The insistence that it always be down, however, essentially amounts to the woman shirking her share of the toilet-seat-state-changing responsibility. She is saying that she doesn't feel that she should ever need to put the toilet seat down or up, and that you, the man, are responsible for putting it both up and down.
Men are frequently inconvenienced by a woman leaving the toilet seat down -- if you show up in the middle of the night, and it's dark, and you really have to go, it's a bit of a pain to always have to feel to see if the seat is up or down before you let it all out. Isn't this exactly the argument most often used by women? Why is it a valid argument coming from them, and not from us? The simple answer is that she wants it her way, and is unable to compromise, and for some reason feels as though society has vindicated her opinion on the matter.
To me, a woman who insists on having the toilet seat down, who cannot take the trouble to put it down if it is up, exactly as I must take the trouble to put it up if it is down, is clearly an example of a selfish, controlling personality who will cause you problems in the long run. And actually, there's a broader theme here: if you're the sort of person, regardless of your gender, who expects other people to conform completely to your habits and norms without considering that in a relationship, everyone needs to change their habits somewhat in order to make things work, then you're probably a shitty significant other. The kind I tend to dump after three weeks, if even.
The fact that some women are even under the impression that insisting that the toilet seat always be down to convenience them is in any way right-thinking at all completely boggles my mind. I don't watch football, but to leverage another cliché as an analogy: it would be like insisting that any time she watches TV that she put it back on ESPN when she's done.
This has turned into a rant, but here's a piece of advice for men who respect themselves: if she starts throwing a shit fit about the toilet seat, dump her. I'm serious. It's the tip of the iceberg, and you'll end up unhappy in the long run.
This is where familiarity with the story would be beneficial. I would recommend that you take the time to watch The Revolution Will Not Be Televised, an Irish documentary which details the role of the private media in the coup of 2002. I watched it at the behest of others who said that it was worth watching. The very beginning of the film seems to indulge a bit much in pro-Chavez propaganda for my taste -- I used to live in China and I've had my fill of that sort of BS -- but when you watch the whole film you begin to understand why the people who made the documentary took Chavez's side and not the side of the Venezuelan opposition. So even if the speeches and the military symbolism make you squirm, as they do me, sit through them to get to the meat of the documentary, which is really very frightening. Then ask yourself, if instead of Chavez it had been Bush or Clinton, if instead of Venezuelan private media it had been CNN, how we would have reacted, and be honest. Because I think you'll find that even if you dislike Chavez intensely, an honest evaluation of the facts will find you siding with him on this matter.
And remember, just because in this particular instance the Venezuelan opposition were bigger assholes than Chavez doesn't mean that Chavez isn't an asshole in a general sense. It seems to me, lamentably, that in Latin America you often have the choice between one machismo dictator and another, most of the time.
Amen. I thought it was great when the Palestinians elected Hamas -- not because I support Hamas, mind you, but because the reaction over here to the election just proved how condescending we could be. "We want everyone to be democratic, as long as they elect the people we want them to elect."
Here's the basic truth: you either support democracy, or you don't. Democracy means people get to choose their leaders, and if the voters are socialist or islamist then you need to accept that they're going to elect socialist or islamist leaders. The US recently has been acting like China does whenever Taiwan has the balls to elect some pro-independence candidate.
My only concern about Chavez is that it seems possible or even likely that he doesn't support the institution that gave him power, and so will attempt to dissolve democracy as soon as it is expedient to do so. That and I don't like his politics. But for crying out loud, he was chosen by the Venezuelan people and remains well supported there -- who are we to think that we can tell them otherwise?
You're absolutely wrong about that. In the US at least, conspiring to overthrow the government, or stating an intention to kill the president, both constitute a federal offense. You can say you don't like the president; you can say you think he shouldn't be president; you can even call for him to be impeached. But we draw the line here in the States at actually supporting an illegal coup. If some liberal-minded anti-Bush TV station supported an attempt to overthrow the Bush government (and by supported I don't mean simply said "we agree with the coup" but actually participated in the attempted overthrow of the government and were credited as such by the people who organized the coup) you bet your ass that the station would get shut down. In all likelihood, most of the people involved would be charged with treason, which is a capital offense in the United States. As in, we would have tried them and killed them.
Chavez, whom I don't particularly support, did not do this. Instead he simply opted not to renew their license to broadcast, something that was completely legal and within his power to do. He could have charged them with treason and imprisoned the lot of them -- that's our standard way of dealing with treason here in the Land of the Free, after all -- but instead he opted to simply not renew their broadcast license. No one went to jail, nothing worse happened.
Listen, I'm personally not a big fan of Chavez, whether it's his political leanings or his worrisome penchant for usurping authority. But I'm fairly sure that he's done enough that's truly worth criticizing that we don't need to look like hysterical raisins by criticizing his behavior in this matter. He acted with a great deal of restraint compared to how such things are normally handled in other countries.
This has happened to me. Once, when I was about 16, a telemarketer called our house, and I used a similar tactic: "You have a very sexy voice," I said. "Are you in the SF bay area? Perhaps we could meet?" (The telemarketer, like me, was male). There was a long pause, and I was sure I had him. Then: "Well... sure... I'd like that..."
At that point, I really didn't know what to do. To this day, I don't know if he was simply calling my bluff, or whether he was truly interested. I remember worrying about it later though, after I hung up on him -- telemarketers typically have your name, address and phone number on the computer in front of them, after all. Nothing happened (this was more than 10 years ago) but since then it's occurred to me that using this strategy comes with a decidedly high risk of backfire. YMMV.
While that might have acted as a deterrent, a firefight in a pressurized cabin with tons of innocent people around probably would not have been such a good idea. Better perhaps than certain death in an impact situation, but nonetheless not an ideal solution, I hope you'll agree.
It seems like arming the pilots and making the cockpit lockable, bulletproof, and soundproof would be a much simpler idea. The airlines would enforce the following protocol: in the event of a hijacking, the pilots (who fly with a locked cockpit by default) would turn off the communication devices that allow people sitting in the plane to communicate with them, report the hijacking and immediately land at the nearest friendly airport. By preventing communication with the back of the plane, they ensure that a hijacker does not have the ability to psychologically guarantee their compliance to demands by threatening to shoot hostages, for example.
Of course once you land you still have a hostage situation, which is not ideal, but the chances of the plane being used as a weapon are nullified. Allowing passengers to fly armed would help this, perhaps, but are the risks worth it? I've seen people freak out on planes -- first time fliers with an acute fear of flying -- who would beg and plead with the flight attendants to have the plane turned around. Do we want such people to have guns? What guarantee is there that armed passengers would only use their weapons in the event of a hijacking? What guarantee is there that they would use their weapons effectively, and not accidentally shoot the person next to them? It's sort of a complicated problem... Not to mention that it makes smuggling firearms onto a plane with the intention of hijacking it all the easier (while arguably rendering the effectiveness of such a strategy questionable).
I think El'Al's strategy of having armed escorts on planes is a good compromise. Have two uniformed guards with military credentials who you know can use their weapons sitting on the plane as a deterrent; have one or two more sitting plain clothes in the cabin, their identities secret from everyone on board. This has all the benefits of your idea without any of the apparent problems.
There most definitely is a cost, and the cost is quality. MP3 is a lossy codec, which means that when you compress a high quality master to MP3, you lose some of the data -- that's how MP3s can be so much smaller than WAVs, for example. This is a calculated loss: the algorithm cuts out information it thinks you won't be able to hear, and the result is a fair approximation of the original. But it is only an approximation.
What this means, of course, is that if you turn a WAV into an MP3, and then decompress your MP3 back to WAV, you do not get the same thing you started with. If you then compress that second WAV back to MP3, you again do not get the same MP3 you had before. With each MP3 compression step, you lose quality.
What your CD trick does is, it decompresses your DRM-laden AAC track (AAC is also a lossy codec, and the same logic applies) in order to burn it onto the CD, and when you rip it back onto your computer, you compress it again. Instant loss of quality. Sure, you may not be able to hear the artifacts on shitty little earbuds, but with a reasonably good setup, you easily can.
If your shiny new MP3s work for you, that's great. But don't think that your trick doesn't come at a price (other than the time and annoyance of doing the ripping). The AAC files you buy from iTunes are not even CD quality to begin with; decompressing them and reripping them to MP3 further reduces the quality.
Not to mention that that CDRW isn't free, ends up in a landfill, etc.
Plus, languages like Haskell use monads to abstract away the state passing, so you can pass state from function to function without even being aware you're doing it, much as you would with a global variable in an imperative language. But state monads give you all the benefits of having a global variable without any of the drawbacks, because you are actually passing thet state into the function and returning it, it's just hidden by the bind operator. So functions are still referentially transparent!
I'm not sure where you get this idea. The folks I've met in the functional programming community were extremely helpful and friendly. But functional programming is a fundamentally different paradigm, and it is definitely more difficult for people with an imperative background (99% of programmers who aren't also mathematicians, I'd wager) to master. The importance of concepts from relatively technical branches of CS and Math don't help to lower the barrier, either.
The GP's comment about how most programmers are just too dumb was perhaps not in good taste, and was probably born of his frustration with people's unwillingness to consider functional solutions to many of these problems to which they appear ideally suited.
Having said that, it is definitely true that most "programmers" today are not as competent or intelligent as the CS geeks of yesteryear, who managed to just as much or more with less resources and without the benefit of the internet to provide them with cookbook solutions to their problems. Essentially, the barrier to entry was higher in the old days -- no one can deny that. Since then, though, programming has become more mainstream, much of what the programmer wants to do has already been done, etc. It's gotten easier, mainly because we better understand the problem space much better now. Functional programming is not quite this mainstream, yet.
The problem, perhaps, is a combination of two things: these days much of the active research in CS is happening in the functional space, and conversely not much wide-scale application development is happening in the functional space. This means that the functional programming beginner is exposed very quickly to rather daunting subjects that are an active area of PL research, which he may find intimidating. He is also not exposed much to subjects that he's familiar with from the imperative space, like writing a GUI chat client or similar. Someone on #haskell joked once that Haskell was the only programming language where research papers are linked in the "Introduction to Haskell" section of the webpage.
I don't think that it's unfair to say that most programmers are not quite cut out to digest papers that use Haskell to tackle problems from category theory, for example.
But contrary to the impression that a beginner to a language like Haskell may get, you don't actually need to understand these topics to do things like write a GUI chat program, and Haskell is perfectly well suited to these more standard applications. It's just that most Haskell-heads are more interested in research than application development, so examples of the former abound whereas examples of the latter are few and far between.
I'm not talking about functional programming. Functional programming is great, and has a lot going for it, but solving concurrent programming issues is not one of those things. Functional programming deals with concurrency issues by simply avoiding them. For problems that have no state and can be coded purely functionally this is fine, but for a large number of problems you end up either tainting the purity of your functions, or wrapping things up in monads which end up having the same concurrency issues all over again. It does have the benefit that you can isolate the state, and code that doesn't need it is fine, but it doesn't solve the issue of concurrent programming.
Not every monad is the IO monad or a state monad; having functional code wrapped up in a monad doesn't inherently force sequential evaluation and one of the great strengths of purely functional languages like Haskell is the guarantee that you won't have side-effects -- thus any function call, anywhere at all, can be executed in its own thread without any worry about blocks or volatile memory.
The IO monad is admittedly a black box, but in practice very little of a well coded Haskell program is wrapped up in the IO monad.
Referential transparency means parallelization and memoization, two of the most promising optimisation techniques moving forward. While it is certainly possible to write very fast parallelizable imperative code, the complexity quickly becomes untenable precisely because imperative programming is so tied to sequencing and makes the often completely unnecessary assumption that one statement must follow another. Because Haskell and its derivatives make the opposite assumption -- that order doesn't matter and that functions should be executed if and only if their values are needed to move computation forward -- one ends up with programs where the compiler knows exactly what can be parallelized and what cannot be. Language extensions like those found in the Glasgow Parallel Haskell project further increase parallelization potential by introducing some explicit parallelization and barrier keywords.
Of course, one is still left with the language-agnostic problem of developers writing crappy algorithms that can't easily be parallelized when one a parallelizable one would do the trick. But it's often a trade-off: for example, easily paralleizable functional algorithms are often slower than their non-parallelizable imperative counterparts in a single-core world.
The Star Wars kid is an interesting thing, because arguably, the making of the video didn't hurt him at all, it was the distribution. There are a class of things like this, most of which involve being caught doing something embarrassing and then having said action passed around for all to see and ridicule. Do I think these should be restricted? Not at all -- but I think it's an interesting example of the opposite of the child porn scenario, where the making of the film hurts the child, but the distribution doesn't, at least not relatively speaking.
I personally am against any form of censorship, including of things I personally find abhorrent, such as child pornography. However, I think it is important not to create an economic incentive to create such material, which means that I am against the distribution of child pornography in exchange for material compensation. If people are swapping it for free on the internet and there's nothing to encourage morally bankrupt production companies from producing more, then I don't really see the problem. When a film surfaces no effort should be spared to locate the people involved in its production, and they should be prosecuted to the fullest extent of the law. But people who look at it -- why should looking at it be illegal? Lots of people get off on stuff I find disgusting. There are people who get off on corpses, for example, and download pictures of dead people. This is gross, but not illegal -- nor should it be. Killing someone to have sex with them is illegal, of course. But fantasizing about necrophilia thankfully is not.
There is no evidence that I'm aware of that people who look at child porn are more likely to rape a child. Certainly, child rapists often look at child porn, but what does that prove? Rapists often look at normal porn, too. Maybe porn causes rape? Unlikely.
Bottom line: it should not be illegal to look at pictures of anything. Acts that are illegal should remain illegal, but watching videos of illegal acts should not be. Otherwise, watching footage of Jack Ruby killing Oswald would be illegal. Think about it.
I think it's not so much that smart people didn't spend time thinking about infrastructure, just that they failed (as people are wont to do) to look far enough down the road. In the early 70s, Silicon Valley was exceedingly agrarian, and most of the peninsula was fruit orchards. I don't think anyone really anticipated the digital revolution and what it would do to the valley. Like most rural areas, the early valley was spread out and cars were needed to get from place to place. No one "planned" the valley -- it boomed, and suddenly there were more people than anyone knew how to handle.
I'm not making excuses, mind you. I can't stand the lack of public infrastructure. But you should consider that most of the west coast's development happened after the introduction of the automobile. At the time, people did not see the inherent problems in the "one man one car" model; cars were seen as granters of freedom, they were seen as the future. Whenever promising new technology surfaces and promises to change people's lives for the better it is not until it becomes commonplace that problems start to surface. For example, few people understood the privacy implications of the internet and the world wide web in particular in 1991 -- it's only now that the average person is beginning to realize that they have to be careful about what they post on the web. In the early days, I had my real name as my handle in most forums (including Slashdot). Now, whenever you meet someone, or interview for a job, or do anything, you get "Googled". This wasn't something anyone thought about in those days. Now, a search for my name will reveal silly (and potentially embarrassing) things I said when I was a teenager that there's no way for me to be rid of.
Here we are, 70 years after Ford started the automobile revolution, and people are only now just beginning to realize that 1) cars don't scale well with growing population density 2) pollution is bad -- remember, the "Beautify America" campaign that sought to change the way Americans thought about litter and their environment was only in the late 50s early 60s 3) having so much of our key infrastructure dependent on a commodity that we ourselves cannot adequately provide is politically and strategically inadvisable. But in the meantime, a lot of civil planning mistakes have been made and it will take time to rectify them and teach the American people (who are, by this time, culturally married to their cars) that driving everywhere is not really such a great idea.
As an aside, San Francisco, which is situated on the tip of a small peninsula, has nowhere to grow and consequently has no sprawl to speak of. It is dense and public transportation infrastructure is, while nothing like what's available in Europe or Asia, reasonably adequate. BART (Bay Area Rapid Transit) connects much of the northern peninsula to the east and north bay (but not the south bay, for frustrating political reasons). Muni and light rail are all over the place, come frequently, and are pretty affordable. It's not really so bad (if you're in the city).
Many modern fiber blends have polymers in them, not just polyester. You'd be surprised.
The GP's point is a good one: fossil fuels are used to produce a great deal more than just gasoline. I still applaud your decision not to drive, though. Realistically, of course, this is not something that everyone can do. There are parts of the US where not having a car makes life impossible. It's mostly the fault of urban (and especially suburban) planning: the whole notion of having residential and commercial zones means that grocery stores and other necessary shops and establishments are often so far removed from peoples' homes that they can't purchase items they need to survive without driving sometimes tens of miles away. Sure, sell the house, move to somewhere less influenced by 60s-era civil engineering, etc -- this works if your job is urban, but otherwise, realistically, your place of employment is probably in a commercial or industrial zone, which by definition has no residences -- and so you're back to square one, commuting. Not to mention the problems inherent with uprooting your family, moving your kids to new schools, etc. Clearly, it's not something anyone can do.
Slashdotters who say "if you don't like company X's products, don't buy them" are usually of a free market persuasion, so in this case you may have your feelings about government involvement vindicated because the zoning fiasco is pretty much entirely the fault of governments -- usually local ones -- who felt (at the time) that they were enforcing some sort of quality of life. The result has been sprawl. Here in Silicon Valley, there are a few developments that are experimenting with a different kind of urban planning, one where industry is still separated from residential and commercial, but where residential and commercial are mixed together. It's still not quite zone-free, because governments tend to tax commercial property-owners differently from residential property-owners, but it's possible to leave your apartment in the morning, walk across the street, buy a coffee, etc. (I'm thinking of a newish development in San Mateo off of 101, next to the Bay Meadows racetrack, if you're familiar with the area).
Personally, I'm all for mass-gentrification. The suburbs need to die.
The Nooks work [Swift et al., 2002] showed that by isolating drivers from the kernel address space, the most common programming errors could be made recoverable. In Nooks, drivers are insulated from the rest of the kernel by running each in a separate address space, and replacing the driver/kernel interface with a new one that uses cross-domain procedure calls to replace any procedure calls in the ABI, and that creates shadow copies of any shared variables in the protected address space.
This approach provides isolation, but also has problems: as the driver model changes, there is quite a lot of wrapper code that has to be changed to accommodate the changed APIs. Also, the value of any shared variable is frozen for the duration of a driver ABI call. The Nooks work is uniprocessor only; locking issues therefore have not yet been addressed.
That obviously is a bit of a show-stopper, as SMP and hyperthreaded systems are becoming more and more common in practice; it's not clear how complex extending the Nooks system would be. But the paper I linked actually suggests that for most drivers, there's no need to have them in kernel space at all: with a little bit of work, it seems that "almost any PCI bus-mastering device could have a user mode device driver." (ibid)
It's an interesting read, if you have a moment I recommend you take a look.
I still think using a microkernel would be best, and the L4 people have shown that a properly implemented microkernel can be nearly as fast as a macrokernel -- turns out (surprise surprise) that it's Mach that's given the microkernel a bad name. But the complexity issue remains daunting, and that (along with an unreasonable political attachment to Mach) has kept the L4-Hurd project from really getting off the ground. It's a shame.
Anyone who calls themselves a techie who thinks that the NT kernel isn't an excellent piece of engineering is, well, full of shit. Most (as in, over 99%) of kernel level glitches on NT-based systems are driver issues. Starting with NT 4.0, there was a bit of kernel level instability due to MS's decision to migrate the GUI into ring 0; this was a non issue in NT 3.5.
The driver issue is one that everyone needs to think about seriously: you can have a completely bug free kernel, but if you allow morons to write stuff that executes in kernel space (ie, drivers) instability will arise. Linux has so far avoided this by deliberately discouraging binary drivers (ironically, people criticize the kernel folks for this decision, but it's one of the things that keeps Linux as stable as it is). The only way to both allow binary drivers and maintain stability is with a microkernel based design, where the drivers run sandboxed and can fail without taking down the whole kernel. Monolithic kernels will never have that sort of stability, but they are faster and far easier to understand. So it's a trade-off.
Of course, from a developer's perspective, being able to look at the code for the kernel you're running your software on is absolutely invaluable. When NT does something, it's voodoo magic. When I do a syscall on Linux or some other open OS, I can trace execution exactly, and I know exactly what's going on. I can't tell you how many times I've had wacky thread dependency problems on NT. It nearly always turns out that NT is doing the RightThing[tm], because as I said, Dave Cutler and friends are not dummies, but I'm staring into a black box and there's no way to figure out what the problem is without doing trial and error rearrangements of thread calls or similar. With Linux, I can set up a debugger to follow the thread of execution into kernel space! It's extremely useful if something wacky is going on.
For this reason, if I'm doing close-to-the-metal development (ie, embedded systems or similar) I'll take an open operating system over a closed one any day of the week. As I said, NT is very well designed, but who wants to go back to the bad old ways?
That's not at all true: you need to be able to look at the source code to determine whether or not a product infringes on copyright, but not patents. What makes patents dangerous is that they are much broader in scope than simple copyright; whereas copyright protects a particular implementation of a particular idea, ie, the source code, patents protect the idea itself, regardless of how it is implemented. So for example, if I did an implementation of LZW compression (this patent is expired now, but pretend for a moment that it weren't) in Haskell, it stands to reason that I'm probably not infringing on Unisys's copyright on their LZW compression implementation, because I seriously doubt they did that in Haskell (probably C, or even machine language, given the time).
However, I am still infringing on their patent, which describes how the LZW compression algorithm works and guarantees Unisys, the patent holder, a thankfully temporary and now expired monopoly on any implementation of said algorithm, in any language, by any developer.
So all a company or person needs to do to determine if Microsoft (or any other closed-source company) infringes on its patents is to look at the program and ask, "does it do the thing I've patented in the way outlined in the patent?" If you have reason to believe that it is so, you can sue them, and demand that they license your patent or stop providing the infringing functionality. This was actually done quite recently by Eolas, a pure IP company, with respect to some sort of plug-in functionality in MS's Internet Explorer browser. They certainly had not seen the IE code when they sued (and won, by the way).
It's important that Eolas was a pure IP company because, well, there are so many patents out there that it's impossible not to infringe on some that don't belong to you, unless you're unreasonably vigilant (like the Ogg Vorbis people). So without any doubt, MS infringes on say, IBM's patents. The catch is, IBM most likely also infringes MS's patents, and they both probably infringe on Sun's patents, who in turn infringes on theirs. This is what we call IP MAD, to borrow a term from the cold war: mutually assured destruction. IBM doesn't sue MS because MS could counter-sue and both would be destroyed in the process. But with a pure IP company, they produce no software, and so there is no MAD: Eolas couldn't infringe on MS's patents, because it had no software product.
Richard Stallman is right about the term "Intellectual Property" -- it refers to three completely different legal beasts, namely copyright, trademark, and patents, all of which are so different that it makes no sense to group them together. The term IP is used by the industry to encourage us to think of ideas as property; they reinforce that notion by calling copyright infringement (illegal in its own right) theft, etc. It's a game of weasel words -- you're best off not using the term "Intellectual Property", because if you use it a lot, you'll begin to think that Copyright, Patents, and Trademark are all "sort of the same" and become confused about things. For example, Slashdotters often say that if a patent is not defended for some period of time, it expires -- but this is only true of trademarks, not patents. Similarly, you apparently confused patents and copyright, because you felt that you would need to see the code to discover if someone is infringing.
Not using the term "IP" unless you're extremely clear on the differences is a good step to clarifying things in your mind. Remember that Trademarks, Patents, and Copyright share no legal common ground, are based on entirely different laws, and do entirely different things.
The SMB bought from IBM in the 90s -- or was it the 80s? -- bears little resemblance to the SMB (or more properly, CIFS) of today. First off, right after buying it, Microsoft merged the product with LAN Manager, a product developed in-house with the help of 3com. Furthermore, and I may be wrong about this, but generally when one buys a product from another business, one also purchases the relevant intellectual property (in this case patents) -- or did you think only the copyright was transfered? Otherwise, how would Microsoft realistically be able to sell, modify, and license its new product? IBM could submarine them: that would have been foolhardy. And MS are nothing if not business-savvy.
So MS most certainly owns a large number of CIFS-related patents, and it stands to reason that Samba, which duplicates that functionality, is infringing. Of course, it should have been clear to anyone with half a brain that Samba and Mono and other free implementations of Microsoft technology would doubtless infringe on their patents. I'd be more concerned about Mono, frankly, as SMB has been around for a long time and was most modified in the Windows for Workgroups era -- those patents are probably either expired or very near to it.
Of course, once the relevant patents are listed -- they'll have to be, I think, before anyone in the industry takes MS seriously -- it will probably be possible to code around them, as the Freetype project did before Apple's truetype hinting patents expired. So as I see it, this is probably FUD. But who knows, perhaps they have a patent that can't be worked around (for example, Unisys's patent on LZW compression could not be worked around, for obvious reasons -- but that patent led to the development of gzip and png, both superior in pretty much every way to LZW, so perhaps even that sort of patent isn't the silver bullet they hope it will be).
Now, I support the right to bear arms, but let's be fair: the days when a "well-regulated militia" had any hope in hell of taking on the US military are long behind us. For example, they have nukes, chemical weapons, etc. If you tried to obtain weapons like these for your "militia" you'd be in Guantanamo bay so fast it wouldn't even be funny. Without them, you don't stand a chance.
If the government becomes corrupt, your only hope is that the military doesn't stand behind them, because if they do, no amount of practice at the shooting range is going to prepare you for an assault by US Marines.
Although I use LaTeX myself for most of my document production needs, asking government employees to use LaTeX to produce documents is probably a little bit unrealistic, no matter what you or I might think about the ease of document production using a TeX-based system. Publishers and professionals will continue to use tools like LaTeX, because in those sectors there are professionals who handle layout and expecting them to be able to use powerful but occasionally cryptic software is not at all unreasonable (authors rarely ever make decisions on how to layout the text of a book they've written). But here, we're talking about people that aren't layout professionals and who are used to WYSIWYG tools, for whom LaTeX would present an unreasonable learning curve.
LaTeX and TeX look great and are arguably still better than most of their direct competitors, and certainly produce documents that look vastly superior to those produced by WYSIWYG programs (as Knuth quipped, "What you see is all you get"). But the government is more concerned about content and the ease of producing it than how it looks. They also probably aren't typesetting complex mathematical formulae, which has historically been TeX's great strength.
And before anyone says as much, yes, I have heard of LyX -- but if you think you're getting all of TeX's power using a TeX editor like that, you'd be wrong. Plus, at that point, how is TeX superior to ODF? You may not realize this, but TeX (like PostScript) is a Turing complete language, complete with branches and loops, and there's no way that any editor, no matter how feature rich, could duplicate that level of complexity, for the same reason that there are no "WYSIWYG" tools for creating applications that duplicate all the functionality of C, C++, Java, C#, whatever.
You may think, "that's ok, let's just support a subset!" Not a bad idea (that is, in fact, what PDF does -- it implements a subset of PostScript that is not anywhere near as complex). But then you really have to make it a subset and only a subset, otherwise I might decide to edit the LaTeX code you wrote with your word-processor by hand and unknowingly create a beautiful document that no one can edit using WYSIWYG tools, because I strayed outside of the supported subset of the language.
Plus, people these days are gravitating towards XML-based formats, and for good reason: XML is easy to parse, standard, and ubiquitous. Using a non-XML based standard like some TeX-subset means having a completely different parser internally. XML is also structured as a tree, which makes dynamic content generation easy, whereas TeX, which was designed to be much more flexible, eschews such restrictions (to our great annoyance, as we cannot support all its exotic features for the reasons outlined above anyway).
Every time this sort of discussion comes up, someone invariably says "What about TeX?" Hopefully I've shed some light on why that's not really workable or ideal.
The GPL, and the organisation that developed and standardised the GPL, basically makes very clear that you can try and make money from GPL software, but you'll be wasting your time.
I'm not sure where you get the idea that they make it very clear that you'll be wasting your time; I'm also not sure where you get the idea that you would be wasting your time. As I said, the FSF ran on the profits generated by selling GPL'd software in the early years -- while it has admittedly become more difficult to make money on distribution alone, the fact remains that when the GNU project was conceived (1984) and the GPL v2 first written (1991) the internet was far less accessible (and far slower) than it is today and there was no reason for the FSF to think of their distribution based business model as unworkable in the long term. The internet revolutionized distribution, and they (and many other organizations and companies) were forced to rethink their business model.
But nowhere was there any idea that you couldn't sell your software for a profit, even for a large profit, if you could find some way to make money off of it.
As for wasting ones time, RedHat remains (although I'm personally not fond of them) the premier provider of Linux-based OSs in the corporate sector, and they do not provide their (GPLd) software for free. You have to buy it. People do, despite the fact that it's expensive. There's a simple reason for that -- the GPL itself (like most free software licenses) explicitly states that the software comes with NO WARRANTY -- NOT EVEN THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This is a scary, scary thing for a company that can't afford downtime, which is why serious businesses don't run Gentoo, even if it might be a good distribution (I don't know, I've never used it). They pay through the nose for support from RedHat -- not even superbly great support, ironically. There's a great deal of money to be made here.
So here's the reality: with the GPL, you can't make a shitty piece of software and then sit on it until its copyright expires, making money on sales for the rest of eternity. That may be a shitty thing for a software programmer, because hey, everyone likes to "do a little bit of work and then retire on royalties." But the market is efficient because it forces people to work, not because it lets you have a free ride like some Soviet Party Cadre. There's no such thing as a free lunch. If you're going to make money, you're going to have to work hard, and that means supporting your software as well as just developing it. To make things even better (for me), you aren't even guaranteed the support contract on software you've written, because if your competitor manages to support your software better than you yourself do, I might just buy my support contract from him.
Low barriers to entry -- that's what capitalism is about. Conventional copyright is an artificial barrier designed to prevent the entry of competitors into your market -- it guarantees the author of a work a temporary monopoly. Even though everyone knew this went against the fundamental tenants of the capitalist system, it was argued (correctly, in my mind) that offering the author the ability to temporarily monopolize profits from his work would act as an incentive for authors to create works in the first place. But when copyright is extended indefinitely, the market suffers, and the consumer pays. This might make you a little bit richer personally, but you're not just an author, you're also a consumer of other people's intellectual property, and perpetual copyright drives the cost of doing business in general up. This acts as a "tax" on the average consumer: everything costs more.
Is making a little bit more money really a good thing, if everything costs more? I live in Silicon Valley. Salaries are high here, much higher than the rest of the country, but, frankly, who car
If you'd actually read the article you linked to, you would realize that the quote in question (about charging money for software being a crime against humanity) was not in fact said by Richard Stallman, but only attributed to him by someone else. There's nothing new here: people are constantly trying to claim that the GPL is somehow anti-profit. But the GPL has never been about restricting anyone's ability to profit: in fact, consider the following statement, from the GPL itself (emphasis added):
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
People who claim that the GPL explicitly forbids making a profit from selling software or that Stallman himself is against the sale of software are either deeply confused or dishonest. In fact, in the early years of the FSF, the foundation was primarily supported by the sale of its own, GPL-licensed software. In those days, the internet was still slow, unstable, and inaccessible to commercial interests, many of whom nonetheless ran UNIX systems and desired GNU tools. These were sold, on floppy disks by snail mail, to people who were interested. Yes, for a fee.
"Yes," says the businessman, "I understand that -- but the GPL effectively drives the profit from selling software to zero, even if it doesn't explicitly prevent me from selling said software, because the person I sell it to can turn around and distribute it to his friends for free, a right the GPL guarantees!"
He's right, in a certain sense. However, anyone with a cursory understanding of economics and the free market knows that healthy markets also serve to drive profits to zero -- that's how you know the market is functioning properly. Margins will decrease with competition by definition, and prices will drop until all that is being covered by price is operational cost. This is considered good for the consumer; it means that businesses are forced to innovate and develop new markets, because when a sector becomes saturated, profits will by definition lower until the margins are so thin that companies previously providing the service will no longer be interested in providing them; this reduces competition, prices rise, margins widen, providing incentive to other companies to re-enter the field and make a profit -- and so the cycle begins anew. Clearly, in a properly functioning market with low barriers to entry, margins will oscillate very close to zero. This is how it is supposed to work. You don't have the right to make a profit, not in capitalism.
The case with the GPL is analogous -- the freedoms it guarantees the user reduce artificial barriers to entry and make competition very easy. For example, had I decided to sell GNU software in the 1980s -- ie, compete with the FSF, who was making a tidy profit this way -- I could have. I would have figured out how much it cost to distribute the software, and made my price lower than theirs by reducing my own profit margins, thus stealing their business. They could then have undercut me, or perhaps a third party could have undercut us both, and so on and so forth, until there was nothing left to undercut, and the price of selling the GPL'd software was exactly equal to the cost of distributing it. I probably wouldn't see this as ideal, and I'd probably stop selling GNU software. Competition would ease. Prices would rise. Business people call this an arbitrage opportunity: a product is overvalued, so you sell it for less to bring prices down, until the opportunity vanishes and there's no more profit.
The catch is, with the internet, distribution costs are nearly -- although not exactly -- zero.
Clearly, there's not much money to be made selling Free Software, although you'r
Slashdot Mirror
You probably noticed this, but I meant to write "Because each wants something different, the fair way to handle it is to simply put it down (or up) as required. Men put it up, women put it down. The distribution of labor is fair, everyone has to put it up or down sometimes and not at other times."
Somehow I reversed the emphasized. Sorry, should have previewed.
I don't mean whether you leave it up or down, I mean the argument. I've run into women who are adamant about having the toilet seat down, and I just can't wrap my head around it. Obviously, if it's her apartment or otherwise constitutes her space (as opposed to a shared space between the two of you) then she gets to make policy on all things, no matter how inane -- when you're in someone else's home, regardless of how intimately connected to them you may be, it's just rude to do things in contravention of their preferences.
However, if you are living together and sharing a space, then insisting that the toilet seat be down (or up, for that matter, although I've never encountered that) is simply a selfish insistence that your needs are more important than your partner's. Consider: when a man wants to pee, if the toilet seat is down, he must first put it up, or the seat will end up with drops of urine on it, which no one (including the man) wants. When a woman wants to pee, if the toilet seat is up, she must put it down, because she cannot sit on the rim.
Because each wants something different, the fair way to handle it is to simply put it down (or up) as required. Men put it down, women put it up. The distribution of labor is fair, everyone has to put it up or down sometimes and not at other times.
The insistence that it always be down, however, essentially amounts to the woman shirking her share of the toilet-seat-state-changing responsibility. She is saying that she doesn't feel that she should ever need to put the toilet seat down or up, and that you, the man, are responsible for putting it both up and down.
Men are frequently inconvenienced by a woman leaving the toilet seat down -- if you show up in the middle of the night, and it's dark, and you really have to go, it's a bit of a pain to always have to feel to see if the seat is up or down before you let it all out. Isn't this exactly the argument most often used by women? Why is it a valid argument coming from them, and not from us? The simple answer is that she wants it her way, and is unable to compromise, and for some reason feels as though society has vindicated her opinion on the matter.
To me, a woman who insists on having the toilet seat down, who cannot take the trouble to put it down if it is up, exactly as I must take the trouble to put it up if it is down, is clearly an example of a selfish, controlling personality who will cause you problems in the long run. And actually, there's a broader theme here: if you're the sort of person, regardless of your gender, who expects other people to conform completely to your habits and norms without considering that in a relationship, everyone needs to change their habits somewhat in order to make things work, then you're probably a shitty significant other. The kind I tend to dump after three weeks, if even.
The fact that some women are even under the impression that insisting that the toilet seat always be down to convenience them is in any way right-thinking at all completely boggles my mind. I don't watch football, but to leverage another cliché as an analogy: it would be like insisting that any time she watches TV that she put it back on ESPN when she's done.
This has turned into a rant, but here's a piece of advice for men who respect themselves: if she starts throwing a shit fit about the toilet seat, dump her. I'm serious. It's the tip of the iceberg, and you'll end up unhappy in the long run.
This is where familiarity with the story would be beneficial. I would recommend that you take the time to watch The Revolution Will Not Be Televised, an Irish documentary which details the role of the private media in the coup of 2002. I watched it at the behest of others who said that it was worth watching. The very beginning of the film seems to indulge a bit much in pro-Chavez propaganda for my taste -- I used to live in China and I've had my fill of that sort of BS -- but when you watch the whole film you begin to understand why the people who made the documentary took Chavez's side and not the side of the Venezuelan opposition. So even if the speeches and the military symbolism make you squirm, as they do me, sit through them to get to the meat of the documentary, which is really very frightening. Then ask yourself, if instead of Chavez it had been Bush or Clinton, if instead of Venezuelan private media it had been CNN, how we would have reacted, and be honest. Because I think you'll find that even if you dislike Chavez intensely, an honest evaluation of the facts will find you siding with him on this matter.
And remember, just because in this particular instance the Venezuelan opposition were bigger assholes than Chavez doesn't mean that Chavez isn't an asshole in a general sense. It seems to me, lamentably, that in Latin America you often have the choice between one machismo dictator and another, most of the time.
Amen. I thought it was great when the Palestinians elected Hamas -- not because I support Hamas, mind you, but because the reaction over here to the election just proved how condescending we could be. "We want everyone to be democratic, as long as they elect the people we want them to elect."
Here's the basic truth: you either support democracy, or you don't. Democracy means people get to choose their leaders, and if the voters are socialist or islamist then you need to accept that they're going to elect socialist or islamist leaders. The US recently has been acting like China does whenever Taiwan has the balls to elect some pro-independence candidate.
My only concern about Chavez is that it seems possible or even likely that he doesn't support the institution that gave him power, and so will attempt to dissolve democracy as soon as it is expedient to do so. That and I don't like his politics. But for crying out loud, he was chosen by the Venezuelan people and remains well supported there -- who are we to think that we can tell them otherwise?
You're absolutely wrong about that. In the US at least, conspiring to overthrow the government, or stating an intention to kill the president, both constitute a federal offense. You can say you don't like the president; you can say you think he shouldn't be president; you can even call for him to be impeached. But we draw the line here in the States at actually supporting an illegal coup. If some liberal-minded anti-Bush TV station supported an attempt to overthrow the Bush government (and by supported I don't mean simply said "we agree with the coup" but actually participated in the attempted overthrow of the government and were credited as such by the people who organized the coup) you bet your ass that the station would get shut down. In all likelihood, most of the people involved would be charged with treason, which is a capital offense in the United States. As in, we would have tried them and killed them.
Chavez, whom I don't particularly support, did not do this. Instead he simply opted not to renew their license to broadcast, something that was completely legal and within his power to do. He could have charged them with treason and imprisoned the lot of them -- that's our standard way of dealing with treason here in the Land of the Free, after all -- but instead he opted to simply not renew their broadcast license. No one went to jail, nothing worse happened.
Listen, I'm personally not a big fan of Chavez, whether it's his political leanings or his worrisome penchant for usurping authority. But I'm fairly sure that he's done enough that's truly worth criticizing that we don't need to look like hysterical raisins by criticizing his behavior in this matter. He acted with a great deal of restraint compared to how such things are normally handled in other countries.
People are suggesting that computers have become unnecessarily bloated, and you bring up Java as a counterpoint? Are you going for +5 Funny, or what?
This has happened to me. Once, when I was about 16, a telemarketer called our house, and I used a similar tactic: "You have a very sexy voice," I said. "Are you in the SF bay area? Perhaps we could meet?" (The telemarketer, like me, was male). There was a long pause, and I was sure I had him. Then: "Well... sure... I'd like that..."
At that point, I really didn't know what to do. To this day, I don't know if he was simply calling my bluff, or whether he was truly interested. I remember worrying about it later though, after I hung up on him -- telemarketers typically have your name, address and phone number on the computer in front of them, after all. Nothing happened (this was more than 10 years ago) but since then it's occurred to me that using this strategy comes with a decidedly high risk of backfire. YMMV.
While that might have acted as a deterrent, a firefight in a pressurized cabin with tons of innocent people around probably would not have been such a good idea. Better perhaps than certain death in an impact situation, but nonetheless not an ideal solution, I hope you'll agree.
It seems like arming the pilots and making the cockpit lockable, bulletproof, and soundproof would be a much simpler idea. The airlines would enforce the following protocol: in the event of a hijacking, the pilots (who fly with a locked cockpit by default) would turn off the communication devices that allow people sitting in the plane to communicate with them, report the hijacking and immediately land at the nearest friendly airport. By preventing communication with the back of the plane, they ensure that a hijacker does not have the ability to psychologically guarantee their compliance to demands by threatening to shoot hostages, for example.
Of course once you land you still have a hostage situation, which is not ideal, but the chances of the plane being used as a weapon are nullified. Allowing passengers to fly armed would help this, perhaps, but are the risks worth it? I've seen people freak out on planes -- first time fliers with an acute fear of flying -- who would beg and plead with the flight attendants to have the plane turned around. Do we want such people to have guns? What guarantee is there that armed passengers would only use their weapons in the event of a hijacking? What guarantee is there that they would use their weapons effectively, and not accidentally shoot the person next to them? It's sort of a complicated problem... Not to mention that it makes smuggling firearms onto a plane with the intention of hijacking it all the easier (while arguably rendering the effectiveness of such a strategy questionable).
I think El'Al's strategy of having armed escorts on planes is a good compromise. Have two uniformed guards with military credentials who you know can use their weapons sitting on the plane as a deterrent; have one or two more sitting plain clothes in the cabin, their identities secret from everyone on board. This has all the benefits of your idea without any of the apparent problems.
I'm pretty sure that there are some circumstances where the likelihood is zero. Running OpenVMS, for example.
There most definitely is a cost, and the cost is quality. MP3 is a lossy codec, which means that when you compress a high quality master to MP3, you lose some of the data -- that's how MP3s can be so much smaller than WAVs, for example. This is a calculated loss: the algorithm cuts out information it thinks you won't be able to hear, and the result is a fair approximation of the original. But it is only an approximation.
What this means, of course, is that if you turn a WAV into an MP3, and then decompress your MP3 back to WAV, you do not get the same thing you started with. If you then compress that second WAV back to MP3, you again do not get the same MP3 you had before. With each MP3 compression step, you lose quality.
What your CD trick does is, it decompresses your DRM-laden AAC track (AAC is also a lossy codec, and the same logic applies) in order to burn it onto the CD, and when you rip it back onto your computer, you compress it again. Instant loss of quality. Sure, you may not be able to hear the artifacts on shitty little earbuds, but with a reasonably good setup, you easily can.
If your shiny new MP3s work for you, that's great. But don't think that your trick doesn't come at a price (other than the time and annoyance of doing the ripping). The AAC files you buy from iTunes are not even CD quality to begin with; decompressing them and reripping them to MP3 further reduces the quality.
Not to mention that that CDRW isn't free, ends up in a landfill, etc.
Plus, languages like Haskell use monads to abstract away the state passing, so you can pass state from function to function without even being aware you're doing it, much as you would with a global variable in an imperative language. But state monads give you all the benefits of having a global variable without any of the drawbacks, because you are actually passing thet state into the function and returning it, it's just hidden by the bind operator. So functions are still referentially transparent!
I'm not sure where you get this idea. The folks I've met in the functional programming community were extremely helpful and friendly. But functional programming is a fundamentally different paradigm, and it is definitely more difficult for people with an imperative background (99% of programmers who aren't also mathematicians, I'd wager) to master. The importance of concepts from relatively technical branches of CS and Math don't help to lower the barrier, either.
The GP's comment about how most programmers are just too dumb was perhaps not in good taste, and was probably born of his frustration with people's unwillingness to consider functional solutions to many of these problems to which they appear ideally suited.
Having said that, it is definitely true that most "programmers" today are not as competent or intelligent as the CS geeks of yesteryear, who managed to just as much or more with less resources and without the benefit of the internet to provide them with cookbook solutions to their problems. Essentially, the barrier to entry was higher in the old days -- no one can deny that. Since then, though, programming has become more mainstream, much of what the programmer wants to do has already been done, etc. It's gotten easier, mainly because we better understand the problem space much better now. Functional programming is not quite this mainstream, yet.
The problem, perhaps, is a combination of two things: these days much of the active research in CS is happening in the functional space, and conversely not much wide-scale application development is happening in the functional space. This means that the functional programming beginner is exposed very quickly to rather daunting subjects that are an active area of PL research, which he may find intimidating. He is also not exposed much to subjects that he's familiar with from the imperative space, like writing a GUI chat client or similar. Someone on #haskell joked once that Haskell was the only programming language where research papers are linked in the "Introduction to Haskell" section of the webpage.
I don't think that it's unfair to say that most programmers are not quite cut out to digest papers that use Haskell to tackle problems from category theory, for example.
But contrary to the impression that a beginner to a language like Haskell may get, you don't actually need to understand these topics to do things like write a GUI chat program, and Haskell is perfectly well suited to these more standard applications. It's just that most Haskell-heads are more interested in research than application development, so examples of the former abound whereas examples of the latter are few and far between.
Not every monad is the IO monad or a state monad; having functional code wrapped up in a monad doesn't inherently force sequential evaluation and one of the great strengths of purely functional languages like Haskell is the guarantee that you won't have side-effects -- thus any function call, anywhere at all, can be executed in its own thread without any worry about blocks or volatile memory.
The IO monad is admittedly a black box, but in practice very little of a well coded Haskell program is wrapped up in the IO monad.
Referential transparency means parallelization and memoization, two of the most promising optimisation techniques moving forward. While it is certainly possible to write very fast parallelizable imperative code, the complexity quickly becomes untenable precisely because imperative programming is so tied to sequencing and makes the often completely unnecessary assumption that one statement must follow another. Because Haskell and its derivatives make the opposite assumption -- that order doesn't matter and that functions should be executed if and only if their values are needed to move computation forward -- one ends up with programs where the compiler knows exactly what can be parallelized and what cannot be. Language extensions like those found in the Glasgow Parallel Haskell project further increase parallelization potential by introducing some explicit parallelization and barrier keywords.
Of course, one is still left with the language-agnostic problem of developers writing crappy algorithms that can't easily be parallelized when one a parallelizable one would do the trick. But it's often a trade-off: for example, easily paralleizable functional algorithms are often slower than their non-parallelizable imperative counterparts in a single-core world.
The Star Wars kid is an interesting thing, because arguably, the making of the video didn't hurt him at all, it was the distribution. There are a class of things like this, most of which involve being caught doing something embarrassing and then having said action passed around for all to see and ridicule. Do I think these should be restricted? Not at all -- but I think it's an interesting example of the opposite of the child porn scenario, where the making of the film hurts the child, but the distribution doesn't, at least not relatively speaking.
I personally am against any form of censorship, including of things I personally find abhorrent, such as child pornography. However, I think it is important not to create an economic incentive to create such material, which means that I am against the distribution of child pornography in exchange for material compensation. If people are swapping it for free on the internet and there's nothing to encourage morally bankrupt production companies from producing more, then I don't really see the problem. When a film surfaces no effort should be spared to locate the people involved in its production, and they should be prosecuted to the fullest extent of the law. But people who look at it -- why should looking at it be illegal? Lots of people get off on stuff I find disgusting. There are people who get off on corpses, for example, and download pictures of dead people. This is gross, but not illegal -- nor should it be. Killing someone to have sex with them is illegal, of course. But fantasizing about necrophilia thankfully is not.
There is no evidence that I'm aware of that people who look at child porn are more likely to rape a child. Certainly, child rapists often look at child porn, but what does that prove? Rapists often look at normal porn, too. Maybe porn causes rape? Unlikely.
Bottom line: it should not be illegal to look at pictures of anything. Acts that are illegal should remain illegal, but watching videos of illegal acts should not be. Otherwise, watching footage of Jack Ruby killing Oswald would be illegal. Think about it.
I think it's not so much that smart people didn't spend time thinking about infrastructure, just that they failed (as people are wont to do) to look far enough down the road. In the early 70s, Silicon Valley was exceedingly agrarian, and most of the peninsula was fruit orchards. I don't think anyone really anticipated the digital revolution and what it would do to the valley. Like most rural areas, the early valley was spread out and cars were needed to get from place to place. No one "planned" the valley -- it boomed, and suddenly there were more people than anyone knew how to handle.
I'm not making excuses, mind you. I can't stand the lack of public infrastructure. But you should consider that most of the west coast's development happened after the introduction of the automobile. At the time, people did not see the inherent problems in the "one man one car" model; cars were seen as granters of freedom, they were seen as the future. Whenever promising new technology surfaces and promises to change people's lives for the better it is not until it becomes commonplace that problems start to surface. For example, few people understood the privacy implications of the internet and the world wide web in particular in 1991 -- it's only now that the average person is beginning to realize that they have to be careful about what they post on the web. In the early days, I had my real name as my handle in most forums (including Slashdot). Now, whenever you meet someone, or interview for a job, or do anything, you get "Googled". This wasn't something anyone thought about in those days. Now, a search for my name will reveal silly (and potentially embarrassing) things I said when I was a teenager that there's no way for me to be rid of.
Here we are, 70 years after Ford started the automobile revolution, and people are only now just beginning to realize that 1) cars don't scale well with growing population density 2) pollution is bad -- remember, the "Beautify America" campaign that sought to change the way Americans thought about litter and their environment was only in the late 50s early 60s 3) having so much of our key infrastructure dependent on a commodity that we ourselves cannot adequately provide is politically and strategically inadvisable. But in the meantime, a lot of civil planning mistakes have been made and it will take time to rectify them and teach the American people (who are, by this time, culturally married to their cars) that driving everywhere is not really such a great idea.
As an aside, San Francisco, which is situated on the tip of a small peninsula, has nowhere to grow and consequently has no sprawl to speak of. It is dense and public transportation infrastructure is, while nothing like what's available in Europe or Asia, reasonably adequate. BART (Bay Area Rapid Transit) connects much of the northern peninsula to the east and north bay (but not the south bay, for frustrating political reasons). Muni and light rail are all over the place, come frequently, and are pretty affordable. It's not really so bad (if you're in the city).
Many modern fiber blends have polymers in them, not just polyester. You'd be surprised.
The GP's point is a good one: fossil fuels are used to produce a great deal more than just gasoline. I still applaud your decision not to drive, though. Realistically, of course, this is not something that everyone can do. There are parts of the US where not having a car makes life impossible. It's mostly the fault of urban (and especially suburban) planning: the whole notion of having residential and commercial zones means that grocery stores and other necessary shops and establishments are often so far removed from peoples' homes that they can't purchase items they need to survive without driving sometimes tens of miles away. Sure, sell the house, move to somewhere less influenced by 60s-era civil engineering, etc -- this works if your job is urban, but otherwise, realistically, your place of employment is probably in a commercial or industrial zone, which by definition has no residences -- and so you're back to square one, commuting. Not to mention the problems inherent with uprooting your family, moving your kids to new schools, etc. Clearly, it's not something anyone can do.
Slashdotters who say "if you don't like company X's products, don't buy them" are usually of a free market persuasion, so in this case you may have your feelings about government involvement vindicated because the zoning fiasco is pretty much entirely the fault of governments -- usually local ones -- who felt (at the time) that they were enforcing some sort of quality of life. The result has been sprawl. Here in Silicon Valley, there are a few developments that are experimenting with a different kind of urban planning, one where industry is still separated from residential and commercial, but where residential and commercial are mixed together. It's still not quite zone-free, because governments tend to tax commercial property-owners differently from residential property-owners, but it's possible to leave your apartment in the morning, walk across the street, buy a coffee, etc. (I'm thinking of a newish development in San Mateo off of 101, next to the Bay Meadows racetrack, if you're familiar with the area).
Personally, I'm all for mass-gentrification. The suburbs need to die.
Thanks for the interesting link! Unfortunately, their work was entirely done on a now obsolete version of the kernel (2.4.18) and a request for comment on porting it to the 2.6 series was ignored by the hackers on LKML. A little more digging found the probable reason: the system has a number of problems. In particular, this paper by Peter Chubb from the University of New South Wales (pdf) outlined some of the issues (pp 2-3, emphasis added):
That obviously is a bit of a show-stopper, as SMP and hyperthreaded systems are becoming more and more common in practice; it's not clear how complex extending the Nooks system would be. But the paper I linked actually suggests that for most drivers, there's no need to have them in kernel space at all: with a little bit of work, it seems that "almost any PCI bus-mastering device could have a user mode device driver." (ibid)
It's an interesting read, if you have a moment I recommend you take a look.
I still think using a microkernel would be best, and the L4 people have shown that a properly implemented microkernel can be nearly as fast as a macrokernel -- turns out (surprise surprise) that it's Mach that's given the microkernel a bad name. But the complexity issue remains daunting, and that (along with an unreasonable political attachment to Mach) has kept the L4-Hurd project from really getting off the ground. It's a shame.
Anyone who calls themselves a techie who thinks that the NT kernel isn't an excellent piece of engineering is, well, full of shit. Most (as in, over 99%) of kernel level glitches on NT-based systems are driver issues. Starting with NT 4.0, there was a bit of kernel level instability due to MS's decision to migrate the GUI into ring 0; this was a non issue in NT 3.5.
The driver issue is one that everyone needs to think about seriously: you can have a completely bug free kernel, but if you allow morons to write stuff that executes in kernel space (ie, drivers) instability will arise. Linux has so far avoided this by deliberately discouraging binary drivers (ironically, people criticize the kernel folks for this decision, but it's one of the things that keeps Linux as stable as it is). The only way to both allow binary drivers and maintain stability is with a microkernel based design, where the drivers run sandboxed and can fail without taking down the whole kernel. Monolithic kernels will never have that sort of stability, but they are faster and far easier to understand. So it's a trade-off.
Of course, from a developer's perspective, being able to look at the code for the kernel you're running your software on is absolutely invaluable. When NT does something, it's voodoo magic. When I do a syscall on Linux or some other open OS, I can trace execution exactly, and I know exactly what's going on. I can't tell you how many times I've had wacky thread dependency problems on NT. It nearly always turns out that NT is doing the RightThing[tm], because as I said, Dave Cutler and friends are not dummies, but I'm staring into a black box and there's no way to figure out what the problem is without doing trial and error rearrangements of thread calls or similar. With Linux, I can set up a debugger to follow the thread of execution into kernel space! It's extremely useful if something wacky is going on.
For this reason, if I'm doing close-to-the-metal development (ie, embedded systems or similar) I'll take an open operating system over a closed one any day of the week. As I said, NT is very well designed, but who wants to go back to the bad old ways?
Loose? LOOSE?
AAAAARGGGGGGHHHHHHHHH!!!!!!
Look, it's not hard. Lose (pronounced luz) as in lost. Loose (pronounced lus) as in your mom.
That's not at all true: you need to be able to look at the source code to determine whether or not a product infringes on copyright, but not patents. What makes patents dangerous is that they are much broader in scope than simple copyright; whereas copyright protects a particular implementation of a particular idea, ie, the source code, patents protect the idea itself, regardless of how it is implemented. So for example, if I did an implementation of LZW compression (this patent is expired now, but pretend for a moment that it weren't) in Haskell, it stands to reason that I'm probably not infringing on Unisys's copyright on their LZW compression implementation, because I seriously doubt they did that in Haskell (probably C, or even machine language, given the time).
However, I am still infringing on their patent, which describes how the LZW compression algorithm works and guarantees Unisys, the patent holder, a thankfully temporary and now expired monopoly on any implementation of said algorithm, in any language, by any developer.
So all a company or person needs to do to determine if Microsoft (or any other closed-source company) infringes on its patents is to look at the program and ask, "does it do the thing I've patented in the way outlined in the patent?" If you have reason to believe that it is so, you can sue them, and demand that they license your patent or stop providing the infringing functionality. This was actually done quite recently by Eolas, a pure IP company, with respect to some sort of plug-in functionality in MS's Internet Explorer browser. They certainly had not seen the IE code when they sued (and won, by the way).
It's important that Eolas was a pure IP company because, well, there are so many patents out there that it's impossible not to infringe on some that don't belong to you, unless you're unreasonably vigilant (like the Ogg Vorbis people). So without any doubt, MS infringes on say, IBM's patents. The catch is, IBM most likely also infringes MS's patents, and they both probably infringe on Sun's patents, who in turn infringes on theirs. This is what we call IP MAD, to borrow a term from the cold war: mutually assured destruction. IBM doesn't sue MS because MS could counter-sue and both would be destroyed in the process. But with a pure IP company, they produce no software, and so there is no MAD: Eolas couldn't infringe on MS's patents, because it had no software product.
Richard Stallman is right about the term "Intellectual Property" -- it refers to three completely different legal beasts, namely copyright, trademark, and patents, all of which are so different that it makes no sense to group them together. The term IP is used by the industry to encourage us to think of ideas as property; they reinforce that notion by calling copyright infringement (illegal in its own right) theft, etc. It's a game of weasel words -- you're best off not using the term "Intellectual Property", because if you use it a lot, you'll begin to think that Copyright, Patents, and Trademark are all "sort of the same" and become confused about things. For example, Slashdotters often say that if a patent is not defended for some period of time, it expires -- but this is only true of trademarks, not patents. Similarly, you apparently confused patents and copyright, because you felt that you would need to see the code to discover if someone is infringing.
Not using the term "IP" unless you're extremely clear on the differences is a good step to clarifying things in your mind. Remember that Trademarks, Patents, and Copyright share no legal common ground, are based on entirely different laws, and do entirely different things.
The SMB bought from IBM in the 90s -- or was it the 80s? -- bears little resemblance to the SMB (or more properly, CIFS) of today. First off, right after buying it, Microsoft merged the product with LAN Manager, a product developed in-house with the help of 3com. Furthermore, and I may be wrong about this, but generally when one buys a product from another business, one also purchases the relevant intellectual property (in this case patents) -- or did you think only the copyright was transfered? Otherwise, how would Microsoft realistically be able to sell, modify, and license its new product? IBM could submarine them: that would have been foolhardy. And MS are nothing if not business-savvy.
So MS most certainly owns a large number of CIFS-related patents, and it stands to reason that Samba, which duplicates that functionality, is infringing. Of course, it should have been clear to anyone with half a brain that Samba and Mono and other free implementations of Microsoft technology would doubtless infringe on their patents. I'd be more concerned about Mono, frankly, as SMB has been around for a long time and was most modified in the Windows for Workgroups era -- those patents are probably either expired or very near to it.
Of course, once the relevant patents are listed -- they'll have to be, I think, before anyone in the industry takes MS seriously -- it will probably be possible to code around them, as the Freetype project did before Apple's truetype hinting patents expired. So as I see it, this is probably FUD. But who knows, perhaps they have a patent that can't be worked around (for example, Unisys's patent on LZW compression could not be worked around, for obvious reasons -- but that patent led to the development of gzip and png, both superior in pretty much every way to LZW, so perhaps even that sort of patent isn't the silver bullet they hope it will be).
Now, I support the right to bear arms, but let's be fair: the days when a "well-regulated militia" had any hope in hell of taking on the US military are long behind us. For example, they have nukes, chemical weapons, etc. If you tried to obtain weapons like these for your "militia" you'd be in Guantanamo bay so fast it wouldn't even be funny. Without them, you don't stand a chance.
If the government becomes corrupt, your only hope is that the military doesn't stand behind them, because if they do, no amount of practice at the shooting range is going to prepare you for an assault by US Marines.
Although I use LaTeX myself for most of my document production needs, asking government employees to use LaTeX to produce documents is probably a little bit unrealistic, no matter what you or I might think about the ease of document production using a TeX-based system. Publishers and professionals will continue to use tools like LaTeX, because in those sectors there are professionals who handle layout and expecting them to be able to use powerful but occasionally cryptic software is not at all unreasonable (authors rarely ever make decisions on how to layout the text of a book they've written). But here, we're talking about people that aren't layout professionals and who are used to WYSIWYG tools, for whom LaTeX would present an unreasonable learning curve.
LaTeX and TeX look great and are arguably still better than most of their direct competitors, and certainly produce documents that look vastly superior to those produced by WYSIWYG programs (as Knuth quipped, "What you see is all you get"). But the government is more concerned about content and the ease of producing it than how it looks. They also probably aren't typesetting complex mathematical formulae, which has historically been TeX's great strength.
And before anyone says as much, yes, I have heard of LyX -- but if you think you're getting all of TeX's power using a TeX editor like that, you'd be wrong. Plus, at that point, how is TeX superior to ODF? You may not realize this, but TeX (like PostScript) is a Turing complete language, complete with branches and loops, and there's no way that any editor, no matter how feature rich, could duplicate that level of complexity, for the same reason that there are no "WYSIWYG" tools for creating applications that duplicate all the functionality of C, C++, Java, C#, whatever.
You may think, "that's ok, let's just support a subset!" Not a bad idea (that is, in fact, what PDF does -- it implements a subset of PostScript that is not anywhere near as complex). But then you really have to make it a subset and only a subset, otherwise I might decide to edit the LaTeX code you wrote with your word-processor by hand and unknowingly create a beautiful document that no one can edit using WYSIWYG tools, because I strayed outside of the supported subset of the language.
Plus, people these days are gravitating towards XML-based formats, and for good reason: XML is easy to parse, standard, and ubiquitous. Using a non-XML based standard like some TeX-subset means having a completely different parser internally. XML is also structured as a tree, which makes dynamic content generation easy, whereas TeX, which was designed to be much more flexible, eschews such restrictions (to our great annoyance, as we cannot support all its exotic features for the reasons outlined above anyway).
Every time this sort of discussion comes up, someone invariably says "What about TeX?" Hopefully I've shed some light on why that's not really workable or ideal.
I'm not sure where you get the idea that they make it very clear that you'll be wasting your time; I'm also not sure where you get the idea that you would be wasting your time. As I said, the FSF ran on the profits generated by selling GPL'd software in the early years -- while it has admittedly become more difficult to make money on distribution alone, the fact remains that when the GNU project was conceived (1984) and the GPL v2 first written (1991) the internet was far less accessible (and far slower) than it is today and there was no reason for the FSF to think of their distribution based business model as unworkable in the long term. The internet revolutionized distribution, and they (and many other organizations and companies) were forced to rethink their business model.
But nowhere was there any idea that you couldn't sell your software for a profit, even for a large profit, if you could find some way to make money off of it.
As for wasting ones time, RedHat remains (although I'm personally not fond of them) the premier provider of Linux-based OSs in the corporate sector, and they do not provide their (GPLd) software for free. You have to buy it. People do, despite the fact that it's expensive. There's a simple reason for that -- the GPL itself (like most free software licenses) explicitly states that the software comes with NO WARRANTY -- NOT EVEN THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This is a scary, scary thing for a company that can't afford downtime, which is why serious businesses don't run Gentoo, even if it might be a good distribution (I don't know, I've never used it). They pay through the nose for support from RedHat -- not even superbly great support, ironically. There's a great deal of money to be made here.
So here's the reality: with the GPL, you can't make a shitty piece of software and then sit on it until its copyright expires, making money on sales for the rest of eternity. That may be a shitty thing for a software programmer, because hey, everyone likes to "do a little bit of work and then retire on royalties." But the market is efficient because it forces people to work, not because it lets you have a free ride like some Soviet Party Cadre. There's no such thing as a free lunch. If you're going to make money, you're going to have to work hard, and that means supporting your software as well as just developing it. To make things even better (for me), you aren't even guaranteed the support contract on software you've written, because if your competitor manages to support your software better than you yourself do, I might just buy my support contract from him.
Low barriers to entry -- that's what capitalism is about. Conventional copyright is an artificial barrier designed to prevent the entry of competitors into your market -- it guarantees the author of a work a temporary monopoly. Even though everyone knew this went against the fundamental tenants of the capitalist system, it was argued (correctly, in my mind) that offering the author the ability to temporarily monopolize profits from his work would act as an incentive for authors to create works in the first place. But when copyright is extended indefinitely, the market suffers, and the consumer pays. This might make you a little bit richer personally, but you're not just an author, you're also a consumer of other people's intellectual property, and perpetual copyright drives the cost of doing business in general up. This acts as a "tax" on the average consumer: everything costs more.
Is making a little bit more money really a good thing, if everything costs more? I live in Silicon Valley. Salaries are high here, much higher than the rest of the country, but, frankly, who car
If you'd actually read the article you linked to, you would realize that the quote in question (about charging money for software being a crime against humanity) was not in fact said by Richard Stallman, but only attributed to him by someone else. There's nothing new here: people are constantly trying to claim that the GPL is somehow anti-profit. But the GPL has never been about restricting anyone's ability to profit: in fact, consider the following statement, from the GPL itself (emphasis added):
People who claim that the GPL explicitly forbids making a profit from selling software or that Stallman himself is against the sale of software are either deeply confused or dishonest. In fact, in the early years of the FSF, the foundation was primarily supported by the sale of its own, GPL-licensed software. In those days, the internet was still slow, unstable, and inaccessible to commercial interests, many of whom nonetheless ran UNIX systems and desired GNU tools. These were sold, on floppy disks by snail mail, to people who were interested. Yes, for a fee.
"Yes," says the businessman, "I understand that -- but the GPL effectively drives the profit from selling software to zero, even if it doesn't explicitly prevent me from selling said software, because the person I sell it to can turn around and distribute it to his friends for free, a right the GPL guarantees!"
He's right, in a certain sense. However, anyone with a cursory understanding of economics and the free market knows that healthy markets also serve to drive profits to zero -- that's how you know the market is functioning properly. Margins will decrease with competition by definition, and prices will drop until all that is being covered by price is operational cost. This is considered good for the consumer; it means that businesses are forced to innovate and develop new markets, because when a sector becomes saturated, profits will by definition lower until the margins are so thin that companies previously providing the service will no longer be interested in providing them; this reduces competition, prices rise, margins widen, providing incentive to other companies to re-enter the field and make a profit -- and so the cycle begins anew. Clearly, in a properly functioning market with low barriers to entry, margins will oscillate very close to zero. This is how it is supposed to work. You don't have the right to make a profit, not in capitalism.
The case with the GPL is analogous -- the freedoms it guarantees the user reduce artificial barriers to entry and make competition very easy. For example, had I decided to sell GNU software in the 1980s -- ie, compete with the FSF, who was making a tidy profit this way -- I could have. I would have figured out how much it cost to distribute the software, and made my price lower than theirs by reducing my own profit margins, thus stealing their business. They could then have undercut me, or perhaps a third party could have undercut us both, and so on and so forth, until there was nothing left to undercut, and the price of selling the GPL'd software was exactly equal to the cost of distributing it. I probably wouldn't see this as ideal, and I'd probably stop selling GNU software. Competition would ease. Prices would rise. Business people call this an arbitrage opportunity: a product is overvalued, so you sell it for less to bring prices down, until the opportunity vanishes and there's no more profit.
The catch is, with the internet, distribution costs are nearly -- although not exactly -- zero.
Clearly, there's not much money to be made selling Free Software, although you'r