I did imply that the GPL enslaves people. That was an example of sloppy rhetoric, and I apologise.
The GPL doesn't enslave people; it merely reduces their rights. It also claims that it's increasing people's freedom.
It lies.
The BSD or XFree or Python licenses increase freedom across the board. THEY are the licenses which result in freedom. If the only alternative to freedom is slavery, the GPL _is_ slavery. Of course, that's nonsense, but that's what the GPL promoters say all the time.
In fact, the only reason to use the GPL is because you prize pragmatism about principle.
"But if you consider denying the right to own slaves to be an advancement why don't you see the same progress in software made by the GPL?"
Good question. The answer is:/because proprietary software isn't slavery,/ any more than copying licenced software is theft. (It's copyright violation, not theft.)
Both are bad. Neither one is the evil that its opponents claim.
Prop SW (unlike slavery) forces nobody to do anything. It can't. In fact, its disutility is so high that for many people, an otherwise inferior freeware will displace it (freeware in the sense merely of freely distributable _binaries_).
The first rule of licenses is that whoever makes the code makes the rules. So you're safe if you're allowed to make the license -- just use the GPL and attach a clause to it pointing out that the output is considered a derivative work of the input, NOT of the Program (or something similar).
The Artistic Licence is written with this in mind for even very complex transforms. You might take a look at it.
And finally, I dislike the GPL. It has a VERY good goal; but its means to that end are repressive. I don't want my software free if it enslaves people.
My ideal license is BSD-style (minus the attribution clause), but I would make the special note (not in the license) that I did not want my program to be used in a proprietary system.
Moral people are free to use my program in moral ways; I'm not concerned about the behavior of immoral people.
I maintain an ancient but popular free game named Omega (see my web page). When I took over maintainance, it have been almost five years since the last substantive change.
A comabination of bad code, almost superb design, and bad licence had killed it. The design was so good that any programmer who started working with it was immediately tempted to upgrade all the code to fit it (an unrewarding task which caused every one of them to give up almost immediately), and the license not only stated that no money could be made on it, but also forbade the distribution of modifications without the author's permission.
The first thing I did was rewrite the UI for the inventory (it'd been a sore point for everyone; hard to learn and hard to use). I showed that to the author and the current maintainer; the maintainer gave me permission to take over, and the author gave me permission to change the license. Working with him, I chose the LGPL, modified to fit the needs of an expandible game (more on this later).
In just a couple of days, I started recieving offers of help from people who had been working on Omega for all those years. The sheer volume of fixed code was almost incredible. Even when I was drawn aside for several months by my work schedule, their work proceeded. If code had been money, my investment in the inventory code would have paid off hundredfold;-).
I credit this partially to the resumption of development on a formerly-thought-dead project (which isn't something most people have an option for), but also to the change in license.
The license fits my idea of gaming. Specifically, I wanted the game to be free, but at the same time I also wanted it to have secrets -- as this article points out. So I started by defining the terms of the LGPL. In my game's context, I defined the "library" (the part protected by the viral clauses) to be the engine, the entire part written in C, plus all of the original game no matter what language. In other words, there's no way to keep a secret that's already out, and I wanted to make sure that a fully playable game was always freely available. I then defined the "application" -- the completely unprotected part -- as being add-on modules.
I haven't finished the licence, nor have I linked Python into Omega. Once I finish the second I'll be able to define the terms I need to make sure the original game remains free and my secrets remain protected.
One other interesting thing I'm doing is adding a cheat mode and relatively strong anti-crack to the savefiles. I want to discourage people from cracking any part of the game for the purpose of cheating, so I'm making cheating legit, and making the only penalty being that all cheaters get moved onto a "cheater's hiscores" list so that they don't get in the way of the legit players. I'm not sure how this will work, but we'll see.
You have some very deep and important points, but the sheer length and scope of your post militates against thoughtful replies. I'll try, but it won't be easy -- you cover too many topics.
First, support for gamers is provided primarily by new versions of their games, which is exactly what the kids paid money for. This is what ESR, and most people in the computer industry, define as 'support'. Tech support is an incidental, needed for certain specific things but in other cases capable of being provided by almost anyone.
Your definition of "earning money for support" is therefore wrong because you misunderstand the meaning of the word "support".
You later claim that ESR is wrong, and id actually released DOOM because "it was obsolete at that point." But what does "obsolete" mean? It still runs; software rot has yet to make it stop working. The problem was exactly what ESR had said: other companies had slowly made the unique value of DOOM into something non-unique. This is the true meaning of your word "obsolete," in this case. At any rate, my point is that you and ESR are both correct here: they released DOOM because it was not optimal to keep it.
And since then, people have improved the DOOM code. It's only a game, so there's no reason to spend a lot on it, but it's still reasonably popular, even considering that there's better tech out there.
As for your later protestations -- look around. Look at Aegis, LyX, TeX, Enlightenment, and so on. Open source is not in the least constrained for ideas, and never has been. Don't weaken your argument with such patent gibberish. It doesn't even make sense from a theoretical point of view -- you can't pay people to have good ideas.
Finally, you ask why MS should make Windows Open Source. Good question; it's not hard to come up with a list of business reasons for. It's also trivial to come up with a list of reasons against. In the final analysis, it's their decision, and having them choose one way or another contributes nothing to either of our arguments -- although if they chose open source it would be contributing a lot to Windows users.
Next, Mozilla. Mozilla has for the first time produced an entirely standard browser, and has set Netscape in the limelight. Sounds good to me.
Finally, your stuff (up to this point) is indeed serious and worthy. But the part about mythmaking -- what a cheapshot. Read the essay before you make your snide little comments.
GGI is your best option -- it works under console (fast), X (okay), and other Unixes.
-Billy
Re: BSOD crap is getting old
on
Digital VCRs
·
· Score: 1
You're right that NT bluescreens differently than 95/98. In my experience, that doesn't mean it bluesceens less, though.
At work, I run NT 4.0 WS without a reboot until it bluescreens, then I reboot and start over. No power-offs, just uptime.
It dies about once a month, not always with a bluescreen. (The machine's a stock Dell OptiPlex GX, P200MMX).
My win98 home computer has never bluescreened, although it innvents other modes of failure -- I don't even TRY to runn it constantly.
Linux has never crashed for me, and even X has never given me problems since I upgraded to Debian 2.0.
-Billy
Re:What will the packages be called?
on
Corel Linux FAQ
·
· Score: 1
I can't claim (and shouldn't have allowed myself to imply) that.debs beat.rpms is every possible category. That would be a pretty difficult (if not impossible) feat; even.tar.gz beats.deb in certain applications.
However, I look at two things to make my comparison.
First, a laundry list of features..rpm is not unrespectable, but.deb comes out ahead for almost everything.
Second, actual use. The system which works with.debs is stable, effective, and powerful. I've been through a lot of upgrades with Debian without more than minor problems (lately the problems have been disappearing as packages become more tested). Compare this with.rpms; they may be a nice package format, but the system which manages them doesn't use their capabilities to any real extent. Yes, you can install and uninstall -- but what if you want to upgrade? AFAICT, you have to buy or download an entire new CD, and run the installation program on it.
You're right that Debian doesn't scale well; fortunately, so far we've done very well keeping everything at debian.org (mainly) and the repackager's site (rarely, the only one I've ever used was KDE 1.1.1).
Considering the sheer number of packages at debian.org, I'm not too worried.
-Billy
Re:What will the packages be called?
on
Corel Linux FAQ
·
· Score: 1
I suspect that they will be called.debs. For one thing, Corel said their 'internal' CVS server would be kept public on the debian.org site (not mirrored, actually stored there).
Not every distro has invented their own. Slackware used Unix tradition together with its own directory structure; Debian developed.deb when it was needed; Redhat developed.rpm because they didn't know about.deb or didn't want to use it; and most distros from then on (including all of the biggest) have chosen.rpms. Stampede is one of the exceptions to the rule.
I'm curious, though. You state that RPMs spread for "obvious reasons". Given that.debs are intrinsicly superior, what are those reasons? I've often wondered.
'Geek' is highly pejorative -- it describes a physical and mental disability.
'Nerd' is better, although it still fails to do what 'Hacker' does so well: describe the fact that we're hackers because we hack, not because we were born into a social group.
If we can't use 'hacker' -- which would be a pity -- perhaps 'coder' is okay. I hate it, though; it's not meaningful.
You mention a Gnome Dragon... Did you mean KDE? The KDE dragon isn't a logo (it's too complicated). It's a paperclip-- I mean a mascot.
The Gnome logo (a misshapen footprint), IMO, is just dead ugly. I don't believe they ran a contest to select a logo, then when the contest was over (and they'd gotten hundreds of entries) they chose the same logo they'd had all along.
Alas, then, that it's not a logo -- it's a nameplate. A logo has to complement text, not struggle with it.
You're right that it looks nice, but I'm glad we now have a logo. I mean, aside from the traumatically ugly and soon inappropriate penguin. (Inappropriate because Debian is working on a Hurd distribution as well, and the penguin is a Linux logo.)
RedHat has by far the best logo, one just perfect for their name. At least Debian didn't wind up with one of the creeping horrors up for suggestion -- the color-soaked seal, the crushed ant... The DG logo wasn't too bad; I would've been happy with it. The chicken was just too strange and didn't have the impact of the genie (perhaps it's too close to a penguin as well).
-Billy
Re:You guys are REALLY missing the point...
on
Germany Frees Crypto
·
· Score: 1
All of your points are correct, but you misread my message. I wasn't defending the US gov't's stupidity; I can't, it's indefensible. I was pointing out that the German gov't isn't as clued in as people here are pretending.
Nor did I ever say or imply that "only constitutionally guaranteed rights are worth anything". What I did imply was that one acknowledgement of a basic right (assuming that it's a correct acknowledgement, of course) is worth a million grants of permission. I hold to that premise.
A lot of this is societal. Britain has its freedom because that's the way its society works. Ditto America (our Constitution is just an outgrowth of it).
This announcement constitutes _permission_ for Germans to use strong encryption. It's not like the problem in the States -- the US gov't is forbidden to restrict its citizens from using strong crypto (classing strong crypto as munitions means that the "right to bear arms" applies to crypto), but they've chosen to forbid them to export it.
The German gov't is giving _permission_ to use crypto, not acknowledging a right. Tomorrow they may alter the deal -- pray that they do not alter it further (Episode 1 is so devoid of cool quotes!).
I don't like the US system, of course, and I'm fighting for a change -- but don't pretend this is somehow better. It's worse.
Because "I've" is short for "I have(verb)", not "I possess".
"Does anyone really understand why we talk the way we do?),"
To one extent or another. Grammar is reasonablely well explored; we have formal models of it, none of which are perfect but most of which are useful.
"and have what is supposed to be an exception...I read really well and fast and a lot, which is the opposite of the normal of ADD. Does anyone else who 'has ADD' do this?"
1000 WPM. Yes. I LOVE reading. ADD is (to say the least) not well understood.
"I'm actually pretty glad, overall, I have this 'disease'. Deep hack mode is easy"
My problem isn't deep hack mode -- it's homework. I can _easily_ spend all weekend not doing a stitch of homework, without ever leaving my book. Time passes randomly, and before I know it -- the weekend's gone. I wasn't doing anything fun, I wasn't doing anything useful; I was just staring into space. I just spent today doing that.
I like deep hack mode, but I so rarely get a chance to drop into it. I hope getting out of school removes most of this problem... I enjoy my job SO much more than my school, even though it's still a problem.
It's not very C-like; if I had to pick a language it _is_ like, it'd be Forth, but with the ability to have syntax. Not at all unpleasant.
Anyhow, one interesting result of the Forth-like nature is that there are a huge number of datatypes which are not possible in other languages; for example, URLs are actually formal datatypes, not just another string (a malformed URL is a compile-time error).
They've obviously learned from Perl and Python otherwise; it's a nicely dynamic language which seems to be error-tolerant, and has quick, easy syntax for most needs.
I'm reasonably happy with it. It doesn't look as _nice_ as Python, but at least its braces and brackets have a purpose.
I suppose I'll have to build a Lojbanic version. Now that would be interesting. A speakable computer language.
Unfortunately, the owners of servers where I work are not hired by us. We're hired by them.:) I work in the Interactive department of an ad agency, and we create the content and programming for web sites hosted by our clients' MIS departments.
Ah. I see the problem. "Selling" Zope to them might sound like fun from the outside, but whew...:-)
That's why the feature to publish static pages via file system or FTP upload is attractive to me, since I might not even have to install a Web Application Server (mine or Zope) on a remote server. Just install one here and use it as a development machine, and have static updates rolled automatically to the client's machines.
Well... Okay, here's the scoop. Separate publishing is a major goal for Zope, meaning that it'll be coming along very soon (we're working on WebDAV in the current version). I don't have any idea on when and how, since I don't follow the mailing list.
Well, I'm hoping that, once I complete the first revision's batch of features and release it open source that I can attract some fellow Perl Mongers to waste time with me.:)
Good luck -- it's quite likely that you'll succeed.
And good luck to all of us if you do -- I'm seriously afraid that having two competing products in this new niche will jeapordize both. I'm probably just paranoid, and aside from that worry I'm excited about your project -- quite aside from my puzzlement about why you're redoing all that work in the first place.
Well, from what limited experience I have with Python, I like it. But my time is limited, and I don't want to devote time to mastering another language for just one product (i.e. Zope) when I have skill in Perl and use it every day. THen again, maybe after an attempt at matching that one product, I'll find that further time might be better spent with Python.
Python is great, but in all my work with Zope I haven't so much as seen a single line of Python code. Why should I? Don't shun Zope because you're afraid of learning Python -- Zope won't force you to learn Python.
But I want to learn the hard way for now.:) Anyone else interested?
No, but can I be your arch-enemy?;-)
Really, though, good luck. And whatever you do, PLEASE study the competition before you release! I've seen far too many inferior products crowd out good ones, to both ones' demise.
Unfortunately, the owners of servers where I work are not hired by us. We're hired by them.:) I work in the Interactive department of an ad agency, and we create the content and programming for web sites hosted by our clients' MIS departments.
Ah. I see the problem. "Selling" Zope to them might sound like fun from the outside, but whew...:-)
That's why the feature to publish static pages via file system or FTP upload is attractive to me, since I might not even have to install a Web Application Server (mine or Zope) on a remote server. Just install one here and use it as a development machine, and have static updates rolled automatically to the client's machines.
Well... Okay, here's the scoop. Separate publishing is a major goal for Zope, meaning that it'll be coming along very soon (we're working on WebDAV in the current version). I don't have any idea on when and how, since I don't follow the mailing list.
Well, I'm hoping that, once I complete the first revision's batch of features and release it open source that I can attract some fellow Perl Mongers to waste time with me.:)
Good luck -- it's quite likely that you'll succeed.
And good luck to all of us if you do -- I'm seriously afraid that having two competing products in this new niche will jeapordize both. I'm probably just paranoid, and aside from that worry I'm excited about your project -- quite aside from my puzzlement about why you're redoing all that work in the first place.
Well, from what limited experience I have with Python, I like it. But my time is limited, and I don't want to devote time to mastering another language for just one product (i.e. Zope) when I have skill in Perl and use it every day. THen again, maybe after an attempt at matching that one product, I'll find that further time might be better spent with Python.
Python is great, but in all my work with Zope I haven't so much as seen a single line of Python code. Why should I? Don't shun Zope because you're afraid of learning Python -- Zope won't force you to learn Python.
I know Zope isn't an editor, per se; however, once you've done a tiny bit of thought to draw up the structure of your page, adding new stuff is SO trivial.
It's very hard to explain, but very easy to understand once you see it. Install a copy and see -- the distro installs quickly and painlessly, and works (by default) without intruding on your normal web server (if you have one). And yes, it works perfectly well on systems without connectivity (that's how I first evaluated it).
And best of all, you can access it from ANYWHERE, using any web browser which supports frames, forms, and passwords.
It doesn't let you drag and drop pictures: to add a picture, you click "picture", "add", "browse", and then choose it from your drive. I think that's close enough.
The only thing it doesn't have is WYSIWYG, but try it and you'll likely agree that such would only get in the way, especially since one sometimes wants to write a little bit of DTML (Zope code). It's just too useful.
1) It's in Python. Ack. I *want* to like Python, but there are just too many factors keeping me from affording any time to it. I'm still a Perl Monger.
You are right to be afraid -- once you spend the half hour needed to know Python well, you'll never want to look at Perl again.
I'm joking, of course. Perl is a cool language, and you'll never stop using it now that you know it -- however, you'll find that text processing is actually NOT the best way to do everything. Including CGI.
2) Major control needed over the server, which sucks when you don't own the server and have no possible say over configuration. Most commonly, Perl and *maybe* a database are available to me. Installing Python, and web server extensions is verboten.
Then Zope is forever off-limits to you. I'm sorry.
On the other hand, perhaps it might be worth your while to appeal to your ISP (whom _you_ are paying to provide a service) and convince them to add what is a very minor and highly useful program.
3) It's all dynamic. No static publishing of pages which are, for the majority of the time, static. Granted there's a cache, but can that be as fast as spitting an HTML file instance of a content object into the web doc root and letting Apahe serve it up?
Zope is *highly* optimized, and if there's a fast way to do something it'll do it. All of the bottlenecks are written in C, thanks to Python's extensibility.
It's a pretty sophisticated program; don't underestimate it.
And no, it's unlikely that a static page would be served faster -- although that would have to depend on your machine, your bandwidth, and the hit rate (and your OS). If Zope's not running your stuff fast enough, going to static pages might provide a speedup over some of that domain -- but then, it might not.
I've been working on what's partially a "clone" of Zope, in that it has much of the same functionality, written in Perl.
I'd say you're wasting your time -- but of course, I don't really believe that. I wish you luck.
You're not going to be able to match Zope, though; Python doesn't have CPAN, but it does have a HUGE number of useful scripts for a huge number of purposes. Zope has ACL security, transaction-level undo and redo, highly optimized code, and a solid support community.
Oh, and you don't have to learn Python to use it -- but you will, you will. Once you've seen what Python can do so easily, there's no way you'll remain satisfied with the Old Way of doing things.
My friend and I both use plain ASCII, with the occasionnal paragraph tag and so on. It's trivial to work with.
Like I said, I never learned HTML very well, because I refused to apply myself to it. Because of that, all the content I wrote was just that, _content_. Because of the way Zope works, all of my content automatically had Sam's styles applied to it, without any work on my part.
And now, I'm almost accidentally learning HTML.
I'm contributing to the site as well -- in spite of my lack of knowledge of HTML, I'm _very_ good at discovering things and experimenting with them, so I often write up some pretty cool DTML (that's Zope's form of server-side HTML) which Sam later on moves into the root where anyone can use it.
It's a fair trade -- I don't need to know HTM, he doesn't need to learn DTML. We both do anyhow, of course, just because.
At www.zope.org, you'll find a complete system to do exactly that, complete with transaction-based undo (that is, anything you can do you can undo later, without having to undo anything else if you don't want to) and access-control-list based security. It's open source.
It has database support, and there are modules to handle slashdot-like forums ("Confera"), WebDAV, and many other things. Its default interface (when not using webDAV) is simply HTML -- you can administer (and add content to) your pages from any web browser which supports passwords, frames, and forms.
It's trivial to install, and the default package is essentially a trial (it stes itself up on another port to not get in your way), so it's harmless to play with before you commit. It's a breeze to use, but almost frighteningly powerful.
I'm an experimental sort, so I never learned HTML well enough to make a page look good. Because of Zope, though (and a little help from CSS), my web page was able to inherit the look and feel of my friend's web page, and automatically change when he changed his. So now I provide the technical design, and he makes the site look good -- and there have NEVER been any maintainance headaches, and we both know that if someday there were it wouldn't matter because we could always 'undo' the problem.
RSA is VERY simple -- a key is just a bunch of bits, it's not anything magic which has to be "generated". Just pick a random number or two.
And this particular Perl isn't Perl, either; it's actually a bunch of calls to 'bc'. Pathetic, if you ask me.
I searched for about an hour before I found a _real_ Perl implementation of this. About five minutes into the search, I found a four-line Python implementation (in ESR's.sig file); when I finally found the Perl implementation, I was shocked and pleased to discover that it was longer than the Python one.
Okay, low blow. It just always amazes me to see how many people confuse "cryptic" (Perl) with "terse" (APL and J). Python unly tries to be non-cryptic, but winds up being somewhat terse as well.
Slashdot Mirror
I did imply that the GPL enslaves people. That was an example of sloppy rhetoric, and I apologise.
The GPL doesn't enslave people; it merely reduces their rights. It also claims that it's increasing people's freedom.
It lies.
The BSD or XFree or Python licenses increase freedom across the board. THEY are the licenses which result in freedom. If the only alternative to freedom is slavery, the GPL _is_ slavery. Of course, that's nonsense, but that's what the GPL promoters say all the time.
In fact, the only reason to use the GPL is because you prize pragmatism about principle.
-Billy
"But if you consider denying the right to own slaves to be an advancement why don't you see the same progress in software made by the GPL?"
/because proprietary software isn't slavery,/ any more than copying licenced software is theft. (It's copyright violation, not theft.)
Good question. The answer is:
Both are bad. Neither one is the evil that its opponents claim.
Prop SW (unlike slavery) forces nobody to do anything. It can't. In fact, its disutility is so high that for many people, an otherwise inferior freeware will displace it (freeware in the sense merely of freely distributable _binaries_).
-Billy
The first rule of licenses is that whoever makes the code makes the rules. So you're safe if you're allowed to make the license -- just use the GPL and attach a clause to it pointing out that the output is considered a derivative work of the input, NOT of the Program (or something similar).
The Artistic Licence is written with this in mind for even very complex transforms. You might take a look at it.
And finally, I dislike the GPL. It has a VERY good goal; but its means to that end are repressive. I don't want my software free if it enslaves people.
My ideal license is BSD-style (minus the attribution clause), but I would make the special note (not in the license) that I did not want my program to be used in a proprietary system.
Moral people are free to use my program in moral ways; I'm not concerned about the behavior of immoral people.
-Billy
I maintain an ancient but popular free game named Omega (see my web page). When I took over maintainance, it have been almost five years since the last substantive change.
;-).
A comabination of bad code, almost superb design, and bad licence had killed it. The design was so good that any programmer who started working with it was immediately tempted to upgrade all the code to fit it (an unrewarding task which caused every one of them to give up almost immediately), and the license not only stated that no money could be made on it, but also forbade the distribution of modifications without the author's permission.
The first thing I did was rewrite the UI for the inventory (it'd been a sore point for everyone; hard to learn and hard to use). I showed that to the author and the current maintainer; the maintainer gave me permission to take over, and the author gave me permission to change the license. Working with him, I chose the LGPL, modified to fit the needs of an expandible game (more on this later).
In just a couple of days, I started recieving offers of help from people who had been working on Omega for all those years. The sheer volume of fixed code was almost incredible. Even when I was drawn aside for several months by my work schedule, their work proceeded. If code had been money, my investment in the inventory code would have paid off hundredfold
I credit this partially to the resumption of development on a formerly-thought-dead project (which isn't something most people have an option for), but also to the change in license.
The license fits my idea of gaming. Specifically, I wanted the game to be free, but at the same time I also wanted it to have secrets -- as this article points out. So I started by defining the terms of the LGPL. In my game's context, I defined the "library" (the part protected by the viral clauses) to be the engine, the entire part written in C, plus all of the original game no matter what language. In other words, there's no way to keep a secret that's already out, and I wanted to make sure that a fully playable game was always freely available. I then defined the "application" -- the completely unprotected part -- as being add-on modules.
I haven't finished the licence, nor have I linked Python into Omega. Once I finish the second I'll be able to define the terms I need to make sure the original game remains free and my secrets remain protected.
One other interesting thing I'm doing is adding a cheat mode and relatively strong anti-crack to the savefiles. I want to discourage people from cracking any part of the game for the purpose of cheating, so I'm making cheating legit, and making the only penalty being that all cheaters get moved onto a "cheater's hiscores" list so that they don't get in the way of the legit players. I'm not sure how this will work, but we'll see.
-Billy
Of ocurse it's cheaper -- AMD's is faster, more scalable, etc.
And to add insult to injury, Intel's chip was delayed, so it'll also possibly be later as well.
-Billy
This reminds me of the book by Brin and Benford, "Heart of the Comet". Very good book, I liked it more than any of Brin's others.
Benford? I've tried to read one of his (Timescape). Eww. I like hard sci-fi, but I hate the total lack of character and character development.
-Billy
You have some very deep and important points, but the sheer length and scope of your post militates against thoughtful replies. I'll try, but it won't be easy -- you cover too many topics.
First, support for gamers is provided primarily by new versions of their games, which is exactly what the kids paid money for. This is what ESR, and most people in the computer industry, define as 'support'. Tech support is an incidental, needed for certain specific things but in other cases capable of being provided by almost anyone.
Your definition of "earning money for support" is therefore wrong because you misunderstand the meaning of the word "support".
You later claim that ESR is wrong, and id actually released DOOM because "it was obsolete at that point." But what does "obsolete" mean? It still runs; software rot has yet to make it stop working. The problem was exactly what ESR had said: other companies had slowly made the unique value of DOOM into something non-unique. This is the true meaning of your word "obsolete," in this case. At any rate, my point is that you and ESR are both correct here: they released DOOM because it was not optimal to keep it.
And since then, people have improved the DOOM code. It's only a game, so there's no reason to spend a lot on it, but it's still reasonably popular, even considering that there's better tech out there.
As for your later protestations -- look around. Look at Aegis, LyX, TeX, Enlightenment, and so on. Open source is not in the least constrained for ideas, and never has been. Don't weaken your argument with such patent gibberish. It doesn't even make sense from a theoretical point of view -- you can't pay people to have good ideas.
Finally, you ask why MS should make Windows Open Source. Good question; it's not hard to come up with a list of business reasons for. It's also trivial to come up with a list of reasons against. In the final analysis, it's their decision, and having them choose one way or another contributes nothing to either of our arguments -- although if they chose open source it would be contributing a lot to Windows users.
Next, Mozilla. Mozilla has for the first time produced an entirely standard browser, and has set Netscape in the limelight. Sounds good to me.
Finally, your stuff (up to this point) is indeed serious and worthy. But the part about mythmaking -- what a cheapshot. Read the essay before you make your snide little comments.
-Billy
GGI is your best option -- it works under console (fast), X (okay), and other Unixes.
-Billy
You're right that NT bluescreens differently than 95/98. In my experience, that doesn't mean it bluesceens less, though.
At work, I run NT 4.0 WS without a reboot until it bluescreens, then I reboot and start over. No power-offs, just uptime.
It dies about once a month, not always with a bluescreen. (The machine's a stock Dell OptiPlex GX, P200MMX).
My win98 home computer has never bluescreened, although it innvents other modes of failure -- I don't even TRY to runn it constantly.
Linux has never crashed for me, and even X has never given me problems since I upgraded to Debian 2.0.
-Billy
I can't claim (and shouldn't have allowed myself to imply) that .debs beat .rpms is every possible category. That would be a pretty difficult (if not impossible) feat; even .tar.gz beats .deb in certain applications.
.rpm is not unrespectable, but .deb comes out ahead for almost everything.
.debs is stable, effective, and powerful. I've been through a lot of upgrades with Debian without more than minor problems (lately the problems have been disappearing as packages become more tested). Compare this with .rpms; they may be a nice package format, but the system which manages them doesn't use their capabilities to any real extent. Yes, you can install and uninstall -- but what if you want to upgrade? AFAICT, you have to buy or download an entire new CD, and run the installation program on it.
However, I look at two things to make my comparison.
First, a laundry list of features.
Second, actual use. The system which works with
You're right that Debian doesn't scale well; fortunately, so far we've done very well keeping everything at debian.org (mainly) and the repackager's site (rarely, the only one I've ever used was KDE 1.1.1).
Considering the sheer number of packages at debian.org, I'm not too worried.
-Billy
I suspect that they will be called .debs. For one thing, Corel said their 'internal' CVS server would be kept public on the debian.org site (not mirrored, actually stored there).
.deb when it was needed; Redhat developed .rpm because they didn't know about .deb or didn't want to use it; and most distros from then on (including all of the biggest) have chosen .rpms. Stampede is one of the exceptions to the rule.
.debs are intrinsicly superior, what are those reasons? I've often wondered.
Not every distro has invented their own. Slackware used Unix tradition together with its own directory structure; Debian developed
I'm curious, though. You state that RPMs spread for "obvious reasons". Given that
-Billy
'Geek' is highly pejorative -- it describes a physical and mental disability.
'Nerd' is better, although it still fails to do what 'Hacker' does so well: describe the fact that we're hackers because we hack, not because we were born into a social group.
If we can't use 'hacker' -- which would be a pity -- perhaps 'coder' is okay. I hate it, though; it's not meaningful.
-Billy
You mention a Gnome Dragon... Did you mean KDE? The KDE dragon isn't a logo (it's too complicated). It's a paperclip-- I mean a mascot.
The Gnome logo (a misshapen footprint), IMO, is just dead ugly. I don't believe they ran a contest to select a logo, then when the contest was over (and they'd gotten hundreds of entries) they chose the same logo they'd had all along.
-Billy
Alas, then, that it's not a logo -- it's a nameplate. A logo has to complement text, not struggle with it.
You're right that it looks nice, but I'm glad we now have a logo. I mean, aside from the traumatically ugly and soon inappropriate penguin. (Inappropriate because Debian is working on a Hurd distribution as well, and the penguin is a Linux logo.)
RedHat has by far the best logo, one just perfect for their name. At least Debian didn't wind up with one of the creeping horrors up for suggestion -- the color-soaked seal, the crushed ant... The DG logo wasn't too bad; I would've been happy with it. The chicken was just too strange and didn't have the impact of the genie (perhaps it's too close to a penguin as well).
-Billy
All of your points are correct, but you misread my message. I wasn't defending the US gov't's stupidity; I can't, it's indefensible. I was pointing out that the German gov't isn't as clued in as people here are pretending.
Nor did I ever say or imply that "only constitutionally guaranteed rights are worth anything". What I did imply was that one acknowledgement of a basic right (assuming that it's a correct acknowledgement, of course) is worth a million grants of permission. I hold to that premise.
A lot of this is societal. Britain has its freedom because that's the way its society works. Ditto America (our Constitution is just an outgrowth of it).
Oh well.
-Billy
This announcement constitutes _permission_ for Germans to use strong encryption. It's not like the problem in the States -- the US gov't is forbidden to restrict its citizens from using strong crypto (classing strong crypto as munitions means that the "right to bear arms" applies to crypto), but they've chosen to forbid them to export it.
The German gov't is giving _permission_ to use crypto, not acknowledging a right. Tomorrow they may alter the deal -- pray that they do not alter it further (Episode 1 is so devoid of cool quotes!).
I don't like the US system, of course, and I'm fighting for a change -- but don't pretend this is somehow better. It's worse.
Do not stop fighting this stupidity!
-Billy
"BTW, I have ADD"
Same here.
"(Why does "I've ADD" seem wrong?"
Because "I've" is short for "I have(verb)", not "I possess".
"Does anyone really understand why we talk the way we do?),"
To one extent or another. Grammar is reasonablely well explored; we have formal models of it, none of which are perfect but most of which are useful.
"and have what is supposed to be an exception...I read really well and fast and a lot, which is the opposite of the normal of ADD. Does anyone else who 'has ADD' do this?"
1000 WPM. Yes. I LOVE reading. ADD is (to say the least) not well understood.
"I'm actually pretty glad, overall, I have this 'disease'. Deep hack mode is easy"
My problem isn't deep hack mode -- it's homework. I can _easily_ spend all weekend not doing a stitch of homework, without ever leaving my book. Time passes randomly, and before I know it -- the weekend's gone. I wasn't doing anything fun, I wasn't doing anything useful; I was just staring into space. I just spent today doing that.
I like deep hack mode, but I so rarely get a chance to drop into it. I hope getting out of school removes most of this problem... I enjoy my job SO much more than my school, even though it's still a problem.
-Billy
It's not very C-like; if I had to pick a language it _is_ like, it'd be Forth, but with the ability to have syntax. Not at all unpleasant.
Anyhow, one interesting result of the Forth-like nature is that there are a huge number of datatypes which are not possible in other languages; for example, URLs are actually formal datatypes, not just another string (a malformed URL is a compile-time error).
They've obviously learned from Perl and Python otherwise; it's a nicely dynamic language which seems to be error-tolerant, and has quick, easy syntax for most needs.
I'm reasonably happy with it. It doesn't look as _nice_ as Python, but at least its braces and brackets have a purpose.
I suppose I'll have to build a Lojbanic version. Now that would be interesting. A speakable computer language.
Ah. I see the problem. "Selling" Zope to them might sound like fun from the outside, but whew... :-)
That's why the feature to publish static pages via file system or FTP upload is attractive to me, since I might not even have to install a Web Application Server (mine or Zope) on a remote server. Just install one here and use it as a development machine, and have static updates rolled automatically to the client's machines.
Well... Okay, here's the scoop. Separate publishing is a major goal for Zope, meaning that it'll be coming along very soon (we're working on WebDAV in the current version). I don't have any idea on when and how, since I don't follow the mailing list.
Well, I'm hoping that, once I complete the first revision's batch of features and release it open source that I can attract some fellow Perl Mongers to waste time with me. :)
Good luck -- it's quite likely that you'll succeed.
And good luck to all of us if you do -- I'm seriously afraid that having two competing products in this new niche will jeapordize both. I'm probably just paranoid, and aside from that worry I'm excited about your project -- quite aside from my puzzlement about why you're redoing all that work in the first place.
Well, from what limited experience I have with Python, I like it. But my time is limited, and I don't want to devote time to mastering another language for just one product (i.e. Zope) when I have skill in Perl and use it every day. THen again, maybe after an attempt at matching that one product, I'll find that further time might be better spent with Python.
Python is great, but in all my work with Zope I haven't so much as seen a single line of Python code. Why should I? Don't shun Zope because you're afraid of learning Python -- Zope won't force you to learn Python.
But I want to learn the hard way for now. :) Anyone else interested?
No, but can I be your arch-enemy? ;-)
Really, though, good luck. And whatever you do, PLEASE study the competition before you release! I've seen far too many inferior products crowd out good ones, to both ones' demise.
-Billy
Ah. I see the problem. "Selling" Zope to them might sound like fun from the outside, but whew... :-)
That's why the feature to publish static pages via file system or FTP upload is attractive to me, since I might not even have to install a Web Application Server (mine or Zope) on a remote server. Just install one here and use it as a development machine, and have static updates rolled automatically to the client's machines.
Well... Okay, here's the scoop. Separate publishing is a major goal for Zope, meaning that it'll be coming along very soon (we're working on WebDAV in the current version). I don't have any idea on when and how, since I don't follow the mailing list.
Well, I'm hoping that, once I complete the first revision's batch of features and release it open source that I can attract some fellow Perl Mongers to waste time with me. :)
Good luck -- it's quite likely that you'll succeed.
And good luck to all of us if you do -- I'm seriously afraid that having two competing products in this new niche will jeapordize both. I'm probably just paranoid, and aside from that worry I'm excited about your project -- quite aside from my puzzlement about why you're redoing all that work in the first place.
Well, from what limited experience I have with Python, I like it. But my time is limited, and I don't want to devote time to mastering another language for just one product (i.e. Zope) when I have skill in Perl and use it every day. THen again, maybe after an attempt at matching that one product, I'll find that further time might be better spent with Python.
Python is great, but in all my work with Zope I haven't so much as seen a single line of Python code. Why should I? Don't shun Zope because you're afraid of learning Python -- Zope won't force you to learn Python.
-Billy
I know Zope isn't an editor, per se; however, once you've done a tiny bit of thought to draw up the structure of your page, adding new stuff is SO trivial.
It's very hard to explain, but very easy to understand once you see it. Install a copy and see -- the distro installs quickly and painlessly, and works (by default) without intruding on your normal web server (if you have one). And yes, it works perfectly well on systems without connectivity (that's how I first evaluated it).
And best of all, you can access it from ANYWHERE, using any web browser which supports frames, forms, and passwords.
It doesn't let you drag and drop pictures: to add a picture, you click "picture", "add", "browse", and then choose it from your drive. I think that's close enough.
The only thing it doesn't have is WYSIWYG, but try it and you'll likely agree that such would only get in the way, especially since one sometimes wants to write a little bit of DTML (Zope code). It's just too useful.
-Billy
1) It's in Python. Ack. I *want* to like Python, but there are just too many factors keeping me from affording any time to it. I'm still a Perl Monger.
You are right to be afraid -- once you spend the half hour needed to know Python well, you'll never want to look at Perl again.
I'm joking, of course. Perl is a cool language, and you'll never stop using it now that you know it -- however, you'll find that text processing is actually NOT the best way to do everything. Including CGI.
2) Major control needed over the server, which sucks when you don't own the server and have no possible say over configuration. Most commonly, Perl and *maybe* a database are available to me. Installing Python, and web server extensions is verboten.
Then Zope is forever off-limits to you. I'm sorry.
On the other hand, perhaps it might be worth your while to appeal to your ISP (whom _you_ are paying to provide a service) and convince them to add what is a very minor and highly useful program.
3) It's all dynamic. No static publishing of pages which are, for the majority of the time, static. Granted there's a cache, but can that be as fast as spitting an HTML file instance of a content object into the web doc root and letting Apahe serve it up?
Zope is *highly* optimized, and if there's a fast way to do something it'll do it. All of the bottlenecks are written in C, thanks to Python's extensibility.
It's a pretty sophisticated program; don't underestimate it.
And no, it's unlikely that a static page would be served faster -- although that would have to depend on your machine, your bandwidth, and the hit rate (and your OS). If Zope's not running your stuff fast enough, going to static pages might provide a speedup over some of that domain -- but then, it might not.
I've been working on what's partially a "clone" of Zope, in that it has much of the same functionality, written in Perl.
I'd say you're wasting your time -- but of course, I don't really believe that. I wish you luck.
You're not going to be able to match Zope, though; Python doesn't have CPAN, but it does have a HUGE number of useful scripts for a huge number of purposes. Zope has ACL security, transaction-level undo and redo, highly optimized code, and a solid support community.
Oh, and you don't have to learn Python to use it -- but you will, you will. Once you've seen what Python can do so easily, there's no way you'll remain satisfied with the Old Way of doing things.
-Billy
My friend and I both use plain ASCII, with the occasionnal paragraph tag and so on. It's trivial to work with.
Like I said, I never learned HTML very well, because I refused to apply myself to it. Because of that, all the content I wrote was just that, _content_. Because of the way Zope works, all of my content automatically had Sam's styles applied to it, without any work on my part.
And now, I'm almost accidentally learning HTML.
I'm contributing to the site as well -- in spite of my lack of knowledge of HTML, I'm _very_ good at discovering things and experimenting with them, so I often write up some pretty cool DTML (that's Zope's form of server-side HTML) which Sam later on moves into the root where anyone can use it.
It's a fair trade -- I don't need to know HTM, he doesn't need to learn DTML. We both do anyhow, of course, just because.
-Billy
At www.zope.org, you'll find a complete system to do exactly that, complete with transaction-based undo (that is, anything you can do you can undo later, without having to undo anything else if you don't want to) and access-control-list based security. It's open source.
It has database support, and there are modules to handle slashdot-like forums ("Confera"), WebDAV, and many other things. Its default interface (when not using webDAV) is simply HTML -- you can administer (and add content to) your pages from any web browser which supports passwords, frames, and forms.
It's trivial to install, and the default package is essentially a trial (it stes itself up on another port to not get in your way), so it's harmless to play with before you commit. It's a breeze to use, but almost frighteningly powerful.
I'm an experimental sort, so I never learned HTML well enough to make a page look good. Because of Zope, though (and a little help from CSS), my web page was able to inherit the look and feel of my friend's web page, and automatically change when he changed his. So now I provide the technical design, and he makes the site look good -- and there have NEVER been any maintainance headaches, and we both know that if someday there were it wouldn't matter because we could always 'undo' the problem.
Get it. Learn it. Live it. Zope.
-Billy
RSA is VERY simple -- a key is just a bunch of bits, it's not anything magic which has to be "generated". Just pick a random number or two.
.sig file); when I finally found the Perl implementation, I was shocked and pleased to discover that it was longer than the Python one.
And this particular Perl isn't Perl, either; it's actually a bunch of calls to 'bc'. Pathetic, if you ask me.
I searched for about an hour before I found a _real_ Perl implementation of this. About five minutes into the search, I found a four-line Python implementation (in ESR's
Okay, low blow. It just always amazes me to see how many people confuse "cryptic" (Perl) with "terse" (APL and J). Python unly tries to be non-cryptic, but winds up being somewhat terse as well.
-Billy