You wrote: > [lots of good points snipped] > > 1. For want of a better term, GNU/Linux. The original POSIX/UNIX > Operating System with Linux as the OS kernel, Glibc (usually) as the C > Library, a mix of BSD and GNU userland, the GNU toolchain and X for > workstations along with one of the many Desktop Environments. > > [...] > > Seen this way, what we want is clear. We want what we wanted from the > beginning, option #1. Simple, easy to articulate and pretty easy to > decide to include/exclude features based on the criteria. And when it > gets time to organize beyond some folks in an IRC channel, some thought > into codifying exactly what the project is and is not trying to > accomplish would be a good idea.
So I really like this line of thinking - trying to articulate the possible ideals/values of the distribution, so that people can work to a common purpose, and that those who have different views don't waste their time and rather contribute to some other project. So possibly candidate points related to this: - having established/simple/stable/documented interfaces between components, so that arbitrary components can be substituted - that there is a choice of components. I think the posix syscall API is probably the best example of this - there are multiple free kernels which can provide it (linux, various BSDs, hurd) and lots of free application code which uses it. But there are other examples - we have multiple shell implementations providing similar command lines, a stable file-system hierarchy, multiple mail clients understanding the same mbox/maildir formats, X11 servers by multiple vendors, etc. It is the change to intricate and fast-moving interfaces, as exemplified by systemd (but also other projects) is concerning, as this means discarding lots of well written and reliable code, almost just for the sake of change (famously gnome). And maybe even: - minimising the size and dependency graph of the essential system. I have had friends worry that the base Debian seems to have been growing each year so that it doesn't fit onto small/embedded systems anymore. For anybody who has tried to build a distribution from scratch particularly for a new architecture or just platform (a really instructive exercise), a small core lets one get to a running system quickly (the first big win), and then a self-hosting system (the real win). Beyond these points the nonessential stuff can depend on arbitrary things, but getting the core up and running is critical for a free distribution to support new/unconventional platforms, or to serve as base for other distributions or appliances. The downside is that somebody's favourite scripting language isn't essential - but it is still there ... it just not used in the core. Maybe visualise this as a well-formed tree, with the kernel, libc, compiler, shell and shell utilities forming the trunk and then only at some meters above ground things branching into complex dependencies ... I suppose there might be other goals related to security, which could be interesting, but that might be a discussion for a later date. Anyway, thanks for reading this far regards marc _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
