The END of Trisquel as we know it
- Anmelden oder Registrieren um Kommentare zu schreiben
A little over a week ago, I posted a fairly successful article on my experience with Trisquel 8 on a Think Penguin J2 laptop recently purchased and received several really good responses to that thread.
https://trisquel.info/en/forum/my-story-about-trisquel-8
Most of the comments made by posters replying in the thread seemed to revolve around their use of Debian rather than Trisquel for their version of a GNU/Linux operating system. There was also a short discussion about the different {opinions} people had about the subject of what the phrase {stable} meant when it referred to a stable distribution.
I can only say that Trisquel 8 is FAST and STABLE and everything works for everything I have installed.
Certain packages/programs such as OBS-STUDIO are not available in Trisquel 8 because the dependency's are not available for installation from the Trisquel 8 repo's. I didn't actually make a list of things I tried to install which would not install because the software maintainers for Trisquel could not find FREE SOFTWARE equivalents for various packages which were used in Ubuntu 16.04 which is Trisquel 8's base.
All I could say was that for the packages I could install, all were stable and reliable and fast.
But, I digress somewhat because the subject of this article is "The END of Trisquel" as a distribution or perhaps the end of Trisquel as we know Trisquel today.
That is to say, Trisquel 9 might be the very last time we see the Trisquel project do what it does, which is to make a direct conversion of Ubuntu into Free Software.
The reason I say this is because in Ubuntu 19.10, we can see the first forced implementations of snappacks or snap images instead of debian packages as we are all used to seeing in previous versions of Ubuntu. And Trisquel will probably not use these snap packages as they will be full of NONFREE software components. We saw the same thing with FLATPAK's as Trisquel ripped out their support for FLATPAK's for the same reason ,, that FLATPAK's included nonfree software.
Trisquel does not have the manpower to make their own snap packages filled with FREE SOFTWARE components.
Nor does Trisquel have the resources to build their own debian packages for their use.
In the aformentioned article thread, the subject of gnewsense was brought up. gnewsense will be based on Debian but I don't believe they have made a release yet.
It was also mentioned that Trisquel itself used to be based on Debian.
It is certain that Trisquel will not be able to continue on as a Ubuntu based OS.
And since gnewsense will be based on Debian, there is no sense on continuing Trisquel on Debian as well. That would be redundant and somewhat backwards.
Running through the list of options which came through my mind over this delima, I surmised that Trisquel could rebase Trisquel 10 on Devuan or perhaps VOID Linux, which would also get rid of System D.
I think System D is perhaps the only thing I really don't like about Trisquel. And now would be a good time to remove it from the OS.
Of course, the other possibility would be to just rebase Parabola Linux into debian packages and continue producing Trisquel in somewhat the conventional sense that they are doing today. Perhaps even make it a quarterly rolling release such as we see in package source on NetBSD.
Something will have to be done or Trisquel will just end, that's for sure.
And if it does just end, I agree with my commentators that Debian is a decent replacement and perhaps we should just use Devuan or gnewsense in the future.
Anyway, I know this is a difficult subject and it's a negative subject I'm bringing up here on this article. I'm probably going to have a few people 'HOLLAR' at me for bringing it up.
But, I felt it needed to be brought up and kicked around and maybe the system engineers/planners for Trisquel would like to enlighten us all on what will happen to Trisquel 10. Will there even be a Trisquel 10????
Anyway, here's to nothing,,,
Charlie
> That is to say, Trisquel 9 might be the very last time we see the Trisquel project do what it does, which is to make a direct conversion of Ubuntu into Free Software.
> The reason I say this is because in Ubuntu 19.10, we can see the first forced implementations of snappacks or snap images instead of debian packages as we are all used to seeing in previous versions of Ubuntu.
Snap integration in Ubuntu is certainly an issue, but so far it has been surmountable. In contributing to Trisquel 9 development I have removed Snap integration from several Ubuntu 18.04 packages. It was annoying, but not impossible. Once Snap integration is removed, it does not matter to Trisquel how much non-free crap is in the Snap Store. Most software in the Snap Store either (a) non-free, in which case we don't want it, or (b) just a newer version of something also in Ubuntu's apt repos. The absence of Snap integration should not be a noticeable issue for Trisquel users, at this time.
What *would* be a serious problem is if Ubuntu began to phase out their apt repositories in favor of the Snap Store. I have speculated that they might eventually do this, at least with their Universe repository, but I have not so far seen evidence of them starting to do so yet. They are certainly pushing Snap, but have they actually started purging packages from their Main and/or Universe repositories? If so, can you link to some examples?
> In the aformentioned article thread, the subject of gnewsense was brought up. gnewsense will be based on Debian but I don't believe they have made a release yet.
Nor, have they started to work on a release, it seems. They have copied gNewSense's old code to a GitLab instance around the same time as this announcement,[1] but no new changes have been made to the code since.[2]
> It is certain that Trisquel will not be able to continue on as a Ubuntu based OS.
Based on what I have seen so far, it seems likely that Ubuntu will continue to be an okay base at least through Ubuntu 20.04 (Trisquel 10). If Ubuntu begins to phase out its apt repositories so that important packages are only available via Snap, it is possible that Trisquel will need to either rebase on Debian or integrate a FSDG-compliant distro-agnostic package manager like Guix in place of Snap. If this happens though, I think it would start to affect Trisquel 11 or later.
> And since gnewsense will be based on Debian, there is no sense on continuing Trisquel on Debian as well. That would be redundant and somewhat backwards.
I am not convinced at this time that gNewSense will be based on anything.
> Based on what I have seen so far, it seems likely that Ubuntu will continue to be an okay base at least through Ubuntu 20.04 (Trisquel 10). If Ubuntu begins to phase out its apt repositories so that important packages are only available via Snap, it is possible that Trisquel will need to either rebase on Debian or integrate a FSDG-compliant distro-agnostic package manager like Guix in place of Snap. If this happens though, I think it would start to affect Trisquel 11 or later.
But why is it desirable to avoid switching to Debian? Embracing Guix is, of course, too radical and too difficult. Better support for new hardware is the only somewhat significant advantage over Debian. But does it out-weight obvious disadvantages: software not in main (or restricted) is not supported, dependency on being downstream of Canonical and difficulty to deviate from their decisions (Debian is generally more sane and cares more about software freedom; Canonical cares about their profits from cloud and IoT instead).
> Better support for new hardware is the only somewhat significant advantage over Debian.
This is something that could be addressed by a point release which backports a newer kernel and graphics stack.
> But does it out-weight obvious disadvantages: software not in main (or restricted) is not supported, dependency on being downstream of Canonical and difficulty to deviate from their decisions (Debian is generally more sane and cares more about software freedom; Canonical cares about their profits from cloud and IoT instead).
I agree.
> But why is it desirable to avoid switching to Debian?
It would take some work to rebase on Debian. Users are anxious for a Trisquel 9 release, and a lot of progress has been made on Trisquel 9 with an Ubuntu 18.04 base. Maybe someday Trisquel should rebase on Debian, but now isn't the time.
> What *would* be a serious problem is if Ubuntu began to phase out their apt repositories in favor of the Snap Store. I have speculated that they might eventually do this, at least with their Universe repository, but I have not so far seen evidence of them starting to do so yet. They are certainly pushing Snap, but have they actually started purging packages from their Main and/or Universe repositories? If so, can you link to some examples?
I can't provide any specific examples now other than conversations had on various linux podcasts like mintcast and late night linux and others which have indicated the goal is to eliminate the repos in favor of using snaps as and open groups support system of maintenance for basic apps. EG Chromium.
Their intentions , as you stated, are clear. They wish to cut costs as Ubuntu is transforming from a desktop OS into a server os in the commercial space.
> FSDG-compliant distro-agnostic package manager like Guix in place of Snap.
I'm pretty impressed with GUIX. They don't use System D. And it's very current. Not exactly LTS stuff in Guix.
> I am not convinced at this time that gNewSense will be based on anything.
snicker&#%$@@!
But, the idea of using Devuan is still good. I think MX Linux is thinking about basing on Devuan. EXEGNUSLINUX has a new release ISO which is very cool too. They've got some good stuff. It would
cool if Devuan just broke off from Debian and were their own feed too.
But I get the point you are making in that Trisquel 10, as far as you know, will be routine.
It's Trisquel 11 which will most likely be affected.
Still, it would be prudent to start making plans on your own LMDE or something...
I don't think that Ubuntu would completely drop deb packages (at least in the near future). It is true that Ubuntu has been promoting its snap packages for a while, yet the main purpose is provide non-free software (like Chrome, and their number is very limited) on GNU/Linux, and thus improving "user experience". So there can be a few more Ubuntu-LTS-based Trisquel versions.
But since Ubuntu has never been a freedom-respecting distribution, we'd better be prepared to migrate to a "not-so-evil" distribution as a base.
> I don't think that Ubuntu would completely drop deb packages (at least in the near future)
Definitely not completely. I think that they will always use Debian packages for the base system. For end user applications, though, they seem to want users to use the Snap Store, even if the application is also available in their apt repositories. When an application is available both in the Snap Store and in their apt repositories, the Software Center recommends the snap version first.[1] If a substantial number of users are still using deb packages, they (hopefully) would be smart enough to not piss everyone off by removing them. However, if they succeed in migrating most of their users to Snap packages, I think it is not impossible that they would decide that any debs also available as snaps are no longer worth maintaining.
I think that this would not happen for a long time.
> But since Ubuntu has never been a freedom-respecting distribution, we'd better be prepared to migrate to a "not-so-evil" distribution as a base.
I think that Ubuntu will be an okay base for Trisquel 10 at least, but this is a possibility to keep in mind moving forward.
[1] https://help.ubuntu.com/stable/ubuntu-help/addremove-install.html.en
You can always rebase Trisquel on Hyperbola. Add an installer on it, some autoconfiguration scripts and you are done.
> You can always rebase Trisquel on Hyperbola.
I was initially excited about Hyperbola, and installed it on all of my machines except as my daily driver. I planned to switch over entirely once Hyperbola was ready for general use (at the time there were some issues like yet-to-be-written OpenRC scripts that prevented important packages from working). I thought Hyperbola would be the medium-term future of FSDG distros until Guix is ready. Eventually I realized that new problems were being introduced faster than the old ones were being fixed, and that as the devs continue to break compatibility and gut functionality, the distro is not getting less broken over time. LTS is not about having old versions of packages. It's about reliability and not having to worry that an update will break your system. In that regard, Hyperbola is even less stable than Arch. Maybe for the 1.0 release Hyperbola will become stable, but by that point it seems they will have ripped out so much software from the repos that it will be incompatible with much of the free software ecosystem. (They're removing entire programming languages, for Christ's sake.) To be clear, I have a lot of respect for the Hyperbola devs. They take software freedom more seriously than any other distro I know of. My only disagreement is with their approach, which I think is isolating them in a way that might not be survivable, and will result in a distro which is very secure and suitable for a certain niche of users, but not suitable as a general base for other distros.
I think a better idea would be to base on Debian. (The further upstream you base on the fewer parties you are heavily reliant on for sustainability and timely releases, and out of the major upstream distros, Debian is the most freedom-minded one that is not primarily maintained by one company. Debian also has broad architecture support, which will become important as x86 becomes harder and harder to use in freedom.) Have two branches, one based on Debian stable and one on Debian unstable, so that package helpers can be updated gradually as new changes are required one-by-one in Debian unstable. At the beginning of Debian testing's freeze period, start a testing branch and copy over the package helpers from unstable while the package versions approximately match, so that the new stable release is ready the same day as Debian's new stable release. If we want init modularity, import packages and/or patches from antiX, Devuan, and Debian experimental as needed to maintain compatibility with SysVinit (eudev, elogind, and the libpam-elogind-compat metapackage are enough to get you pretty far. libsystemd0 might be present, but not in a way that is more invasive than a normal libfoo Debian package and not in a way that breaks init modularity.)
Again though, if Ubuntu ever does become unsuitable as a base for Trisquel, it will not happen for a while. Certainly not by Trisquel 10. This is something to think about, but not urgent in my opinion.
Interestingly enough, antiX was at one time a distro that didn't put non-free stuff on their installation images and that used Linux-Libre. I guess that was a few releases ago. Of course, it's pretty easy to do anytime you are based on Debian like they are.
> I was initially excited about Hyperbola, and installed it on all of my machines
I have to research Hyperbola.
As far as I'm concerned, GUIX will replace ARCH.. GNU/HURD MOONSHOT...
I've used GUIX on Devuan, Slackware, ConnochaetOS, Freenix, and Trisquel 8 as well as stand alone GNU/Linux install. It's the most advanced OS I've ever seen in my life and I've been coding since 1975.
I'm learning about new things here on the Trisquel Forums and am enjoying myself.
I've also done the Debian to Devuan conversion scripts and their stuff just works.
So, if Trisquel 12 switched to Debian for it's base, it would be just clean fun for me to run the conversion on that trainset and see what happens.
I enjoy copying the mail here on this article thread.
> I've used GUIX on Devuan, Slackware, ConnochaetOS, Freenix, and Trisquel 8 as well as stand alone GNU/Linux install. It's the most advanced OS I've ever seen in my life and I've been coding since 1975.
I temporarily install GuixSD on a spare machine every so often to see how it's coming along. It's been a while though. Looks like they've reached the 1.0 mark,[1] and there's an actual installer now.[2] I should try it out sometime soon. I've also used the package manager with Trisquel in the past, but it's just so damn slow. I wonder if that's improved at all.
Install Guix. I don't know why would anyone still use old GNU/Linux instead of supporting true next-gen OSes. It's not about Trisquel, the problem is technical. I see 3 ways here. Either GNU/Linux will become more and more commercialized and will adopt superficially convenient (but dead-end in the long run) technologies like Flatpak that will inevitably turn it into a mostly non-free, semi-proprietary OS, or you will have these small, isolated, disconnected tinfoil hat communities that will be even more reactionary than big distros..
OR it will evolve into something new entirely, make a quantum leap as it were, and will transcend itself. The original idea was to grow freely in a decentralized manner like a mycelium, and I think both commercial and radical GNU/Linux communities simply failed to embody this idea, not least because of technical reasons, and moved in a totally wrong direction.
> Install Guix
Are you advising to install Guix-the-package-manager on top of other distros, or are you recommending Guix-the-distro? Do you use GuixSD as your daily driver?
> I don't know why would anyone still use old GNU/Linux instead of supporting true next-gen OSes.
I am excited about Guix in concept, and have tried both the package manager and distro periodically.
I used to use the package manager to install a handful of packages which either are not in Trisquel's repositories or for which I needed newer versions. However, the package manager was so slow that I found it more convenient to build these packages from source and run "git pull" and recompile to upgrade them.
I try out the distro periodically. It is continually improving, but last time I checked was still too buggy to recommend to a normal person who doesn't want to spend time working around them. I'm not a normal person, and if I were only thinking of myself the bugs would not stop me from using a distro I was otherwise excited about. However, I help a lot of partially-normal people migrate to free software who are open to free software values but not techy enough to handle something like Guix (in the state it was in last time I used it). For them I have to recommend something like Trisquel in the meantime, and so I use Trisquel too, partly for dogfood reasons, partly in order to stay familiar with it so I can more easily help them when they are stuck.
> Either GNU/Linux will become more and more commercialized and will adopt superficially convenient (but dead-end in the long run) technologies like Flatpak that will inevitably turn it into a mostly non-free, semi-proprietary OS
In the desktop space, I think this is a pretty likely outcome. It's certainly the direction Ubuntu is going (emphasizing Snap rather than Flatpak in their case). These distro-agnostic package management systems have the practical advantage of scaling better than repositories maintained by each distro. However, I suspect that the inconveniences of the traditional system have had the net-positive effect of disproportionately deterring proprietary app developers from targeting GNU/Linux compared to free app developers, and that Snap and Flatpak are likely to neutralize that dynamic, or even flip it (they increase the convenience of distributing binary packages more than they increase the convenience of distributing source code, which is more helpful to non-free app developers than a platform like Launchpad PPAs which, while flawed, requires source packages). Like you say, this is likely to result in a "a mostly non-free, semi-proprietary OS". Specifically, I think that things like the kernel, desktop environments, and core utilities are likely to remain free, but that non-free apps will take over when it comes to end user applications.
Simply excluding Snap from Trisquel, while the right call IMO, does not actually solve this problem. We need an alternative distro-agnostic package management system which is freedom-minded, and which has some practical advantages over Snap and Flatpak in order to be adopted by people who don't care about software freedom. I think that Guix-the-package-manager has the potential to become this, but it first needs to
* be faster
* have a graphical frontend
* distinguish between end-user applications and other packages (This doesn't necessarily have to be handled by the package manager. The frontend could handle it, although a solution at the package manager level could be interesting.)
I mean this as a way to prevent the GNU/Linux ecosystem from getting steered in a non-free direction at the high-userspace level. I don't think that the Canonical approach of trying to appeal to primarily to convenience will be successful in achieving widespread adoption of GNU/Linux. No matter how polished the user-facing software becomes, switching operating systems is itself inconvenient, which fatally undermines a strategy of appealing to convenience. This is some need for an appeal to other values than convenience.
> or you will have these small, isolated, disconnected tinfoil hat communities that will be even more reactionary than big distros..
I think I might agree with you here, to some extent, but before I assume I understand your viewpoint can you clarify what you mean by "reactionary" and "tinfoil hat" in this context?
> OR it will evolve into something new entirely, make a quantum leap as it were, and will transcend itself.
Are you just referring to Guix here, or do you have other examples of innovations with this potential?
"I understand your viewpoint can you clarify what you mean by "reactionary" and "tinfoil hat" in this context?"
By "reactionary" I mean misguided frustration. People who are caught in basic technological limitations of their own systems and are fated to go paranoid, so to say, because their objective technological level can't bring about things that were promised to them in the earlier days of free software.
They'll ask questions like, "where we failed?" "who contributes to our predicament?" etc. Whereas in realty they didn't fail, many things simply are structurally impossible in their present environment. So they start to implement projects that most likely will not change anything, like "systemd-free" distros, or start to profess privacy zealotry that can make Trisquel look like Windows. They start to see "the enemy" everywhere, out of dissatisfaction that they can not fully articulate or resolve.
Meanwhile, pragmatic and indifferent corporates take advantage of this general confusion and introduce their dubious yet efficient short-term solutions, which only adds up to the paranoia of free software groups, so these groups become afraid of any change that doesn't originate in their own tiny communities. Comically, it further cements their state of affairs.
"Are you just referring to Guix here, or do you have other examples of innovations with this potential?"
I think there are vague ideas of what a better future might look like already floating in the air of the present. I have no answers, and I don't know how it will turn out. But there are good signs that may give us some hints, like the advent of functional package managers, which I think is a great breakthrough for free operating systems, and can potentially make most current conventions of what comprises an OS obsolete. Not necessarily Guix, I think it's bigger than just a single project.
Snap and Flatpak are likely to neutralize that dynamic, or even flip it (they increase the convenience of distributing binary packages more than they increase the convenience of distributing source code, which is more helpful to non-free app developers than a platform like Launchpad PPAs which, while flawed, requires source packages). Like you say, this is likely to result in a "a mostly non-free, semi-proprietary OS".
As far as I remember, a significant difference between Snap and Flatpak is that Canonical runs the one single Snap repository, whereas anybody can administrate her own Flatak repository. Trisquel could run its own, with only free software.
I have been charmed....
https://www.youtube.com/watch?v=el6KTRV4Ej4
So, we will all build a *FREE* appimage collection and just publish this for *ALL*
Then we will all get the next release of FREENIX and retire....
My mental sickness... GUIX...
When the concept of FREE operating systems and FREE licenses came forth to us in the early 90's, I chose Slackware over i386BSD at that time because I believed the lawsuit would destroy any UNIX copies.
GNU's not UNIX. Yet it still had the same hangup's UNIX had in that you could install multiple versions of a particular library or program but it was very messy and was hard to maintain over time. You can still do this on Slackware to this very day as Slackware does not change it's core OS skeleton over time.
I started using OpenBSD about 14 years ago for the same reason, that OpenBSD does not change over time either.
So, I like systems which do not change over time and introduce security vulnerabilities and bugs and system administration headaches as the OS moves though time.
In the case of my OpenBSD server, it has been up for 12 years now and has had need for ONE configuration file change in all that time, upgrade after upgrade after upgrade. OpenBSD now had sysupgrade which automatically upgrades the base system so we don't need to make install/upgrade media from file images anymore or even download tar balls nor previously - download the sources via CVS and manually compile the entire system for every upgrade. OpenBSD has become Ubuntu - HA HA!!! It has...
SystemD based distro's constantly introduce new security problems with ever release, it's never ending.
Over time, SystemD has proven to NOT be the best/ most efficient way to boot a system. While I will say Trisquel boots very, very fast,,, I can not say that of other SystemD distro's as they don't keep up with configuration in those distro's. Trisquel is a hand crafted OS and the developers have taken the time to do it right. Lazyness prevails combined with those security problems on most SytemD distro's.
So, this is an important issue for me and GUIX resolved it just like Void did and Slackware and OpenBSD have done always... There is no need to change something which works, and introduce trouble in doing so.
GUIX uses a libre kernel and sources, just like Trisquel, just like Freenix, just like Parabola.
Linux Torvalds and the Linux kernel foundation have very poor judgement in what they allow into the kernel source tree. And by that comment, I don't mean just closed source blobs are added but rather, they allowed NSA code into the kernel one time,,, just to show the loonacy. It was removed but, the fact it got in their to begin with is a problem. You just can't trust that management team. And I'm not even opening the door of Microsoft being there now...
The people who work on our FREE liberated sources remove blobs and also errant code which is questionable and this helps... So, using a FREE distro which uses these sources helps a lot.
https://cdn.kernel.org/pub/linux/kernel/
GUIX is not UNIX either. GUIX is the first systen I've seen which is a brand new - unique - intelligently designed from the ground floor up - Operating System. GUIX fixes the mistakes and problem of UNIX.
Through the use of Symlinks, GUIX allows users to install multiple versions of various library's and programs intelligently/efficiently and maintain them over time. GUIX makes Flatpaks and Snaps obsolete.
GUIX makes UNIX obsolete.
We have witnessed the birth of a brand new generation of Operating System.
I realized when version 1.0 of GUIX came out finally, that every operating system I know of just died.
When I first started using GUIX, I tried to install it to an computer as the base OS and failed installing it. So, I started using GUIX packages thinking it would be something like NetBSD package source. GUIX provides the option today to install the current GNU/Linux OS to a computer or just use the package system, just like package source from NetBSD. You can install binaries or compile your own executables from source code through their system. I prefer compiling because it's more compatible.
GUIX allows you to install their packages across almost any Linux distro known. I have it running on Devuan, Slackware, Freenix, Trisquel and others..
By version 2.0 of GUIX, they will have filled out the new OS enough that it will be pretty common to talk to people who use it as a daily driver. It's a little buggy now, but mainly it needs more packages added to it's repo's to become a daily driver..
As I said, GUIX made me realize that all UNIX's are dead. This comment encompasses my feelings about Arch Linux as well as Gentoo and Void Linux. By the time version 2.0 of GUIX is released, you can see there is no real good reason to run Arch Linux because GUIX is a tip version OS. You can implement new software faster/better than Arch Linux does. Arch Linux is a frigging mess really. But at the same time, because of it's unique version control, GUIX also destroyed Debian. With Arch you run only TIP/CURRENT software. With Debian you run mainly/only STABLE. GUIX does all of this. GUIX is the messiah of the GNU's.
GUIX has only one flaw which is evident. It's not portable across different hardware architectures.
It's not NetBSD.
GUIX will also offer the GNU/HURD microkernel one day, that is their goal. And this will help resolve the issue of Linux Torvalds by simply removing him. But it also brings on the challenges of Intel DRM source code support and again we have this portability issue as the GNU/HURD won't run on just anything yet.
The two most advanced OS's which I follow closely are GUIX and OpenBSD.
The three best daily kick around driver OS's are Devuan, Trisquel and Freenix for me as all three of these options give me a totally FREE OS.
Of OpenBSD,
They offer way to many security enhancements for me to start talking about here.
DOAS is of note which replaces SUDO.
Trisquel repos have signify-openbsd which is the same signify we use on OpenBSD and I make use of this frequently.
And allow me to make a PLUG here for FuguIta OS out of Japan.
http://fuguita.org/
Yoshihiro Kawamata {KAW} my friend and his absolutely wonderful implementation of OpenBSD which I used as much as I use Trisquel. This is a good way to use OpenBSD for everyone and not install it to a hard drive.
So, no matter what happens at the Linux Foundation with the Linux Kernel, I have other OS options readily available to me. I'm happy we currently have fine people editing out the trash from the Linux Kernel sources to give us a FREE Linux kernel, but, as with my comments about Trisquel ending due to Cannonical, the same could be said of the FREE of blobs and DRM kernel we use here.
Not only do I see Trisquel eventually having to move away from a Ubuntu base but I see the Linux kernel sources being forked just so we can get away from {THEM}.............
So, long term, from my mindset, GUIX and OpenBSD, NetBSD maybe the only certain survivors who will not be involved or affected in this coming war.
> But at the same time, because of it's unique version control, GUIX also destroyed Debian. With Arch you run only TIP/CURRENT software. With Debian you run mainly/only STABLE. GUIX does all of this. GUIX is the messiah of the GNU's.
How does Guix (the distribution) allow you to run "stable" versions with bug fixes? You can run "frozen" old versions alongside the newer ones, but that's all. There are few exceptions to this rule. Am I wrong here?
It is possible to create a Debian-like, non-rolling-release distribution with Guix as its package manager, though.
>>>> It is possible to create a Debian-like, non-rolling-release distribution with Guix as its package manager, though.
Granted, it takes manual intervention at this point in time. But, it's obvious this is planned.
Their just at release 1.0 . The future is going to be WILD!!!
@andyprough
I'm replying to this comment [https://trisquel.info/en/forum/end-trisquel-we-know-it#comment-144827] here because first page of this thread has become very difficult to navigate.
It seems like you think I'm attacking MX. I have made some rather harsh statements in this thread, so I can understand why I could be coming across as hostile at this point, but I don't mean to be in this case. I actually tried out MX today (to check out the apt frontend you recommended in this thread[1]), and apart from including and promoting non-free software it seems like a fine distro. It's by far the best Xfce setup I've seen, and their custom tools provide some unique features that are perfect for intermediate level users. I think that MX's popularity is well-deserved. My only points are:
(1) While we can speculate in any direction who searches for distros on Distrowatch and for what reasons, without knowing for certain I don't think we can reliably reach specific conclusions about specific types of users based on Distrowatch rankings.
(2) Apart from using a default init system other than systemd, which is not something I've criticized about either distro (I'm all for it), MX has little in common with Hyperbola. In fact, they are almost opposites:
* Hyperbola is extremely dedicated to software freedom. They go further than any distro I know of, including Trisquel, to remove anything that even might become a freedom issue. MX not only includes Debian's non-free repositories, but actively promotes non-free software which isn't even in Debian's non-free repositories such as Chrome.
* Hyperbola prioritizes stability over new features. Although I have argued that the 0.x is not stable, this is because it is in flux due to sweeping policy decisions. Individual packages are highly stable as a direct result of their packaging guidelines, and I am sure that their packaging guidelines will result in a very stable 1.0 release. MX does not have such strict stability requirements, and backports new versions of many packages so that users can enjoy the latest and greatest features.
* Hyperbola tries to KISS, focusing on the quality of their repositories and base system and leaving users to set up their desktops themselves. MX puts great care into their heavily customized default desktop, and writes their own graphical tools to make intermediate-to-advanced tasks more accessible for beginning-to-intermediate level users.
* Hyperbola takes a very aggressive stance on what is allowed in their repositories, and an especially hard line against certain Red Hat software. When they decide that one program is better than another another, they not only change the default but purge the other program from the repository. In the future they plan to remove all software that they deem "unnecessary." They have completely purged systemd, and they plan to completely purge pulseaudio. MX seems to have no hard polices against packaging any particular software. They include all of the software in Debian's repositories. Systemd and pulseaudio are not only available, but installed by default. (Although MX boots into SysVinit by default, it comes with systemd installed alongside SysVinit and gives users the option of booting into either init system.)
So regardless of which demographics of users are responsible for MX's popularity, it seems like a stretch to conclude that therefore Hyperbola is likely to become popular too.
[1] https://trisquel.info/en/forum/addremove-applications-alternative-trisquel-9
> It seems like you think I'm attacking MX. I have made some rather harsh statements in this thread, so I can understand why I could be coming across as hostile at this point, but I don't mean to be in this case.
Not at all, I think it's a lively discussion, nice to see you and Magic Banana jump into a troll lounge discussion like this, mix it up a little with us trolls every once in awhile.
> So regardless of which demographics of users are responsible for MX's popularity, it seems like a stretch to conclude that therefore Hyperbola is likely to become popular too.
You are probably correct. As I pointed out in the earlier post, they do have some things in common in terms of some respected leadership that has a following, and filling a need for an established set of users. Nothing you've said here is incorrect, but I think that Hyperbola is something that may end up being a bit special ultimately.
> I actually tried out MX today (to check out the apt frontend you recommended in this thread[1]), and apart from including and promoting non-free software it seems like a fine distro. It's by far the best Xfce setup I've seen, and their custom tools provide some unique features that are perfect for intermediate level users.
As I said earlier, one useful thing is the live USB remaster tool to get rid of non-free software and repos and install the Linux-libre kernel prior to installation. I think I have an ISO I remastered with all of that done if you want to have a look at it.
> Systemd and pulseaudio are not only available, but installed by default. (Although MX boots into SysVinit by default, it comes with systemd installed alongside SysVinit and gives users the option of booting into either init system.)
Nice to see choice be a priority, isn't it? You've got to admit, that's a pretty interesting setup. I also got rid of pulseaudio and added all the alsa packages I needed in order to get sound to run, but I don't know that most people would want to be bothered with that.
My crystal ball says that Snap is purely a gimmick to allow newbies to be given their comfort blankets (familiar nonfree apps, and newer versions of free code apps), without Ubuntu having to do the work, or take responsibility for the results. Allowing developers to package their own apps for the Snap store is cheaper for Ubuntu than doing the work of backporting or adding to their own repos. As with Firefox add-ons responsibility for any stability or security effects on the users' OS can be outsourced to the widget developer along with the packaging work.
We can of course spend an infinite amount of time casting the bones and trying to skry out what Canonical might do with Ubuntu in the future. My take is that they will do whatever is simplest and cheapest. I'm guessing that building a desktop distro on top of snapshots of Debian is fairly simple, and as a result, fairly cheap. Trisquel builds a desktop distro on top of releases of Ubuntu on the smell of an oily rag, so it can't be that expensive. So it seems likely to me that under the hood, Ubuntu will continue to be what it's always been - repackaged Debian. Which means it will be pretty safe for Trisquel to be based off Ubuntu for the foreseeable future.
> My take is that they will do whatever is simplest and cheapest.
Currently, they are encouraging users to use Snaps instead of debian packages where possible. The recommend snaps over debs in the Software Center. I have seen Ubuntu documentation which describes debs as intended for the base system and snaps intended for applications. Livepatch, a new Ubuntu-specific package, is only available as a snap package. If they are successful in migrating users from debs to snaps for a substantial number of packages, which will be simpler and cheaper: continuing to maintain redundant debian packages, or to drop support for debian packages which are also available as snap packages?
> I'm guessing that building a desktop distro on top of snapshots of Debian is fairly simple, and as a result, fairly cheap.
It's as simple as you choose for it to be.
Basing your releases on Debian stable is relatively simple, because Debian backports bug fixes and security updates to their stable snapshot. If you use your own snapshots like Ubuntu does, you have to maintain those packages yourself, which is a lot of work. Canonical's solution is to just not do all of that work, only maintaining the packages in Main and leaving those in Universe as-is from the snapshot date. ¯\_(ツ)_/¯
Another way Ubuntu complicates things is by heavily customizing core Debian packages with a mess of Ubuntu-specific patches that are not high-quality enough to be accepted upstream. I have run into this mess when porting some Ubuntu-specific software to Debian. (Casper and Ubiquity. I was successful with Casper, but eventually decided that Ubiquity wasn't worth the effort now that Debian packages Calamares). Casper depends on Ubuntu-specific patches to Busybox, and Ubiquity depends on parts of Unity which require patches to Gtk3. (The Gtk patches are largely why other distros have been reluctant to package Unity).
> Trisquel builds a desktop distro on top of releases of Ubuntu on the smell of an oily rag, so it can't be that expensive.
We couldn't possibly maintain our own snapshots. We only backport bug and security fixes when there is a significant problem with a package in Universe.
> So it seems likely to me that under the hood, Ubuntu will continue to be what it's always been - repackaged Debian. Which means it will be pretty safe for Trisquel to be based off Ubuntu for the foreseeable future.
In *near* future, I agree. I have reasonable confidence that Ubuntu 20.04 will be a suitable base for Trisquel 10. As for the *foreseeable* future, I can absolutely foresee a situation in which a large number of packages in Universe become redundant because most users have migrated to Snaps, and Canonical deciding to save themselves some work by dropping these debian packages. Of course we can't predict the future with with certainty, but I think that this is certainly a plausible outcome.
> We can of course spend an infinite amount of time casting the bones and trying to skry out what Canonical might do with Ubuntu in the future. My take is that they will do whatever is simplest and cheapest.
I think the only reason Ubuntu still exists at this point is because Shuttleworth wants to hang onto it long enough to find a big company to sell it to for a few billion dollars. With IBM having devoured RedHat, Oracle may need to buy an OS, as IBM could try to turn the screws on Oracle and make it harder and harder for them to use RedHat as their base for Oracle Linux. They are direct competitors in a lot of corporate markets, and IBM is not going to like giving their top competitor a free ride for too much longer.
This page is not functional with JavaScript disabled, and looking though the blocked scripts I see many from Cloudflare. Is this video hosted anywhere else?
Nope
- Anmelden oder Registrieren um Kommentare zu schreiben