On 15 Dec 1998 04:32:26 +0000, Erik Naggum <e...@naggum.no> claimed or asked:
% I'd certainly rate this a real world application. without Linux, we % would have had to request a 50% larger initial budget for new hardware, % which wouldn't have been a useful suggestion to the board at the time.
I'm confused. Didn't you just flame free software a few posts back? Or did you just flame the idea that all software must be free?
* trash...@david-steuber.com (David Steuber "The Interloper") | I'm confused. Didn't you just flame free software a few posts back? | Or did you just flame the idea that all software must be free?
I did neither. pay attention.
#:Erik -- man who cooks while hacking eats food that has died twice.
Erik Naggum <e...@naggum.no> writes: > the key is "mind share". when you have deal with a number of things in > some clearly inferior language, such as C, you lose in a big way. for > instance, I'm currently struggling with MD5 checksums.
There's MD5 lisp code in the sources of CL-HTTP, check it out (I haven't looked at it myself, but I know it's there).
This is kinda off topic, but after all your talk Erik about your involvement with the FSF and Emacs, and all the things you had to say about what's wrong with Emacs, I'm kinda curious about what your "from the _inside_ of the FSF" view of XEmacs is. In the XEmacs FAQ, they mention:
"There are currently irreconcilable differences in the views about technical, programming, design and organizational matters between RMS and the XEmacs development team which provide little hope for a merge to take place in the short-term future."
I can see in your X-Newsreader header that you're using Stallmacs instead of XEmacs, and I'm wondering if this is just because you prefer the FSF style mousing behavior or some similar detail or if it's because you believe that Stallmacs offers some type of technical superiority to XEmacs or is perhaps superior by virtue of not being irreconcilably fubared (perhaps you have this view?).
I used to use Stallmacs whenever I wanted a text-mode or terminal buffer until I realized that XEmacs actually has the (IMHO) superior text mode to.
At any rate, I love your idea of a CL-Emacs which would enable one to compile everything to native code for a speed advantage and also not have to maintain an inferior (with respect to CL) and seperate interpreter for an inferior dialect implemented in an inferior language.
Just earlier this week tried out Hemlock, and it's a nice little editor, but it only seems to have like 2 modes right now and obviously no gnus or any other comparable packages, and ilisp seems to be a better listener interface at the moment anyways (IMHO).
Rainer> In article <4n7lvuvkvz....@rtp.ericsson.se>, Raymond Toy Rainer> <t...@rtp.ericsson.se> wrote:
>> Can someone remind my why gzip, tar, MPEG, MP3 need to be in lisp?
Rainer> Yes, this is questionable. The ultimate goal would Rainer> be to have it on a Lisp machine in a sane way. But Rainer> we will not get it soon - just because there is Rainer> a lot of work needed for this software. Still I haven't seen Rainer> a really satisfying strategy to incorporate this stuff into Rainer> a Lisp environment.
So, for gzip, you have a lisp function that takes a stream, say, produces a gzipped version of the stream to another? (Replace stream with your favorite data type).
For writing a tar, you want a to hand it a list of files and it creates a tar file? For reading, you hand it a tar file and it lists or extracts the contents?
I think a tar file handler would be fairly easy. Emacs has a tar mode for reading a tar file (format) so that would be a start.
> Rainer> In article <4n7lvuvkvz....@rtp.ericsson.se>, Raymond Toy > Rainer> <t...@rtp.ericsson.se> wrote:
> >> Can someone remind my why gzip, tar, MPEG, MP3 need to be in lisp?
> Rainer> Yes, this is questionable. The ultimate goal would > Rainer> be to have it on a Lisp machine in a sane way. But > Rainer> we will not get it soon - just because there is > Rainer> a lot of work needed for this software. Still I haven't seen > Rainer> a really satisfying strategy to incorporate this stuff into > Rainer> a Lisp environment.
> So, for gzip, you have a lisp function that takes a stream, say, > produces a gzipped version of the stream to another? (Replace stream > with your favorite data type).
> For writing a tar, you want a to hand it a list of files and it creates a tar > file? For reading, you hand it a tar file and it lists or extracts > the contents?
Correct. If you have functionality you can use as black box, you can easily define a wrapper (or a calling convention) and use it in some way.
If you need to make it using internal data structures (say, a stream buffer) you have on your Lisp side - then you are losing.
My question was how to generate the appropriate wrapper automagically. Say, you have Quicktime as a library and you want all the provided interfaces (data structure, algorithms, ..) packaged via CLOS. The software may or may not be written in an OO-style. But you may want an easy to use interface and excellent performance.
* Espen Vestre <e...@nextel.no> | There's MD5 lisp code in the sources of CL-HTTP, check it out (I haven't | looked at it myself, but I know it's there).
I know it's there, too, but because of CL-HTTP's licensing terms (or, more precisely, the utter lack thereof), I can't use it, and would have some problems if I were to study it.
incidentally, my MD5 implementation has been working in production mode since about 06:30 this morning -- I spent almost 8 hours debugging a stupid little typo on the initial context. its only problem is that it's _really_ slow (800 µs CPU per block) and conses like mad because 32-bit numbers aren't fixnums. I'll have to look into that.
#:Erik -- man who cooks while hacking eats food that has died twice.
Rainer> Correct. If you have functionality you can use as black box, you Rainer> can easily define a wrapper (or a calling convention) and use Rainer> it in some way.
Ok, after 30 minutes of hacking (plus some more to find out the format of a tar file) I have a very, very simple tar file reader. It basically returns the tar header for each entry and the contents of each entry. The header is a Lisp structure with the sanitized header information (filename, mod time, uid, gid, checksum, etc.). The contents is just a giant array of (unsigned-byte 8). What would you want to do with that?
A related question: Is the character type the same for all lisps (8-bit unsigned byte, essentially)? For portability I assumed that this is not true, so I open the file with element-type (unsigned-byte 8) and massage that appropriately to get what I want.
Rainer> If you need to make it using internal data structures (say, a Rainer> stream buffer) you have on your Lisp side - then you are losing.
I'm sorry, I didn't follow this last sentence. What are you trying to say?
* cba...@2xtreme.net (Christopher R. Barry) | This is kinda off topic, but after all your talk Erik about your | involvement with the FSF and Emacs, and all the things you had to say | about what's wrong with Emacs, I'm kinda curious about what your "from | the _inside_ of the FSF" view of XEmacs is.
well, nobody cares. XEmacs is a bunch of hateful lunatics who appear to take pleasure in attacking Emacs users and maintainers for no good reason yet aren't anywhere near as good at what they're doing as the Emacs people are (except in the MULE division, where XEmacs got it right and the MULE team in Emacs act as if they think that because Japan suffered exclusion for a lot of years, now Europe can suffer, instead).
| I can see in your X-Newsreader header that you're using Stallmacs instead | of XEmacs,
you can? really? "Stallmacs", even? look, you should know by now that I hate idiots. do me a favor and haul your ass over to Bagdad, OK? but since you bring it up, look a little closer:
X-Newsreader: Gnus v5.5/Emacs 19.2003
doesn't look much like "Stallmacs" to me. I get the impression that you aren't very careful in collecting evidence before you jump to conclusions. I need some evidence that XEmacs proponents aren't _all_ fucking morons, and you're not it, so let me just can this off topic discussion right now.
#:Erik -- Attention, Republican members of the House Judiciary Committee! We have intercepted a coded transmission from Bill Clinton to Saddam Hussein that puts your life in jeopardy. Clinton is prepared to cease fire if all of you are killed by Iraqi terrorists, whom he won't prosecute. Be warned!
Damn Erik, mellow out. I guess you think using "Stallmacs" to refer the the FSF maintained version of Emacs is somehow deragatory, and I didn't know that you would take it in that sense, because I didn't mean to attack it or anything. I still have a copy of it on my machine and I've set up XEmacs to use a lot of the (IMHO) superior FSF defaults and behavior. At least from my experience though, XEmacs is kinda nicer in some ways, and that is all I really said. I didn't specifically downtalk Emacs, because I don't think there is anything to downtalk. You had plenty to downtalk about it though about how asian languages support was implemented and you also downtalked the XEmacs people saying that the FSF Emacs people are way better at what the're doing, but didn't really give any (IMO) satisfying or unheated reasons why. I just wanted to know your opinion on a few things, and I got it, but I would have thought that since this is comp.lang.lisp it would have been civil and unheated.
"I need some evidence that XEmacs proponents aren't _all_ [...], and you're not it"
I'm not really an XEmacs proponent. I have both ACL 5.0 and CMUCL on my machine here, and (until very recently) I used ACL 5.0 99% of the time. I'm now using CMUCL slightly more, but have yet to really form any opinions about really favoring one over the other. And if I did, and said that I say, like CMUCL more, but not specifically downtalked ACL 5, and also wanted your opinion as someone that has worked with some of the ACL 5 sources, would that have also made your blood boil?
* Joachim Achtzehnter <joac...@kraut.bc.ca> | Agree 100%. I do believe that non-free software is a bad thing compared | to free software, but in comparison with other evils in this world I | consider it rather unimportant. Life is not perfect, and if one has to | compromise, better do it in a less important area.
well, I don't believe that "non-free software" is a bad thing. period.
I believe that blocking people's access to the whatever they need to do a good job and to understand what's going on is bad, but, and this is my gripe: I get _better_ results in this exact regard from signing NDAs and license agreements than I get from stamping GPL on my code or using GPL'ed code, and in some cases, purportedly free code contaminates a commercial product to the point where one just cannot use it. that's why I have come to talk about "unrestricted source availability", since what is free to you may be unfree to me, and what is unfree to you may be free to me. e.g., because I cannot agree on behalf of my paying client that their code be subject to the GPL, I am _not_ free to use GPL'ed code in the development of our software. however, because I do agree to a lot of other terms, I _am_ free to use source code that few other people are free to use because they don't agree to those terms (or haven't had the opportunity to).
_real_ freedom is not subject to what you agree to, but in the ability to agree or disagree with whatever you want and proceed from there. ergo, in at least one sense, "free software" is antithetical to real freedom. there is no such thing as arguing that people "should agree", and that's the change in attitude that I see from the Free Software movement: the freedom to choose commercial, proprietary, closed, or whatever software is no longer respected as much as it used to be.
| What exactly about my opinions do you have in mind here?
"advancing personal ambitions". you need hard evidence that that is what people are really after before you go public with such comments. people have ambitions of all sorts and shapes, but you're denying them the opportunity to be constructive by saying what you did, because one whose goals are "advancing personal ambitions" _will_ be illoyal to his peers and causes if he thinks he can profit on and get away with it.
always look for the constructive element in what people do. you might be surprised how often it is not the "personal amibition" it appears to be. competent people very seldom place their person above their merits -- I have found it to be a disturbingly recurring trait of the incompetent to do so, perhaps because their merits don't quite cut it. again, I am not willing to judge people that harshly without significant evidence.
| Is it that you think the OSI is a good thing?
I have no opinion on OSI.
| Perhaps your expectations were too high? Progress never happens over | night.
I tend to invest at least half a decade in something before I start to look for returns on investment. I don't know many other people who are equally patient. however, it doesn't appear that you need much evidence to imply that people believe in "overnight progress" nor that they might "advance personal ambitions", and your vagueness and non-committal form is quite annoying coupled with the vaguely derogatory style. it could be that "progress never happens over night" is just a meaningless phrase to you that seemed to fit, but why repeat content-less phrases, and out of context, even?
| Agree with these lofty goals 100%, but have to say that in reality, like | always, we'll have to live with compromises. Not every piece of code | will be as good as it could be. And it doesn't really have to be either, | if it does the job. Writing software is not a goal in itself, most | people write software to address a practical requirement.
what _do_ you actually say here? there are several paragraphs like this in both this and your previous messages. I can't spot the contents or the issue you want to raise -- it's all very comfortably non-committal.
I don't think life is about compromises, it's about goals and values and dealing with physical reality and other people's goals and values, and in this compromise is _sometimes_ a necessary evil, but reaching goals and upholding values is what makes it all worth it. for me, competence is such a high value that I'm unwilling to compromise it against anything. we don't _have_ to live with compromises -- it's a choice as good as any, and you are free to walk away. I do that sometimes, and I get this weird look from people who think they have to take all the shit that's given to them because "life's all about compromises".
| This is simply not true. Bad code has been removed from the Linux | kernel on many occasions, and the same is true for other projects.
only when it failed to "work". I haven't seen people go over free code in the "review" sense. but that's what it all needs. (BTW, it appears that the FreeBSD people are actively engaged in code review internally.)
| But I don't see any big problem with this. If it really works then why | fix it? The real problem with bad code is that it often doesn't work, | especially in the face of changing requirements. And after trying | band-aid fixes a few times it is certainly advisable to do it right.
it's bad because "if it ain't broke, don't fix it" has a bad habit of turning into "if we can't fix it, it ain't broke"¹, or, in more software terms, "it isn't a bug, it's a feature".
| Certainly. Of course I don't know you personally, but is it so outlandish | to consider the possibility that _you_ may have changed a little too?
as I said, I have ruled that out. what changes have occurred have to do with reaching the goals that I had with my free software work elsewhere, and it appears that I'm not at all alone in this regard, probably because the protest movement against closed source and no access has succeeded in giving people access, but at much more _reasonable_ terms than the GPL.
| No doubt, the FSF is changing too, like everything else.
I don't know what this statement means. I don't know what the entirely equivalent statement that everything stays the same means, either.
#:Erik ------- 1 attributed to Lt.Col. Walt Weir, USArmy -- Attention, Republican members of the House Judiciary Committee! We have intercepted a coded transmission from Bill Clinton to Saddam Hussein that puts your life in jeopardy. Clinton is prepared to cease fire if all of you are killed by Iraqi terrorists, whom he won't prosecute. Be warned!
* cba...@2xtreme.net (Christopher R. Barry) | I guess you think using "Stallmacs" to refer the the FSF maintained | version of Emacs is somehow deragatory, and I didn't know that you would | take it in that sense, because I didn't mean to attack it or anything.
then why not call it by its name? notice that the problems started when the XEmacs crowd called their Emacs version just that. users everywhere have serious problems talking about Emacs as opposed to XEmacs because of _their_ name. so those who think XEmacs is entitled to usurp the name space choose some other means to refer to Emacs, such as "Stallmacs", which I cannot fathom how you can even believe is _not_ derogatory -- think about how you came up with it, why you cannot call Emacs by its name, and what the real problem is. OK?
and if you know about the history of XEmacs and Emacs at all, you would _know_ that the stupid name collision is one of the contentious points. and of course I assume that people aren't completely ignorant when they ask about contentious issues.
| I'm not really an XEmacs proponent.
well, _excuse_ me for thinking that one looks, walks, and quacks like a stupid XEmacs proponent is one. my patience with that kind was exhausted years ago. there's a reason I don't talk about XEmacs. deal with it.
| I have both ACL 5.0 and CMUCL on my machine here, and (until very | recently) I used ACL 5.0 99% of the time. I'm now using CMUCL slightly | more, but have yet to really form any opinions about really favoring one | over the other. And if I did, and said that I say, like CMUCL more, but | not specifically downtalked ACL 5, and also wanted your opinion as | someone that has worked with some of the ACL 5 sources, would that have | also made your blood boil?
if you found cause to use a derogatory name for either of them, sure. incidentally, I'm not aware of any comparable hostility between ACL and CMUCL that you seem to take for granted or ignore between Emacs and XEmacs -- you just _can't_ compare two things without understanding whether they have similar natures at all.
BTW, XEmacs has another good thing going for it that I forgot besides getting MULE right (that is, the ability to compile without it): it is not scheduled for conversion to GUILE, which I consider to be another serious mistake in the FSF camp. all the language version chaos that reigns in Emacs Lisp and especially between XEmacs Lisp and Emacs Lisp is not getting any better with a language that has serious growth problems built into it. my first reason for wanting a Common Lisp Emacs was that it would have a stable language underneath it. trying to keep a lot of Emacs customization working is a lot more work than it should be, and I'll wager a bet that this is _because_ it is free software and there aren't very many reasons to do the boring work of maintaining a stable and a development release and actual specifications people can trust.
#:Erik -- Attention, Republican members of the House Judiciary Committee! We have intercepted a coded transmission from Bill Clinton to Saddam Hussein that puts your life in jeopardy. Clinton is prepared to cease fire if all of you are killed by Iraqi terrorists, whom he won't prosecute. Be warned!
On Tue, 15 Dec 1998 04:40:38 +0000, Paul Dietz <di...@interaccess.com> wrote: >Christopher Browne wrote:
>> This is even somewhat useful to the Lisp community, if it results in the >> availability of a reasonably stable platform on which to deploy Lisp >> systems. It might be nicer in some respects to have something >> implemented more deeply using Lisp, however that has the disadvantage >> that it means having to worry about the low level stuff that changes >> almost too fast to track.
>More directly, it might be useful to hack the Linux kernel to >more efficiently support Lisp, say by providing additional >ways of interacting with the virtual memory system.
... And if such hacks proved worthwhile, it would be entirely appropriate to submit such code for general inclusion in "production" versions of the Linux kernel.
>It might also be useful to have a Lisp that could run on >a microkernel like L4 or Fiasco, with Linux running beside >it (as another microkernel task.)
That is more useful for microkernels that are well-supported; 'tis not clear where L4 and Fiasco stand at this point. L4 having been made unavailable due to licensing issues not entirely unlike those associated with FluxOS, and Fiasco being "somewhat early in its history" and of unknown stability.
I would suggest the thought that it may be preferable to have a Lisp that runs on a highly supported kernel like Linux than to require that people get a research microkernel running. A reasonably competent UNIX person can have a PC, a floppy, and a CD, and reasonably expect to have Linux up and running within a half hour.
I've struggled unsuccessfully to try to get a purportedly "reasonably well-packaged" Hurd to boot. Initial browsing of L4 docs suggest that it is "fairly challenging" to install.
The point being that if the overall purpose is to Hack Lisp Code, time spent messing around with kernel installation is counterproductive, as is time spent trying to keep a research kernel somewhat in sync with developments in the Linux production kernels vis-a-vis new PC hardware...
-- "And 1.1.81 is officially BugFree(tm), so if you receive any bug reports on it, you know they are just evil lies." (By Linus Torvalds) cbbro...@hex.net- <http://www.ntlug.org/~cbbrowne/oses.html>
In article <871zlzvcws....@2xtreme.net> cba...@2xtreme.net (Christopher
R. Barry) writes:
> "I need some evidence that XEmacs proponents aren't _all_ [...], and > you're not it"
Well, recently I have been developing an Elisp package and more than once have had to rig some of the perfectly reasonable code just so that it would work for our XEmacs users. That is to say that XEmacs clearly does not work according to specification.
Erik Naggum <e...@naggum.no> writes: > only when it failed to "work". I haven't seen people go over free code > in the "review" sense. but that's what it all needs. (BTW, it appears > that the FreeBSD people are actively engaged in code review internally.)
In this area, the OpenBSD group has also been notable, in that one or two years ago they performed a full security audit on their source base. Other OSes (open- and closed-source) have mostly taken on the attitude, that fixing security holes one at a time as they appear on the diverse security alert fora is sufficient... ;-(
> it's bad because "if it ain't broke, don't fix it" has a bad habit of > turning into "if we can't fix it, it ain't broke"¹, or, in more software > terms, "it isn't a bug, it's a feature".
It's also problematic, in that broken code will slowly start infecting many other parts of the system, since others will have to code around the broken bits.
In article <3122861705479...@naggum.no>, Erik Naggum <e...@naggum.no> wrote:
>* cba...@2xtreme.net (Christopher R. Barry) >| I guess you think using "Stallmacs" to refer the the FSF maintained >| version of Emacs is somehow deragatory, and I didn't know that you would >| take it in that sense, because I didn't mean to attack it or anything.
> then why not call it by its name? notice that the problems started when > the XEmacs crowd called their Emacs version just that. users everywhere > have serious problems talking about Emacs as opposed to XEmacs because of > _their_ name. so those who think XEmacs is entitled to usurp the name > space choose some other means to refer to Emacs, such as "Stallmacs", > which I cannot fathom how you can even believe is _not_ derogatory -- > think about how you came up with it, why you cannot call Emacs by its > name, and what the real problem is. OK?
Are you saying that the name "Emacs" refers to FSF Emacs, or that people should say "FSF Emacs" or "GNU Emacs" rather than using a nickname like "Stallmacs"? If the former, I don't think that's right. "Emacs" refers to an entire family of editors, including: PDP-10 EMACS, Multics Emacs, Gosling/Unipress Emacs, Micro Emacs, Zimmerman's Emacs, GNU Emacs, Xemacs, and even Epsilon.
And how does the derivation of "Stallmacs" imply that it's derogatory? It seems to be an abbreviation of Stallman's Emacs, which is an accurate description of GNU Emacs. I admit that I'd never heard the term before this thread, but I instantly understood it and didn't think it was intended as an insult. Do you think there's something wrong with being associated with RMS? Or that the people who came up with that term do? Maybe it's like the word "nigger" -- if a white person uses it, it's an insult, but African Americans can use it among themselves with no such implications.
-- Barry Margolin, bar...@bbnplanet.com GTE Internetworking, Powered by BBN, Burlington, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Don't bother cc'ing followups to me.
In article <vrotneyF43sor....@netcom.com>, William Paul Vrotney <vrot...@netcom.com> wrote:
>Well, recently I have been developing an Elisp package and more than once >have had to rig some of the perfectly reasonable code just so that it >would work for our XEmacs users. That is to say that XEmacs clearly does >not work according to specification.
There's an Emacs specification that's intended to apply across different implementations? Since when?
-- Barry Margolin, bar...@bbnplanet.com GTE Internetworking, Powered by BBN, Burlington, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Don't bother cc'ing followups to me.
* Barry Margolin wrote: > Are you saying that the name "Emacs" refers to FSF Emacs, or that people > should say "FSF Emacs" or "GNU Emacs" rather than using a nickname like > "Stallmacs"? If the former, I don't think that's right. "Emacs" refers to > an entire family of editors, including: PDP-10 EMACS, Multics Emacs, > Gosling/Unipress Emacs, Micro Emacs, Zimmerman's Emacs, GNU Emacs, Xemacs, > and even Epsilon.
If I remember correctly, RMS's point of view was that Lucid Emacs (as it then was) was a GNU Emacs as well as the version looked after by the FSF. So he didn't like us (Lucid emacs people) calling the FSF variant `FSF Emacs'. It may have been that he was happy with `Lucid GNU Emacs' and `FSF GNU Emacs', but I'm not sure. He was pretty difficult about the whole thing, IMO. In any case the name change to XEmacs was pretty unfortunate, and was, I think, because Sun &c who were putting money into it then didn't want it called `Lucid'. I voted for Lambda Emacs (so the binary would still be lemacs...), but I don't think anyone listened. The ultimate irony is that Lucid then went bankrupt, so it could have been called Lucid GNU Emacs after all.
| Are you saying that the name "Emacs" refers to FSF Emacs, or that people | should say "FSF Emacs" or "GNU Emacs" rather than using a nickname like
Well, RMS once asked me (in private email) not to call Emacs "FSF Emacs". I have understood from other discussions in various Emacs newsgroups that the same wish applies to "GNU Emacs" too (although he didn't say anything about that). Thus, I use Emacs for Emacs and XEmacs for XEmacs. Simple.
| And how does the derivation of "Stallmacs" imply that it's derogatory? It | seems to be an abbreviation of Stallman's Emacs, which is an accurate | description of GNU Emacs. I admit that I'd never heard the term before | this thread, but I instantly understood it and didn't think it was intended | as an insult. Do you think there's something wrong with being associated
Perhaps it wasn't intended that way, but, personally, I wouldn't want to be on this planet when RMS hears Emacs being called "Stallmacs" :)
In article <_rae2.56$pr1.5...@burlma1-snr1.gtei.net>, Barry Margolin <bar...@bbnplanet.com> writes:
> In article <vrotneyF43sor....@netcom.com>, > William Paul Vrotney <vrot...@netcom.com> wrote: >>Well, recently I have been developing an Elisp package and more than once >>have had to rig some of the perfectly reasonable code just so that it >>would work for our XEmacs users. That is to say that XEmacs clearly does >>not work according to specification.
> There's an Emacs specification that's intended to apply across different > implementations? Since when?
> well, I don't believe that "non-free software" is a bad thing. > period.
> I believe that blocking people's access to the whatever they need > to do a good job and to understand what's going on is bad,
This is an interesting point of view. The point of the "free software" versus "non-free software" debate is, of course, exactly about making sure that people get this access to what they need. Sorry about repeating "old rhetoric" again, but your contradictory statements provoke such repetition.
> I get _better_ results in this exact regard from signing NDAs and > license agreements than I get from stamping GPL on my code or using > GPL'ed code,
You should have highlighted the word _I_ in this statement. You will have to admit that not everybody who needs access will get access in this way. With non-free software access is not a right, access is a privilege given to whoever the people controlling the software want to give that privilege. Effectively, the people who control the software get to decide who needs access. It is in this sense that non-free software is bad.
> and in some cases, purportedly free code contaminates a commercial > product to the point where one just cannot use it.
On this point I have had my own doubts about the GPL for a long time. Clearly, the GPL restricts freedom in the sense that GPL'd software cannot be used in certain circumstances. The way I look at this is that I accept this restriction because it is a means by which an author who makes the source available to everybody is trying to ensure that her work is not exploited by others who don't provide such access. On the other hand, I have no problem with software licenses that give totally unrestricted access to source code.
> that's why I have come to talk about "unrestricted source > availability", since what is free to you may be unfree to me, and > what is unfree to you may be free to me. e.g., because I cannot > agree on behalf of my paying client that their code be subject to > the GPL, I am _not_ free to use GPL'ed code in the development of > our software.
Not sure whether I get your point here. If you are advocating that there should be absolutely no restriction on access to source code, then I agree. But then, you said above that non-free software is not a bad thing? I'm confused.
> however, because I do agree to a lot of other terms, I _am_ free > to use source code that few other people are free to use because > they don't agree to those terms (or haven't had the opportunity > to).
You agree then, that source code access via an NDA is not the kind of unrestricted source availability we need?
> _real_ freedom is not subject to what you agree to, but in the > ability to agree or disagree with whatever you want and proceed > from there. ergo, in at least one sense, "free software" is > antithetical to real freedom.
Yes, one aspect of the GPL is problematic in this regard, namely the insistence that "any work based on" the software must fall under the same license. An acceptable objective here is that somebody granting access to source code wants to prevent others from exploiting her work. The problem is, that with software components and systems becoming more and more interrelated and integrated, it is becoming increasingly difficult to apply the mechanisms in the GPL/LGPL that try to differentiate between mere _use_ of a software package (in the way libraries are linked with programs) and a derivative work.
> there is no such thing as arguing that people "should agree", and > that's the change in attitude that I see from the Free Software > movement: the freedom to choose commercial, proprietary, closed, > or whatever software is no longer respected as much as it used to > be.
Agree in the sense that nobody should be forced to agree with, or use the license of, the Free Software Foundation. People should continue to have the right to use and create proprietary, closed software. Whether or not it is true that respect for these rights is less than what it used to be is open to question.
Note, that the right to create proprietary, closed software implies that freedom of access is explicitly denied, which I accept. If somebody doesn't agree with this restriction they can choose not to use proprietary software, but this is the only remedy. Equally though, it must be acceptable for people to put certain restrictions on the use of _their_ free software. And again, the only remedy for people who disagree with such restrictions is to not use the software.
> "advancing personal ambitions". you need hard evidence that that > is what people are really after before you go public with such > comments.
I'll accept your criticism on this point, I did indeed make these statements without providing specific evidence. Instead of providing such evidence now and starting another long debate I prefer to retract my statements, especially because I think this isn't the most important problem with the OSI (and I don't want to start a discussion about the OSI, period!). These issues are being discussed almost weekly on Slashdot, if anybody is interested...
> always look for the constructive element in what people do.
Thanks, for reminding me. _Everybody_ should heed this advise :-)
> I am not willing to judge people that harshly without significant > evidence.
Since you are giving out free advise, let me contribute some of my own: You may want to re-read some of your posts, one can detect an ever so slight tendency to "harshly judge people without significant evidence" even in _your_ posts. :-)
> | Perhaps your expectations were too high? Progress never happens over > | night.
> it doesn't appear that you need much evidence to imply that people > believe in "overnight progress" ... and your vagueness and > non-committal form is quite annoying
The simple reason for the vagueness was that I didn't want to claim that I knew the definitive reason for your believe that there was a failure. Was only suggesting that perhaps it hasn't failed with the finality you seemed to imply.
> | Agree with these lofty goals 100%, but have to say that in reality, like > | always, we'll have to live with compromises. Not every piece of code > | will be as good as it could be. And it doesn't really have to be either, > | if it does the job. Writing software is not a goal in itself, most > | people write software to address a practical requirement.
> what _do_ you actually say here?
I am saying that the purpose of software is to do a job, to work according to requirements. Whether a particular piece of source code is in bad style, is irrelevant as long as it complies with requirements and does the job. I disagree with the contention that it is worth going through working software with the only purpose to replace badly written (but correct) code with well-written code.
Now, before I am mis-interpreted here. I am not advocating bad code or incompetence. On the contrary, I have shaken my head in disbelief many times when reading bad code. When problems with such bad code do occur, then by all means take the opportunity to do it right.
> I don't think life is about compromises, it's about goals and > values and dealing with physical reality and other people's goals > and values, and in this compromise is _sometimes_ a necessary > evil,
That was more or less what I was trying to say. I might want to add one more reason for compromise with regard to the competence thing: Not every software project has the luxury to only employ people from the exclusive group of highly competent software developers like yourself. This requires certain compromises in terms of the kind of source code that is "acceptable", or "good enough".
> for me, competence is such a high value that I'm unwilling to > compromise it against anything.
Can't resist making another one of these "vaguely derogatory" remarks: Might this explain the tone in some of your posts? Being surrounded by incompetence must be hard to take! :-)
> we don't _have_ to live with compromises -- it's a choice as good > as any, and you are free to walk away.
We don't have to compromise on everything. But I still claim that the statement "we have to live with compromises" is very true if you want to achieve anything that requires collaboration with other people.
> | This is simply not true. Bad code has been removed from the Linux > | kernel on many occasions, and the same is true for other projects.
> only when it failed to "work". I haven't seen people go over free > code in the "review" sense.
Depends on the purpose of the review. If the only objective is to replace "bad code" with "good code" for the sake of purity then I firmly believe that most substantial software systems cannot afford such luxury, it usually does more harm than good. Of course, often bad code does, in fact, _not_ work, and then, yes! it should be fixed properly and band-aid solutions are short-sighted.
> it's bad because "if it ain't broke, don't fix it" has a bad habit > of turning into "if we can't fix it, it ain't broke"¹, or, in > more software terms, "it isn't a bug, it's a feature".
Then let us avoid the habit. The reluctance to fix broken software doesn't invalidate the argument that things that work don't need fixing.
On 16 Dec 1998 05:21:52 +0000, Erik Naggum <e...@naggum.no> claimed or asked:
% * trash...@david-steuber.com (David Steuber "The Interloper") % | I'm confused. Didn't you just flame free software a few posts back? % | Or did you just flame the idea that all software must be free? % % I did neither. pay attention.
I thought I was paying attention. Perhaps you weren't being clear?
> Erik Naggum <e...@naggum.no> writes: > > it's bad because "if it ain't broke, don't fix it" has a bad habit > > of turning into "if we can't fix it, it ain't broke"¹, or, in > > more software terms, "it isn't a bug, it's a feature".
> Then let us avoid the habit. The reluctance to fix broken software > doesn't invalidate the argument that things that work don't need > fixing.
Perhaps, but what _does_ invalidate it is that virtually the entire history of technological advancement is based on fixing things that weren't broken.
Hannu Koivisto <az...@iki.fi.ns> writes: > Barry Margolin <bar...@bbnplanet.com> writes:
> | Are you saying that the name "Emacs" refers to FSF Emacs, or that people > | should say "FSF Emacs" or "GNU Emacs" rather than using a nickname like
> Well, RMS once asked me (in private email) not to call Emacs > "FSF Emacs". I have understood from other discussions in various > Emacs newsgroups that the same wish applies to "GNU Emacs" too > (although he didn't say anything about that).
FWIW, Stallman uses the term ``GNU Emacs'' all the time.
> > | Are you saying that the name "Emacs" refers to FSF Emacs, or that people > > | should say "FSF Emacs" or "GNU Emacs" rather than using a nickname like
> > Well, RMS once asked me (in private email) not to call Emacs > > "FSF Emacs". I have understood from other discussions in various > > Emacs newsgroups that the same wish applies to "GNU Emacs" too > > (although he didn't say anything about that).
> FWIW, Stallman uses the term ``GNU Emacs'' all the time.
Also FWIW, when I start up Emacs on my machine it displays:
Welcome to GNU Emacs, one component of a Linux-based GNU system. [newbie commands snipped]
GNU Emacs 20.2.2 (i386-debian-linux-gnu, X toolkit) of The Jul 16 1998 on raven Copyright (C) 1997 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY; [rest snipped]
