No, the GPL is enforcable for simple copying. I don't think anyone has ever disagreed with that seriously (after all, the GPL let's you opt out of it at will and copy all you like, under the usual terms of copyright law).
The question here is, what am I modifying? Is it ultimately perfectly reasonable to write the code I did, and distribute it as my own work? Personally, I think the answer is yes. Why? Because, the entity making the change to the software is the compiler.
Imagine an artist requiring royaltees from a filter-maker for "modifying" the image of their art when photographers take a picture! That's pretty much the same thing as is going on here. The compiler provides the filter attachment, I provide the filter. CGI.pm itself is never modified.
However, I think that the classic issue that has stumped the traditional wisdom is not coverdd. That is the case of "interface definitions" that must be loaded and merged with your source code at compile time. These include C or C++ "header files", or the "modules" of Perl. In interpreted languages the issue gets really sticky because you can modify those external libraries at run-time.
For example, is this Perl module a derivative work?
package CGIOverride; use CGI; sub import {} package CGI; sub params { die } sub new { die } sub start_html { die } 1; __END__
Here I basically edit the CGI module, but I do it at compile-time. If the law has to start getting into compile-time vs. pre-compile-time distinctions, I think we're going to be in for a bumpy ride!
Even worse... one way to resolve the above is to say that I'm not editing CGI, I'm editing the CGI namespace. At that point, we have to decide if a namespace is something that is protected under copyright law! Are namepsaces just a loosely maintained analog of the domain name system? Is a Perl module or a C++ header analogous to a programmer's Web site? *shudder*
Little nitpick - Levels were introduced into old school RPG's for a way to show that your player is more skilled. Levels are outdated. In online games, keeping skills seperate and increasing them based on learning them makes for a more realistic and fun game.
This is also true in the "old school RPG's", by which I mean table-top dice-and-books RPGs that involve real role-playing.
Level-based systems are slowly becoming a thing of the past. Even the prototypical level-based game, D&D, has moved on and the most recent edition (called "the d20 system") is partly skill-based and partly level-based.
Skill-based systems are quite common, and there are many ways that they can work. There are point-driven systems, use-driven systems, and hybrids between those extremes.
I suggest that if you're looking for good gaming experiences, try tabletop gaming again. The Hero System has just released their 5th edition and GURPS is going strong with cool releases like GURPS: Discworld and GURPS: Imperial Rome.
Re:I was hoping they would wait.
on
New Red Hat Beta
·
· Score: 3, Interesting
1. KDE was never crippled. A release of 3.1 would have the same bluecurve theme that 3.0.5 did, so anyone who thinks bluecurve is the spawn of Satan, would likely think the same of this beta with or without a pre-release of KDE.
2. Red Hat does not hold up a release unless they absolutely have to, otherwise they would never release. Making the call to go ahead without some key new development is always agonizing, but I don't think we can reasonably armchair quarterback those calls. I'd rather than both RH and KDE wait and make sure everything is ready for the public than get it all early in RH8.1 and find it's broken.
3. Just because they're releasing a beta now doesn't mean that it's all final. If KDE 3.1 releases in time and has no significant changes from 3.0.5 that prevent fast Q/A, perhaps RH will include it.
4. I don't think it's entirely fair to ascribe Red Hat's release timetable (which has been at a pretty steady pace of 6 months per release since the early days) to liking Gnome better than KDE.
Red Hat has always released about every 6 months. Did you think this was a problem back at 4.0?
Re:PHP resolves some shortcomings of Perl
on
Professional PHP4
·
· Score: 3, Informative
I won't get into PHP-vs-Perl, as I think the two complement eachother nicely (if you realy know how to use mod_perl and PHP, you can do some amazing things with the Web which are not idealy suited to either one).
However, you are incorrect on some points:
Outstanding database support. PHP supports virtually every DB under the sun (although Berkeley DB is missing, oddly enough.) Perl seems limited to MySQL and PostgreSQL, and its really a kludge for the later. I've heard that this will be fixed in upcoming versions of Perl though.
Since version 4 (over 10 years ago) Perl has had access to Sybase and Oracle. Newer additions (from the past 5 years or so) include MySQL, PostgreSQL, CSV flat-file DBs, DB2, *DBM, and an ODBC interface layer for just about any database.
Speed. PHP is one of the fastest languages I've ever used. While it won't be replacing assembly or C, its definitely faster than Perl in most cases.
This depends wildly on what you're doing. PHP is pretty slow when it comes to handling deep, and complex data-structures, but quite fast when it comes to handling simple data like strings. Perl maintains a balance between these two, and an elegant interface to C and C++ for applications which need to speed up critical sections of code.
Portability. I can take PHP code off my Linux box and plop it onto an IIS server, or even one of those new Macintosh servers and have it run without having to change a single line of code. Try doing this with Perl! Its as though it was written in assembly, Perl requires that much rewriting.
My Perl programs run on Windows, MacOS/X, VMS, all UNIXen, and many other platforms. Dunno what you've had trouble with, but I suggest you may have had trouble with Perl because you were not familiar with it.
Graphics. PHP comes with a nice little graphics library. While I wouldn't use its to code the new Doom (VB would be a better choice!) its adequate for most web pages, and should be considered as a substitute for Flash for certain things. Perl lacks a graphics library of any kind.
This is so wildly untrue, it's amazing! Perl has some of the most comprehensive graphics handling possible. From OpenGL to the GD module to PDL, Perl can do anything from complex scientific simulation graphics to simple 2 and 3-D charts and graphs to line-drawing. PDL requires special note. It's a library for dealing with arbitrary binary data in a number of ways from performing vast arrays of numeric transformations (e.g. Fourier Transforms, and other matrix transformations) to rendering graphics to modifying image data. It's a god-send for the scientific community that previously had to deal with proprietary systems that were of dubious value given that they could not be modified.
There's even a comprehensive interface to The Gimp, which I wrote an article on for The Perl Journal.
The Perl resource that you probably are not aware of (based on your comments) is the Comprehensive Perl Archive Network (CPAN). There is a module list that gives you a nice index of everything that Perl can do that is not shipped with the binaries. Perl also provides a CPAN module that can be used to automatically download, compile and install anything from CPAN.
If somebody placed code under BSD license nobody could change license and code ownership
Correct.... and your point is? Once again, for clarification, this was my statement:
the BSD license is not about avoiding restrictions. It's about giving up rights.
And so it is. The BSD license gives up certain rights that are otherwise granted to a copyright holder. I've claimed at no time that the BSD license gives up all rights, but certainly it does relinquish some. That's the goal, after all.
One of the advantages of the BSD license for businesses is that there is no compensatory mechanism in the license, it's just a statement that the copyright holder felt they had too many rights, and they didn't want some of them.
Oh, and GPL is not about copyright as you wrote - it's about copyleft
And copyleft in turn is a way of using copyright as a tool to allow copying and modification of source code and binaries without losing access to the fruits of your labor. The GPL creates communities out of source code, which can be a hinderance to businesses who do not wish to be a part of that community. As we see with examples like IBM, Red Hat and many smallers companies, though, there is a class of business that can do quite well with GPLed software.
The thing that is going to take a long time to accept is that we're making software valueless, and instead placing that value on initial development and support. Of course, that only makes sense. The idea that a CD full of bits has any more value than that of the plastic is absurd. It's the work that goes into creating that CD and the work that it takes to support its use that have value.
More and more, I think that the companies that use software the most will become its patrons, and as that happens, the GPL is poised to help build the communities that those companies will interact through. You get GPLed software for free, but if you want to do something with it other than simply use it, there is a price. That price is that you do to others as was done to you: give back the source.
Personally, I think that's quite reasonable, but if you don't then I point you to the plethora of other licenses that are available.
"[With the BSD license] u can be commercial, or non-profit or mad scientist with it, and not have anyone sue you"
Bravo, and cool stuff eh? Of course, you can still be sued for any number of reasons, but I do understand your core point (regardless of the fact that no one has ever been sued over the GPL).
Now pay attention because I'm about to say something that you don't want to believe. That's all true for the GPL and any other truly open-source license.
If you could not "be commercial" with a GPL-licensed package, Red Hat would certainly be in a world of hurt, and would not be turning a profit.
Let's also be clear that the BSD license is not about avoiding restrictions. It's about giving up rights. You have certain rights over your creations under copyright law. The BSD license sacrifices those rights in favor of (hopefully) wider distribution and usage. It does not go quite so far as to place the work under the Public Domain, but gets damn close. A aplaud the generosity of the folks who make this sacrifice in the same way that I aplaud scientists who are willing to give up the fruits of their research, but not everyone is willing to make such a sacrifice.
Enter the GPL. By contrast with such unilateral sacrifice, the GPL sacrifices very few rights and only does so as part of an exchange which is fair to both parties. What's more, the GPL is 100% optional for anyone who wants to use a piece of software. That's right, if you want to use GNU Emacs and not accept the terms of the GPL you can. Here's a mind-blower: if you want to DISTRIBUTE a copy of GNU Emacs and not accept the terms of the GPL you can. You just have to do so within the restrictions of copyright law (which means that you must be able to demonstrate that a) you are the copyright holder or b) you are acting withing the definition of fair use or c) you have specific license from the copyright holder). These restrictions are not the GPL's they are copyright law's.
I'm not a license zealot. I've used the Artistic license, GPL, BSD, and worked on many a proprietary package. However, it really ticks me off when people try to bad-mouth a license without understanding it.
In general, when people use the term "lie with statistics", what they mean is producing statistics that obfuscate or mislead.
While doing so in a court could earn you the censure of the judge and even a contempt citation, it is not perjury.
For example, I could take the stand and say that, according to my carefully conducted research, 99 out of 100 people prefer curried yak shavings to McDonalds Hamburgers.
If asked if I conducted the survey in a country where curried yak-shavings are a popular snack-food, I would have to tell the truth, but otherwise I've lead the court to believe what I want without actualy lying.
Slashdot really needs an editor-in-cheif. It's not that they need someone to even out the stylistic content or even to fix the spelling (spalling, if you prefer), but constant streams of duplicate articles are just getting silly. Someone should at least know what's going up on the site.
I think the problem with that is that Slashdot is essentially a congress-of-peers at the editor level, and they don't want to relegate everyone but one to "culling the crap" status while one of them coordinates and edits.
I can sympathize, but is there any other way? Perhaps cull the crap to a "pre-post" list that we can comment on and point out duplicates and/or inaccuracies? That's been shot down before too.
I think you're missing the point. I think he was saying that it requires registration, which he does not have so he can't give you the link to the story. Just guessing. It was oddly worded.
The article referenced is quite clear on this point. It is quotoing the RIAA's announcements regarding income industry-wide (though presumably the RIAA's definitaion of "industry-wide" refers only to it's members).
The differnce between saying that the RIAA's income statistics are incorrect and saying that the NRA shot someone is that the NRA was likely not involved in the shooting, and likely did not colude to make the shooting happen the way it did.
The RIAA is directly reporting these statistics. They are the RIAA's collective industry statistics. Also, the RIAA members have been shown to actively colude to make these statistics what they are through price-fixing and other tactics.
On the point of calling the RIAA a monopoly, I think it's perfectly fair. Just as a corporation can act as a single entity even though it is made up of many individuals, so too does the RIAA act as a single entity for the purposes of controling retail sales of music and lobbying (i.e. buying politicians) for music-industry causes like passing the DMCA. BMI did not lobby to pass the DMCA independantly, the RIAA did. This is a tactic for gaining control over the market and over the technologies that affect the market by the RIAA.
Yes, you are correct, and that's the kind of optimization that I'm saying is the least of your worries.
The kind of optimization that's needed is engineering, not CS. Things like removing redundant functions that are spread across dozens of libraries, sharing storage for common items, etc. None of it is really along the lines of making a sort trade off speed for memory or the like.
Code optimization is actually the least of your worries. Most of the latency in modern desktops, for example, comes from memory access, not algorithmic slow-downs.
Try structuring the data better, and you will go far.
I'm drawing on my history in many firms. I've been in financial institutions (investment and banking), software companies, data services companies, and a dot com. The dot com wanted only some backups to become permaunent record.
"In the five years that I did phone support, my main problem was people that had been "in the business" for 12+ years and had never seen some of their misconceptions corrected"
You missed my point. It wasn't *my* misconceptions. What I said was in the 12+ years I've been doing this (not meant to impress you with my experience so much as impress upon you that I have a fairly good sample set) no one in the industry has ever asked me for a backup that wasn't for archival purposes unless something very unusual was going on (e.g. we're performing a paranoid backup before an upgrade).
Given that, I just don't see what the place of tape is in the picture. I've used DLT, 8mm, TK-50, TK-75, R2R Mag, etc. Each one of those media I've seen fail after months or years of storage, and I've never seen a tape last more than 5 years.
So, that's the bottom line for me. If someone asks me if we can back up to tape I say, sure but don't expect to be able to read that tape in a year. The response is often shocked disbelief (why would good folks like HP sell crap, they ask). All I can do is outline my experience and the experience of many of my fellow engineers. Then I give them the really bad news: how much it's going to cost to reliably back up and archive their data.
In the end most opt for tape and simply live in the "we'll get our data if we need it" dreamworld until a disaster happens....
Your distinction between backup and archival is interesting, but I've been in this business for 12+ years, and that's the first time I've heard of someone *not* expecting a backup to be archived by default (certainly, you make an exception for some short-term backups, but that's an exception, not the rule).
What you suggest a "backup" is for, is why I use netapps. Their snapshot feature provides me with not just online, but user-accessible backups that happen in a matter of seconds on whatever schedule you wish. They also require very nearly the least space possible (it's a block-by-block copy-on-write at it's core, which means that, e.g., a growing log file will not result in a backup of all of the old log data). You can then look at/mountpoint/.snapshot//your/files and see what they looked like in the past.
Add in netapp's snap-mirror and you have the first part of what I described (though I suggested rsync, since most people don't have netapps). Snap-mirror is basically a snapshot that is coppied over to a target netapp and applied like a diff. Snap-mirror allows you to keep two netapps as synchronized as you like with minimal data transfer. However, when I last used it, I did have some CPU contention issues, you may want to check with netapp about how it behaves now.
I counter with this: tapes rot too. In fact, any tape older than one year that I've had to go back to has been worthless (read: it had deteriorated data).
Tape is a really bad medium to trust, but we keep buying it because we can't think of a better solution. Personally, I think the way to go is just to give up and admit that disk is not cheap. You need to back up your data to a live mirror system with identical storage (hourly rsync does a nice job) and then you need to arrage a service that can back up your data to remote live mirror systems. Note that in both cases I said "live mirror". You don't want a backup sitting on a cold box because you never know the quality of it until you need it.
The remote backup part is expensive, but it's the only reliable way. You seed it by tape (full backup to tape, and mail them to the vendor) and then use dedicated lines to keep a regular incremental update going.
If one of those two backup systems fail you know about it right away and you fix it. No more tapes rotting on a shelf only to be discovered when your data goes south.
Ok, I grant your comment is funny, but I'm a Linux user (and sympathizer:) who grew up on BSD, and it really pains me to think that any OS (Solaris, Linux, HP/UX, etc) needs to be viewed as a competitor to BSD rather than a fellow citizen in the realm of UNIX and UNIX-derived OSes.
Each has its niche, and while some of those niches wane over time (e.g. SCO, IRIX, DG/UX), others flourish (Linux, FreeBSD, Solaris) and that's a good thing. They continue to flow into the containers that they define, rather than having to attack eachother as many products do.
You can find confirmation of this in the only source I would trust: coke. They made repeated comments in interviews post-new-coke-fiasco that both Pepsi and New Coke taste tested higher than Coke's original recipie, and that they initiated the whole flavor change project in response to their own confirmation of the Pepsi Challenge results.
If Coke's results had shown that Coke was better, I'd supspect their methods, but when a company A (bias toward answer 1) gets answer 1 and company B (bias toward answer 2) gets answer 1, I begin to accept the credibility of answer 1.
On the topic of doing google searches for testing done 20 years ago, and being shocked that you don't find that much info on-line... well, you can guess where I'm going with this:-)
However, there is an ok summary on the Urban Legends site which details among other things, "Batteries of well-controlled taste tests showed folks liked the taste of Pepsi better" All of the references they cite are print-publications (again, not shocking given the era).
That really wasn't much of an interview, and as far as I can tell, it was no fault of the Slashdot crowd. Some of the questions were very interesting and informative, but he engaged only two of them, and only as briefly as he could possibly manage (one with a link and one with a quick pat on the back to Wil).
Man, my opinion of him has always been mixed, but it went down a couple notches today!
No, bridges are unlike software because people are all required to use bridges in roughly the same way, and the problem domains that a single bridge must solve are fairly narrow.
A *much* better comparison would be a building. Buildings are complex things which are used by each occupant differently, and which have a very large number of problem domains to solve for.
The result? Buildings require a great deal of operational maintenance and until fairly recently (50 years ago or so) building a large building was fraught with failres large and small. Even today, as building construction has become much more modular and well-understood, we run into things like under-tested wind stress leading to the need to completely re-rivit an existing building (this happend to one of the skyscrapers that went up in the 80s in New York).
Slashdot Mirror
No, the GPL is enforcable for simple copying. I don't think anyone has ever disagreed with that seriously (after all, the GPL let's you opt out of it at will and copy all you like, under the usual terms of copyright law).
The question here is, what am I modifying? Is it ultimately perfectly reasonable to write the code I did, and distribute it as my own work? Personally, I think the answer is yes. Why? Because, the entity making the change to the software is the compiler.
Imagine an artist requiring royaltees from a filter-maker for "modifying" the image of their art when photographers take a picture! That's pretty much the same thing as is going on here. The compiler provides the filter attachment, I provide the filter. CGI.pm itself is never modified.
A good overview of the issues.
However, I think that the classic issue that has stumped the traditional wisdom is not coverdd. That is the case of "interface definitions" that must be loaded and merged with your source code at compile time. These include C or C++ "header files", or the "modules" of Perl. In interpreted languages the issue gets really sticky because you can modify those external libraries at run-time.
For example, is this Perl module a derivative work?
package CGIOverride;
use CGI;
sub import {}
package CGI;
sub params { die }
sub new { die }
sub start_html { die }
1;
__END__
Here I basically edit the CGI module, but I do it at compile-time. If the law has to start getting into compile-time vs. pre-compile-time distinctions, I think we're going to be in for a bumpy ride!
Even worse... one way to resolve the above is to say that I'm not editing CGI, I'm editing the CGI namespace. At that point, we have to decide if a namespace is something that is protected under copyright law! Are namepsaces just a loosely maintained analog of the domain name system? Is a Perl module or a C++ header analogous to a programmer's Web site? *shudder*
Little nitpick - Levels were introduced into old school RPG's for a way to show that your player is more skilled. Levels are outdated. In online games, keeping skills seperate and increasing them based on learning them makes for a more realistic and fun game.
This is also true in the "old school RPG's", by which I mean table-top dice-and-books RPGs that involve real role-playing.
Level-based systems are slowly becoming a thing of the past. Even the prototypical level-based game, D&D, has moved on and the most recent edition (called "the d20 system") is partly skill-based and partly level-based.
Skill-based systems are quite common, and there are many ways that they can work. There are point-driven systems, use-driven systems, and hybrids between those extremes.
I suggest that if you're looking for good gaming experiences, try tabletop gaming again. The Hero System has just released their 5th edition and GURPS is going strong with cool releases like GURPS: Discworld and GURPS: Imperial Rome.
1. KDE was never crippled. A release of 3.1 would have the same bluecurve theme that 3.0.5 did, so anyone who thinks bluecurve is the spawn of Satan, would likely think the same of this beta with or without a pre-release of KDE.
2. Red Hat does not hold up a release unless they absolutely have to, otherwise they would never release. Making the call to go ahead without some key new development is always agonizing, but I don't think we can reasonably armchair quarterback those calls. I'd rather than both RH and KDE wait and make sure everything is ready for the public than get it all early in RH8.1 and find it's broken.
3. Just because they're releasing a beta now doesn't mean that it's all final. If KDE 3.1 releases in time and has no significant changes from 3.0.5 that prevent fast Q/A, perhaps RH will include it.
4. I don't think it's entirely fair to ascribe Red Hat's release timetable (which has been at a pretty steady pace of 6 months per release since the early days) to liking Gnome better than KDE.
Red Hat has always released about every 6 months. Did you think this was a problem back at 4.0?
I won't get into PHP-vs-Perl, as I think the two complement eachother nicely (if you realy know how to use mod_perl and PHP, you can do some amazing things with the Web which are not idealy suited to either one).
However, you are incorrect on some points:
Outstanding database support. PHP supports virtually every DB under the sun (although Berkeley DB is missing, oddly enough.) Perl seems limited to MySQL and PostgreSQL, and its really a kludge for the later. I've heard that this will be fixed in upcoming versions of Perl though.
Since version 4 (over 10 years ago) Perl has had access to Sybase and Oracle. Newer additions (from the past 5 years or so) include MySQL, PostgreSQL, CSV flat-file DBs, DB2, *DBM, and an ODBC interface layer for just about any database.
The DBI module provides one uniform interface to all of these.
Speed. PHP is one of the fastest languages I've ever used. While it won't be replacing assembly or C, its definitely faster than Perl in most cases.
This depends wildly on what you're doing. PHP is pretty slow when it comes to handling deep, and complex data-structures, but quite fast when it comes to handling simple data like strings. Perl maintains a balance between these two, and an elegant interface to C and C++ for applications which need to speed up critical sections of code.
Portability. I can take PHP code off my Linux box and plop it onto an IIS server, or even one of those new Macintosh servers and have it run without having to change a single line of code. Try doing this with Perl! Its as though it was written in assembly, Perl requires that much rewriting.
My Perl programs run on Windows, MacOS/X, VMS, all UNIXen, and many other platforms. Dunno what you've had trouble with, but I suggest you may have had trouble with Perl because you were not familiar with it.
Graphics. PHP comes with a nice little graphics library. While I wouldn't use its to code the new Doom (VB would be a better choice!) its adequate for most web pages, and should be considered as a substitute for Flash for certain things. Perl lacks a graphics library of any kind.
This is so wildly untrue, it's amazing! Perl has some of the most comprehensive graphics handling possible. From OpenGL to the GD module to PDL, Perl can do anything from complex scientific simulation graphics to simple 2 and 3-D charts and graphs to line-drawing. PDL requires special note. It's a library for dealing with arbitrary binary data in a number of ways from performing vast arrays of numeric transformations (e.g. Fourier Transforms, and other matrix transformations) to rendering graphics to modifying image data. It's a god-send for the scientific community that previously had to deal with proprietary systems that were of dubious value given that they could not be modified.
There's even a comprehensive interface to The Gimp, which I wrote an article on for The Perl Journal.
The Perl resource that you probably are not aware of (based on your comments) is the Comprehensive Perl Archive Network (CPAN). There is a module list that gives you a nice index of everything that Perl can do that is not shipped with the binaries. Perl also provides a CPAN module that can be used to automatically download, compile and install anything from CPAN.
If somebody placed code under BSD license nobody could change license and code ownership
Correct.... and your point is? Once again, for clarification, this was my statement:
the BSD license is not about avoiding restrictions. It's about giving up rights.
And so it is. The BSD license gives up certain rights that are otherwise granted to a copyright holder. I've claimed at no time that the BSD license gives up all rights, but certainly it does relinquish some. That's the goal, after all.
One of the advantages of the BSD license for businesses is that there is no compensatory mechanism in the license, it's just a statement that the copyright holder felt they had too many rights, and they didn't want some of them.
Oh, and GPL is not about copyright as you wrote - it's about copyleft
And copyleft in turn is a way of using copyright as a tool to allow copying and modification of source code and binaries without losing access to the fruits of your labor. The GPL creates communities out of source code, which can be a hinderance to businesses who do not wish to be a part of that community. As we see with examples like IBM, Red Hat and many smallers companies, though, there is a class of business that can do quite well with GPLed software.
The thing that is going to take a long time to accept is that we're making software valueless, and instead placing that value on initial development and support. Of course, that only makes sense. The idea that a CD full of bits has any more value than that of the plastic is absurd. It's the work that goes into creating that CD and the work that it takes to support its use that have value.
More and more, I think that the companies that use software the most will become its patrons, and as that happens, the GPL is poised to help build the communities that those companies will interact through. You get GPLed software for free, but if you want to do something with it other than simply use it, there is a price. That price is that you do to others as was done to you: give back the source.
Personally, I think that's quite reasonable, but if you don't then I point you to the plethora of other licenses that are available.
"[With the BSD license] u can be commercial, or non-profit or mad scientist with it, and not have anyone sue you"
Bravo, and cool stuff eh? Of course, you can still be sued for any number of reasons, but I do understand your core point (regardless of the fact that no one has ever been sued over the GPL).
Now pay attention because I'm about to say something that you don't want to believe. That's all true for the GPL and any other truly open-source license.
If you could not "be commercial" with a GPL-licensed package, Red Hat would certainly be in a world of hurt, and would not be turning a profit.
Let's also be clear that the BSD license is not about avoiding restrictions. It's about giving up rights. You have certain rights over your creations under copyright law. The BSD license sacrifices those rights in favor of (hopefully) wider distribution and usage. It does not go quite so far as to place the work under the Public Domain, but gets damn close. A aplaud the generosity of the folks who make this sacrifice in the same way that I aplaud scientists who are willing to give up the fruits of their research, but not everyone is willing to make such a sacrifice.
Enter the GPL. By contrast with such unilateral sacrifice, the GPL sacrifices very few rights and only does so as part of an exchange which is fair to both parties. What's more, the GPL is 100% optional for anyone who wants to use a piece of software. That's right, if you want to use GNU Emacs and not accept the terms of the GPL you can. Here's a mind-blower: if you want to DISTRIBUTE a copy of GNU Emacs and not accept the terms of the GPL you can. You just have to do so within the restrictions of copyright law (which means that you must be able to demonstrate that a) you are the copyright holder or b) you are acting withing the definition of fair use or c) you have specific license from the copyright holder). These restrictions are not the GPL's they are copyright law's.
I'm not a license zealot. I've used the Artistic license, GPL, BSD, and worked on many a proprietary package. However, it really ticks me off when people try to bad-mouth a license without understanding it.
In general, when people use the term "lie with statistics", what they mean is producing statistics that obfuscate or mislead.
While doing so in a court could earn you the censure of the judge and even a contempt citation, it is not perjury.
For example, I could take the stand and say that, according to my carefully conducted research, 99 out of 100 people prefer curried yak shavings to McDonalds Hamburgers.
If asked if I conducted the survey in a country where curried yak-shavings are a popular snack-food, I would have to tell the truth, but otherwise I've lead the court to believe what I want without actualy lying.
IANAL, YMMV.
Good point. I guess I was equating monopoly and cartel, but they really aren't quite the same. Thanks for pointing it out.
Slashdot really needs an editor-in-cheif. It's not that they need someone to even out the stylistic content or even to fix the spelling (spalling, if you prefer), but constant streams of duplicate articles are just getting silly. Someone should at least know what's going up on the site.
I think the problem with that is that Slashdot is essentially a congress-of-peers at the editor level, and they don't want to relegate everyone but one to "culling the crap" status while one of them coordinates and edits.
I can sympathize, but is there any other way? Perhaps cull the crap to a "pre-post" list that we can comment on and point out duplicates and/or inaccuracies? That's been shot down before too.
I think you're missing the point. I think he was saying that it requires registration, which he does not have so he can't give you the link to the story. Just guessing. It was oddly worded.
So now we know what step 2 is!
:-)
"2. Fork gcc development for a major release"
The article referenced is quite clear on this point. It is quotoing the RIAA's announcements regarding income industry-wide (though presumably the RIAA's definitaion of "industry-wide" refers only to it's members).
The differnce between saying that the RIAA's income statistics are incorrect and saying that the NRA shot someone is that the NRA was likely not involved in the shooting, and likely did not colude to make the shooting happen the way it did.
The RIAA is directly reporting these statistics. They are the RIAA's collective industry statistics. Also, the RIAA members have been shown to actively colude to make these statistics what they are through price-fixing and other tactics.
On the point of calling the RIAA a monopoly, I think it's perfectly fair. Just as a corporation can act as a single entity even though it is made up of many individuals, so too does the RIAA act as a single entity for the purposes of controling retail sales of music and lobbying (i.e. buying politicians) for music-industry causes like passing the DMCA. BMI did not lobby to pass the DMCA independantly, the RIAA did. This is a tactic for gaining control over the market and over the technologies that affect the market by the RIAA.
Monopoly tactics? Yep.
Yes, you are correct, and that's the kind of optimization that I'm saying is the least of your worries.
The kind of optimization that's needed is engineering, not CS. Things like removing redundant functions that are spread across dozens of libraries, sharing storage for common items, etc. None of it is really along the lines of making a sort trade off speed for memory or the like.
Code optimization is actually the least of your worries. Most of the latency in modern desktops, for example, comes from memory access, not algorithmic slow-downs.
Try structuring the data better, and you will go far.
I'm drawing on my history in many firms. I've been in financial institutions (investment and banking), software companies, data services companies, and a dot com. The dot com wanted only some backups to become permaunent record.
Hope that helps.
"In the five years that I did phone support, my main problem was people that had been "in the business" for 12+ years and had never seen some of their misconceptions corrected"
You missed my point. It wasn't *my* misconceptions. What I said was in the 12+ years I've been doing this (not meant to impress you with my experience so much as impress upon you that I have a fairly good sample set) no one in the industry has ever asked me for a backup that wasn't for archival purposes unless something very unusual was going on (e.g. we're performing a paranoid backup before an upgrade).
Given that, I just don't see what the place of tape is in the picture. I've used DLT, 8mm, TK-50, TK-75, R2R Mag, etc. Each one of those media I've seen fail after months or years of storage, and I've never seen a tape last more than 5 years.
So, that's the bottom line for me. If someone asks me if we can back up to tape I say, sure but don't expect to be able to read that tape in a year. The response is often shocked disbelief (why would good folks like HP sell crap, they ask). All I can do is outline my experience and the experience of many of my fellow engineers. Then I give them the really bad news: how much it's going to cost to reliably back up and archive their data.
In the end most opt for tape and simply live in the "we'll get our data if we need it" dreamworld until a disaster happens....
Good points.
/mountpoint/.snapshot//your/files and see what they looked like in the past.
Your distinction between backup and archival is interesting, but I've been in this business for 12+ years, and that's the first time I've heard of someone *not* expecting a backup to be archived by default (certainly, you make an exception for some short-term backups, but that's an exception, not the rule).
What you suggest a "backup" is for, is why I use netapps. Their snapshot feature provides me with not just online, but user-accessible backups that happen in a matter of seconds on whatever schedule you wish. They also require very nearly the least space possible (it's a block-by-block copy-on-write at it's core, which means that, e.g., a growing log file will not result in a backup of all of the old log data). You can then look at
Add in netapp's snap-mirror and you have the first part of what I described (though I suggested rsync, since most people don't have netapps). Snap-mirror is basically a snapshot that is coppied over to a target netapp and applied like a diff. Snap-mirror allows you to keep two netapps as synchronized as you like with minimal data transfer. However, when I last used it, I did have some CPU contention issues, you may want to check with netapp about how it behaves now.
that disks will rot, so you can't trust them.
I counter with this: tapes rot too. In fact, any tape older than one year that I've had to go back to has been worthless (read: it had deteriorated data).
Tape is a really bad medium to trust, but we keep buying it because we can't think of a better solution. Personally, I think the way to go is just to give up and admit that disk is not cheap. You need to back up your data to a live mirror system with identical storage (hourly rsync does a nice job) and then you need to arrage a service that can back up your data to remote live mirror systems. Note that in both cases I said "live mirror". You don't want a backup sitting on a cold box because you never know the quality of it until you need it.
The remote backup part is expensive, but it's the only reliable way. You seed it by tape (full backup to tape, and mail them to the vendor) and then use dedicated lines to keep a regular incremental update going.
If one of those two backup systems fail you know about it right away and you fix it. No more tapes rotting on a shelf only to be discovered when your data goes south.
Ok, I grant your comment is funny, but I'm a Linux user (and sympathizer :) who grew up on BSD, and it really pains me to think that any OS (Solaris, Linux, HP/UX, etc) needs to be viewed as a competitor to BSD rather than a fellow citizen in the realm of UNIX and UNIX-derived OSes.
Each has its niche, and while some of those niches wane over time (e.g. SCO, IRIX, DG/UX), others flourish (Linux, FreeBSD, Solaris) and that's a good thing. They continue to flow into the containers that they define, rather than having to attack eachother as many products do.
You can find confirmation of this in the only source I would trust: coke. They made repeated comments in interviews post-new-coke-fiasco that both Pepsi and New Coke taste tested higher than Coke's original recipie, and that they initiated the whole flavor change project in response to their own confirmation of the Pepsi Challenge results.
:-)
If Coke's results had shown that Coke was better, I'd supspect their methods, but when a company A (bias toward answer 1) gets answer 1 and company B (bias toward answer 2) gets answer 1, I begin to accept the credibility of answer 1.
On the topic of doing google searches for testing done 20 years ago, and being shocked that you don't find that much info on-line... well, you can guess where I'm going with this
However, there is an ok summary on the Urban Legends site which details among other things, "Batteries of well-controlled taste tests showed folks liked the taste of Pepsi better" All of the references they cite are print-publications (again, not shocking given the era).
That really wasn't much of an interview, and as far as I can tell, it was no fault of the Slashdot crowd. Some of the questions were very interesting and informative, but he engaged only two of them, and only as briefly as he could possibly manage (one with a link and one with a quick pat on the back to Wil).
Man, my opinion of him has always been mixed, but it went down a couple notches today!
No, bridges are unlike software because people are all required to use bridges in roughly the same way, and the problem domains that a single bridge must solve are fairly narrow.
A *much* better comparison would be a building. Buildings are complex things which are used by each occupant differently, and which have a very large number of problem domains to solve for.
The result? Buildings require a great deal of operational maintenance and until fairly recently (50 years ago or so) building a large building was fraught with failres large and small. Even today, as building construction has become much more modular and well-understood, we run into things like under-tested wind stress leading to the need to completely re-rivit an existing building (this happend to one of the skyscrapers that went up in the 80s in New York).
f) and that involves at least 10,000 moving parts which must be manufactured by 20-30 individual supliers, and all of which are unique to this bridge.