Re: [GNU-linux-libre] Re: any Free BSD variant?

[Sam Geeraerts]

Karl Goetz schreef:
> On Thu, 18 Jun 2009 01:48:00 +0300
> Waver Doganov <address@hidden> wrote:
(trim)
> > * The system should never ever contain non-free parts/components, no
> >   matter how unpopular the decision about the removal is.  This may
> >   seem self-explanatory, but it's not, actually.  This leaves no place
> >   for exceptions, like the (in)famous Debian GRs about the firmware in
> >   the Linux kernel.  A perfect example of this policy in action was
>
> I agree with the 'no exceptions'
> I'm interested to hear how you think this situation could be handled:
>
>  1 week before release 2 bits of non-free firmware are found in the
> kernel. Would you delay release? remove them in an update ASAP after
> release (to allow testing)? something else?
In relation to this: how do you "cleanly" handle a "heavy" freedom bug? 
To give an extreme example: suppose we find a problem with a core piece 
of X, after release, which requires it's removal. Do you just push the 
removing update to the repo, knowing that some users just install the 
updates they get without thinking about and preparing for the 
consequences? I think something like an advance warning would be in 
order then.

(trim)
> >   more about freedom, so Debian follows them.  However, non-free parts
> >   discovered in texlive are not removed in stable and oldstable
> >   releases.  My dream distro would treat these as "serious" bugs which
> >   warrant an update in stable and oldstable (when supported).
>
> Debians policy is not to change the archive post release - it would be
> a matter of policy to add a clause 'freedom bugs mean package removal'
> as we do in gNS, and the system under discussion would be good to go.
Agreed.

> > * GNU packages by design are intended to work together: this is
> >   inherently a very important and core decision, because the ultimate
>
> (trim)
>
> >   will by default use GNU packages that are intended for certain
> >   tasks, instead of the (far more popular) non-GNU alternatives.  In
> >   no doubt this will help overall with the enhancement of the GNU
> >   system.  FWIW, I somewhat partially agree with the widespread
> >   opinion that in the recent years lots of packages of dubious quality
> >   (like my own :-)) had become GNU packages, so the decision about
> >   switching to the GNU alternative should be deeply thought.
>
> Switching to GNU packages is a nice long term goal, but where the system
> is the only one using them in a certain way it puts all the burden of
> testing and integration onto that distro. Long term, perhaps a good
> goal, I won't try and do it in gNS though.
>  
> >   In short, this means that by default the following will happen:
>
> (trim)
>
> >   This goal is very ambitious, no doubt about that.  But I'm
> >   absolutely sure that it would be a good thing for GNU.  Making them
> >   default at least will make them more tested, especially in
> >   conjunction with the rest of the system.
>
> Agreed.
>  
Switching to GNU packages would be good for GNU, but would it be good 
for free sofware as a whole? I'd rather see a free distro (and upstream) 
with more users and contributors and less GNU than comparatively few 
users and contributors and more GNU. I agree that GNU packages have an 
advantage because of the ideological background, but that's also 
reflected in the distro's mission statement, so I'd rather see the 
software most users are already familiar with. gNewSense was based on 
Ubuntu because that was the most popular distro, so that it wouldn't be 
"alien" to new users, who could then devote all their attention to the 
freedom aspect of it.

> > * The system should not assume that the user is a clueless dummy.
>
> Thank you.
>
> >   According to my interpretation this does not contradict with the
> >   goal the system to be easy to use, which is something desirable.
> >   The problem here is that "easy to use" != "something that looks like
> >   Windoze || MuckOS".  Now, things like command-not-found are nice as
> >   a concept, and have noble goals, but how annoying it is to wait
>
> Pet peeve at this end too.
>
> Especially when it winds up with bugs like this: 
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524896
> Summary:
> FreeDesktop.org mandates a dozen directories in $HOME/ and they will be
> recreated if you remove them.
>
> >   nearly a minute on a slow machine thinking that the program does its
> >   job, while at the end discovering that the CPU cycles went for
> >   Packages.gz parsing?  Users just need to learn which packages
> >   provide the programs they need, and packages like command-not-found
> >   are not a replacement.
>
> Or need to learn how to search for the command they want (`apt-cache
> search coreutils` or synaptic -> find -> coreutils for example).
I disagree. Almost everyone around me (except at work) is more or less a 
clueless dummy. It's not good to take resources away from freedom issues 
(educating and checking/removing packages) when dealing with technical 
issues (educating and support) is not really necessary. Even slightly 
less clueless people, like terminal newbies, should not have to know 
that coreutils happens to be the package they need. Using mostly old 
hardware myself, I wholy sympathize with the pain of slow processes, 
limited disk space and all that, but the people who are most likely to 
keep using that hardware probably know their way around. They wouldn't 
have much trouble disabling stuff like command-not-found.

