Hello world

Anticipating that Flidas may not be available for some time, let me expand a bit more on preliminaries. In future I intend to start a separate thread on each one of them.

1. I believe that Trisquel should follow Debian, instead of Ubuntu. Reasons being;
* Debian is the kitchen and Ubuntu is a restaurant. Following the kitchen is always a step ahead of following its followers.
* Debian has 5 years of support too. ( https://wiki.debian.org/LTS )
* Following Debian means having both a LTS (stable) and a temporary rolling (testing) distro concurrently, which solves the problem of lagging behind.
* Debian is more dedicated to free software than Canonical, which can reduce DFSG compliance burden.
* Rolling out a LTS release is simple and streamlined. (as in Debian, just freeze the rolling-testing)

2. I believe that a compromise between "being unique" and "being complete" should be tipped -heavily- in favor of completeness. That is, less work should go into things like "what apps should be installed by default?" and more work should focus on things like "what workaround should be applied for DFSG incompatible hardware, media formats, communications protocols etc." Because application level functionality more or less is already there, while compatibility issues are the main challenge that confronts any DFSG compliant distro.

3. [Controversial] I believe that FSF should be pressured to fine tune their compliance terms. Currently there are just two options: ideal and unacceptable - black and white. Acceptable means ideal. This makes managing a distro acceptable to both DSFG _and_ the masses an enormous and unyielding task. I believe DFSG should expand on "ideal", "acceptable" (with minor compromises), and "unacceptable" system definitions. There are certain minor controversies over the "ideal" case, which, if acknowledged by FSF as "gray but acceptable" cases, would lift a heavy burden off distro maintainers' shoulders. I mean, like firmware blobs (not driver, just firmware), proprietary software referrals or providing viaducts (not obligations or inclusions), and the like. As far as I understand, they're all debatable gray areas and don't really derail or spoil the free software guidelines.

I can't see how FSF could be coaxed into buying it, so this is rather a speculative subject and could be postponed for the time being. I've presented it here for completeness only. So much for controversies. :)

As I've said, in the future I'll try to expand on each one of them separately in dedicated threads.

Hello, and welcome to the forum! :)

1.If you want a FSF-endorsed GNU/Linux distro based on Debian, you can see for gNewSense: gnewsense.org
Ubuntu LTS also has 5 years of support.
The Trisquel main goal isn't be steps ahead in technology. Instead, is to provide a fully free operating system easy to install and use.

2.I am agree with you, there are other things to do: https://listas.trisquel.info/pipermail/trisquel-devel/2016-November/001024.html

3.This is 50% true. Now, the FSF support Coreboot, a free BIOS but it contains binary blobs. The goal is to make devices compatible with Coreboot without these blobs. There's a project that provides a 100% free BIOS: libreboot.org

Also, you can use Debian with only "main" enabled. in h-node.org you can see you can use Debian for testing hardware.

Hi Magic, I should say upfront that I'm not criticizing Trisquel, nor am I trying to derail it. I just liked the idea and am trying to find some ways for mass adoption. That's all. I'm aware of the question of producing a free OS with best user experience with as low workload on developers as possible and with the limited resources at hand. This is a three-legged scale. We can't have it all and *this* is a reason for compromise - at least pour some thoughts on it. That's what I've been trying to do.

My original intent was separating FSDG requirements, distro personalization, and Debian vs. Ubuntu. But the issues are so intertwined that I don't know how to discuss them separately. OTOH rolling all into one thread might cause spreading it too thin, which might also be counterproductive.

You are right in stating that following a rolling release (Debian testing) would have required far more work than following a LTS one - with the presumption that most packages would be scrutinized for strict FSDG compliance, and there were some changes regarding personality (uniqueness) of Trisquel. But imagine that there were no FSDG compliance work needed for most of the packages, and that Trisquel had just a minimal personality - i.e. heavily depended on whatever desktop environment has to offer off the shelf. I'm oversimplifying the case for the sake of clarity.

