Re: whither GNU

Re: whither GNU

[Juanma Barranquero]

On Fri, Aug 22, 2008 at 02:34, Thomas Lord <lord@emf.net> wrote:

> The GNU projects, especially central ones like Emacs, do
> double duty as "messages" and their role as messages takes
> priority over technical quality.

That was pretty evident in the way bzr did get "chosen" as future dVCS
for Emacs.

   Juanma

whither GNU

[Thomas Lord]

It's interesting how this discussion has laid something bare:

The take away message from RMS' intransigence seems to be
that if you want to make a priority of exercising software freedom
so as to maximize the utility of available free software, you should
not subject yourself to GNU project leadership.  That seems
ironic but it shouldn't be a surprise:

The GNU projects, especially central ones like Emacs, do
double duty as "messages" and their role as messages takes
priority over technical quality.

I'm pretty sure that isn't what I signed up for when I
decided that software freedom is the Right Thing but
I guess other people's mileage may vary.

-t






Richard M. Stallman wrote:
>     About 4 years ago I asked you about whether it was compatible with the
>     GPL to distribute an XEmacs with a Qt interface, given that (a) the
>     X11 version of Qt had been relicensed to GPL, but (b) the Windows
>     version was still under a non-free license.
>
>     You replied that it was compatible if the build system provided no
>     support for linking Qt on the Windows system, and configure (for
>     Cygwin) warned that Qt is a nonfree library and therefore not
>     supported on Windows.
>
> That sounds right, but it is a different issue.
>
>
>
>   

Re: whither GNU

[David Robinow]

On Thu, Aug 21, 2008 at 8:17 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Fri, Aug 22, 2008 at 02:34, Thomas Lord <lord@emf.net> wrote:
>> The GNU projects, especially central ones like Emacs, do
>> double duty as "messages" and their role as messages takes
>> priority over technical quality.
>
> That was pretty evident in the way bzr did get "chosen" as future dVCS
> for Emacs.
No, that's a separate issue. Thomas is referring to the (unnecessary)
war against non-free software having preference over the improvement
of free software.
 The choice of bzr was perfectly reasonable. Emacs and bzr are part of
the GNU community. The choice has increased the "market share" of bzr
and has already led to improvements.
 Are there still problems? I don't know. I haven't used it yet. If you
find any you should file a bug report.

re: whither GNU

[Jonathan Yavner]

> Juanma Barranquero wrote:
>   That was pretty evident in the way bzr did get "chosen" as future
>   dVCS for Emacs.

> David Robinow wrote:
>   Are there still problems? I don't know. I haven't used it yet. If
>   you find any you should file a bug report.

I tried using it, but it was too slow, even for my small project (only 
1200 commits of history, bzr takes many seconds just to show "info").
I haven't bothered to file a bug report because previous messages on 
emacs-devel indicate that the bzr people are already quite aware of the 
speed problem.  I hope Emacs doesn't drop CVS until after bzr has been 
improved considerably.

I also tried git and looked at mercurial, but I haven't yet found the 
right dVCS for my application (central repository and working checkout 
on server, copy of repository and checkout on laptop, push from laptop 
to server updates server's checkout but only if no merge-conflicts 
occur).  For now I'm still using CVS even though it doesn't really do 
the job.  A familiar tool with problems (and known workarounds) is 
better than an unfamiliar tool that still has problems but no known 
workarounds!

Re: whither GNU

[Johannes Weiner]

Hi,

"David Robinow" <drobinow@gmail.com> writes:

> On Thu, Aug 21, 2008 at 8:17 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
>> On Fri, Aug 22, 2008 at 02:34, Thomas Lord <lord@emf.net> wrote:
>>> The GNU projects, especially central ones like Emacs, do
>>> double duty as "messages" and their role as messages takes
>>> priority over technical quality.
>>
>> That was pretty evident in the way bzr did get "chosen" as future dVCS
>> for Emacs.
> No, that's a separate issue. Thomas is referring to the (unnecessary)
> war against non-free software having preference over the improvement
> of free software.
>  The choice of bzr was perfectly reasonable. Emacs and bzr are part of
> the GNU community. The choice has increased the "market share" of bzr
> and has already led to improvements.
>  Are there still problems? I don't know. I haven't used it yet. If you
> find any you should file a bug report.

