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

[Yavor Doganov]

Rubén Rodríguez Pérez wrote:
> > Thanks for the encouraging words.
> 
> I will add some skeptic ones.

Excellent, thank you even more for that!  I adore criticism.

> This list is just for _fully_free_ systems, and as by now there are
> only GNU/Linux distros in the list, this name was proposed.

OK, so talks about GNU/kFreeBSD are not off-topic.  Good.

> > in the free world there is no clear distinction between a
> > developer and a user, and that's a good thing.
> 
> This is not true.

I disagree.  This is what makes us a community.  The users have equal
powers as developers, where in the proprietary world users are just
helpless consumers who sycophantically follow their masters.  The
developers decide users' faith there, and often not even the
developers, but their bosses and managers.

In the free world everyone can contribute and decide herself about the
level of contribution/involvement.  This equality is fundamental, and
the ability to publish your modifications if they are rejected by the
developer for any reason is an absolute wealth.  If we lose it, we
lose everything.

> You are clearly a developer:

I am sorry if I left that impression.  I am most definitely not a
developer, let alone a hacker.  A user who wants to learn more about
the system than the average user and who wants to help the cause --
maybe that's what I am.

> you compile your own emacs

Compiling Emacs and other packages is what users typically do.  Users
of binary distributions like Debian have to do it less often, and
that's good.  The pool of free software packages is growing every
hour, so I very much appreciate this, especially having in mind the
archaic hardware I use.

> and you are bothered about the lack of debugging symbols.

Sure I am, but this doesn't imply I'm a developer.  I think that a
diligent user has to at least try to report every bug she encounters,
doing her best to submit the most decent and efficient bug report as
possible.  This should be possible by default, that's all I'm saying.

I also use GDB as a learning tool, to figure out how a specific
functionality works.  That's precisely because I'm not a developer,
and almost always can't figure out how the program works by just
looking at the source code :-)  The distro should make such tinkering
easy by default.

> but most users are not interested in becoming hackers, they just
> want to

Sure, the majority of the users are not interested in contributing to
the community, and don't even care to report the bugs they come upon.
There's nothing wrong with that, and they should be equally well
supported.

But our priority should be those who care to improve the software, and
we should do our best to teach users to become diligent users and good
members of the community.

> I like the idea of a free distro being a way for a user to become a
> developer: include compilers, code, debuggers, doc... but as a
> complement of a non-technical-user oriented system.

I firmly believe that a good system should be suitable for just about
any task one can think of.  That's the "universality" feature of
Debian that people value so much.  That's the goal of GNU as well.

> is probably why you also think that GNU is an usable system by
> itself.

Did I say that the system is perfect?  Absolutely no.  As an old user
I was witness of the improvements in the last two decades, and
definitely can say that there's a long way to go, still.  There are
hundreds of specialized applications that are missing free
replacements.

Other than that, I think the system is usable, yes.  It was less
usable when I started using it, and I remember almost all of the
troubles I went through.  I also remember my colleagues' hurdles when
we made the switch.

> Sadly it is not, we need lots of external programs to have a
> distro.

We agree here.

But you are missing the fact that the typical mindset of the new GNU
users that come from the non-free land is the consumer's, and what we
have to do is *not* to make the system more like their favorite
non-free one, but to change the way they think, look at and act in our
free world.  Only then we'll have a sustainable and healthy community,
and a system that is constantly improved and not degraded into
something worse just because we wanted to keep those guys pleased.

> The only way to have a GNU system,

But we have a GNU system!  It was never the intention the GNU system
to comprise only of GNU packages.  At the dawn of the project all
efforts have been made to reuse existing free software.  Facts like
rms' quest for a free compiler and the early decision to use large and
important software like X and TeX speak in favor of this.

> Is true that Debian is not as free as we'd like, but they are the
> closer we have,

I don't think so.  Please correct me if I'm wrong -- I read only two
Fedora lists (mostly to watch Alexandre Oliva's heroic Sisyphean
efforts, and for general information) -- but:

- Fedora doesn't have any contrib/non-free repos ("contrib" in
  Debian's meaning -- i.e. free software that depends on non-free)
- Fedora ships the free GNU manuals
- Because of Red Hat's corporate fears, they have a stricter policy
  regarding patents, but that's not a sin, just inconvenience for
  users.  Some people say that this policy even helps in the adoption
  of free audio/video codecs, and maybe they're right.

My only conclusion is that Fedora is closer to a free system than
Debian is.  Not yet there, surely.

> > > Basing on debian is a first step.
> > 
> > Fully agreed.
> 
> And another reason to keep working with them.

Of course.  Cooperation is always a good thing.  I never meant to burn
all bridges out there.

> > This was just one (albeit central) point of my plan, and it's not
> > something to be taken lightly.
> 
> I think that this is not a good idea.

I was expecting a comment like this.  As a GNUer, don't you want to
improve the system?  I'd even say that everyone who appreciates the
goals of the GNU project wishes it success, both on philosophical and
technical level.

> If a program is free, then it needs no replacement. Why should we
> replace, let's say. openssh -which has become an standard- with a
> new and unsupported GNU app?

TTBOMK, GNU lsh is supported both upstream and in Debian.  It's not
like we'd kick out openssh, cron or mawk.  Users who need them can
always install them, just like you can install lsh-utils or gawk now
even if it's not done by default.

My idea to switch to the GNU implementations is a natural act of
solidarity.  If we can't do this, who will?  Lots of bugs will be
discovered, and these packages will be eventually enhanced and will
hopefully surpass the functionality provided by the alternatives.