(trim)
> I can't find a 'make-dfsg'.
Not really the same, but it illustrates my point. Someone looking for 
the 'link' command would not look for coreutils. I he was informed 
enough to know about apt-cache, he'd do 'apt-cache search link', which 
is not very helpful.

(trim)
> >   They are hard to maintain if not done upstream (this is true for any
> >   documentation format, of course).  I have personally never submitted
> >   upstream even one of those I wrote myself, because they make no
> >   sense and cannot be handled by upstream's build system (GNUstep Make
> >   in my case).  I absolutely hated every minute spent in nroff-mode
> >   (this is subjective, surely).
>
> Theres a number of 2man packages in Debian for this very reason. The
> man page format sucks to write.
>
> >   This "should" Debian Policy directive will be replaced by "Every
> >   program should contain documentation, in the most appropriate form
> >   suitable for it".  A requirement for documentation in Info format is
> >   nice, but not realistic to be adopted upstream.  Besides, Texinfo
>
> The nice thing about man is the skill required to use it: none.
> Navigating through info is like nethack (only the monsters are scarier
> when using info)
Man is not just easy to use, but it's also the de facto standard, like 
F1 in a GUI. If you're going to have documentation in its "most 
appropriate form" you'd practically need a meta-help command which would 
in turn invoke man/info/whatever so you would have to try 5 commands 
before hitting the right one for the manual. And then still have to know 
how to navigate in each possible interface. The man command effectively 
fills this meta-help role with a "should" policy. The man pages may be 
incomplete, but they would at least contain the most important 
information and possibly point to better documentation.

> > * Every package (ideally) will have a dedicated maintainer, who will
> >   ensure that it is always up-to-date and properly maintained, to the
> >   best of her ability.  This is the hardest (and most unrealistic)
> >   part, but it solves numerous fundamental issues, like:

I'm sure this would have happened if gNS had enough contributors.
> I dislike the single maintainer concept.
>
> >   - The maintainer will ensure that the package is entirely free,
> >     because she will review the diff between every upstream release,
> >     thus constantly verifying the package's suitability for inclusion.
> >     Efforts like PFV/KFV are admirable, but they'll never be
> >     completed, and are a waste.  Understandably, the gNS maintainers
>
> Yes, {P,K}FV are suboptimal.
>
> >     cannot review the diff between two releases, even if they happen
> >     to be extremely masochistic.
>
> We're bad, but not that bad ;)

Freedom checking by the maintainers is just PFV (incl. KFV) with more 
people. PFV as it is now leaves much to be desired, but it's one of the 
core tasks for a free distro. I've scribbled up some ideas about 
possible improvements, but I'd like to see us move to the new 
infrastructure and base system first. But with few people I think it 
makes more sense to have dedicated freedom checkers than to just have 
maintainer roles who's job description includes FV.

(trim)
> >     Unfortunately, a migration Debian -> gNS is out of question
> >     currently because gNS does not guarantee upgrades (an essential
>
> 2->3 will also be unsupported, but hopefully 3->4->onwards will be
> supported.

No 2->3 migration path is disappointing, but to be expected. This is my 
main reason for not pushing gNS as much as I'd like to in my real life 
surroundings. I agree that we should do better with future releases.
> >     feature of every system, I'd say), even though we're otherwise
>
> I agree.
>
> >     ready to do it (only my boss uses 2 non-free packages on his
> >     laptop, and I'll happily buy a network card with my own money for
> >     one machine where the driver is removed because it has blobs).
>
> kk