The fact that antiplagiarism sites make money from their line of business (and the examples submitted by the students) is of no import, as long as they aren't selling the essays as part of an anthology or something.
The problem is that they can change their license at any time.
If their license stipulated that (a) upon dissolution of the company, all paper rights will be forfeited, (b) the paper rights may not be sold, (c) the paper rights are for exclusive use in detecting cheating, and (d) the license is nonexclusive (perhaps there's a generic email address that reports can be sent to to be entered into *all* the anticheating services, so that they recieve no business benefit in owning the paper as property -- only the academic communit as a whole really does -- then I'd be interested in seeing if folks still object).
I don't think that there are many legitimate concerns that the anticheating company could raise. The professor doen't have to do significantly more work. At least some of the students' concerns are addressed.
The second is for them to retain an escrow service to destroy their databases if they ever go out of business. This would ensure that if the company goes bottom up, my IP is protected.
How do you have an escrow service guarantee *destruction* of data?
It would be interesting if universities required students to place papers in some kind of international repository. This would be searchable, and could be read (and used as a reference). It would also serve as a marvelous plagiarism detector.
Linus is married to a woman. He has had several children with her. I'm not sure how much more heterosexual you get.
Oh, and forget dunking Linus. Everyone likes Linus, and he was getting up in front of a horde of his fans. You know who Linux folks would pay to dunk? McBride. You want to know what takes *balls* is standing in Speedos in front of a mass of people that hate you and saying "dunk me if you can".
First of all, a laptop doesn't take as much space as a desktop; just try to fit a desktop computer into a dining room or a living room, or even a bedroom, it's just damn unsightly and unweilding, let alone unportable, a laptop will fit into these with no trouble at all, and if you wish to you can unplug it in throw it into the drawer.
I don't think many people would try to put a computer in a dining room. I don't see a problem with putting it in a den (for Chrissake, we're talking about two feet by eight inches or something like that of desk space. It's not *that* bad).
The real benefits I see of a desktop replacement laptop (and I still prefer the real thing to a "desktop replacement"):
* The battery acts as a built-in UPS.
* You can move to a different room for one reason or another.
The drawbacks:
* All the crap in laptop BIOSes and stuff associated with power management. Laptops just plain do weird things occasionally. Too much custom stuff, not enough commodity.
* Most OSes other than Windows have pretty incomplete power-saving support. Even good ol' Linux.
* Prices. Laptops are still more expensive.
* Modularity. Desktops consist of all standard parts that I can cannibalize for other machines, swap out if something goes wrong, or can upgrade piecemeal. I can grab another motherboard or video card. Laptop manufacturers, in a desperate bid to keep their market from becoming a commodity, have avoided modularity and standardization of parts like the plague.
Hmm. Lessee. I'm not a WWI buff, but Germany definitely lost in 1815. They might have shoved troops into France, but I'm not sure whether they beat them.
Also, remember that there was an active French Resistance that took place composed of people who weren't happy with the government's decision.
Imagine some jackass like Bush (well, actually, despite all of Bush's failings, surrendering too early probably isn't one of them) doing something dumb and then everyone being held responsible and being joked about for the next century because of it.
Oh, and as a followup--remember that the Miracle of the Bread and Fish took place during a sermon that Jesus was giving. So, in fact, Jesus *was* placing the condition that they come to sermon at least *once* in order to be fed. I still agree with your general idea that the points that Jesus was advocating through his life as a whole could be more closely summed up by the BSD license, but I think that the example you selected probably could have been better chosen.
You may avoid helping the enemy, but you also won't help as many of the legitimately needy.
That, however, is in the short term. The FSF thesis (which I'm not going to try arguing for, just state as a plausible argument) is that promoting open source is beneficial in the long term. So, yes, in the short term, there may be a closed source software company that *would* act in a good manner that will benefit from your code donations. However, it may be to almost everyone's benefit if open source becomes the dominant form of software.
Which of these did Jesus do?
Well, Jesus took a BSD-like approach -- giving to both his allies and enemies. However, that isn't necessarily usable as a justification for what we should do. The complaint about the symbiotic and highly prolific nature of the GPL is that it tends to help its allies only, and then encourages them to spread it to other hosts. Jesus's goal was in moderating and reforming a religion that *already* had both of those properties and was spreading and gaining political influence (Judaism). He had no reason to advocate the institution of help-ally-only or spreading, which was already highly present.
Plus, let me reform the question. Suppose Jesus was walking along and met Queen Jezabel (yes, I'm aware of the anachronistic nature of this -- for the sake of discussion, let it ride). She had been abandoned by her followers, and was dying in the desert. Jesus takes out fish and bread, blesses it in the name of his Father, and offers the food to her. Jezabel, however, refused to eat unless Jesus first blessed the meal in the name of her own god. What Would Jesus Do, indeed?
This is how many GPL advocates feel about Microsoft. They have already offered to the world a marvelous collection of code. Companies are free to accept it, including Microsoft. However, Microsoft chooses *not* to accept the code -- they want it on their *own* terms, with all rights granted to Microsoft. They are certainly not constrainted to go "all GPL" -- if, for instance, they shipped GIMP instead of Windows Paint, they would not need to GPL all of Windows. However, they refuse to have any contact with the GPL ideology at all. They have made their choice. Should the GPL-using folks be expected to change, or should Microsoft? I'm not certain, but I don't think that it's nearly as clear as you've made out.
To be honest, CVS isn't all that hot as a VC system, compared to what could be done. The problem is that it's a pain in the ass to make a VC system, it's a pain in the ass to migrate from one to the other, and CVS has been there and free, so folks use it.
Don't get me wrong -- using CVS is waaay better than no VC. CVS was the first VC system I used seriously (well, after a short stint with RCS). However, CVS is seriously hampered by trying to be highly compatible with RCS, which was never designed for the kinds of environments that CVS is used in.
Anyway, as to things that aren't that hot about CVS:
* CVS doesn't grok "text" files where the linefeed format matters. If you have a piece of software that uses a text file in CRLF format, you need to treat it as a binary format.
* CVS sucks -- badly -- from a security standpoint. The current feature branch is getting vaguely closer, fixing a huge number of symlink-related bugs present. Basically, something as simple as a repository where some folks have read access, some folks have read/write access, and some have no access to each module is a real pain to set up.
* CVS allows spoofing of version history. Bad, given that one reason folks like VC is that they treat it as auditable. CVS is *not* an auditing system that can be trusted for legal or security purposes.
* CVS does not grok the concept of files moving.
* CVS cannot version CVS metadata. This means that if you have a file checked in as text (accidentally), and at some point switch it to binary format, you must break all checkouts before the original date when you mark the file as binary.
* CVS understands things based on a file-by-file basis. While it's not too hard to write scripts to provide functionality like listing all tags used in a project, it's annoying that CVS can't handle this.
* CVS lacks some of the re-merging features that BitKeeper and more advanced VC systems have. I haven't needed to muck with this, but it's apparently one of the two big reasons that the Linux kernel folks don't use CVS.
* CVS can't do distributed, disconnected development. You have to have one server that everyone can talk to, full stop. This is the second major reason that the Linux kernel folks don't use CVS.
* CVS does not do atomic updates or checkouts across multiple files (as I said, CVS sees everything on a per-file basis). Frankly, our databases and filesystems all moved to transaction semantics long, long ago. A VC system has even less excuse not to have transaction support. CVS is way behind the times in terms of reliability -- theoretically, this can cause all kinds of nastiness.
* CVS makes it a real pain in the ass to delegate administrative access, and tends to not be particularly secure. For example, if I want to allow someone to add a module, and want some *subset* of the modules in a repository to generate commit notification messages, I need to give that person write access to CVSROOT/loginfo. Bad. (Again, you can write a program that provides this access, but it's not part of CVS.)
* The CVSWin GUI sucks, and hangs if CVS is processing anything. If you have anyone that doesn't use the CLI and uses Windows, life is annoying for them.
* Unless you want to do mucking about with secure shells, giving someone CVS write access means giving them shell access on the server. Because Linux (and, I suspect, most *IXes) don't support restricted/proc out of box, this means that they can also do a fair amount of monitoring of what's going on.
Really, to be honest, CVS was a cool system for when lots of people were using RCS. CVS's killer feature is RCS compatibility. Without this constraint, CVS would not have most of its drawbacks.
I haven't seriously checked out Subversion, but I'd like to see how well it stacks up. It certainly fixes at least some of the problems.
Err...runlevel scripts can certainly be read and modified.
The only difference is that someone sat down and imposed a bit of order on the chaos, making a nice, standard way to install and uninstall packages and provide runlevel functionality.
Of course, there's a lot of software out there that won't compile on anything but Linux...Sometimes, that means you need to pick up a 2x4 and go find the author, because they've put in something gratuitously imcompatible through...laziness.
What kind of jerk *is* this guy?
Yeah, I think I'll "go after the Mozilla authors with a 2x4" because they've failed to provide native support for my sixth mouse button. Christ. What happened to "I want something done, so instead of making someone that *already* gave me a bunch of software for free miserable, I'll write a patch and contribute it so that others can enjoy"?
But it works surprisingly often. I won't go into details, and it's not exactly "emulation", but often a Linux binary can just be picked up and run on a BSD system (at least between i386 systems).
This is not compelling -- it makes BSD look like a Linux that works sometimes.
BSD has always considered it more important to let the advanced user do more, than to let the novice do more.
And what exactly is *that* supposed to mean? Linux shortchanges the advanced user? Give me a break.
"BSD users are a bunch of elitist self-centered rude snobs."
Yup. And proud of it.:-)
Given the previous statement, I'm inclined to agree.
It's possible that BSD, due to its more technical and engineering background, ends up with elitism being more prevalent than in other communities.
Surrrreee...Linux is primarily produced by a bunch of fine-arts majors who don't really go in for technical things, you know?
With Linux, you've got the linux-kernel mailing list, which is practically all developers. And just kernel developers and maintainers. The make and cron and locate and tar developers and maintainers have their own lists off somewhere else. There are very well segregated gathering areas like mailing lists, newsgroups, and web forums, for admins, for programmers, and for end-users.
This is because most folks don't even have time to keep up with the flood of kernel development, much less everything else included. Breaking this up is a *good* thing.
The problem is that Microsoft acts in ways that negatively impact the life of OSS folks (such as promoting.doc lockin). If you help Microsoft, you are helping someone who uses spare resources to repeatedly kick in you in the nuts.
Seriously. This reminds me of one of the startup articles that some of the early "Linux news" sites started running to *look* like someone actually submitted a real story, but was just the editors trying to jump-start discussion.
The HP's and the IBM's of the world are just saying that they'll lease the machine, administration, and pipe to the machine cheaper than what you'd buy it. And if you need more capacity quickly all you have to do is get on the phone and call them. If you've got too much capacity, then IBM will sell that to some other customer and you'll never notice the difference.
Hmm. Okay -- so the idea is that the cost savings come from (a) eliminating local IT staffs, and (b) reducing bandwidth supplied to given companies? The savings are on bandwidth and administration, not cycles?
According to benchmarks, even old versions of Java are within a factor of 2 in performance with C++. See Java Performance Comparison with C/C++.
You can get in this neighborhood, but it involves using object pools and the like -- significant optimizations. This is not just taking a C++ program and coding it in Java. Furthermore, these benchmarks are pretty optimal situations for Java -- straight factoring (presumably using primitive typtes, not objects, which avoids a lot of the performance problems in Java), file I/O (not compute or memory bound), memory allocations *using arrays only of primitives*, which avoids a major Java performance hit -- dealing with arrays of objects, which *requires* runtime type work.
In sum, if I were choosing a set of benchmarks to favor Java, I could not have chosen a better set.
Don't get me wrong. Java has very good applications. It's just that CPU-bound ones (what we're talking about, and what Sun has sold it as) are not one of them. For user-bound or network-bound systems, it provides fast development, and good error checking.
Why? A well written distributed application can scale to thousands of CPU's.
Okay, there are a couple of issues. My main point is that, well, imagine a line that looks like this: ":::::::::::" This line of ten colons represents all the CPU-bound realtime problems (about 10 orders of magnitude instructions per second) that can be solved on a desktop. The next line represents the range of problems that can be solved on a cluster of machines ":::" -- about three orders of magnitude beyond single-system problems. It's much more expensive to run a 1000 computer cluster than it is a single computer system. Now, in academic scientific computing, there are frequently people with a good handle on what kinds of requirements their algorithms require when they're writing the thing. However, Sun also doesn't sell a lot of "scalable systems" to academia. They do sell a lot to business, where there's a stunning number of incredibly awful programmers running around (any time I see "web and Java developer" I get scared -- there is a stunningly high proportion of really awful developers in said field). I stand by my claim that, for real world systems, using C++ alone will generally give an order of magnitude improvement ":" over Java. Chosing more intelligent algorithms can easily reduce a problem by many orders of magnitude, but since it's hard to predict whether you've had an incompement developer working on a system or a really good mathematician working on parallizing a fluid dynamics problem, we'll let that sit.
Now, remember that most very large jobs like the ones you mentioned (weather modeling, fluid dynamics, etc) do not need to be completed in a second. An hour, or even a day might work. If we're allowing a job to be completed in under three hours rather than in one second, the "single desktop" bar is suddenly extended by four more bars, while the "thousand computer cluster" remains the same. now we have "::::::::::::::" compared to ":::". So we have a little tiny, constantly moving window compared to a large bar -- and our ability to shift that window around is quite high, given our ability to use a different language or algorithm.
You don't think that eBay, or a bank, or an airline runs on 1 CPU, do you?
No. But much of that is for reliability reasons, not because the problem is computationally so difficult that a single P4 cannot solve it in a timely manner. About 1.5 billion (well, before September 11th) commercial passengers are carried worldwide by all airlines put together each year. That works out to about 47 passengers a second. The I/O bandwidth required to run a transaction-oriented database that can perform 47 transactions a second is below what a P4 and consumer motherboard can do by many, many orders of magnitude. Of course, it's a bit more complex than that -- airlanes have their own databases that must talk to airports, and probably more is done
My understanding of trademarks is that the system in question dates back (in the US) to the 1700s and manufactured goods -- where you had various craftsmen with their own mark identifying their work. If Thomas Jefferson used a "TJ" in a circle with a flower in the background to identify his silversmithing work (I'm sure his mark was something different), then it's pretty clearly benficial to society to allow him to enter that mark into a register somewhere and allow nobody else to use it. That way, people can't pass off cheap crap as authentic "Thomas Jefferson" work.
The question at hand is whether *marketing* (which existed in a far more rudimentary form at the time) associated with a brand should also recieve trademark protection -- i.e. once people have expressed any interest in your brand (which may be the only product they've heard of in the field), whether laws should be passed to ensure that they remain locked in to being *only* informed about that particular product. I don't see any reason why it should, or how it benefits society to do so. Suppose I walk into a pharmacy and ask for, oh, I don't know, Tylenol. I think that the pharmacist should *not*t be prohibited by law from saying "we just got in these new generics that people seem to like and cost half as much".
Now, that doesn't mean that there aren't trademark-infringing ways to muck with search engines. The idea of trademarks is to avoid consumer confusion. If you set up a *fake* Viagra website that *looks* like the official Pfizer website and buy "Viagra" or "Pfizer" as an AdWord, *then* you're engaging in deceptive marketing, and you can be nailed on trademark infringement (as well as potentially on criminal fraud charges).
However, this is wildly different from Chevy purchasing "Ford buy" as an AdWord. All that means is that someone is looking to buy a car, probably preferring a Ford, and if Chevy wants to try to convince them that a Chevy is a better deal by setting up www.why-chevy-kicks-ford-ass.info and directs people there...heck, I don't see any justification for making this illegal. It's clear to people that Chevy is a different product from a different manufacturer. It competes, and may be superior. This gives the consumer more information, which I tend to think is not a bad thing.
Frankly, I'd have the kid just plain masturbate once a day before getting on the Internet. She wants to get a Playboy subscription for him or something without additional commercial offerings associated with sex, great. The idea is to not have a horny 15-year-old being confronted with an option of getting sexual material by dropping $20.
Also, I would hope that said mother isn't hassling him about having porn or masturbating. Hell of a throwback to Victorian times, when Freud realized that, gee, sexual repression does really awful things to people.
Mmf. P2P has actually become a true word with different meaning than peer-to-peer.
The Internet is peer-to-peer. Lots of things are peer-to-peer. The phrase "peer-to-peer" goes *waaaay* back.
"P2P" only started life as an acronym for the insanely popular filesharing systems. These filesharing systems have a number of properties that differ from the conventional use of "peer=to-peer".
Most *Internet-based systems* (not the Internet itself) have traditionally been client-server. The reason why is pretty straightforward. Peer-to-peer implies that all hosts involved in a system are equal, and none have inherent privileges or rights greater than the others. The Internet doesn't provide a native way to locate "A computer that can give me the time, but may also ask me for the time", as a peer-to-peer system would imply. You generally set up a machine that's reasonably dedicated to a particular task, and then usually give it a DNS entry. Clients can contact this machine.
There were no real major protocols that implimented the use of servents (the term used to refer to hosts that are both client and server). There were some that came close -- IRC clients frequently could both send and recieve files, thus acting as DCC servents, but it was only a relatively small proportion of IRC servents that offered files (and, at any rate, IRC servers were still part of the game). There were plenty of protocols that *could* run over the Internet that operated as peer to peer -- any network games that used a virtual token-ring style system, such as Stuart Cheshire's excellent Bolo, would count -- but these were very small systems, and hampered by bandwidth constraints.
When bandwidth became less of an issue (colleges started providing government-subsidized bandwidth to students, and the first affordable home broadband started coming out), Napster got really popular. Napster wasn't particularly technically amazing -- really, it did the same thing that IRC did, but it in an automated fashion, and with less dependence upon the central server and more on the client nodes, all of which ran servents with the default client.
Gnutella was, perhaps, the first fully peer-to-peer protocol of the P2P filesharing programs that came out afterwards. The protocol provided no native way to get the address of a host on the P2P network. Thus, Gnutella clients had to be bootstrapped by having the user involved, thus creating a non-fully-peer-to-peer system that involved Gnutella and another network. A popular method was IRC or HTTP to introduce the non-peer-to-peer element, as people went to a web page or IRC server to obtain a list of other nodes on the network.
Today, P2P is a term that is instantly recognizable as referring to any of the current group of filesharing programs and their associated protocols, including Napster, eDonkey, Gnutella, kast, Freenet, FastTrack, Chord, and so forth. (Note that Freenet may be considered a filesharing program, though the files it deals with are small and sometimes automatically generated.) Technically, modern P2P clients are frequently not completely peer-to-peer, as there is generally some form of trusted server that is automatically queried to at least get an initial node list.
This is much the same thing as the use of the term "PC", referring to "personal computer". Yes, technically if one expands the acronym, it is inclusive of Macs. However, it is generally used as a shortened form of "IBM-compatible PC" -- otherwise, the common and accepted phrase "PC and Mac compatible" would be entirely nonsensical. (To be honest, most folks actually *mean* Windows-running IBM-compatible PC"). Terms change and evolve over time, like it or no.
To be fair, the Hindi/Hindu thing is a bit unusual for English speakers, and is frequently confused.
I'm sure that there are many equally strange things in English that muck with speakers of other languages (especially with all the tech-associated English acronyms and words being exported to other countries).
Though, to be fair, there are reasons that most folks here have such a negative impression of Microsoft that they're willing to stretch so far to bash them. Microsoft *did* sell technically inferior systems, *did* use rather nasty and misleading marketing for years, *did* work rather hard to ensure product lock-in, *did* leverage monopolies to ensure that other products of theirs beat superior ones, and *did* hide a lot of internals information that their competitors were better at providing, among other things.
So, yes, Microsoft probably gets the sharp end of the stick on Slashdot more than they deserve. However, a lot of this is pent-up dislike that has been building up in people that have been repeatedly screwed by Microsoft for years. It's not as if Microsoft is a complete innocent that's suddenly, for no good reason, being dragged through the coals by the community of knowledgeable techies.
I find this widespread dislike rather interesting WRT free market reactions to monopolies (which are supposed to break free markets). For years, people have been claiming that "Microsoft can screw over their customers if they want, because they're the only game in town." However, Microsoft's position has also become increasingly unstable, and difficult, as they're force to herd customers from step to step. Now, people are willing to go with non-Microsoft alternatives that may even be inferior in the short term, because they've been so badly burned by Microsoft in the past. It may be that better treatment to your customers is necessary, even *if* a company is a monopoly.
You're right that the grandparent is not flamebait, though.
I know Lucent as "the company that management scaled up too far, too fast, that as a result is a broken shell of their former selves". Lucent management's history of gambling isn't good.
On the other hand, I don't know her particular opinions at Lucent. She could have been the dissenting voice urging slower growth and caution. I rather doubt it, but it's possible.
Slashdot Mirror
The fact that antiplagiarism sites make money from their line of business (and the examples submitted by the students) is of no import, as long as they aren't selling the essays as part of an anthology or something.
The problem is that they can change their license at any time.
If their license stipulated that (a) upon dissolution of the company, all paper rights will be forfeited, (b) the paper rights may not be sold, (c) the paper rights are for exclusive use in detecting cheating, and (d) the license is nonexclusive (perhaps there's a generic email address that reports can be sent to to be entered into *all* the anticheating services, so that they recieve no business benefit in owning the paper as property -- only the academic communit as a whole really does -- then I'd be interested in seeing if folks still object).
I don't think that there are many legitimate concerns that the anticheating company could raise. The professor doen't have to do significantly more work. At least some of the students' concerns are addressed.
The second is for them to retain an escrow service to destroy their databases if they ever go out of business. This would ensure that if the company goes bottom up, my IP is protected.
How do you have an escrow service guarantee *destruction* of data?
It would be interesting if universities required students to place papers in some kind of international repository. This would be searchable, and could be read (and used as a reference). It would also serve as a marvelous plagiarism detector.
Linus is married to a woman. He has had several children with her. I'm not sure how much more heterosexual you get.
Oh, and forget dunking Linus. Everyone likes Linus, and he was getting up in front of a horde of his fans. You know who Linux folks would pay to dunk? McBride. You want to know what takes *balls* is standing in Speedos in front of a mass of people that hate you and saying "dunk me if you can".
First of all, a laptop doesn't take as much space as a desktop; just try to fit a desktop computer into a dining room or a living room, or even a bedroom, it's just damn unsightly and unweilding, let alone unportable, a laptop will fit into these with no trouble at all, and if you wish to you can unplug it in throw it into the drawer.
I don't think many people would try to put a computer in a dining room. I don't see a problem with putting it in a den (for Chrissake, we're talking about two feet by eight inches or something like that of desk space. It's not *that* bad).
The real benefits I see of a desktop replacement laptop (and I still prefer the real thing to a "desktop replacement"):
* The battery acts as a built-in UPS.
* You can move to a different room for one reason or another.
The drawbacks:
* All the crap in laptop BIOSes and stuff associated with power management. Laptops just plain do weird things occasionally. Too much custom stuff, not enough commodity.
* Most OSes other than Windows have pretty incomplete power-saving support. Even good ol' Linux.
* Prices. Laptops are still more expensive.
* Modularity. Desktops consist of all standard parts that I can cannibalize for other machines, swap out if something goes wrong, or can upgrade piecemeal. I can grab another motherboard or video card. Laptop manufacturers, in a desperate bid to keep their market from becoming a commodity, have avoided modularity and standardization of parts like the plague.
Hmm. Lessee. I'm not a WWI buff, but Germany definitely lost in 1815. They might have shoved troops into France, but I'm not sure whether they beat them.
Also, remember that there was an active French Resistance that took place composed of people who weren't happy with the government's decision.
Imagine some jackass like Bush (well, actually, despite all of Bush's failings, surrendering too early probably isn't one of them) doing something dumb and then everyone being held responsible and being joked about for the next century because of it.
Oh, and as a followup--remember that the Miracle of the Bread and Fish took place during a sermon that Jesus was giving. So, in fact, Jesus *was* placing the condition that they come to sermon at least *once* in order to be fed. I still agree with your general idea that the points that Jesus was advocating through his life as a whole could be more closely summed up by the BSD license, but I think that the example you selected probably could have been better chosen.
You may avoid helping the enemy, but you also won't help as many of the legitimately needy.
That, however, is in the short term. The FSF thesis (which I'm not going to try arguing for, just state as a plausible argument) is that promoting open source is beneficial in the long term. So, yes, in the short term, there may be a closed source software company that *would* act in a good manner that will benefit from your code donations. However, it may be to almost everyone's benefit if open source becomes the dominant form of software.
Which of these did Jesus do?
Well, Jesus took a BSD-like approach -- giving to both his allies and enemies. However, that isn't necessarily usable as a justification for what we should do. The complaint about the symbiotic and highly prolific nature of the GPL is that it tends to help its allies only, and then encourages them to spread it to other hosts. Jesus's goal was in moderating and reforming a religion that *already* had both of those properties and was spreading and gaining political influence (Judaism). He had no reason to advocate the institution of help-ally-only or spreading, which was already highly present.
Plus, let me reform the question. Suppose Jesus was walking along and met Queen Jezabel (yes, I'm aware of the anachronistic nature of this -- for the sake of discussion, let it ride). She had been abandoned by her followers, and was dying in the desert. Jesus takes out fish and bread, blesses it in the name of his Father, and offers the food to her. Jezabel, however, refused to eat unless Jesus first blessed the meal in the name of her own god. What Would Jesus Do, indeed?
This is how many GPL advocates feel about Microsoft. They have already offered to the world a marvelous collection of code. Companies are free to accept it, including Microsoft. However, Microsoft chooses *not* to accept the code -- they want it on their *own* terms, with all rights granted to Microsoft. They are certainly not constrainted to go "all GPL" -- if, for instance, they shipped GIMP instead of Windows Paint, they would not need to GPL all of Windows. However, they refuse to have any contact with the GPL ideology at all. They have made their choice. Should the GPL-using folks be expected to change, or should Microsoft? I'm not certain, but I don't think that it's nearly as clear as you've made out.
To be honest, CVS isn't all that hot as a VC system, compared to what could be done. The problem is that it's a pain in the ass to make a VC system, it's a pain in the ass to migrate from one to the other, and CVS has been there and free, so folks use it.
/proc out of box, this means that they can also do a fair amount of monitoring of what's going on.
Don't get me wrong -- using CVS is waaay better than no VC. CVS was the first VC system I used seriously (well, after a short stint with RCS). However, CVS is seriously hampered by trying to be highly compatible with RCS, which was never designed for the kinds of environments that CVS is used in.
Anyway, as to things that aren't that hot about CVS:
* CVS doesn't grok "text" files where the linefeed format matters. If you have a piece of software that uses a text file in CRLF format, you need to treat it as a binary format.
* CVS sucks -- badly -- from a security standpoint. The current feature branch is getting vaguely closer, fixing a huge number of symlink-related bugs present. Basically, something as simple as a repository where some folks have read access, some folks have read/write access, and some have no access to each module is a real pain to set up.
* CVS allows spoofing of version history. Bad, given that one reason folks like VC is that they treat it as auditable. CVS is *not* an auditing system that can be trusted for legal or security purposes.
* CVS does not grok the concept of files moving.
* CVS cannot version CVS metadata. This means that if you have a file checked in as text (accidentally), and at some point switch it to binary format, you must break all checkouts before the original date when you mark the file as binary.
* CVS understands things based on a file-by-file basis. While it's not too hard to write scripts to provide functionality like listing all tags used in a project, it's annoying that CVS can't handle this.
* CVS lacks some of the re-merging features that BitKeeper and more advanced VC systems have. I haven't needed to muck with this, but it's apparently one of the two big reasons that the Linux kernel folks don't use CVS.
* CVS can't do distributed, disconnected development. You have to have one server that everyone can talk to, full stop. This is the second major reason that the Linux kernel folks don't use CVS.
* CVS does not do atomic updates or checkouts across multiple files (as I said, CVS sees everything on a per-file basis). Frankly, our databases and filesystems all moved to transaction semantics long, long ago. A VC system has even less excuse not to have transaction support. CVS is way behind the times in terms of reliability -- theoretically, this can cause all kinds of nastiness.
* CVS makes it a real pain in the ass to delegate administrative access, and tends to not be particularly secure. For example, if I want to allow someone to add a module, and want some *subset* of the modules in a repository to generate commit notification messages, I need to give that person write access to CVSROOT/loginfo. Bad. (Again, you can write a program that provides this access, but it's not part of CVS.)
* The CVSWin GUI sucks, and hangs if CVS is processing anything. If you have anyone that doesn't use the CLI and uses Windows, life is annoying for them.
* Unless you want to do mucking about with secure shells, giving someone CVS write access means giving them shell access on the server. Because Linux (and, I suspect, most *IXes) don't support restricted
Really, to be honest, CVS was a cool system for when lots of people were using RCS. CVS's killer feature is RCS compatibility. Without this constraint, CVS would not have most of its drawbacks.
I haven't seriously checked out Subversion, but I'd like to see how well it stacks up. It certainly fixes at least some of the problems.
Err...runlevel scripts can certainly be read and modified.
The only difference is that someone sat down and imposed a bit of order on the chaos, making a nice, standard way to install and uninstall packages and provide runlevel functionality.
I am incredibly annoyed by some of the customization that is coming with recent Linux systems I've used.
Fine, but
Of course, there's a lot of software out there that won't compile on anything but Linux...Sometimes, that means you need to pick up a 2x4 and go find the author, because they've put in something gratuitously imcompatible through...laziness.
:-)
What kind of jerk *is* this guy?
Yeah, I think I'll "go after the Mozilla authors with a 2x4" because they've failed to provide native support for my sixth mouse button. Christ. What happened to "I want something done, so instead of making someone that *already* gave me a bunch of software for free miserable, I'll write a patch and contribute it so that others can enjoy"?
But it works surprisingly often. I won't go into details, and it's not exactly "emulation", but often a Linux binary can just be picked up and run on a BSD system (at least between i386 systems).
This is not compelling -- it makes BSD look like a Linux that works sometimes.
BSD has always considered it more important to let the advanced user do more, than to let the novice do more.
And what exactly is *that* supposed to mean? Linux shortchanges the advanced user? Give me a break.
"BSD users are a bunch of elitist self-centered rude snobs."
Yup. And proud of it.
Given the previous statement, I'm inclined to agree.
It's possible that BSD, due to its more technical and engineering background, ends up with elitism being more prevalent than in other communities.
Surrrreee...Linux is primarily produced by a bunch of fine-arts majors who don't really go in for technical things, you know?
With Linux, you've got the linux-kernel mailing list, which is practically all developers. And just kernel developers and maintainers. The make and cron and locate and tar developers and maintainers have their own lists off somewhere else. There are very well segregated gathering areas like mailing lists, newsgroups, and web forums, for admins, for programmers, and for end-users.
This is because most folks don't even have time to keep up with the flood of kernel development, much less everything else included. Breaking this up is a *good* thing.
And s/Linus/Theo/ would not apply to OpenBSD *how* again?
The problem is that Microsoft acts in ways that negatively impact the life of OSS folks (such as promoting .doc lockin). If you help Microsoft, you are helping someone who uses spare resources to repeatedly kick in you in the nuts.
Seriously. This reminds me of one of the startup articles that some of the early "Linux news" sites started running to *look* like someone actually submitted a real story, but was just the editors trying to jump-start discussion.
Thus, this rant; as a BSD person, I want to try to explain how BSD works in a way that Linux people can absorb.'
The server is feeding back 403s, which seems to make some sort of statement...
The HP's and the IBM's of the world are just saying that they'll lease the machine, administration, and pipe to the machine cheaper than what you'd buy it. And if you need more capacity quickly all you have to do is get on the phone and call them. If you've got too much capacity, then IBM will sell that to some other customer and you'll never notice the difference.
Hmm. Okay -- so the idea is that the cost savings come from (a) eliminating local IT staffs, and (b) reducing bandwidth supplied to given companies? The savings are on bandwidth and administration, not cycles?
According to benchmarks, even old versions of Java are within a factor of 2 in performance with C++. See Java Performance Comparison with C/C++.
You can get in this neighborhood, but it involves using object pools and the like -- significant optimizations. This is not just taking a C++ program and coding it in Java. Furthermore, these benchmarks are pretty optimal situations for Java -- straight factoring (presumably using primitive typtes, not objects, which avoids a lot of the performance problems in Java), file I/O (not compute or memory bound), memory allocations *using arrays only of primitives*, which avoids a major Java performance hit -- dealing with arrays of objects, which *requires* runtime type work.
In sum, if I were choosing a set of benchmarks to favor Java, I could not have chosen a better set.
Don't get me wrong. Java has very good applications. It's just that CPU-bound ones (what we're talking about, and what Sun has sold it as) are not one of them. For user-bound or network-bound systems, it provides fast development, and good error checking.
Why? A well written distributed application can scale to thousands of CPU's.
Okay, there are a couple of issues. My main point is that, well, imagine a line that looks like this: ":::::::::::" This line of ten colons represents all the CPU-bound realtime problems (about 10 orders of magnitude instructions per second) that can be solved on a desktop. The next line represents the range of problems that can be solved on a cluster of machines ":::" -- about three orders of magnitude beyond single-system problems. It's much more expensive to run a 1000 computer cluster than it is a single computer system. Now, in academic scientific computing, there are frequently people with a good handle on what kinds of requirements their algorithms require when they're writing the thing. However, Sun also doesn't sell a lot of "scalable systems" to academia. They do sell a lot to business, where there's a stunning number of incredibly awful programmers running around (any time I see "web and Java developer" I get scared -- there is a stunningly high proportion of really awful developers in said field). I stand by my claim that, for real world systems, using C++ alone will generally give an order of magnitude improvement ":" over Java. Chosing more intelligent algorithms can easily reduce a problem by many orders of magnitude, but since it's hard to predict whether you've had an incompement developer working on a system or a really good mathematician working on parallizing a fluid dynamics problem, we'll let that sit.
Now, remember that most very large jobs like the ones you mentioned (weather modeling, fluid dynamics, etc) do not need to be completed in a second. An hour, or even a day might work. If we're allowing a job to be completed in under three hours rather than in one second, the "single desktop" bar is suddenly extended by four more bars, while the "thousand computer cluster" remains the same. now we have "::::::::::::::" compared to ":::". So we have a little tiny, constantly moving window compared to a large bar -- and our ability to shift that window around is quite high, given our ability to use a different language or algorithm.
You don't think that eBay, or a bank, or an airline runs on 1 CPU, do you?
No. But much of that is for reliability reasons, not because the problem is computationally so difficult that a single P4 cannot solve it in a timely manner. About 1.5 billion (well, before September 11th) commercial passengers are carried worldwide by all airlines put together each year. That works out to about 47 passengers a second. The I/O bandwidth required to run a transaction-oriented database that can perform 47 transactions a second is below what a P4 and consumer motherboard can do by many, many orders of magnitude. Of course, it's a bit more complex than that -- airlanes have their own databases that must talk to airports, and probably more is done
My understanding of trademarks is that the system in question dates back (in the US) to the 1700s and manufactured goods -- where you had various craftsmen with their own mark identifying their work. If Thomas Jefferson used a "TJ" in a circle with a flower in the background to identify his silversmithing work (I'm sure his mark was something different), then it's pretty clearly benficial to society to allow him to enter that mark into a register somewhere and allow nobody else to use it. That way, people can't pass off cheap crap as authentic "Thomas Jefferson" work.
The question at hand is whether *marketing* (which existed in a far more rudimentary form at the time) associated with a brand should also recieve trademark protection -- i.e. once people have expressed any interest in your brand (which may be the only product they've heard of in the field), whether laws should be passed to ensure that they remain locked in to being *only* informed about that particular product. I don't see any reason why it should, or how it benefits society to do so. Suppose I walk into a pharmacy and ask for, oh, I don't know, Tylenol. I think that the pharmacist should *not*t be prohibited by law from saying "we just got in these new generics that people seem to like and cost half as much".
Now, that doesn't mean that there aren't trademark-infringing ways to muck with search engines. The idea of trademarks is to avoid consumer confusion. If you set up a *fake* Viagra website that *looks* like the official Pfizer website and buy "Viagra" or "Pfizer" as an AdWord, *then* you're engaging in deceptive marketing, and you can be nailed on trademark infringement (as well as potentially on criminal fraud charges).
However, this is wildly different from Chevy purchasing "Ford buy" as an AdWord. All that means is that someone is looking to buy a car, probably preferring a Ford, and if Chevy wants to try to convince them that a Chevy is a better deal by setting up www.why-chevy-kicks-ford-ass.info and directs people there...heck, I don't see any justification for making this illegal. It's clear to people that Chevy is a different product from a different manufacturer. It competes, and may be superior. This gives the consumer more information, which I tend to think is not a bad thing.
Frankly, I'd have the kid just plain masturbate once a day before getting on the Internet. She wants to get a Playboy subscription for him or something without additional commercial offerings associated with sex, great. The idea is to not have a horny 15-year-old being confronted with an option of getting sexual material by dropping $20.
Also, I would hope that said mother isn't hassling him about having porn or masturbating. Hell of a throwback to Victorian times, when Freud realized that, gee, sexual repression does really awful things to people.
Mmf. P2P has actually become a true word with different meaning than peer-to-peer.
The Internet is peer-to-peer. Lots of things are peer-to-peer. The phrase "peer-to-peer" goes *waaaay* back.
"P2P" only started life as an acronym for the insanely popular filesharing systems. These filesharing systems have a number of properties that differ from the conventional use of "peer=to-peer".
Most *Internet-based systems* (not the Internet itself) have traditionally been client-server. The reason why is pretty straightforward. Peer-to-peer implies that all hosts involved in a system are equal, and none have inherent privileges or rights greater than the others. The Internet doesn't provide a native way to locate "A computer that can give me the time, but may also ask me for the time", as a peer-to-peer system would imply. You generally set up a machine that's reasonably dedicated to a particular task, and then usually give it a DNS entry. Clients can contact this machine.
There were no real major protocols that implimented the use of servents (the term used to refer to hosts that are both client and server). There were some that came close -- IRC clients frequently could both send and recieve files, thus acting as DCC servents, but it was only a relatively small proportion of IRC servents that offered files (and, at any rate, IRC servers were still part of the game). There were plenty of protocols that *could* run over the Internet that operated as peer to peer -- any network games that used a virtual token-ring style system, such as Stuart Cheshire's excellent Bolo, would count -- but these were very small systems, and hampered by bandwidth constraints.
When bandwidth became less of an issue (colleges started providing government-subsidized bandwidth to students, and the first affordable home broadband started coming out), Napster got really popular. Napster wasn't particularly technically amazing -- really, it did the same thing that IRC did, but it in an automated fashion, and with less dependence upon the central server and more on the client nodes, all of which ran servents with the default client.
Gnutella was, perhaps, the first fully peer-to-peer protocol of the P2P filesharing programs that came out afterwards. The protocol provided no native way to get the address of a host on the P2P network. Thus, Gnutella clients had to be bootstrapped by having the user involved, thus creating a non-fully-peer-to-peer system that involved Gnutella and another network. A popular method was IRC or HTTP to introduce the non-peer-to-peer element, as people went to a web page or IRC server to obtain a list of other nodes on the network.
Today, P2P is a term that is instantly recognizable as referring to any of the current group of filesharing programs and their associated protocols, including Napster, eDonkey, Gnutella, kast, Freenet, FastTrack, Chord, and so forth. (Note that Freenet may be considered a filesharing program, though the files it deals with are small and sometimes automatically generated.) Technically, modern P2P clients are frequently not completely peer-to-peer, as there is generally some form of trusted server that is automatically queried to at least get an initial node list.
This is much the same thing as the use of the term "PC", referring to "personal computer". Yes, technically if one expands the acronym, it is inclusive of Macs. However, it is generally used as a shortened form of "IBM-compatible PC" -- otherwise, the common and accepted phrase "PC and Mac compatible" would be entirely nonsensical. (To be honest, most folks actually *mean* Windows-running IBM-compatible PC"). Terms change and evolve over time, like it or no.
To be fair, the Hindi/Hindu thing is a bit unusual for English speakers, and is frequently confused.
I'm sure that there are many equally strange things in English that muck with speakers of other languages (especially with all the tech-associated English acronyms and words being exported to other countries).
That would just make you want to get away from work all day and get home. Forget sexual harassment, this probably *would* impact productivity.
Though, to be fair, there are reasons that most folks here have such a negative impression of Microsoft that they're willing to stretch so far to bash them. Microsoft *did* sell technically inferior systems, *did* use rather nasty and misleading marketing for years, *did* work rather hard to ensure product lock-in, *did* leverage monopolies to ensure that other products of theirs beat superior ones, and *did* hide a lot of internals information that their competitors were better at providing, among other things.
So, yes, Microsoft probably gets the sharp end of the stick on Slashdot more than they deserve. However, a lot of this is pent-up dislike that has been building up in people that have been repeatedly screwed by Microsoft for years. It's not as if Microsoft is a complete innocent that's suddenly, for no good reason, being dragged through the coals by the community of knowledgeable techies.
I find this widespread dislike rather interesting WRT free market reactions to monopolies (which are supposed to break free markets). For years, people have been claiming that "Microsoft can screw over their customers if they want, because they're the only game in town." However, Microsoft's position has also become increasingly unstable, and difficult, as they're force to herd customers from step to step. Now, people are willing to go with non-Microsoft alternatives that may even be inferior in the short term, because they've been so badly burned by Microsoft in the past. It may be that better treatment to your customers is necessary, even *if* a company is a monopoly.
You're right that the grandparent is not flamebait, though.
I know Lucent as "the company that management scaled up too far, too fast, that as a result is a broken shell of their former selves". Lucent management's history of gambling isn't good.
On the other hand, I don't know her particular opinions at Lucent. She could have been the dissenting voice urging slower growth and caution. I rather doubt it, but it's possible.