Debian/main repository is kind of approved by FSF, if I'm not mistaken? If Trisquel taps on Debian testing/main repository (free riding on original Debian repositories) and add selected few apps from contrib and non-free, liberate them, and include them into a private Trisquel repository, then dev work would only be needed for those liberated apps. There would be literally no work needed to maintain the "main". Then following Debian testing could become much easier. Of course, on the condition that FSDG allows using Debian main repo untouched. Am I missing something here?

These are my main reasons for suggesting an "unpersonalized" distro and a bit loosened FSDG rules.

As per the firmware, well of course firmware is software. But to be inside OS domain, a software should be run by the OS. Software run on the hardware still belongs to hardware domain. A modem card has onboard ROM and runs firmware onboard. So a proprietary modem card locally running a non-free firmware off of onboard ROM, doesn't violate FSDG restrictions for free OS. Then how can it be named violation when a cousin of this modem card runs the same firmware locally off of onboard RAM? The only difference is that, in the previous case ROM based firmware is always there, and in the second case it's been uploaded (just upload, not run) by the OS into the modem cards RAM. This is why I called firmware blobs as gray area.

In my first three posts I've erroneously used DFSG (Debian Free Software Guidelines - by Debian) where I actually meant FSDG (GNU Free System Distribution Guidelines - by FSF). Please read them all as FSDG. Sorry for the confusion.

1.- Debian is already free software by Default.(Just use with caution do not add non free repository)

2.-I think you are talking about Trisquel development but I am not sure. I think a developer has all the right to work in a way that feels comfortable.

One of the great things about Free Software is that if you feel something is needed you can do it yourself (instead of asking someone else to do it) and send it to developers and share it with the community :)

3.- If the Free Software Foundation starts accepting non free software they would be hypocrites.

And also they understand really well that free software is about Ethics not about anything else.

Thats why they will never accept under any "practical" approach non free software

1. I can see your point about moving to Debian, and am largely inclined to agree with you. That said, there is already the free software distro gNewSense based on Debian, which I haven't tried, so I'm not sure it would be necessary to switch bases.
2. I'm not entirely sure what you mean, but it seems like a fair point. The thing that I found most exciting about Trisquel on first trying it was how it had most of the software I needed. That said, I do think presentation is important too, in particular not shifting towards touch-oriented WMs (e.g. Gnome 3 default)
3. Although I understand your point, I also feel as the risk in compromising is one that must be carefully assessed.

   As for firmware, the principle source of pain is not actually the fact that only free ones are installed by default, but a bug in Linux-Libre whereby the cleaning scripts strip the names of all blobs, making it impossible to install them. Fixing this would be beneficial. However, an OS installer adding proprietary firmware as it sees fit is not a good idea. For example, my current Fedora installation added firmware for my proprietary Wi-Fi card. This is what I need at present, but what if I had a libre USB Wi-Fi adapter? The system Debian employs is ideal, I think.

   With alternative repositories, I don't think there is anything inherently wrong with what Debian does (as you state). However, I still don't believe they should be entirely in the clear because the default distribution ISN'T entirely free. Although everything included is libre-licensed, (I am reasonably certain) the documentation and information provided about the distro references non-free software without flagging it as such. This means it isn't entirely suitable for certification, as it doesn't have any system in place to ensure uninitiated users are aware of what they get themselves into when the add (say) the non-free repo to get Adobe Reader.

   As such, I think you have a valid point, but:

   1. A better system of classification, perhaps, would be "Acceptable for everyone", "Acceptable for freedom-savvy users", and "Unacceptable".
   2. Although it isn't quite what you're looking for, the document at https://www.gnu.org/distros/common-distros.html does effectively act as distinguishing the two classes you listed.

Hi Soon,

I too haven't tried gNewSense yet, and I don't know its release policy. But whatever I say here in this forum should equally apply for them as well.

Let me go backwards from 3 to 1. :)

Such a FSDG compromise is one way, without turning back for corrections. So yes I agree, due care should be taken. I'm sure such a compromise -if ever made- would be evaluated from all angles diligently by FSF, so I'm counting on them about the technicalities.

