I volunteer to go up into space and conduct a scientific experiment to determine whether a 2 week vacation in space increases or decreases the productivity of an opensource programmer upon return to earth.
This contest demonstrates the literary value of spam, so... spam is good! We ought to embrace it. The winning poem ought to be mailed out to as many email addresess as possible.
The opensource movement ought to contribute all of the addresses from all mailing lists, from all website registrations, from slashdot and freshmeat, and anywhere else.
The winning poem, which no doubt will be pretty damn funny, ought to be turned into a chain letter, requesting that you forward it to 12 friends. Furthermore, it ought to have a viral attachment that, when opened, mails it out to everyone in your address book.
With the collective might of the opensource movement behind it the resulting mailstorm ought to bring the net to its knees.
What happens to an ISP in the US if it refuses to go along with Carnivore? Wouldn't it get shut down at some point?
Is it really so different?
Maybe the Chinese are using their monitoring software to find people non-violently opposed to the government, whereas the US is using the monitoring software to find people who are violently opposed to the government.
In any case it's not as different as people are making it sound.
Imagine if an FBI raid on CNN resulting in the broadcaster going off the air for a few hours, or the website being shut down.
I think there's some bias here.
Sure, they probably have a search warrant. Sure, it's probably warranted. But this wouldn't be the first news organization had some information the police wanted or needed, and didn't hand it over. Journalists have these crazy ideas about protecting their sources, and don't always willingly give the police what they want.
But still, if it were a western mainstream media organization the police would be careful not to disrupt operations.
JSP is not a good scripting engine for Java in my opinion. It forces you to put all your code and your HTML together in one place. A real mess. I have the same problem with ASP and PHP.
WebMacro is a Java servlet template engine which allows you to separate this stuff. You write pure Java code in the back end, and straight up HTML with some formatting codes in the front.
Ebay's content is NOT in the public domain. It's fairly well established that putting something on a web-page does NOT make it public domain material. You have implicitly granted everyone the right to view your material on the web using ordinary means--but you have NOT given them permission to copy your work and put it up on their own site, or do anything else with it.
With search engines I would argue that the robots.txt spells out your intentions as to how you want your work used by spiders and so forth. It's your material, you have every right to decide how it's used.
I agree with everyone saying that Ebay is being *stupid* by disallowing search engine access: if it was my company, I'd open it up. But it isn't my company, and there is unfortunately no law against stupidity.
It's important to distinguish between what Ebay is legally entitled to do, and what would be intelligent behavior.
You guys might not like this, but I think the reasonable answer is that "robots.txt" should be obeyed. robots.txt is the file you can put on your website telling spiders which areas they should or should not access.
If you put up a robots.txt that forbids spidering your site, and someone spiders it, I think you are well within your rights to claim that that amounts to copyright infringement: a use of your work which you did not authorize (not even implicitly).
But you're a hypocrit and should get no help from the courts, in my opinion, if you allow search engines into your sites (open robots.txt) but you somehow claim your competitor is infringing your copyright when they index you with a metabrowser.
If you don't want to be metabrowsed then you ought to accept that you can't be spidered by search engines either--all or nothing, you ought not to pick and choose who can or cannot spider you.
1: release early, and release often. don't hold your source code internally until you think it is a perfect expression of your great coding skills. release it while it's still a pile of junk, and let everyone help you turn it into something truly useful.
2: admit outside developers into your team ASAP. you don't have to trust them early on: give them an opportunity to prove their track record by submitting add-on modules, patches, etc., from outside the core before letting them further into your source tree.
3: create a mailing list on day one and thank everyone who contributes to it for helping you
4: make your CVS archive available for anonymous checkout for everyone to access, not just developers.
5: make snapshots of the source tree on a regular basis for people who can't/won't get it by CVS (in other words, do everything you can go provide people with access to the code, no matter who they are)
6: run a bug tracking system publically, like bugzilla or scarab or some other.
7: interoperate with as many other opensource projects as you can. You will start out as a lonely independent but if you can combine with the efforts of other projects (by using them as modules, by encouraging them to use your code) then you'll grow faster.
8: show that you appreciate help--accept and incorporate people suggestions as soon as you can. help people to feel THEY own the source as much as you do.
9: refactor on a regular basis. oss projects get a lot of contributions and a lot of ideas put into them--that don't always jive. DO NOT be afraid to rework your basic design to make it all simple and sensible again. DO refactor constantly.
10: later, when you ahve more developers involed, encourage everyone to hang out on an IRC channel when they're coding, using, or working on the project. use communication tools like irc to grease the wheels of progress:-)
Do all that and your project should work out reasonably well--assuming you have a good idea to start out with.
Transferring ("assigning") copyright is DANGEROUS and I'm not sure the GPL or any other open-source software should be attempting to do this.
The problem is that the legal requirements to actually effect a transfer are complicated and difficult: the law wants to make sure that when you give up your copyrights, you really really meant to do that. I am not a lawyer, but my understanding is it requires an actual signature on an actual piece of paper--some unsigned statement posted to the internet or sent via email just won't do.
So all these copyright "assignments" that have supposedly given the FSF rights to a variety of software are probably unenforceable. This may be no big deal, but if people wander around relying on the idea that they've effected a copyright transfer when in fact they HAVE NOT, there could be bad consequences.
It is much easier to make a NON-EXCLUSIVE (and likely irrevocable) copyright grant, permitting the original author to anything at all they like with the software. That doesn't require a signature on paper--any statement in any written media (including email, web pages, etc.) will likely suffice. The contributor retains copyright ownership, but the original author gets to use the code in any way at all.
Both the contributor and the original author would then be able to go to bat in court for the software, as both would be copyright holders.
Of course, I'm not a lawyer... but people shouldn't get the idea that they understand all of the issues here. Copyright ASSIGNMENT (transferring ownership) is a difficult and thorny thing.
Steve Punter has a good site for Canadian cell users. Non-Canadians might want to have a look too since it has a great deal of information about different kinds of phones.
What makes it a Canadian site is that he's ridden around on his bike and MAPPED all the cells in the Toronto area. He documents how to do this, so maybe someone in another city wants to copy the technique and map their area too:-)
A lot of people have been talking about doing something about broken software patent law. I think now it is finally time that we should actually do things. There are at least two things we should do:
1-- Establish a pool of open software patents. Anyone can use any patent in the pool providing they agree to make all of their own patents (if any) available to everyone else in the pool. proprietary developers who want to use some of the patents in the pool may do so: if they add their own patents to the pool.
2-- Establish OSS patent language: you may use this software, but any patented material you add to it must be licensed to all users, etc.
3-- Support reasonable compromizes like the one Amazon is backing. Not the best of all possible worlds, but as someone said, better than a poke in the eye with a broomhandle.
My whole site is only 18k, with each page weighing in at around 2-3k. I don't think you need any graphics to make a useful website. Of course I'm not a designer so my pages are just plain and simple--but I like that.
www.semiotek.com: just plain text with some tables and some fonts and colours.
This solution is very similar, but a little different to the/usr/ports solution in BSD. It would be easier to build this autoconf idea on top of ports than on top of the existing package managers, because they're already very similar.
Brief intro for those unfamiliar with *BSD: To install "gimp" on FreeBSD you do this: "cd/usr/ports/graphics/gimp ; make install" and away it goes--it downloads gimp from wherever it needs to, notices that it depends on GTK so it downloads that, etc., and builds each thing it needs in a giant make script until the whole thing is installed on the machine.
The FreshMeat editorial makes it sound like this is a brand new cool idea--it's not, all of the *BSD's have worked this way for years. I really like it.
I would love to see Linux support something like this. The closest is Debian's apt, which has a mode for fetching and installing from source, but it's not as simple and direct as this/usr/ports solution.
Some comments on this way of doing things:
-- I *love* being able to browse through the filesystem to find out what packages I could possibly install. It's a very natural thing to do: if I want to browse graphically, I do so via netscape or some filemanger. Mostly, being a geek, I use "ls", "cd", and "locate" to find out what packages i might want to install.
-- It's less to learn. If you are already going to have to learn how to do "make install" in order to get packages installed outside of your package management system (you just HAVE to have the version released yesterday) then you have already learned what you need to know to install any other package.
-- It does support a binary packages system. Binary packages amount to doing the compile stage on someone else's server, the whole install process goes exaclty the same way except that ratehr than compiling the binaries, you fetch them.
-- It brings everyone closer to the source tree. It's natural to grow up from being a novice user, to being a bit of a code hacker. There the code is, in front of your face, begging you to look at it--many people say this will scare people off, but nothing *requires* you to look at the code; and it's incredibly tempting for the curious. I think this leads to more developers, and is the main reason why *BSD has been able to keep pace with Linux despite having many fewer users.
-- The filesystem is a concrete, easy to understand organization for the packages. I can visualize where things are and how they relate to one another. With other package managers, like RPM or DEB, the dependencies seem complicated and abstract. When there is a failure, I haven't got a clue what to do (well I do now, but I didn't used to). AT least with compiling when there is a failure I can kind of see that it is a file in this package that lives over here, and that is causing my problem. I may not know what to do, but I know where the problem "lives". This makes me a little more motivated ot try and fix it, possibly by trying to install that other package some different way or something. In theory deb is the same, but it just doesn't *feel* the same.
In my opinion the only package management approaches that anyone should seriously consider are the Debian approach (apt/dpkg) and the *BSD appraoch (ports, plus their package management tools that back it up). Both of these allow all kinds of fun stuff like upgrading your system live without rebooting; synchronizing on a daily basis with the most current version; and have intricate and strong concepts of dependencies between packages.
In theory, they are functionally equivalent--or close enough--but I prefer the filesystem based implementation that has source code at its heart. It not only seems more Unix-like to me, it seems more open.
The big counter-argument to all of this is that source is scary to average users, many of whom don't understand the filesystem at all. I figure this is no argument at all, because you can bury the compilation under a pretty GUI just as easily as any other dependency system. And if your user can't figure out a filesystem, they won't be installing stuff using *any* package manager: it'll be pre-installed, or nothing, for them.
First, release it from a country where the patents and trademarks do not apply. You might have to do some digging to figure that out. At the very least, that confuses the jurisdictional issues. Second, release it to the public domain. Third, release it anonymously. If you don't have the resources to fight the legal battles (and it sounds like you don't; and it also sounds like you might lose them) then the best thing you can do is simply make it available to those who might have the resources, or who might be in a better position to win the battles. For example, it might turn out that European users will be able to make use of your software, whereas U.S. users may not. Obviously since you haven't said what you are doing, I don't know:-)
GPL compatibility is important in any free software license, otherwise you cut yourself off from an enormous code base.
I am not worried about GPL zealots creating a GPL version out of spite. That version would offer users of it *fewer* rights than my version, so it would be at a disadvantage.
RMS has actually read a previous draft of my license and said that he thought it was fair to call it a free software license. It's changed since then, so I will have to resubmit it to him once the lawyer gets done with it--but since nothing has changed philosophically since then, I think that any problems he has with the license now will be small and correctable.
Also, the GPL uses the word "proprietary" correctly, and does allow for commercial use! I think you are just biased here. I can use GPL'd software on a commercial website, or as the back end of a commercial data system, etc.--the GPL has no problem with commercial use. What it has a problem with is the production of proprietary source code (meaning code which makes strong intellectual property claims, and uses those claims to deny access to the source--the word proprietary here literally means "property of", and refers to the statement of ownership).
I forwarded a previous draft of this license to RMS and he said it appeared to be a "free software" license as near as he could tell. I also have run previous drafts through the open-source approval list a few times. This version still has to go to a lawyer for review and legal tightening, at which point I will complete the OSS process, and resubmit it to the FSF for review.
Before you all tell me not to do this, here is why:
The LGPL (which this is similar to) is 11 pages, and none of my users are willing to read it. Since half of them run my Java servlet framework (WebMacro) on NT it isn't true that they have already heard of LGPL.
It allows a distributor like Red Hat to continue shipping CD's even if they contain a program on them with a violated license. Under LGPL they would have to recall the entire run.
It makes a stronger assertion about crediting the author--for web software, I would like it if my name appeared somewhere where the actual end users could look it up. Under LGPL/GPL your name only appears in the copyright statement, not in the list of authors.
The main thing is it is shorter, taking up two pages to the LGPL's 11.
Please review! You can send comments on the license to justin@vsdl.org.
XML doesn't solve this problem either. Writing a different stylesheet for each browser winds up being just as much work. The key is to get all of that work out of your source code, so that it is independent of the application. You can do that by using a template system.
The IBM example has multiple sources of documents feeding multiple target formats, where those targets are diverse--not just different forms of HTML, but different media altogether. In those cases XML is a big win.
The key insight into XML is that it should be used only where other solutions fall apart. XML is one of those technologies that is so general, so abstract, and so powerful that you can construct a solution for ANY problem.
The downside is that the solution will involve extra processing steps, extra stuff to be implemented, and impose on you a development model that might not always be convenient (not everything wants to be a document, or a conversion or transcoding between document formats).
However, there are many cases where XML is the only viable solution, and in those cases you're just glat you can solve the problem at all! A typical example is when you have documents coming from multiple sources, and you publish them to multiple targets. It's easy to see what the XML solution would look like--but the problem doesn't even fit into the other ways of doing things.
With WebMacro a common implementation strategy is to drop key XML objects into a template that is otherwise created through ordinary WebMacro HTML template gunk.
The advantage of this approach is that you can create the bread-and-butter stuff like shopping carts, authentication, login/logout, using ordinary Java servlet code and templates. (These things are nasty when you try and force them into a document model).
Then in the middle of your page somewhere you have your XML document, rendered using XSLT or something. You have other targets, besides your servlet, where you publish that same XML document, so the whole thing winds up being a rather pleasant mixture of two different programming paradigms.
Again, the key insight in this strategy is that you use XML for the parts of your problem where it is the only viable solution--and you do everything else the normal way (without the extra costs imposed by XML, since you don't need the extra power).
I worked in an SGML shop for a couple of years, and became smitten with SGML/XML. I set out to do absolutely everything I could in SGML/XML for awhile, before realizing that a traditional template tool (like WebMacro) was far more useful for typical bread and butter servlet programming.
I still use XML a lot, but now I use it intelligently, where it's needed!
With all due respect, an MCSE course isn't going to teach you what you need to know about designing an "enterprise network". You need real hard won experience to do that.
I would guess the guy who sets up a complex network at home is going to be further ahead than the guy who only read books about it, and wrote an MCSE exam.
When I was in school I lived in a residence with 15 other people, and another 12 next door. We wired the whole place up with ethernet, running it through the eves troughs, up the side of the house, etc., with lots of hubs and so forth. The network had two dial out SLIP lines (that dates me, huh?) which we shared between all of us. That means you've got a network with many hubs, a couple of servers, and two connections to the outside world. Most mid-size corporate networks look something like that. If you're talking about anything more complex, your MCSE isn't going to be nearly enough.
There is no limit to what you can learn playing around. The only thing you don't get out of playing with computers is a sense of how to work in a team--you're a hacker, until you've worked in a real world team.
But an MCSE won't give you team experience either, and since team experience is the only thing separating hackers from computing professionals, I'd say you lose on your MCSE.
Book learning is good--you don't need an MCSE to get that either. I read an average of one good technical book a month, and have been doing that since I was about 15. Since I'm 30 now, that's a lot of hard study. Except the few years I was in school (studying math), none of those were course work.
Note that I did not assert any anti-Microsoft sentiment in my message. I just don't believe in these stupid certification courses like MCSE, and CNE before that. They're all stuff and nonsense, and a Linux version wouldn't be any better.
If you learned a lot by playing around with NT while getting your MCSE, let me suggest to you that you would have learned just as much by playing around with NT without the MCSE. Similarly you would likely get more out of installing Linux and intelligently playing around with it, than you would by studying some ridiculously fat book and writing some dumb certification exam.
The MCSE/CNE/etc. is a bunch of drivel. An intelligent person might learn something quite by accident--most likely because intelligent people learn something from most anything they do.
It's my job to interview and hire programmers, at least part of the time. I will continue to view MCSE (or its Linux equivalent) as evidence that someone felt they were incompetent and didn't know how to educate themselves, so they turned to scam artists who promptly took their money. My experience interviewing people is that the MCSE (or other style certification) candidates went through that cert process because they were alien to the field and didn't know where to start. The MCSE, in general, doesn't solve that problem.
The reason these MCSE/etc. things exists is mythical: there are supposedly companies out there who receive so many resumes that they need to look for the "certified" candidates just to reduce the stack somewhat. This isn't true. Any competent technical person can quickly work through a stack of resumes and pick out the ones that look promising.
The real problem is HR departments--when someone who is not qualified reviews the resumes and pretends to select the ones that are "interesting". These incompetent HR drones are likely the best justification that the certification programs have. But rather than create a certificaion process, the right thing to do is fire the HR drone and give the stack of resumes to someone qualified to read them.
If you want to find good people you have to do hard work to find them. And anyway, contrary to the myth above, there simply aren't that many qualified people out there. I do NOT get a huge stack of resumes when I go looking for good people--it's a sellers market right now.
...met someone with an MCSE who knew what they were doing, nor have I met any CNE or CNA who had a clue either. I wouldn't expect an LNE or LNA or LCSE or whatever it winds up being called to be any smarter.
Slashdot Mirror
I volunteer to go up into space and conduct a scientific experiment to determine whether a 2 week vacation in space increases or decreases the productivity of an opensource programmer upon return to earth.
Any hope of keeping existing customers flew out the window already, they might as well give up.
This contest demonstrates the literary value of spam, so... spam is good! We ought to embrace it. The winning poem ought to be mailed out to as many email addresess as possible.
The opensource movement ought to contribute all of the addresses from all mailing lists, from all website registrations, from slashdot and freshmeat, and anywhere else.
The winning poem, which no doubt will be pretty damn funny, ought to be turned into a chain letter, requesting that you forward it to 12 friends. Furthermore, it ought to have a viral attachment that, when opened, mails it out to everyone in your address book.
With the collective might of the opensource movement behind it the resulting mailstorm ought to bring the net to its knees.
What happens to an ISP in the US if it refuses to go along with Carnivore? Wouldn't it get shut down at some point?
Is it really so different?
Maybe the Chinese are using their monitoring software to find people non-violently opposed to the government, whereas the US is using the monitoring software to find people who are violently opposed to the government.
In any case it's not as different as people are making it sound.
Imagine if an FBI raid on CNN resulting in the broadcaster going off the air for a few hours, or the website being shut down.
I think there's some bias here.
Sure, they probably have a search warrant. Sure, it's probably warranted. But this wouldn't be the first news organization had some information the police wanted or needed, and didn't hand it over. Journalists have these crazy ideas about protecting their sources, and don't always willingly give the police what they want.
But still, if it were a western mainstream media organization the police would be careful not to disrupt operations.
I think there must be some bias here.
otherwise someone worked too hard.
JSP is not a good scripting engine for Java in my opinion. It forces you to put all your code and your HTML together in one place. A real mess. I have the same problem with ASP and PHP.
Check out WebMacro: webmacro.org
WebMacro is a Java servlet template engine which allows you to separate this stuff. You write pure Java code in the back end, and straight up HTML with some formatting codes in the front.
It makes everything really clean.
Ebay's content is NOT in the public domain. It's fairly well established that putting something on a web-page does NOT make it public domain material. You have implicitly granted everyone the right to view your material on the web using ordinary means--but you have NOT given them permission to copy your work and put it up on their own site, or do anything else with it.
With search engines I would argue that the robots.txt spells out your intentions as to how you want your work used by spiders and so forth. It's your material, you have every right to decide how it's used.
I agree with everyone saying that Ebay is being *stupid* by disallowing search engine access: if it was my company, I'd open it up. But it isn't my company, and there is unfortunately no law against stupidity.
It's important to distinguish between what Ebay is legally entitled to do, and what would be intelligent behavior.
You guys might not like this, but I think the reasonable answer is that "robots.txt" should be obeyed. robots.txt is the file you can put on your website telling spiders which areas they should or should not access.
If you put up a robots.txt that forbids spidering your site, and someone spiders it, I think you are well within your rights to claim that that amounts to copyright infringement: a use of your work which you did not authorize (not even implicitly).
But you're a hypocrit and should get no help from the courts, in my opinion, if you allow search engines into your sites (open robots.txt) but you somehow claim your competitor is infringing your copyright when they index you with a metabrowser.
If you don't want to be metabrowsed then you ought to accept that you can't be spidered by search engines either--all or nothing, you ought not to pick and choose who can or cannot spider you.
Here are the golden rules:
:-)
1: release early, and release often. don't hold your source code internally until you think it is a perfect expression of your great coding skills. release it while it's still a pile of junk, and let everyone help you turn it into something truly useful.
2: admit outside developers into your team ASAP. you don't have to trust them early on: give them an opportunity to prove their track record by submitting add-on modules, patches, etc., from outside the core before letting them further into your source tree.
3: create a mailing list on day one and thank everyone who contributes to it for helping you
4: make your CVS archive available for anonymous checkout for everyone to access, not just developers.
5: make snapshots of the source tree on a regular basis for people who can't/won't get it by CVS (in other words, do everything you can go provide people with access to the code, no matter who they are)
6: run a bug tracking system publically, like bugzilla or scarab or some other.
7: interoperate with as many other opensource projects as you can. You will start out as a lonely independent but if you can combine with the efforts of other projects (by using them as modules, by encouraging them to use your code) then you'll grow faster.
8: show that you appreciate help--accept and incorporate people suggestions as soon as you can. help people to feel THEY own the source as much as you do.
9: refactor on a regular basis. oss projects get a lot of contributions and a lot of ideas put into them--that don't always jive. DO NOT be afraid to rework your basic design to make it all simple and sensible again. DO refactor constantly.
10: later, when you ahve more developers involed, encourage everyone to hang out on an IRC channel when they're coding, using, or working on the project. use communication tools like irc to grease the wheels of progress
Do all that and your project should work out reasonably well--assuming you have a good idea to start out with.
Transferring ("assigning") copyright is DANGEROUS and I'm not sure the GPL or any other open-source software should be attempting to do this.
The problem is that the legal requirements to actually effect a transfer are complicated and difficult: the law wants to make sure that when you give up your copyrights, you really really meant to do that. I am not a lawyer, but my understanding is it requires an actual signature on an actual piece of paper--some unsigned statement posted to the internet or sent via email just won't do.
So all these copyright "assignments" that have supposedly given the FSF rights to a variety of software are probably unenforceable. This may be no big deal, but if people wander around relying on the idea that they've effected a copyright transfer when in fact they HAVE NOT, there could be bad consequences.
It is much easier to make a NON-EXCLUSIVE (and likely irrevocable) copyright grant, permitting the original author to anything at all they like with the software. That doesn't require a signature on paper--any statement in any written media (including email, web pages, etc.) will likely suffice. The contributor retains copyright ownership, but the original author gets to use the code in any way at all.
Both the contributor and the original author would then be able to go to bat in court for the software, as both would be copyright holders.
Of course, I'm not a lawyer... but people shouldn't get the idea that they understand all of the issues here. Copyright ASSIGNMENT (transferring ownership) is a difficult and thorny thing.
A Canadian law firm has a couple of good articles up on licensing, copyight, etc.
legal documents
I found these quite useful.
Steve Punter has a good site for Canadian cell users. Non-Canadians might want to have a look too since it has a great deal of information about different kinds of phones.
:-)
What makes it a Canadian site is that he's ridden around on his bike and MAPPED all the cells in the Toronto area. He documents how to do this, so maybe someone in another city wants to copy the technique and map their area too
A lot of people have been talking about doing something about broken software patent law. I think now it is finally time that we should actually do things. There are at least two things we should do:
1-- Establish a pool of open software patents. Anyone can use any patent in the pool providing they agree to make all of their own patents (if any) available to everyone else in the pool. proprietary developers who want to use some of the patents in the pool may do so: if they add their own patents to the pool.
2-- Establish OSS patent language: you may use this software, but any patented material you add to it must be licensed to all users, etc.
3-- Support reasonable compromizes like the one Amazon is backing. Not the best of all possible worlds, but as someone said, better than a poke in the eye with a broomhandle.
What are we waiting for?
My whole site is only 18k, with each page weighing in at around 2-3k. I don't think you need any graphics to make a useful website. Of course I'm not a designer so my pages are just plain and simple--but I like that.
www.semiotek.com: just plain text with some tables and some fonts and colours.
This is great news. I had been holding the WebMacro servlet framework to 1.1.8 because there wasn't good support for Java2 on free OS's.
Now I can move it forward to Java2!
This solution is very similar, but a little different to the /usr/ports solution in BSD. It would be easier to build this autoconf idea on top of ports than on top of the existing package managers, because they're already very similar.
/usr/ports/graphics/gimp ; make install" and away it goes--it downloads gimp from wherever it needs to, notices that it depends on GTK so it downloads that, etc., and builds each thing it needs in a giant make script until the whole thing is installed on the machine.
/usr/ports solution.
Brief intro for those unfamiliar with *BSD: To install "gimp" on FreeBSD you do this: "cd
The FreshMeat editorial makes it sound like this is a brand new cool idea--it's not, all of the *BSD's have worked this way for years. I really like it.
I would love to see Linux support something like this. The closest is Debian's apt, which has a mode for fetching and installing from source, but it's not as simple and direct as this
Some comments on this way of doing things:
-- I *love* being able to browse through the filesystem to find out what packages I could possibly install. It's a very natural thing to do: if I want to browse graphically, I do so via netscape or some filemanger. Mostly, being a geek, I use "ls", "cd", and "locate" to find out what packages i might want to install.
-- It's less to learn. If you are already going to have to learn how to do "make install" in order to get packages installed outside of your package management system (you just HAVE to have the version released yesterday) then you have already learned what you need to know to install any other package.
-- It does support a binary packages system. Binary packages amount to doing the compile stage on someone else's server, the whole install process goes exaclty the same way except that ratehr than compiling the binaries, you fetch them.
-- It brings everyone closer to the source tree. It's natural to grow up from being a novice user, to being a bit of a code hacker. There the code is, in front of your face, begging you to look at it--many people say this will scare people off, but nothing *requires* you to look at the code; and it's incredibly tempting for the curious. I think this leads to more developers, and is the main reason why *BSD has been able to keep pace with Linux despite having many fewer users.
-- The filesystem is a concrete, easy to understand organization for the packages. I can visualize where things are and how they relate to one another. With other package managers, like RPM or DEB, the dependencies seem complicated and abstract. When there is a failure, I haven't got a clue what to do (well I do now, but I didn't used to). AT least with compiling when there is a failure I can kind of see that it is a file in this package that lives over here, and that is causing my problem. I may not know what to do, but I know where the problem "lives". This makes me a little more motivated ot try and fix it, possibly by trying to install that other package some different way or something. In theory deb is the same, but it just doesn't *feel* the same.
In my opinion the only package management approaches that anyone should seriously consider are the Debian approach (apt/dpkg) and the *BSD appraoch (ports, plus their package management tools that back it up). Both of these allow all kinds of fun stuff like upgrading your system live without rebooting; synchronizing on a daily basis with the most current version; and have intricate and strong concepts of dependencies between packages.
In theory, they are functionally equivalent--or close enough--but I prefer the filesystem based implementation that has source code at its heart. It not only seems more Unix-like to me, it seems more open.
The big counter-argument to all of this is that source is scary to average users, many of whom don't understand the filesystem at all. I figure this is no argument at all, because you can bury the compilation under a pretty GUI just as easily as any other dependency system. And if your user can't figure out a filesystem, they won't be installing stuff using *any* package manager: it'll be pre-installed, or nothing, for them.
Just my $0.02
First, release it from a country where the patents and trademarks do not apply. You might have to do some digging to figure that out. At the very least, that confuses the jurisdictional issues. Second, release it to the public domain. Third, release it anonymously. If you don't have the resources to fight the legal battles (and it sounds like you don't; and it also sounds like you might lose them) then the best thing you can do is simply make it available to those who might have the resources, or who might be in a better position to win the battles. For example, it might turn out that European users will be able to make use of your software, whereas U.S. users may not. Obviously since you haven't said what you are doing, I don't know :-)
GPL compatibility is important in any free software license, otherwise you cut yourself off from an enormous code base.
I am not worried about GPL zealots creating a GPL version out of spite. That version would offer users of it *fewer* rights than my version, so it would be at a disadvantage.
RMS has actually read a previous draft of my license and said that he thought it was fair to call it a free software license. It's changed since then, so I will have to resubmit it to him once the lawyer gets done with it--but since nothing has changed philosophically since then, I think that any problems he has with the license now will be small and correctable.
Also, the GPL uses the word "proprietary" correctly, and does allow for commercial use! I think you are just biased here. I can use GPL'd software on a commercial website, or as the back end of a commercial data system, etc.--the GPL has no problem with commercial use. What it has a problem with is the production of proprietary source code (meaning code which makes strong intellectual property claims, and uses those claims to deny access to the source--the word proprietary here literally means "property of", and refers to the statement of ownership).
I am working on a simpler license here:
Simple Public License
I forwarded a previous draft of this license to RMS and he said it appeared to be a "free software" license as near as he could tell. I also have run previous drafts through the open-source approval list a few times. This version still has to go to a lawyer for review and legal tightening, at which point I will complete the OSS process, and resubmit it to the FSF for review.
Before you all tell me not to do this, here is why:
The main thing is it is shorter, taking up two pages to the LGPL's 11.
Please review! You can send comments on the license to justin@vsdl.org.
XML doesn't solve this problem either. Writing a different stylesheet for each browser winds up being just as much work. The key is to get all of that work out of your source code, so that it is independent of the application. You can do that by using a template system.
The IBM example has multiple sources of documents feeding multiple target formats, where those targets are diverse--not just different forms of HTML, but different media altogether. In those cases XML is a big win.
The key insight into XML is that it should be used only where other solutions fall apart. XML is one of those technologies that is so general, so abstract, and so powerful that you can construct a solution for ANY problem.
The downside is that the solution will involve extra processing steps, extra stuff to be implemented, and impose on you a development model that might not always be convenient (not everything wants to be a document, or a conversion or transcoding between document formats).
However, there are many cases where XML is the only viable solution, and in those cases you're just glat you can solve the problem at all! A typical example is when you have documents coming from multiple sources, and you publish them to multiple targets. It's easy to see what the XML solution would look like--but the problem doesn't even fit into the other ways of doing things.
With WebMacro a common implementation strategy is to drop key XML objects into a template that is otherwise created through ordinary WebMacro HTML template gunk.
The advantage of this approach is that you can create the bread-and-butter stuff like shopping carts, authentication, login/logout, using ordinary Java servlet code and templates. (These things are nasty when you try and force them into a document model).
Then in the middle of your page somewhere you have your XML document, rendered using XSLT or something. You have other targets, besides your servlet, where you publish that same XML document, so the whole thing winds up being a rather pleasant mixture of two different programming paradigms.
Again, the key insight in this strategy is that you use XML for the parts of your problem where it is the only viable solution--and you do everything else the normal way (without the extra costs imposed by XML, since you don't need the extra power).
I worked in an SGML shop for a couple of years, and became smitten with SGML/XML. I set out to do absolutely everything I could in SGML/XML for awhile, before realizing that a traditional template tool (like WebMacro) was far more useful for typical bread and butter servlet programming.
I still use XML a lot, but now I use it intelligently, where it's needed!
With all due respect, an MCSE course isn't going to teach you what you need to know about designing an "enterprise network". You need real hard won experience to do that.
I would guess the guy who sets up a complex network at home is going to be further ahead than the guy who only read books about it, and wrote an MCSE exam.
When I was in school I lived in a residence with 15 other people, and another 12 next door. We wired the whole place up with ethernet, running it through the eves troughs, up the side of the house, etc., with lots of hubs and so forth. The network had two dial out SLIP lines (that dates me, huh?) which we shared between all of us. That means you've got a network with many hubs, a couple of servers, and two connections to the outside world. Most mid-size corporate networks look something like that. If you're talking about anything more complex, your MCSE isn't going to be nearly enough.
There is no limit to what you can learn playing around. The only thing you don't get out of playing with computers is a sense of how to work in a team--you're a hacker, until you've worked in a real world team.
But an MCSE won't give you team experience either, and since team experience is the only thing separating hackers from computing professionals, I'd say you lose on your MCSE.
Book learning is good--you don't need an MCSE to get that either. I read an average of one good technical book a month, and have been doing that since I was about 15. Since I'm 30 now, that's a lot of hard study. Except the few years I was in school (studying math), none of those were course work.
Note that I did not assert any anti-Microsoft sentiment in my message. I just don't believe in these stupid certification courses like MCSE, and CNE before that. They're all stuff and nonsense, and a Linux version wouldn't be any better.
If you learned a lot by playing around with NT while getting your MCSE, let me suggest to you that you would have learned just as much by playing around with NT without the MCSE. Similarly you would likely get more out of installing Linux and intelligently playing around with it, than you would by studying some ridiculously fat book and writing some dumb certification exam.
The MCSE/CNE/etc. is a bunch of drivel. An intelligent person might learn something quite by accident--most likely because intelligent people learn something from most anything they do.
It's my job to interview and hire programmers, at least part of the time. I will continue to view MCSE (or its Linux equivalent) as evidence that someone felt they were incompetent and didn't know how to educate themselves, so they turned to scam artists who promptly took their money. My experience interviewing people is that the MCSE (or other style certification) candidates went through that cert process because they were alien to the field and didn't know where to start. The MCSE, in general, doesn't solve that problem.
The reason these MCSE/etc. things exists is mythical: there are supposedly companies out there who receive so many resumes that they need to look for the "certified" candidates just to reduce the stack somewhat. This isn't true. Any competent technical person can quickly work through a stack of resumes and pick out the ones that look promising.
The real problem is HR departments--when someone who is not qualified reviews the resumes and pretends to select the ones that are "interesting". These incompetent HR drones are likely the best justification that the certification programs have. But rather than create a certificaion process, the right thing to do is fire the HR drone and give the stack of resumes to someone qualified to read them.
If you want to find good people you have to do hard work to find them. And anyway, contrary to the myth above, there simply aren't that many qualified people out there. I do NOT get a huge stack of resumes when I go looking for good people--it's a sellers market right now.
...met someone with an MCSE who knew what they were doing, nor have I met any CNE or CNA who had a clue either. I wouldn't expect an LNE or LNA or LCSE or whatever it winds up being called to be any smarter.