[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gNewSense-users] New PFV Emacs mode (Re: What sucks about gNewSense

From: Edianer
Subject: Re: [gNewSense-users] New PFV Emacs mode (Re: What sucks about gNewSense?)
Date: Tue, 13 Nov 2007 09:01:35 +0100

wow thanks!


On Nov 12, 2007 7:41 PM, Bake Timmons <address@hidden> wrote:
> > How was THAT for a loaded title? :P
> >
> > We spend a LOT of time with PFV and as we go along we find out now and
> > then that we've got non-free software. Some scripts have been written
> > to help automate these checks, but it still takes "too long".
> > That got me thinking about the WEAKNESSES of gNewSense (and Free
> > Software distros in general) and I figured that a realistic
> > self-evaluation could help us improve the process of creating a Free
> > Software distro.
> >
> > I've made a post on UTUTO's forums asking a bit about what THEY do
> > (How do THEY identify binary blobs, for instance) and what weaknesses
> > they have. Hopefully we might be able to identify common weakpoints
> > and work together to solve them.
> >
> >  I don't believe that any package manager has built-in support for
> > license issues and this is something that I think is a technical flaw
> > that harms our distro - has anyone really thought about how much PFV
> > needs to be "redone" for gNewSense 2.0? Perhaps something like
> > liblicense is better to work out... Just brainstorming here.
> >
> > I don't know how to "find" binary blobs. I dont' know what they look
> > like in the source, so I'm almost totally useless as to determining
> > non-license freedom - Brian's Builder tools are very limited to the
> > version of the kernel gNewSense uses and will have to be re-tooled to
> > handle the newer versions that future versions will be built. Because
> > of this, despite our PFV we're still not 100% sure that user's
> > freedoms are fully protected.
> >
> > Everyone hopes that as more developers come on board, we'll be able to
> > do more and more, but I'd personally like to look at this from another
> > angle... How can we harness the skills that we have to best meet our
> > goals? For instance, I'm willing to learn more about programming so
> > that I can contribute more to the technical side. If we had tools to
> > give to less technical people to harness Linus's Law, we may be able
> > to do other things as well.
> >
> > What shortcomings do OTHER people see in the development process of the 
> > distro?
> >
> Thank you for the criticism, just enough impetus for me to announce the
> release of a PFV mode for Emacs, which I have attached to this email,
> along with a file of "license name" shortcuts that can be inserted with
> keystroke commands.
> --------------
> While I have not yet properly documented the mode, here is a short
> example:
> In Emacs, give the command pfv-top, then paste in a PFV wiki page that
> you wish to edit, such as
> Emacs then draws a previewed table to fill out.  Function key F11 shows
> a list of license names with shortcuts.  E.g.,
> 0: GPLv3+
> 1: GPLv2+
> 2: LGPLv3+
> 3: LGPLv2.1+
> 4: BSD License (revised)
> So, pressing C-z 3 inserts "BSD License (revised)" at the cursor
> position.
> The only things to fill out are just the names of the licenses and
> whether the package is free (Yes/No).  (There are a several other
> convenience functions, such as downloading package files and unpacking
> them for inspection, but they still have a kink or two that need to be
> ironed out.)
> When done, just give the command pfv-tbl2markup
> and your cursor shows up in a new buffer with converted markup
> (including the correct current package URLs, etc.) which can be copied
> and pasted into the wiki form.
> --------------
> We clearly have relied too much on the Debian copyright file, so I
> suppose a big help would be an automated way of classifying or
> clustering files in a package based on their license comments.
> I just have installed the crm114 package: The Controllable Regex
> Mutilator and Spam Filter.  More than a spam filter, it is like a super
> grep that may be do a good job on this kind of task.  It already has
> been used on a number of other classification/clustering tasks.  It may
> hold particular promise for non-programmers perhaps.  Perhaps some
> people have used a CLI a little and have played around with a few shell
> commands, such as grep.  (However, programmers might also profit from
> cmr114's unusual capabilities.)
> That is the "guessing" piece, which we must not underestimate.  Consider
> the licensing hodge-podge of just the Linux kernel alone.  The guessing
> capability need not be too smart, since it could just be used to
> automate, say, 90% of the work, with the 10% involving real thought.
> What I take from your comment also involves an organization piece, which
> I too very much symaptize with.  While the isolated files that we are
> editing comprise a database of sorts, I think a queryable format would
> be better, say a sqlite file.  Working with this kind of file would be
> an easy intermediate step to, say, ultimately devising some enhanced
> package manager features.
> Thanks again for stimulating some thought on these things.
> _______________________________________________
> gNewSense-users mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]