As for FSDG classification / certification, I think we basically share the same point of view. I too don't believe in Debian's main repository getting full clearance ("Acceptable for everyone") from FSDG and also I'm not suggesting FSDG to be specifically adapted for Debian's needs, but certain compromises can be made by all parties involved, leading to a better cooperation community-wise (not just Debian). For instance, FSDG can make assessments based on repositories (as opposed to the whole distro) so that each distro can have layered assessments. E.g. Debian main (base system) gets "Acceptable for freedom-savvy" status, while other repositories (contrib and non-free) get "Unacceptable". Such layered assessments should be fairly easy for repository based distros. Also FSDG could ask for some prerequirements to be met, such as recommending free software *first* in a reference list if there are free viable alternatives for a given task. And Debian documentation adapts to that requirement. Things like that. The gist of it is if all parties can make even minor compromises and collaborate, then the whole community benefits from this.

Assuming Debian main repository gets the "Acceptable for freedom-savvy" clearance, a derivative distro like Trisquel depending on Debian's main repository, would automatically get the same status, and the rest would depend on private repositories of each derivative distro. If their other (private) repositories are like Debian's contrib/non-free then they get clearance only for the base system. Now this is where I expect Trisquel would thrive. Trisquel's private repository(ies) would be comprised of select applications picked from Debian's "Unacceptable" contrib and non-free repositories, which are then cleaned from non-free elements and served in a private "Acceptable" Trisquel repository (perhaps a couple of them, one being "for everyone" other being "for freedom-savvy"). So, while other distros can only get clearance for their base systems, Trisquel would get it for the whole distro. And the price to pay would be dramatically reduced due to most of the work (base system) is delegated to Debian - even physical repository serving to the world.

This would reduce the burden dramatically off the developers' shoulders. This, coupled with a "minimally personalized" distro strategy, should result in nearly all the work going into software/driver liberation efforts. This is what Trisquel is for, this the "reason d'etre" of Trisquel. So, concentrating all the resources on the core issues (which is sw/hw liberation) should eventually -theoretically?- bring the success and mass adoption.

It would be fantastic if there were so much resources that both liberation and personalization can be perfected at the same time. But we must accept the reality. My understanding is resources are tight and a lot of packages are in wait queue for liberation and/or maintenance. This is precisely why I advocate for an unpersonalized plain distro, but I need to cover that in another post as this is already getting huge.

Re, plain distro strategy.

A quick question. I got this whatever distro, customized it to my own taste and re-released it as Abdullah Linux 1.0 - actually what have I achieved? Not much really, just converted it from Ali's taste to Abdullah's taste. Both tastes turn out to be unpalatable to Soon, so he re-converts it to his own taste and so forth. No matter how many times it gets customized, it's always ripe for yet another customization. But the simple fact remains that, the original (Ali's) distro was already built to a sensible maturity, and all the recustomizations were redundant. My conclusion is, we can simply take what Debian default installation offers for whatever desktop environment selected and just be done with it.

Of course there will be exceptions like distro logo, distro name, maybe a wallpaper, minor changes to default apps list, docs pertaining the distro-specific changes... This is what a minimally personalized distro is, and it should be quite acceptable. From there on it's the user's taste and domain. BTW I think trying to dazzle the user with default apps selection art is somewhat a wasted effort and not a big deal really, as each user's taste is to himself and he can install whatever he likes. The apps list that excites you may disappoint me, and vice versa.

And changing as few packages as possible in the upstream distro has additional benefits (other than the saved time and energy gone into customization). Trisquel will be able to use Debian main repository to the full extent, save a few exceptions that contain distro logos etc. The whole burden of building, debugging, maintaining, rolling, even physical serving of the "main" repo, which presumably will constitute most of the distro, will be near zero. It's repercussions are self evident. More liberated hardware and software, less bugs, less resources drained. A good candidate for mass consumption. :)

PS: Not happy with defaults of a certain app? E.g. suppose in Debian Firefox comes with this -unwanted- feature enabled. Let it stay the way it is! The benefits of such changes are dwarfed against the long term costs of maintaining firefox separately in the private repo.