Such solidarity exists in other free communities, take a look at the
*BSD folks for example.  If you install FreeBSD, which is the default
`make' utility?  Wild guess: FreeBSD make (available in Debian in the
freebsd-buildutils package).  If you install NetBSD, which is the
default `make'?  Wild guess: yet another implementation, NetBSD make
(available here in the pmake package).

If you're brave enough to claim that GNU make is not the most popular
and most powerful make implementation, let me know :-)  I'd by amused
to argue just for the sport.  Yet, they include their own
implementations, because of natural solidarity and the desire to
improve their own system.  I guess their default shells are not Bash
as well, etc.

> There are lots of non-free software that needs a replacement, that's
> a much more urgent issue.

I agree 100% with you.  It is more urgent and more important, too.

But that's a bit out of scope from the perspective of a distro
maintainer.  The task of distro maintainers is to make the system more
usable, more coherent and integrated for the benefit of its users.  A
distro maintainer is a proxy for the user -- the complex task of
assembling the system is not anymore user's responsibility, like in
the early days.

> And by the way, you cannot replace them all as I said previously.

Naturally.  I don't suggest to introduce a GNU implementation which is
buggy and leads to important regressions.  This is a process that
should be handled with great care.

> Is there a point in replacing all but the kernel and the xserver?

I'm not sure why you think that X needs to be replaced?

,---- http://www.gnu.org/philosophy/x.html ----
| When you work on the core of X, on programs such as the X server,
| Xlib, and Xt, there is a practical reason not to use copyleft. The
| XFree86 group does an important job for the community in maintaining
| these programs, and the benefit of copylefting our changes would be
| less than the harm done by a fork in development. So it is better to
| work with the XFree86 group and not copyleft our changes on these
| programs. Likewise for utilities such as xset and xrdb, which are
| close to the core of X, and which do not need major improvements. At
| least we know that the XFree86 group has a firm commitment to
| developing these programs as free software.
`----------------------------------------------

Even the Hurd is not a priority for rms, not anymore.  But if someone
writes a working and powerful kernel and wants it to replace Hurd as a
kernel for GNU, I bet it would be seriously considered.  I hope that
Neil Walfield's research work on Viengoos will lead to something.

Shyam | ശ്യാം കാരനാട്ട്  | Karanattu wrote:
> something like that http://gns.katsarov.org/ ?

Everyone can upload here, and I'd be happy to grant you access.  If
you're interested, just mail me you public SSH key and I'll reply back
with details, possibly CCing the mailing list [1].

I feel obliged to point out a few obvous things:

- This is a time-consuming task and a great responsibility.  Breaking
  people's systems is Not A Good Thing, so do your best to make sure
  your changes are sane.  Of course, everybody makes mistakes, just
  try to minimize the fatal ones.
- You take care of all security uploads, and you have to watch out for
  such issues.  The automatic security fixes going on in gNS will not
  affect the users of your packages, because you bump the version.
- Subscribe to the PTS of the Debian package.  Users often report
  genuine bugs there which the Debian maintainer doesn't care to fix
  but you do.  Of course, often the Debian maintainer fixes something
  that you've missed or forgotten.
- If you can, watch the patches in other distros like Fedora and
  Gentoo; not all of them are forwarded upstream.
- Watch your upstream by all possible means.
- If you're not familiar with Debian packaging, start with a simple
  package.
- Don't choose a library, unless it is a small and stable one with few
  reverse dependencies.  Libraries are harder to maintain, and we
  can't carry out library transitions because this effectively means to
  maintain all packages involved in the transition (again, because of
  security concerns).
- Don't choose a package that is deeply dependendent on components low
  in the stack and other important libraries; this would require
  someone to take care of them too (example: gnome-power-manager).  (A
  Mexican developer wanted to maintain Pidgin once, but was stunned by
  the work involved when I told him that he should take care of all
  pidgin-foo extensions as well.)
- Be aware that when you step down, someone (most probably me as
  there's noone else active) must adobt your package, because we can't
  leave the users out in the cold.
- When there is a major distro release (like DeltaD -> DeltaH), try to
  upgrade quickly, and rebuild/reupload all of your packages.  This is
  not to hold other people from upgrading (when there are libraries
  with soname bumps in the new release that your package depends on),
  and to avoid reintroducing a version of your package that's not
  yours, but coming from Debian/Ubuntu -- this can (potentially) be
  something destructive, depending on how you have diverged and what
  you do in the maintainer scripts.  (If my plan is carried out some
  day, this problem will not exist as such packages won't be synced at
  all.)
- If you're not fully confident/pleased with your work, post a link to
  the .dsc or even a debdiff to the mailing list.  The more eyes look
  at it, the better.
- Please try not to neglect your duties as Malayalam gnu.org
  translation team co-ordinator :-))  (Joking, I just couldn't
  resist.)

> I would love to do join in as i have just learned the magic of
> building debs:)

Oh, I can assure you that this is something you'll never learn
completely.  The Debian toolchain is under constant development, and
new techniques are invented quite often.  There are new challenges to
solve, too.  Like most non-trivial things in life, you learn until the
moment you die.

Furthermore, there are many specific things related to a particular
set of packages that you simply don't have to learn.  Some people
won't ever need to touch Mono/OCaml packages, others are scared by
Java or GNUstep, etc.  Do what you're interested to do, what you
believe you can do, or what you feel you must do.

[1] http://mail.ivanovi.net/mailman/listinfo/gns-devel_ivanovi.net