Perhaps the devs might not be quite sure about calling it a bug, but
does it count when I say I have never ever checked out the bzr
repository because I just aborted the operation when it still said `I am
working' after almost 15 minutes?

Btw, there is no point for me in filing a bug report.  There is a free
program that works way better for me and I am not interested in using
something inferior.  I would ponder if the other one was non-free but
this way it's just ridiculous.

	Hannes

Re: whither GNU

[Jonathan Lange]

On Fri, Aug 22, 2008 at 2:47 PM, Jonathan Yavner <jyavner@member.fsf.org> wrote:
>> Juanma Barranquero wrote:
>>   That was pretty evident in the way bzr did get "chosen" as future
>>   dVCS for Emacs.
>
>> David Robinow wrote:
>>   Are there still problems? I don't know. I haven't used it yet. If
>>   you find any you should file a bug report.
>
> I tried using it, but it was too slow, even for my small project (only
> 1200 commits of history, bzr takes many seconds just to show "info").
> I haven't bothered to file a bug report because previous messages on
> emacs-devel indicate that the bzr people are already quite aware of the
> speed problem.  I hope Emacs doesn't drop CVS until after bzr has been
> improved considerably.

Well, the Bazaar hackers always appreciate well-filed bugs —
particularly those that include profiling information. And since
pretty much every release includes performance improvements, it's
worth filing a bug so you get notified when we fix *that* speed
problem. (Like most other complex applications, Bazaar's got a few of
them.)

Also, your particular bug interests me. :)

jml

Re: whither GNU

[Juanma Barranquero]

On Fri, Aug 22, 2008 at 05:40, David Robinow <drobinow@gmail.com> wrote:

> No, that's a separate issue.

I don't think so. I was answering to that specific point: that some
GNU projects do double duty. bzr was chosen as a political statement,
so its role as message took priority over technical quality (its
technical quality, and those of the alternatives).

> Thomas is referring to the (unnecessary)
> war against non-free software having preference over the improvement
> of free software.

I've been reading the thread.

>  The choice of bzr was perfectly reasonable. Emacs and bzr are part of
> the GNU community. The choice has increased the "market share" of bzr
> and has already led to improvements.

You're agreeing with Tom: the choice of bzr was "perfectly reasonable"
for political, not technical, reasons.

>  Are there still problems? I don't know. I haven't used it yet. If you
> find any you should file a bug report.

I have used it. Perhaps that's why it's a bit more difficult for me to
consider it a perfectly reasonable choice.

(I'm not trying to restart that debate, though; I'm just agreeing with
Tom on a very specific point of his very interesting thoughts).

  Juanma

Re: whither GNU

[Thomas Lord]

Juanma Barranquero wrote:
> (I'm not trying to restart that debate, though; I'm just agreeing with
> Tom on a very specific point of his very interesting thoughts).
>   

It's "off topic" no matter where you bring it up (which is itself
an interesting fact) but ... yeah ... I have trouble cottoning to
any purported free software movement leadership that comes up
with some theory to explain why and demand that we do our
jobs as software engineers less well, on purpose.

Something is wrong with your political calculus if you manage
to come to that conclusion, in my opinion.

I can imagine doing deliberately less well is the Right Thing
if someone is holding a gun to your head, in some imaginable
circumstances, but as an overall GNU policy?  Think harder, RMS.


-t






>   Juanma
>
>
>
>   

Re: whither GNU

[Thomas Lord]

David Kastrup wrote:
> If technical superiority would have been RMS' priority, he would not
> have started the GNU project: 
It all started when he wanted to fix a bug in a printer driver
(the story goes)....





> a starting project will always be worse
> than existing solutions.

That's nothing to do with what we're talking about.

It's fine: we're building a new system and it starts off
"behind the pack".  Of course.

The question is what happens when we get to a fork
in the road.  Say, you are hacking some GNU code
and a choice arises:  you can make a change that makes
it better or you can avoid that change.  So, there's the
choice.    RMS is offering some pretty abstract
"theory" about why you should choose to *not* make
the improvement in these cases. 

Now, I'm not really reaching for some overarching
theory of my own about what makes a program
better or worse but I will go so far as to say that there
are some straightforward cases.  GCC is better (all
else being equal) with tree print/read.  Emacs is better
with a dynamic loader.   I don't think those are controversial
assertions *other than* RMS' theory that those features
put the free software movement at risk.

Now, wait and let's see if I understand this:  I should
fight for software freedom in order (among other things)
to have the rights to inspect and improve a program I
use but, in the course of my fight for software freedom,
I should inspect but not improve in these certain cases.
Sorry, that seems like a reductio ad absurdum conclusion --
there must be some bogus premise.    The bogus premise,
I see from about 20 years of history, is that it is important
to fret over what proprietary hacks a feature might enable.
It's a bogus premise because foresight is not 20-20:  we
sure kept people from making proprietary Emacs or
GCC add-ons but, meanwhile, built a heck of a platform
for proprietary web software.  Fretting over tactics to
avoid creating such platforms is pointless.  20 years of
experience shows this.  

So, I say, back to common sense and simple minded
"make the programs better."    Reject a dynamic loader
in Emacs if there is no good use for it or if the maintenance
cost is too high but don't reject it because someone might
possibly use it to launch proprietary code -- they'll do that
anyway, one way or another, using whatever features we
do include.




>   The free software movement which he started
> has always and consistently considered non-free software unacceptable.
> The "Open Source Movement", in contrast, tries selling free development
> models via claims of technical superiority.  RMS has never ascribed to
> that somewhat seductive idea.
>   

This has nothing to do, either, with the Open Source Industrial
Complex, or ESR's eyeball fetish, or any of that.   Quite independently
of any of those things there is a fork in the road: dynamic loader or
no.




> I don't see your use of insulting language like "think harder"

It's not insulting.   It's colloquial and comparatively mild.  

So: guess again.



>  as a
> desirable contribution either.  You imply that people coming to
> different conclusions than you or having other priorities must be
> stupid.
>   

Well, that's kind of true.   Yes, I think it is a dumb idea to ban
features like a dynamic loader in GNU Emacs.    That's not insulting.
I'm using "dumb" in the technical sense.  It means "please rethink that,"
or something close.   It also means "um, I'm not sure people should
trust the leadership if this is what they're coming up with."

If you can't say words like that in an engineering discussion
then you can't have an engineering discussion.   It isn't personal.
It isn't an attack.   Those words summarize the conclusion of the
critical analysis. 

My own mistakes in software engineering I usually describe
as "bone-headed" or "idiotic" or something like that.   Those
words are attributes of mistaken ideas -- they aren't personal
attacks.   Those are useful words in part because it is always important
to remember that anyone, especially one's self, can be "bone headed"
in an engineering project.    That's why we have peers -- to point
that kind of bogosity out, when it happens, if you are lucky.



> I can assure you that Richard is not an idiot 


He's been my supervisor.  I've worked in an office down the
hall from him.  I've interacted with him on and off for about 20 years.
I personally happen to like him although we aren't close.   I'm pretty
familiar with his strengths and weaknesses as a software engineer.


> (which is not to say that
> you can't find some relative idiots among free software supporters as
> well as anywhere else).  I can also tell you that this sort of public
> insulting and derision is not going to win any points for your case.
>   

Nobody is slinging insults and derision UNTIL YOU JUST THERE.

Stop impugning my character.   I can be understood perfectly well without
interpreting my comments as "insult" and "derision".   You have absolutely
no excuse for attacking my reputation that way.  Knock it off.



> Richard is not a person who takes kindly to this sort of behavior.  And
> I don't see that I can blame him much for that.
>   

Are you his spokesperson?



> If you want to show off your purported superiority, 

Um.... as one who is posturing as a defender of civility,
you make a *fine* hypocrite.


> go ahead and make a
> spectacle of yourself. 

WTF?!?



> But if you want to have your arguments
> considered at all, you'd better choose a different conversation style

Ok.  Try this one:  shut up with that noise.

I've been critical of some ideas that have governed GNU.  You've
"spun" that as if I'm on some kind of personal rampage trying
to attack RMS and prove my superiority or something.
YOU are the problem here, sycophant, and I'm tired of
being attacked in the way you are attacking me.

-t

Re: whither GNU

[Richard M. Stallman]

We need and appreciate bug reports for Emacs -- so please do report
the bugs you find in other free programs.