Re, Debian vs. Ubuntu. (I'll be partly reiterating myself)

1. Debian is the kitchen, Ubuntu is the restaurant. Ubuntu itself follows Debian. The original recipe cooks in the Debian kitchen and then Ubuntu serves it with a time lag. So, following the leader itself is always a step ahead than following the follower. Not that being a step ahead of Ubuntu is a big deal, but it's a bonus nevertheless.

2. Trisquel follows Ubuntu LTS which has 2 years release cycles and 5 years support. So is Debian: It's got 2 years stable release cycles, 3 years Debian inhouse team support + 2 years Debian LTS team support. So there's no disadvantage from support point of view. ( https://wiki.debian.org/LTS )

3. Ubuntu releases are rigid, whereas Debian is a blend of a both rigid and rolling distro. Debian stable releases are fixed and rigid, but testing (and unstable) releases are rolling. So, if Trisquel would follow Debian testing release in close lockstep (which also implies following stable release), then the outcome would've been a fixed release every 2 years (with 5 yrs of support) and a rolling testing release in between, which will get frozen after 2 years and thus become the next stable release. Best of both worlds.

4. Debian community is way more dedicated to philosophy of freedom than Canonical is. For instance take the spyware in Ubuntu Unity search feature.
See http://www.gnu.org/philosophy/ubuntu-spyware.html
Also see http://nathanheafner.com/home/2013/09/22/ubuntu-dash-search-is-not-anonymous/
Canonical builds business partnerships with non-free companies and while this is not a bad thing per-se from business perspective, this creates a slippery surface from free-software perspective. Long story short, following Ubuntu means more awareness needed, more scrutinizing hours spent, more possible hiccups, than following Debian. Debian (main repo) is a sure bet FOSS-wise. Following Ubuntu... I'd be keeping one eye open, just in case.

5. Since Debian stable is really just final freeze of the testing branch, to follow Debian/testing branch means that rolling out a release is as simple as freezing it. Whenever Debian freezes testing and releases it as the new stable, Trisquel just needs to do the same to roll out a new release. This in turn means both easy releases and least time to market (following the leader with minimal lag and with minimal effort).

So Trisquel becomes both long supported (5 years stable support) *and* cutting edge (rolling testing) *and* timely (just freeze to launch). What's more, most all free ride (tap on the native debian main repo).

So let me summarize.

Suppose for a moment that Trisquel is built in such a way that...
[EDIT: Also suppose that Debian/main is FSF cleared somehow]

* Trisquel follows Debian testing (therefore also stable) main repository in a tight lockstep. Since Debian's main repository is composed of -wishfully- FSF cleared packages, there's no need to create a separate trisquel/main for it. Trisquel just taps on the original Debian main repositories worldwide and gets a free ride. There are a few exceptions though, like Debian personalization packages, which can be modified for Trisquel and transferred to a private trisquel repository with a higher priority. Note that maintaining a rolling Trisquel version is easier than it might first sound, because only a limited number of liberated packages that are in private Trisquel repository needs to be maintained.

* Selected packages from Debian contrib and non-free repositories are liberated (almost all the Trisquel effort actually goes here) and served in a private trisquel repository with higher priority.

* Security updates are also handled the same way: Tap on the Debian security updates for "main" repository, and manage your own security updates separately for the -rather small- private repository.

* Absolutely nothing, not a single thing, is done for personalizing Trisquel, except distro logos, perhaps a wallpaper, basic documentetion of distro-specific peculiarities, and documentation pertaining to changes. So Trisquel comes with all the bells and whistles of whatever desktop manager happens to be installed, and nothing more. That should cover most all users' functionality needs - system-wise as well as application wise. For instance I may prefer KDE or Xfce over MATE. If Trisquel is to be personalized, then it should be personalized for *all* DE's, because if it's done only at MATE level, then all that personalization work would have been meaningless for anyone who uses another DE. On the other hand, if personalization is done for all the possible DE's to cover everyone, then this would be a big waste of time and effort. So the best bet is not personalize it at all - leave it to whatever Debain defaults to.

* By this logic, also installer is the very Debian Installer, untouched, except logo and distro name modifications and -optionally- default apps list.

Thus, all the energy saved from non-essential work can now be spent on excelling the free drivers, finding better substitutes for popular non-free apps, polishing them -if need be- to the same level as their closed source counterparts, developing a knowlegde/solution base for utilising unfriendly hardware and protocols, etc. That is, now all the energy can go into providing a libre OS with the best possible free alternative solutions to closed ones. This is a huge work already, so I think all the energy should be concentrated there.

Now we have a distro that is statically released biannually, covering the in-between time with a rolling testing release, with low release latency, with lowest possible extra work needed.

I don't claim that this is flawless or even well thought of strategy, but anyway it's a fresh approach to the main goal (of a libre and hopefully popular distro). The more tought poured on it, the better solutions will emerge.

I'll be partly reiterating myself too:

* Following Debian testing is a lot of work and Trisquel does not have the adequate work force. Same observation for biannual releases. Debian stable and Ubuntu LTS remain valid options for Trisquel's base. Trisquel has chosen Ubuntu LTS, i.e., it has chosen to be "closer to the kitchen" since Ubuntu is based on Debian unstable. Another 100% free GNU/Linux distribution, gNewSense, has chosen Debian stable.

* Most of the technical work achieved in the Trisquel project is writing package helpers (not theming). Basing Trisquel on Debian (rather than Ubuntu) would not ease the work because Ubuntu does not add freedom issues, except for the kernel (but the deblobbing script already exists). Try to list the package helpers in https://devel.trisquel.info/trisquel/package-helpers/tree/flidas/helpers that would become moot if the package was taken from Debian's repositories instead of Ubuntu's.

* Defaults matter a lot. Look around you: many users keep Windows' default wallpaper by fear of altering anything! In fact, the main reason why people use Windows is because it comes by default on their computers. Defaults even matter for highly technical users. For instance, one of the main critics to the OpenSSL library is its insecure default configuration: most of the applications using it were keeping that insecure default configuration. I guess most users of Trisquel keep its default desktop environment. It is hard to prove that point though: the less skilled users (for example my parents and my brother, who exclusively use Trisquel) do not actively participate in the community. Many (most?) users cannot choose their applications from a list, by lack of knowledge. They have no idea what difference it makes to choose MATE or GNOME or KDE or Xfce or... if they even know what a desktop environment is. And it is perfectly fine: users should be able to easily free themselves, without having to know the names of the different free software programs.

* https://www.gnu.org/distros/common-distros.html says that Debian's "installer in some cases recommends nonfree firmware files for the peripherals on the machine". It cannot be used "untouched", as you wrote.

* The Trisquel project has never dealt with "software/driver liberation efforts", "excelling the free drivers", "finding better substitutes for popular non-free apps", "polishing them", "developing a knowlegde/solution base for utilising unfriendly hardware and protocols", contrary to what you seem to believe. Almost no distribution does. Because that work had better be achieved upstream. Not at the level of the distribution. So that all distributions can profit from that work.

I just want to point out that following Debian Testing would be largely pointless, and it's not what Ubuntu does. Testing freezes non-security updates at some point so that it can become Stable, then that release becomes stable and a new Testing release is made, so it's not a smooth rolling release. Ubuntu derives its releases from Sid, not Testing.

Regarding "FSF should not compromise" opinion expressed by CalmStorm, hack and hack and others;

https://www.fsf.org/news/fsf-and-debian-join-forces-to-help-free-software-users-find-the-hardware-they-need

Upon this link (thanks to Alberto) I take my "loosened FSDG" suggestion back. Still, a layered, fine tuned approach of per-repository assessment (as opposed to per-distro) would be better in my opinion. Regardless, Debian/main seems to be officially declared as libre by FSF, as per the link above. At least this is what I inferred from the text. So, to my understanding, no compromise needed in order for a libre distribution to be able to tap on Debian's main repository, while keeping its FSF endorsement at the same time.