Trisquel continuously crashing, the state of the FOSS community

> I have had much trouble with this OS. Both on my desktop and on a laptop,
> the OS will crash anywhere from 0-10 minutes after startup every time
> without incident.

This is unusual. I have installed Trisquel on many people's computers
and they have not had this problem.

> I doubt this is an installation issue as the
> Technoethical laptop came with the OS previously installed.
> Re-installing doesn't help.

Maybe a hardware issue then?

> I have no idea what kind of programmer
> fancied this project is even close to being viable for production when
> it appears this unstable. There is no way in hell mainstream adoption is
> possible with these kind of gaping bugs.

If adoption of operating systems had anything to do with quality no one
would be using Windows. :) Windows 8 and 10 are far buggier than any
GNU/Linux distribution I've tried.

In my opinion, the biggest obstacles to adoption of free operating
systems are social ones. If there are any significant technical
obstacles, I would say that they are the lack of free firmware for most
WiFi cards and many GPUs.

> The sloppiness of this software, combined with the lack of awareness and
> concern of these bugs in the free software movement will be its downfall.
> I am a programmer myself and this apathy deeply worries me.

It is completely understandable to be frustrated, and I hope we can
figure out what's wrong and stop your system from crashing, but your
experience is not universal. Most users do not encounter this issue. I
don't see any recent posts or bug reports about such any issue apart from
this thread. How can you know that people will be apathetic about your
issue before you've even told them about it?

> I'm happy to
> provide help to make this software more accessible and usable if someone
> can help point me in the right direction.

Great! I'm not much of a programmer, with just enough knowledge to fix
minor bugs, but I think by now I have a basic grasp on how Trisquel
development works. Here's a summary of what I know.

As you may know, Trisquel 8 is downstream from Ubuntu 16.04. Many
Ubuntu packages are simply rebuilt with the code unaltered, so
Trisquel development mostly deals with exceptions to this:

Some Ubuntu packages are completely removed, usually because they are
proprietary or specific to Ubuntu's branding. Here is the list of
packages purged from 16.04.

https://devel.trisquel.info/trisquel/ubuntu-purge/blob/master/purge-xenial

A handful of packages are maintained entirely by Trisquel. They appear
to be mostly data related to Trisquel branding and artwork.

https://devel.trisquel.info/trisquel/trisquel-packages/tree/master/8.0

Then there are packages from Ubuntu that need to be modified. Usually
this is to change Ubuntu branding to Trisquel branding, or to address a
freedom issue with an otherwise free package. This is done with package
helpers, which are scripts that modify the source code of the Ubuntu
package before rebuilding it.

For example, Firefox is free software, but it comes with support for
DRM, recommends proprietary addons, and doesn't have great default
privacy settings. The "make-firefox" script fixes these things. However,
Mozilla's trademark policy does not allow modified versions of their
software to use their branding, so the script also changes references to
"Mozilla" and "Firefox" with "Trisquel" and "Abrowser" respectively.

Here are the package helpers,

https://devel.trisquel.info/trisquel/package-helpers

and here is a guide to getting started with them.

https://devel.trisquel.info/trisquel/package-helpers/blob/flidas/CONTRIBUTING.md

> Let's start with whatever bug
> is causing the fatal crash on my machine.

The culprit could be
- a bug from upstream (might be worth checking Ubuntu's bug tracker)
- a bug introduced by a Trisquel package helper
- something specific to your hardware or configuration

> Thus far the primary
> culprits seem to be:
> - indicator-application-service
> - systemd

Maybe you could try disabling indicator-application-service entirely for
a day and see if the issue goes away, so that we know for sure whether
or not it has something to do with your problem.

I have been using Trisquel for nearly 10 years without without that problem. Indeed, Trisquel powers the servers for fsf.org and gnu.org (which handles tons of traffic each day from people all over the world for the entire GNU Project) without any problems. Perhaps it's better if you focus on presenting your problem rather than saying it's some distro-wide problem and that the entire free software movement will fail because of some problem that only you are reporting.

name at domain wrote ..
> I have had much trouble with this OS.

I have not. It's just as bad as Debian Stable, no worse, and a little
better.

> Both on my desktop and on a laptop, the
> OS will crash anywhere from 0-10 minutes after startup every time
without
> incident.

I have had Trisquel on several computers. They've all worked just as
good as any other OS, even with Wi-Fi.

- Asus laptop
- System76 Meerkat
- ThinkPad X60s
- ThinkPad X200

> I doubt this is an installation issue as the Technoethical laptop

I have no experience with Technoethical and don't need any. Minifree
has always served me well, providing me with very clean and functional
hardware and surpassing my expectations.

> I have no
> idea what kind of programmer fancied this project is even close to
being
> viable for production when it appears this unstable. There is no way
in hell
> mainstream adoption is possible with these kind of gaping bugs.

It's Ubuntu LTS. It powers many important services around the world.
The FSF uses it internally for all their operations. LibrePlanet was
streamed with Trisquel 8 before it was even released. The server that
powers my email runs Trisquel 8 and rarely ever has issues.

> The sloppiness of this software, combined with the lack of awareness
and
> concern of these bugs in the free software movement will be its
downfall. I
> am a programmer myself and this apathy deeply worries me. I'm happy to
> provide help to make this software more accessible and usable if
someone can
> help point me in the right direction.

https://devel.trisquel.info/

Get to work.

> Let's start with whatever bug is
> causing the fatal crash on my machine.

My Minifree machine Just Works™️. I'm buying a new one soon, in fact.

> Attached is a good portion of my syslog. There were probably at
least a dozen
> crashes within this log.

Have you tried booting plain Ubuntu 16.04 LTS on it? If I think there
might be an issue with upstream, I test it with upstream and report
the issue there.

Like jxself, I have been administrating several Trisquel systems for nearly a decade: a breeze.

About your syslog ('journalctl' could remove the mere notices...), those lines are repeated many times:
Feb 24 13:38:52 redbeard systemd[1]: Received SIGTERM from PID 1927 (killall).
Feb 24 13:38:52 redbeard systemd[1]: Reexecuting.
Feb 24 13:38:52 redbeard systemd[1]: systemd 229 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
Feb 24 13:38:52 redbeard systemd[1]: Detected architecture x86-64.
Feb 24 13:38:52 redbeard systemd[1]: Started ACPI event daemon.
Feb 24 13:38:52 redbeard systemd[1]: Started CUPS Scheduler.
Every second in fact. I believe it is a consequence of your "script that restarts indicator-application-service every single second". I do not understand why you want to blame "indicator-application-service" or "systemd". Would you care to explain?

When a crash occurs, your syslog does not contain any error but, sometimes, a sequence of unprintable characters. That is why, like chaosmonk, I would bet on an hardware issue. Probably the RAM. Have you tested it? Memtest86+ is in Trisquel repository and on some live ISO (but not Trisquel's).

@chaosmonk

> This is unusual. I have installed Trisquel on many people's computers
and they have not had this problem.

Then it appears I have been ambushed by a glint of poor fortune, since my success rate with this OS is 0%.

> Maybe a hardware issue then?

Could be... I doubt it. The laptop I bought from Technoethical was specifically sold with this OS installed. So, unless they are foolish enough to sell their stock on hardware components that are incompatible with Trisquel, the answer is no. And if Trisquel IS incompatible with any hardware that exists, that is a massive adoption barrier that need be addressed.

> If adoption of operating systems had anything to do with quality no one
would be using Windows. :) Windows 8 and 10 are far buggier than any
GNU/Linux distribution I've tried.

If the comparison we're titillating is Ubuntu, I'd be inclined to agree. However, Trisquel has contained more bugs than any OS I've used in my experience, to which I suspect all FSF distros are likely to experience similar fates.

> In my opinion, the biggest obstacles to adoption of free operating
systems are social ones. If there are any significant technical
obstacles, I would say that they are the lack of free firmware for most
WiFi cards and many GPUs.

The two are tied together. When I try and convince my friends and family to convert to free software, and tell them all of the moral upsides, they'll smile and nod the whole way; but the second you tell a human being they have something to lose, they will immediately rationalize an excuse as to why it's not worth it. If there is a single aspect to be lost, or if the transition is in anyway cumbersome, 99% of people won't give it the time of day -- unfortunate, but true. We can eradicate this problem by eradicating all downsides - bugs included, hence my urgency and tone.

> It is completely understandable to be frustrated, and I hope we can
figure out what's wrong and stop your system from crashing, but your
experience is not universal. Most users do not encounter this issue. I
don't see any recent posts or bug reports about such any issue apart from
this thread. How can you know that people will be apathetic about your
issue before you've even told them about it?

My experience should never happen to anyone. This is not a matter of personal offense; I'm trying to convey a matter of principle. A principle this community needs to rigorously adopt. It is THE worst conceivable thing to happen for widespread migration when the software breaks to the point where it is no longer usable. The fact that this happened even once should give you nightmares. Why is the fact that it is not happening to everyone consolation to you? Where is your urgency? This community needs a radical shift of mentality if it ever wants to make a lasting effect.

As for why I know that people must have been negligent to let this happen, is due to the fact that a branch with such a fatal error was even deployed in the first place. Perhaps I made myself unclear in just how big of a deal I think this is. As much as we can have fun bashing Windows, I've never heard of a case where someone installed it on the first day only to experience it crash reboot every 10 minutes, and to have this identical experience on two unique machines. Further, if the Windows developers then explained this to their boss as "but no one told us about the bug", they would be met with aggressive scorn coupled with a scrunching of eyebrows. The ownness is irrevocably on the developer to prevent something like this from happening, and the proper response to discovering a case of it slipping through their fingers should be absolute horror. Perhaps this is my more extremist idealistic programmer brain seeping through, but I believe the tenets to be irrefutable.

I'll have a look at the resources you provided, but in the meantime I am stuck as I can't look at my screen for more than 10 seconds before it shuts off.

---

@jxself

> I have been using Trisquel for nearly 10 years without without that problem. Indeed, Trisquel powers the servers for fsf.org and gnu.org (which handles tons of traffic each day from people all over the world for the entire GNU Project) without any problems. Perhaps it's better if you focus on presenting your problem rather than saying it's some distro-wide problem and that the entire free software movement will fail because of some problem that only you are reporting.

The fact that it works on other systems consistently should be the expectation, not a balancing act to someone else experiencing a fatal error. A bug that completely breaks usability is the worst possible outcome in the software-verse. As for how this extends to the community as a whole, I believe very well that this defeatist and apathetic attitude towards competing with Mac and Windows is pervasive. Instead of wanting to convince those users to migrate, rather there is often an elitist tongue vainly portraying these users as sheepish, whereas they could be motivated to educate and persuade them. Further, there is a feeling of a lowered bar for the average, everyday user experience based off of the features and stability of the software. If you don't think so, you should ask yourself why GNU/Linux is the least used OS framework without defaulting to one of those two responses. Also ask yourself why the responses on this forum merely seem to confirm my view.

---

@calher

> I have not. It's just as bad as Debian Stable, no worse, and a little
better.

I don't care. It should be as good as never breaking, and as bad as only the best. How's that for a bar?

It's great that your machine works. Every machine needs to work.

Thanks for the link, I will utilize it.

--

@Magic Banana

> Every second in fact. I believe it is a consequence of your "script that restarts indicator-application-service every single second". I do not understand why you want to blame "indicator-application-service" or "systemd". Would you care to explain?

After each crash, I would peruse the syslog only to find indicator-application-service acting up for several lines just before each crash, saying something about how there was already an instance running. I do realize my every-second killall script is a bit of a hacky solution, and as stated, not a long-term one. It was merely an attempt to use the damn system in the first place, and worked albeit briefly. systemd was suspect for similar reasons.

> When a crash occurs, your syslog does not contain any error but, sometimes, a sequence of unprintable characters. That is why, like chaosmonk, I would bet on an hardware issue. Probably the RAM. Have you tested it? Memtest86+ is in Trisquel repository and on some live ISO (but not Trisquel's).

Come to think of it, the RAM may very well be the issue. The seller may have upgraded the RAM before reselling the unit to me. No matter; I'm not going to downgrade the RAM merely to make it usable, it would make more sense to fix the bug. Where would Memtest86+ be logging its output to, if anywhere?

Trisquel panel's indicator applet (scrolling the volume) crashes sometimes but it can be relaunched. Other than that, I've had virtually zero issues with Trisquel 8 on my HP Probook 6460b laptop.

I'd put it down to "rush to conclusions".

http://catb.org/~esr/faqs/smart-questions.html#idm46060474146768

Don't rush to claim that you have found a bug

When asking your question, it is best to write as though you assume you are doing something wrong, even if you are privately pretty sure you have found an actual bug. If there really is a bug, you will hear about it in the answer. Play it so the maintainers will want to apologize to you if the bug is real, rather than so that you will owe them an apology if you have messed up.