Hello everybody,
First things first, a big thank you to all our sponsors and donors. Many thanks to you and to all the people who support our project. I know we say it every month, but it’s important.
Fastly powered repositories
Earlier this month we announced a BETA test for our new Fastly repositories. This is a long test. The more people join it, the better.
We’re working with Fastly on a partnership to power the next generation of Linux Mint repositories. Their CDN (Content Delivery Network) and its caching mechanism are extremely impressive. Unlike our repository servers which are located in one place and have a maximum bandwidth capacity, the Fastly network replicates and caches data to make it available anywhere in the World, consistently at fast speed, without downtime or slow-downs.
To give you an idea, a single Linux Mint server currently serves data from Chicago at 1Gbps. The further away you are from Chicago the slower it might be for you. When the load is high (during a release or during a peak of important security updates affecting large packages), the server serves more people at the same time and so its 1Gbps bandwidth gets shared/divided between all the people who try to get data from it. When there are too many people trying to update, we get really slow speeds or even errors.
When Linux Mint started in 2006 our bandwidth needs were relatively modest. As the project grew year after year, the servers were upgraded to have more and more resources and allow for higher bandwidth. We also set up multiple servers and balanced the load between them. This allowed us to increase our capacity and face higher and higher loads. But the problem remains, it just depends on the load.
The Fastly network allows us to address the issue in a much better way. First, Fastly has servers in many different places in the World, so it no longer matters if you’re close or far from our servers. The data is cached by the Fastly network and serves efficiently anywhere. Second, because the data is cached, Fastly is able to provide it even when/if our servers become unreachable.
We’re hoping this test will be a success and lead to a great partnership with Fastly. Don’t hesitate to join the test and give us your feedback.
New partnership with Datadog
We are thrilled to announce a new partnership with Datadog.
Datadog specializes in… data. It’s not just monitoring and log analysis, they provide an incredibly customizable set of tools which lets you define your own parsers, metrics, dimensions and basically get the information you want, analyzed and monitored in real time.
The stats we shared last month, which showed the popularity of each Linux Mint edition, were powered by Datadog.
Datadog could make us understand our own services better. What are the most downloaded packages in our repositories? Which versions? How big is i386? Where is most of the bandwidth going? When during the week? etc.
Note: This data comes from the traffic on the download pages of our website. We do not collect any telemetry inside the OS.
Joining the Matrix
Following the discontinuation of Hexchat we announced efforts to make IRC easier with the development of a new custom chat room application called Jargonaut.
Jargonaut works. It works well and does exactly what we want. Its implementation was relatively easy and I’d say it’s now 75% complete.
When we announced it though, we heard some of your feedback about Matrix. We tested that as well and started using it.
Today we’re announcing we’ll be moving to Matrix and integrating Element into Mint 22 instead of Jargonaut.
While being as open as IRC, Matrix provides a user experience which is similar to Slack or Discord to some extent. It’s modern, it’s persistent, and simply by being modern and persistent it’s actually less confusing to newcomers than an extremely simple application like Jargonaut which connects you to a room without even having to log in.
Matrix also feels future-proof. It has everything it needs to be backed by the FOSS community at large. Its specifications continue to evolve. Its many clients provide a variety of choices today on different platforms and if we ever needed to make a custom client in the future it would be possible as well.
With a bit of integration, Matrix can be simple too. Mint 22 will feature a preinstalled Web App called Matrix.
That Web App will show you some information to help you get started:
And then it will connect you to the Linux Mint space on Matrix using a Web client called Element:
The Web App will be present in the WebApp Manager. If you want to use a different Matrix client, you’ll be able to modify it or delete it.
Of course, you don’t need to wait for Mint 22 to connect to the Linux Mint space on Matrix. You can simply head over to https://app.element.io/#/room/#linuxmint-space:matrix.org.
XApp should be independent
Linux Mint is the largest consumer of XApp applications, but the reason XApp was created, as a project, was to make these applications work everywhere and for everybody. Whenever a new XApp application was started, the goal was specifically to NOT make it Linux Mint and/or Cinnamon specific.
At a time where GNOME applications are less and less designed to work anywhere else than in GNOME, a project like XApp is extremely important.
Was it a success outside of Linux Mint though? Yes and no. Many Xapps are available in other distributions (Debian, Ubuntu, Fedora, Arch, etc..) but very few distributions actually make use of them.
Take Xubuntu for instance. It used to ship with file-roller, gnome-calculator, evince. These applications moved to libAdwaita (more on that in the next paragraph) and now look completely out of place in Xfce so Xubuntu replaced them with engrampa, mate-calc, atril..
For GNOME-Scan, it couldn’t find alternatives though.
This is GNOME-Scan and Atril side by side in Xubuntu 24.04:
This isn’t ideal for Xubuntu. These applications are installed by default, this is how it looks out of the box.
Before I go on with this, I want to say this isn’t criticism directed at Xubuntu. As an official Ubuntu derivative they cannot ship with a previous version of GNOME Scan, and I think it’s partly our fault they got in this situation.
So on the right you have Atril which looks like all the other apps in Xubuntu 24.04, and on the left you’ve got an app which has nothing to do here and which is designed to integrate specifically with GNOME Shell.
To add to the issue, although MATE apps such as mate-calc work everywhere, they were designed for MATE, so if you open up the application menu you don’t see “Calculator” in your Xubuntu desktop, but “MATE Calculator”.
Now, why is it partly our fault? Because we never knocked on Xfce’s door and/or worked with them.
They have the same problems as us, as MATE, as Budgie, as many other desktops.. we made Xapps because we needed them in Mint, in Cinnamon. We didn’t want to make Cinnamon apps, so we made “Linux” apps which worked “everywhere”, we wrote it somewhere and we left it that.
It was enough for us, but it wasn’t enough for Xubuntu or other desktops. From their point of view they saw Linux Mint making something in their own little corner and putting it on github.com/linuxmint, or even worse they saw nothing at all.
What should have happened ideally would have been more communication and an independent XApp project, not hosted or maintained by Linux Mint, but by people from various desktop and/or distributions.
XApp should be its own organization, with its own github repositories, chat room, website, etc. It should be a space which facilitates collaboration, compatibility and the development of application which works everywhere, not just apps which are needed or maintained by us.
If we want other developers and other projects to work together on compatible software and common solutions, we need a space like XApp. But this space needs to be independent of any DE and any distribution for everyone to feel equal and to feel welcome. Not just on paper, but in general, in discussions, empowerment and decision-making.
Xapp is on Matrix at https://matrix.to/#/#xapp:matrix.org. Everyone is welcome.
libAdwaita is for GNOME only
No matter what happens upstream, we will always do our best to make each Linux Mint release a better experience than the one you already have. Applications will be native and look native. They will integrate well. If we let you choose a desktop theme, ALL installed applications will support it.
If an application doesn’t support Cinnamon we can’t ship with it in our Cinnamon edition. The same goes for MATE and Xfce.
It would be completely unacceptable for us to ship with an application which used its own window controls and didn’t follow the system theme. Looking at it long-term, we also do not want our apps to be designed by people who have no consideration for what is important to us, and whose decisions are motivated by a desktop we don’t even use.
This is File Roller 3.42. This application has always been labeled as “for GNOME”, but it integrated well in any GTK desktop. With File Roller 44 this is no longer the case. It looks just like GNOME Scan in the previous screenshot. It’s not made for MATE, Cinnamon or Xfce and it really shows.
By moving to GTK4/libAdwaita this app really became a GNOME app, an app which looks specifically designed for GNOME and nothing else.
So what do we do in Linux Mint 22?
We could do like Ubuntu 24.04. They provide a finished product with a high level of integration. The way they do that is by modifying libAdwaita to support their theme: Yaru. We could do the same with Mint-Y. It would make all GNOME applications look nice in Linux Mint, but we’d have to remove theme selection, since it would only work with Mint-Y. In the long term it wouldn’t solve the main issue either: These applications are designed for a desktop which is more and more different to ours by the day. It’s not just a question of themes or look. Today these apps are losing menubars, themes, tomorrow they might come with no minimize button or anything GNOME doesn’t use.
We didn’t want to fork a whole suite of apps right now. Not with the upcoming major release and not before we try to make XApp more independent and boost collaboration with other projects.
In Mint 22 GNOME Font Viewer was removed and the following applications were downgraded back to GTK3 versions:
- Celluloid
- GNOME Calculator
- Simple Scan
- Baobab
- System Monitor
- GNOME Calendar
- File Roller
- Zenity
These applications are very likely to be forked in the near future, except for Zenity which we’ll probably stop using altogether.
libAdwaita is for GNOME and GNOME only. We can’t blame GNOME for this, they’ve been very clear about it from the start. It was made specifically for GNOME to have more freedom and build its own ecosystem without impacting GTK.
We want to send a strong signal upstream and towards other projects. We cannot and will not support applications which do not support our users and environments.
We can’t promote applications to our users which don’t support our users. The software manager will be vigilant towards that going forward and list compatible software by default.
I want to reach out to upstream developers here. If your application is only for GNOME, then by all means, ignore this and use libAdwaita, it’s made for that.
If you intend to support all environments then don’t use this library. At the very least please get in touch with us so we’re aware of your intention and keep you listed as a supported app. You can reach us at https://matrix.to/#/#linuxmint-dev:matrix.org.
Adwaita no longer works outside of GNOME
Adwaita (the theme) will be removed from the list of available themes in Cinnamon 6.2.
Here is the Adwaita icon theme in Ubuntu 24.04:
As you can see the theme provides icons for some categories (Internet, Accessories..etc) but not others. Many icons are missing, the desktop looks completely broken and it’s not a bug, it’s a feature. The direction Adwaita is taking is to only support GNOME and nothing else.
It would be OK if we could remove Adwaita or not ship with it, but we can’t. GTK depends on it.
Budgie didn’t wait for it to break and blacklisted Adwaita 2 years ago. We’re doing it now in Cinnamon. MATE and Xfce should probably do it since it looks just as bad on any non-GNOME desktop.
Flatpak verification is extremely important
In Linux Mint, is it safe to open up the Software Manager and install Google Chrome? Yes? No? Well.. it depends, and it has nothing to do with how much you trust Linux Mint, or Google.
You need to trust refi64 because it isn’t Mint or Google who update the Flatpak for Chrome, it’s someone who goes by the name of “refi64” on the Internet.
Now as it happens, refi64 is very nice developer. The problem isn’t refi64. The problem is that amongst the 6 million people who installed his Flatpak, very few people know who refi64 is.
In Flathub, a verified app is an app that is published by its original developer or a third party approved by the developer. Chrome is published by refi64 and is therefore “unverified”.
Right now, 42% of Flatpaks have been verified by Flathub. The store is actively trying to verify apps, especially now after the XZ story and the multiple times malware was injected in the Snap Store.
This is Chrome in the Linux Mint Software Manager:
There isn’t a single mention of refi64 here.
The situation online on the Flathub website is a little bit better:
The app is shown as “Unverified” but you still have to dig to find who’s maintaining it.
We’ve been lucky so far. We really need to take action:
- We’ll update the Software Manager to not show unverified Flatpaks by default. This will be an opt-in.
- When shown, unverified apps will have a score of 0. The score can help a user build trust towards the application, but the issue here isn’t the application, it’s the fact that the maintainers aren’t who people think they are.
- When shown, unverified apps will be clearly marked as unverified.
We’re fully aware this goes against convenience and will hurt Linux Mint a little bit. It might not be a popular decision but we think it’s a very important one.
By the time malware hits Flathub, we hope these measures and the measures taken by Flathub will have minimized the number of exposed users and raised awareness around the risks which are being taken.
In the case of XZ, the maintainer would have been “verified”. What worked for us was the vigilance of upstream developers and the time it took for new code to make its way into Linux Mint. The malware in XZ affected Debian Sid but it never made its way into Debian Stable, or Ubuntu LTS or Linux Mint.
Unlike the Debian base which takes months or even years to stabilize and reach you here, a Flatpak updated by its maintainer can reach millions of users almost instantaneously. We recommend automated updates, also for security reasons. When it comes to Flatpak the risk isn’t just taken at installation time, it’s taken with every update, at a time when you might not even think about Flatpaks. This is more risky than Windows users downloading software from random websites. It’s supported by the update manager.
You REALLY need to trust where you get your software from and in our own Software Manager we don’t show you the info you need to make informed decisions.
We’ll address this ASAP. Thank you for your attention on this important topic.
Edit: Refi64 wasn’t aware his identity was publicly available and asked for his real name not to be published. This article was edited to remove it.
Sponsorships:
Linux Mint is proudly sponsored by:
Gold Sponsors: Silver Sponsors:    |
Bronze Sponsors:         |
Donations in March:
A total of $9,626 were raised thanks to the generous contributions of 302 donors:
$1200 (8th donation), Abigail M.
$216, Luca P.
$200, John R.
$162, Karsten K.
$162, Thomas Metzinger
$150 (5th donation), Scott G.
$128, Christopher B.
$120 (4th donation), George C.
$120, Christopher L.
$108 (4th donation), Michael F.
$108 (3rd donation), Franky W.
$108, Endris
$108, Jean-pierre V.
$108, Michael K.
$100 (6th donation), Robin S.
$100 (5th donation), Brittany Taylor F.
$100 (3rd donation), Charlotte B.
$100, Douglas P.
$100, John R.
$100, Larry M.
$100, Rich B.
$100, Vaughn A.
$95, Jérôme G.
$80, Brendan Gilet Graphic Design
$59, Julie M.
$54 (18th donation), David M.
$54 (9th donation), Volker P.
$54 (4th donation), Reg O.
$54 (4th donation), Robert H. M.
$54 (3rd donation), Hubert F.
$54 (3rd donation), Jan Sepp
$54 (3rd donation), Kees K.
$54 (3rd donation), Philippe Robert aka “phsrobert”
$54 (2nd donation), Christian S.
$54 (2nd donation), Sergio B.
$54 (2nd donation), Siegfried S.
$54, Brian T.
$54, Christina R.
$54, Jürgen N.
$54, Konrad T.
$54, Laurent B.
$54, Leo P.
$54, Philippe A.
$54, Ryan M.
$54, Urs K.
$54, Yvo D.
$52 (7th donation), John Mc
$50 (82th donation), Anthony C. aka “ciak”
$50 (10th donation), Wade T.
$50 (8th donation), Terrence P.
$50 (6th donation), W G. M.
$50 (5th donation), Linden R.
$50 (4th donation), Brandon O.
$50 (4th donation), Peter B.
$50 (3rd donation), Charles H.
$50 (3rd donation), Clifford N.
$50 (2nd donation), Che H.
$50 (2nd donation), Neil M.
$50 (2nd donation), Willard M.
$50, Anders J.
$50, David B.
$50, Denis B.
$50, Erik M.
$50, Glenna D.
$50, Jeff M.
$40, Thomas L. aka “Calvicii”
$39 (2nd donation), Online Biz Builders SEO
$35, Willie E.
$32 (10th donation), Mark A.
$32 (5th donation), Andrew C.
$32 (4th donation), 974_RUN
$32 (3rd donation), jjb
$32 (2nd donation), Peter K.
$32, Antonio M.
$32, Bruno L.
$32, Harry F.
$30 (4th donation), Kevin H.
$30 (3rd donation), Carl T.
$30 (2nd donation), Ron N. aka “TechNick”
$27 (10th donation), Alexander M.
$27 (4th donation), Cezary Z.
$27, Rafael M.
$25 (37th donation), Linux Mint Sverige
$25 (14th donation), Charles W.
$25 (4th donation), William B.
$25 (2nd donation), John S.
$25 (2nd donation), Tim S.
$25, Anthony C.
$25, ATV Brakes N More
$25, Derek S.
$25, Kelvin W.
$25, Ross B.
$23 (2nd donation), Paul F.
$22 (46th donation), Peter E.
$22 (11th donation), Francois B. aka “Makoto”
$22 (9th donation), Marek S. [LMDE SUPPORTER]
$22 (8th donation), Benjamin W.
$22 (5th donation), Arno W.
$22 (5th donation), Mircea V.
$22 (4th donation), Ingo P.
$22 (4th donation), Neil S.
$22 (3rd donation), Frank S.
$22 (3rd donation), Jean, Jacques G.
$22 (3rd donation), Mario N.
$22 (3rd donation), Michael M.
$22 (3rd donation), P V.
$22 (2nd donation), Anthony O.
$22 (2nd donation), Daniel J.
$22 (2nd donation), Eero V.
$22 (2nd donation), Marc LASTHAUS
$22 (2nd donation), Reinhold S.
$22 (2nd donation), Robert B.
$22, André M.
$22, Charles A.
$22, Charles F.
$22, Charles V.
$22, Christopher R.
$22, David E.
$22, Elder D.
$22, Eric H.
$22, Franco H.
$22, Gerhard K.
$22, Jan Z.
$22, Jean-françois H.
$22, Jean-marie M.
$22, Jens K.
$22, Jeroen B.
$22, Jose Luis D.
$22, Leena N.
$22, Philip R.
$22, Rainer V.
$22, Sandro G.
$22, Stephane L.
$22, Xabier A.
$20 (46th donation), Stefan M. H.
$20 (28th donation), vagrantcow
$20 (22nd donation), Aimee W.
$20 (11th donation), Uncle Geek
$20 (10th donation), Robert D. aka “MacDhai”
$20 (9th donation), Daniel V. M.
$20 (7th donation), Andreas G.
$20 (3rd donation), Charles B.
$20 (3rd donation), Christian M. aka “manygave”
$20 (3rd donation), Illya Konnoff K.
$20 (3rd donation), M G U.
$20 (2nd donation), Melvin M.
$20 (2nd donation), Ted C.
$20, Alex R.
$20, David B.
$20, Edward R K.
$20, Eric M.
$20, Financial Advisor Diddel & Diddel
$20, Harry B.
$20, Howard B.
$20, Jason M.
$20, Jesse G.
$20, Karen L.
$20, Kimberly L.
$20, Marion P.
$20, Mark D.
$20, Paul C.
$20, Peter M.
$20, Ross B.
$16 (74th donation), Andreas S.
$16 (3rd donation), Helmuth P.
$16 (2nd donation), Martin B.
$15 (3rd donation), Terry P.
$15, Ewan T. aka “Blinks7588”
$11 (93th donation), Johann J.
$11 (47th donation), Daniel S.
$11 (24th donation), Tugaleres.com
$11 (21st donation), Denys G.
$11 (16th donation), Adis H.
$11 (15th donation), Peter R.
$11 (13th donation), Christian B.
$11 (11th donation), Robert W.
$11 (11th donation), Stefan W.
$11 (10th donation), François L.
$11 (10th donation), Karlheinz R.
$11 (9th donation), Darius O.
$11 (8th donation), Thomas R.
$11 (7th donation), Ivo H.
$11 (5th donation), Kjerkreit Ytre, Anders Kiær
$11 (5th donation), Joel E.
$11 (5th donation), Joerg B.
$11 (5th donation), Johnny H.
$11 (5th donation), Keith W.
$11 (4th donation), Aghiles C.
$11 (4th donation), Carlo R.
$11 (4th donation), Jan Z.
$11 (4th donation), Massimo F.
$11 (3rd donation), Karl-heinz P.
$11 (3rd donation), Rimas V.
$11 (2nd donation), Giovanni T.
$11 (2nd donation), Graham T.
$11 (2nd donation), K. M.
$11 (2nd donation), Neil E.
$11 (2nd donation), Pablo M.
$11 (2nd donation), Sami S.
$11 (2nd donation), Vinay B.
$11, Andrzej H.
$11, Armando M.
$11, Carolina S.
$11, Daniel C.
$11, Georg G.
$11, Innocenzo M.
$11, J.
$11, Joan P.
$11, John F.
$11, Klaus B.
$11, Knut L.
$11, Konstantinos A.
$11, Lorenzo P.
$11, Maurizio D.
$11, Mirjam S.
$11, Oana U.
$11, Pedro S.
$11, Robert A.
$11, Tim M.
$11, Tobias R.
$10 (96th donation), Thomas C.
$10 (90th donation), Frank K.
$10 (43th donation), Philip Woodward
$10 (15th donation), Troy T.
$10 (12th donation), Dave S.
$10 (12th donation), Fábio Ranquetat aka “Ranquetat”
$10 (10th donation), Thevirtua
$10 (8th donation), Michael B.
$10 (6th donation), Mihai-Vlad N.
$10 (5th donation), Carl T.
$10 (4th donation), Conrad M.
$10 (3rd donation), Geoffrey P.
$10 (3rd donation), George D.
$10 (3rd donation), Lubos K.
$10 (2nd donation), Jeffrey S.
$10 (2nd donation), Landscaping Fresno CA
$10 (2nd donation), Loren D.
$10 (2nd donation), Marcelo A. Maito
$10 (2nd donation), Michele D.
$10 (2nd donation), Oleksandra K.
$10 (2nd donation), Rick Edwards aka ” ”
$10 (2nd donation), Szymon G.
$10 (2nd donation), Tomasz K.
$10, B R S.
$10, Barbara W.
$10, Barry M.
$10, Computronix
$10, Computronix Managed IT Support & Cyber Security
$10, David N.
$10, Edward G.
$10, George R.
$10, H2Z45Y2K
$10, Luke P.
$10, Oleksandr O.
$10, Paul B.
$10, Paul C.
$10, Psychedelic Medicine Centers Of America
$10, REI Capital Growth Real Estate Investment Fund
$10, Steven R.
$10, Tarcísio F.
$10, Todd D. aka “Newfoundlander”
$10, Vlad N.
$8 (2nd donation), Ivan D.
$7 (35th donation), Sami Mannila
$147 from 38 smaller donations
If you want to help Linux Mint with a donation, please visit https://www.linuxmint.com/donors.php
Patrons:
Linux Mint is proudly supported by 1,086 patrons, for a sum of $3,304 per month.
To become a Linux Mint patron, please visit https://www.patreon.com/linux_mint
I’m sure not all of these decisions were easy to take… but I’m glad you did it. All those hard decisions is what makes Linux Mint the distro I trust and use every single day.
Thank you Clem and Mint team.
+1
Thank you and your team for going in this direction. Balancing what you want to do with what you can do must be very hard. Seeing what you have to do is even harder. The extra work beyond easy will be something that I will get used to doing. The decisions made by you and your team have always been for the best. I look forward to passing on to Linux newcomers the things that will keep us all secure.
I don’t pretend to understand everything that was explained here, but I have one piece of feedback about the comparison picture “This is GNOME-Scan and Atril side by side in Xubuntu 24.04:” — In my book, the GNOME version wins here: clear, immediate information. The other side could be anything, from waiting to work, to not work at all, to…? This is general feedback, to any devs, to keep users and usability in mind, not just “prettiness.” Same goes for scrollbars – some of us really need them, so don’t keep trying to kill them off. Just saying.
Hi Sam,
I agree with you, and I’ll also say this, I think libAdwaita (the hardcoded theme used by GNOME-Scan) is much better looking than Greybird (the theme used by the system, and Atril here in the picture).
But the problem isn’t which theme looks better. Ultimately that’s subjective and Xubuntu’s cosmetic decision. The problem is that they look completely different. Here on this picture you only see the theme and the window controls, but there’s also a huge different in layouts, UI, dialogs, button placement etc.
Thanks, Clem, for taking the time to respond. I just want to be clear: those two were meant to show the same state — not finding a scanner — correct? If that’s the case — and again, I have no clue about the options, just total user comment — is there a third option, that doesn’t look too different from everything else but is informative, quick and easy to grasp? The Atril version could really be anything. I needed to blow up the picture to even read what it was meant to be. And, if it’s actually really meant to be the image of the scanning app, that’s really confusing, because it says “Document Viewer.”
Personally, I’d much rather stick with different looking GNOME versions (hey, let’s embrace differences, if they’re mostly just cosmetic!) if they’re much easier and more intuitive to use. Maybe I’m just used to it from my old Windows days, using software made with differing layouts.
Hi Sam,
The app on the right is a PDF reader. They’re different apps doing different things. It’s not the content of the app the screenshot illustrates, it’s the differences in the look and feel, the theme and very importantly also the window controls.
Regarding Flatpak, I hope you can update it to the latest version that solves the recently found security problem (CVE-2024-32462).
I am happy to see that they are improving things that were not 100% resolved, such as app integration and themes. (ps. I hope you keep the symbolic icons of adwaita).
Kind regards
Roooh la la, great news for Matrix !
Really, that’s great 🙂
I’ve just set up Fastly Repositories, I’ll give you an update soon.
For XApp, I hope developers will be there! Yes, I also find that the GTK4/libAdwaita apps, beyond the fact that I don’t like the aesthetics, clash with the rest of LM…
Je frétille d’mpatience pour cette version 22 🙂
Many thanks to the whole team 👃️
Since the Software Manager is mentioned. I have to say that the opening is very slow, I also hear quite a few complaints about its slow to open. I hope you will consider that detail.
Thanks for creating this great distribution
Thanks Julio I agree. I hope we can improve that soon.
Since there are ever more Ubuntu provided apps that can no longer be used by Linux Mint without modification or replacement, what are the major reasons to remain based on Ubuntu rather than Debian?
Is a migration to GTK4 in the todo list?
Clem has already expressed himself numerous times about this. An Ubuntu base provides a better user experience, compatibility, and access to third-party programs.
The GTK libraries, although essential in the Linux ecosystem, are becoming increasingly problematic due to the “monopolistic” attitude of their developers, the same as Gnome and Red Hat products.
Regards.
Hi Dave,
This has nothing to do with Ubuntu. These applications are also in Debian. The reason you don’t see them in LMDE 6 is simply because the Debian Stable base is slightly older than the Ubuntu 24.04 base, which just included the GNOME 46 updates.
GTK4, no. We fully support GTK4 apps but we’re not migrating to it.
It took a decade for GTK3 to be stable, we want to enjoy it for a while. Many widgets we’re using in GTK3 no longer exist in GTK4 so the migration isn’t easy and could force the loss of features or layout changes in some applications. GTK4 probably needs a library to make it complete and easy to use, a libAdwaita for generic apps really. But nobody made one so far, assuming they ever will. Long term we don’t know if GTK will continue to support themes or even Xorg. Some GTK users moved to Qt or other toolkits. Some are looking at GTK3 forks. Some are thinking of making a GTK4 lib. And some like us, are just happy to stay on GTK3 until there’s more visibility going forward.
With Flatpak, Snap, AppImage…, Linux distributions are not anymore safe, like Windows. Everybody can distribute malwares into packages, without any verification. It’s indeed an important and good decision to begin to verify packages and inform users.
Matrix is a very good new too.
Linux Mint choices are very interesting. I’m more and more happy to use Linux Mint and will donate again.
From my point of view, the security (and privacy) of Linux lies not primarily in its means of software distribution, but in the permissions of the programs.
Regards.
They can be safe, or at least safer than they are now. Flathub’s verification process is very welcome and we really need to support it. Showing permissions could also help users make a more informed decision. Although ultimately convenience is key, no matter what information is shown, and these technologies put you in direct contact with upstream.
It’s what we’ve been missing really badly on our Debian frozen package bases where software is safe but not bleeding edge, direct access to the very latest. It’s both risky and more rewarding. Pros vs cons.
> Right now, only 25% of Flatpaks have been verified by Flathub.
I’m not sure about that figure. Currently, Flathub states: Verified: 1084 / Total apps: 2574.
That’s 42% of apps verified.
Thanks, I’ll correct this asap.
Every time the Mint team is hit with hard problems it always comes out with some of the best and most well-reasoned decision making I’ve seen in over two decades of software development. No ego and with the good of all in mind. I am consistently impressed and appreciative of all the team’s efforts.
I strongly agree with David. The strengths of Linux Mint lie not necessary in the decisions made or the outcome of those, but also in the transparent communication of the decision-making process and the clearcut, crapfree and straightforward factual explanations of reasoning behind them. This is why I appreciate Mint so much. Not only is Mint my absolute favorite because of the actual OS but also because of the people behind and around.
This was a very good read, thank you for maintaining the distro. You do make really good decisions as always!
No matter what you want, IRC is dying. Not for us, but for most people it is, since the advent of Discord, Slack and other services. It doesn’t have media sharing, or history, or user profiles. Matrix is a great choice.
GNOME can now be considered an enemy to all other distros. They were first a friend, making apps and tools for all of us, they made GTK. Then they made GNOME 3, but it didn’t really affect GTK. Now they started tailoring the library to GNOME, made their apps use it. And they heavily promote them as the only Linux. You can see it on Flathub, they have a GNOME aesthetic precisely due to this.
What I think is going to happen is that even GTK could become unusable for other distros. GTK3 will be deprecated around 2030. But GTK5, it will effectively integrate Adwaita because it won’t even recognise themes. I don’t think you can migrate to GTK4, as it has no menus. So GTK is a dead end unless you fork.
I also see a problem with GNOME encouraging devs to style their apps more due to the users not being able to do so. This could lead to a Windows situation where 75% of apps have their own window bar and fancy styling. I don’t think anyone wants this, except the GNOME devs, of which one said they never met anyone who thought themes are good because it doesn’t give them enough creative control. But apps are not websites.
I’m trying to make a widget toolkit myself, because I’m so tired of this. It will have themes. I think what GNOME needs to solve the problems of app developers is this:
* ability to get the properties of something else (i.e this is similar to a button in appearance, make it look the same but circular);
* a general theme attribute light/dark so at least text contrast is fine.
Mine will have both of these.
Also, can Zenity be downgraded even further? The last GTK3 version has the accept button in the headerbar. Same with Screenshot.
However, I’ve got some criticism. Without a font app, newbies won’t know where to install fonts. At least make a simple dialogue to state where the font must be moved.
Hi Vlad,
I don’t agree with the vocabulary. “Enemy” is uncalled for. I also don’t think they heavily promote their ecosystem as the only Linux, quite the opposite, they agree with us on libAdwaita being GNOME-only. They made it so GNOME design could continue to diverge and innovate without impacting GTK. If you ask me that’s a very good thing.
The problem we have is that past that they don’t really care. So if GTK4 is incomplete and a poor replacement for GTK3 it’s not their problem. And again here, I can’t really blame them. You can’t expect people to work on something they don’t need or committed to. But we do have a real problem because without that, GTK isn’t really an option long term.
I agree with everything else you said and I think you said it really well. I just want to say I understand GNOME’s position even though it really doesn’t suit us and it could indeed lead to the death of themes and many desktop environments.
Regarding Zenity, let us know which versions introduce which regressions and which application it impacts. It’s a very small component so it could be replaced easily if it only affects a few apps.
The font viewer had so many problems. It had been downgraded multiple times in the past already. Nothing to do with libAdwaita at the time, it just crashed on startup or had critical bugs. We also felt it wasn’t really needed for most people so we removed it. If it’s just the installation of a font file you need, a simple Nemo action could solve that.
Some GitLab discussions, however, show that they are looking to sometime merge libadwaita and GTK, so GTK will only work with it.
Drooping gnome font viewer is not good news. 🙂 Maybe you can make an XApp out of it? A nemo action..but no, opening the file should make sense, not only using a specific action from the context menu. As for zenity, I hope you’ll continue supporting it – maybe as it looks now in Mint 21.3?
Honestly at this point we need a serious alternative to Flatpak.
There are so many complaints about it on the Forums.
People struggle with very large update sizes, multiple versions of the same runtime dependencies (especially Nvidia drivers), download errors, some broken apps, permission problems, being stuck in `/run/user/1000` directories by default, theming issues, and now malware!
I cannot in good conscience recommend Flatpak to anyone at this point.
There are way too many downsides, with almost no upside.
Maybe Mint should take a look at integrating appimages? There is a distro called Nitrux that exclusively focuses on them.
Or something similar to what Arch builds have, that can build / install from source.
Even better would be some way of getting newer versions of DEB packages (I’m perfectly happy to use older LTS versions but others aren’t) and forgetting about all the stupid app systems entirely…
Anyway, I’m not trying to be anti-Flatpak, I hope it improves over time. It really really sucks right now.
Appimages don’t integrate at all, they’re like EXE for Linux.
There is appimage-launcher, which provides Menu / desktop integration.
For integration into a software manager program, there is Appimagehub.
But yes I recognize it would still be a lot of work.
I just feel like somebody has to mention it as a future possibility on behalf of all the users struggling with Flatpak.
Doesn’t AppImageHub face the same security issues as Flathub? They also need to verify the identity of the maintainers.
I don’t want to get into sandboxing/permissions because the vast majority of users don’t review them when they install smartphone apps, Firefox extensions etc.. if a maintainer requires a permission it’s usually given as a habit and for convenience. That said, Flatpak has that built-in for people who care, AppImage doesn’t.
AppImages don’t theme either.
In my opinion, some Linux distributions more focused on the common user could aim to imitate MacOS regarding the simplicity of “installing” programs. I’m not talking about a “walled garden”, but rather betting on Appimage or some alternative to make it easier for a user to install and run programs without the risk of unfulfilled dependencies or breaking the system. Flatpak, in my opinion, is so restrictive that it causes many bugs (sometimes difficult to detect) due to sandboxing.
Let’s imagine there was a folder called “Programs” where the user entered a .appimage and an entry was automatically created in the menu as if it were a really installed program. I know that, currently, this idea would have many limitations. However, I think it would be an interesting approach.
Just for clarity, I mentioned appimage as just one option.
Yes it has issues, I’m not “pushing” for it, it just needs mentioning.
I’d prefer distro-packages-or-something-like-it solution the most.
But it’s interesting to think what would have happened if the community at large embraced Appimage instead of Flatpak, and put the same amount of work / resources behind it… where would we be now?
By far the biggest issue turning people away from Flatpak is size.
Updates are sometimes 4-5 GB.
Not only I don’t see this getting better, but it will probably get worse over time.
It’s very un-fashionable to speak against Flatpak these days, since for whatever reason it “won” the Linux app format contest. But somebody has to talk about it.
I don’t enjoy doing this, but I don’t see anyone else talking about it.
Butting in here: you say further down this thread that Flatpack “[u]pdates are sometimes 4-5 GB.” I used to think that, because that’s what the Update Manager states when there’s a Flatpack update. However, if you monitor the actual size of any update, it is typically MUCH much less. I even read an explanation somewhere that the size is initially given without knowledge of what the system that needs to be updated has and needs.
Honestly AppImage is not a solution, it has the same security problems, no sandboxing, they’re not really portable and can be even bigger. Snaps, don’t get me started on them. Distro packages are what all these formats are tyrying to replace, and for good reason.
I don’t think Flatpak is as bad as you pointed it to be.
Update size is usually much smaller than announced because it uses delta updates; I hope it was showing the correct size rather than the “full” one.
Sandboxing is still causing issues for now because it’s transitioning, but once apps adopt portals it should be seamless and much more secure than the current solution – even better then on smartphones actually, since when picking a file via portals you’re only giving the application that specific file, not all files, so even for users who mindlessly click “yes” everywhere, it’s a net positive.
I agree that Flatpak leads to very large updates, and more often than I’d like. It’s very useful for sure, but starting with Mint 22 I’ll be very restrictive and avoid Flatpak entirely if possible. I get 700 MB of flatpak updates (per transaction) at least once a week, which is ridiculous.
It would actually be nice if the “History of updates” window would also show the size of the installed packages. Sometimes I think I got a lot more updates per week, closer to 2GB. Not sure if Clem will see this, I might propose this in mintupdate’s issue tracker.
Thanks Nick,
The size we show for Flatpaks is unreliable. Michael might comment on that as it’s quite technical. Also keep in mind that Flatpaks sometimes include platforms/runtimes as dependencies. These can be quite big, but they’re shared among Flatpaks.
The estimates and size reports when installing or updating flatpaks are always ‘worst-case’ conditions. I haven’t looked into why in a while, but I think part of it is that flatpak doesn’t know how much of some runtime (the library bundle) is being modified by the updated package, it only knows how large it is in total. When the update actually starts, a special filesystem designed to reduce file duplication decides how much of the update really needs to be downloaded, which is usually only a fraction of what the update manager was told. I’m not sure there’s any way for us to get this information, we can only pass along what flatpak tells us, unfortunately. A related flatpak bug report: https://github.com/flatpak/flatpak/issues/2627
My own particular dislike of Fplatpak (not hatred, just a personal choice to avoid it) is that even though you’ve installed an entire GTK-based environment, for example, adding a simple 512K or 1MB application could mean having to install half a gig worth of associated libraries. It seems such a messy solution. If you’re running an Immutable installation Flatpaks are necessary of course, and they fit well there.
I’ll prefer AppImages for those times when there aren’t distro packges (and compiling isn’t workable). Been trying to build one myself (an alternative client for very obsolete JavaWS out-of-band remote clients), where even Podman didn’t seem to work.
I “love” how the blog post mentions malware on the Snap store and the comments are like “OMG this is proof Flatpak is bad!”
Ever since coming from Windows, I’ve been baffled by GTK3 and GTK4 somehow failing “Fitts law” (the aforementioned file roller is a good example—with a maximized window, clicking the very top-right pixel does not click the (X) close button, though Firefox also falls for this issue).
I’m wondering if XApp as a whole can avoid this issue?
I mean, I cannot help but wonder if the entire reason the issue exists is all down to “being for GNOME” which obviously uses a completely different window and desktop design that doesn’t even take advantage of “Fitts law” with regards to corners or other edges of the screen.
This issue happens with all applications using thick headerbars, I think. Maybe this lies in Gtk oder Cinnamon directly?
An interesting read, thank you. I hope your point of view on GTK4 an Xapps is shared by the maintainers of other GTK desktop environments and applications and leads to cooperation. More public discussion seems necessary. And, as you observe, satisfaction with what we already have, e.g. GTK3, if it i s mature and performant, can’t be neglected, especially when novelty means mutilation of features and incohesive theming (even if attractive, libadwaita looks quite nice IMHO). It”s sad that good traditional apps get discontinued and their modern replacements choose looks over functionality. More work that results in ‘less’…
Hi Clem, I’m a bit confused practically, if these changes aren’t right, will we move to gnome gtk4 or kde in the future? I see a lot of question marks.
Hi Angelo,
I don’t think we’ll move to GTK4 until it’s clear we have a future with GTK. This is what is being discussed for instance right now for GTK5:
Consider removing the gtk-theme-name setting: https://gitlab.gnome.org/GNOME/gtk/-/issues/3586
Consider dropping the X11 backend: https://gitlab.gnome.org/GNOME/gtk/-/issues/5004
We would not invest in a toolkit which drops support for themes and/or X11, not until themes and X11 are already dead, which is not the case right now.
By KDE I think you mean Qt? It’s one possibility. Our favorite toolkit isn’t Qt though, it’s GTK3.
It’s hard to predict where we’ll be in 5 to 10 years, but right now we’re very happy with GTK3. Wherever we move next, I would like to think it will be very similar to it, or very compatible in terms of what it offers.
Hi Angelo,
I don’t think we’ll move to GTK4 until it’s clear we have a future with GTK. This is what is being discussed for instance right now for GTK5:
Consider removing the gtk-theme-name setting: https://gitlab.gnome.org/GNOME/gtk/-/issues/3586
Consider dropping the X11 backend: https://gitlab.gnome.org/GNOME/gtk/-/issues/5004
We won’t invest in a toolkit which drops support for themes and/or X11, not until themes and X11 are already dead, which is not the case right now. Mint 22 will be the current platform until 2026, all of its DEs support X11 and themes.
By KDE I think you mean Qt? It’s one possibility. Our favorite toolkit isn’t Qt though, it’s GTK3.
It’s hard to predict where we’ll be in 5 to 10 years, but right now we’re very happy with GTK3. Wherever we move next, I would like to think it will be very similar to it, or very compatible in terms of what it offers. GTK3 itself will last a very long time. Some people might complement GTK with libs or fork it if it becomes useless, or they might join the GTK project and help them support what GNOME doesn’t want to work on. Who knows?
The only thing that is for sure is that the things we need, we need. When solutions disappear the needs don’t vanish, we find alternatives. Right now many people need things which are no longer provided or being discussed and removed. It’s hard to predict who will do what, who will follow and what will happen, but it’s definitely the right time to start talking about it and getting people to understand each other a little bit more.
When GNOME 2 disappeared we weren’t ready. I don’t know if you remember the mess Mint 12 was and MGSE, we certainly do. It was the only time in our history we recommended people stay on the previous release. Efforts went cojointly towards MATE and Cinnamon. We needed a panel, we needed a menu, we needed a tray icon. We had them before, what provided them disappeared, we had to step up and really react. We’re not in this position with GTK but we’re vigilant. We could end up killing themes, Cinnamon and X11, shipping with GNOME, just like we could fork GTK and never look back. These are two extremes. What we know for sure is that we’ll always be a finished product for our users, something polished and ready to use. That will never change and we’ll always want to have a better release and stable release every 6 months. Where does that lead us long-term? It depends on GNOME, it depends on Xfce, forks, other toolkits, ourselves… it’s hard to say. And right now, the best guarantee we can give you is that in between now and then, things won’t change, you won’t be looking at a broken transition, we’ll continue to ship with GTK3 in the short-term and with the same desktop experience.
If you look back at Mint throughout the years, it changes. It changes slowly. It evolves but without brutal or radical changes. That’s something we appreciate and which we find important. The best toolkit to give you that experience right now, even for new projects, is GTK3.
A few more things. We’re really good at what we do and so is GTK. But we do very different things. We do not want to maintain a toolkit and certainly not to innovate and build the toolkit of the future. We work with stable software on a stable frozen package base. We need mature, supported technology which lasts a while. GNOME is a bleeding edge project which is turned towards the future and doesn’t care about the past. But what they see as the past, is not only our present, it’s also our near future. That’s another part of the problem. You see us react to all of this here in 2024 because it just litterally landed in Ubuntu a few weeks ago. We’re already OK until 2026 without having to do much at all, but if you look at the links I posted above they’re about GTK5 and yet they were posted 3 years and 1 year ago respectively. That’s an important aspect to understand in our inability to be understood/considered by GNOME in their decisions and vice versa.
Looking back at GTK3 it was both painful and a great step forward. It was unstable for years but it eventually brought us fantastic innovations. Gtk.Stack among some of our favorites, HiDPI support of course.. even really divisive technology such as CSD and symbolic icons. If you look back at it, there’s no question only GTK could have innovated that well, but the transition and mayhem they created downstream was almost unacceptable.
We’ve been reacting to regressions and feature loss since GNOME 2 because we had to. Every time we take on more responsibility we get more empowerment and it allows us to implement an even better solution, but if we didn’t have to, we wouldn’t have. We’d have spent our resources more on distribution tooling, utilities. I’m really hoping we won’t need to migrate away from GTK, or get involved in maintaining a fork because we need innovators such as the GTK folks, but I really don’t know. As I said, our core business isn’t to work on innovation, it’s to distribute what’s stable, and prepare the near future, so it will depend largely on GTK and other people. We’ll use the best tool to do the job, we just don’t know what tool that will be.
Hi Clem
Thanks for that detailed explanation. It sounds like the future is going to be “interesting” to say the least. In my opinions the Cinnamon desktop is the best desktop experience, and I also appreciate the stability and the fact it evolves slowly, but very well in a positive direction.
The flatpak improvements are very welcome, I was one of those people who never thought about flatpaks when updating. I far prefer to use native deb packages, but there is some software where that is not possible. Looking I can see I have a couple of “unverified” packages so I will remove them on my main machine until Flathub have verified them as being OK
A big thanks to you and the team for continuing to make LM such a great distro.
Thank you for the update: I’m glad to see you on Matrix!
Thanks for the update and your explanation of how you are making plans in order to be able to react to upstream changes. Yesterday (April 30) I made several attempts (using Chromium, Firefox and even Safari on mac) to send you a donation using my debit card via PayPal (with all details triple checked). However, all the attempts failed with a rather vague message about PayPal having problems. I tried again today with the same result. Sorry, but I don’t seem to be able to send you any money at the moment.
I finally managed to send a donation. I don’t know if PayPal had fixed a problem, or whether it was because I selected USD this time instead of Euros, but the payment did go through this time 🙂
Hello
2 sad pieces of news that I just saw:
1) clamtk is dead. The developer announced his “retirement” April, 2nd.
2) neofetch also seems dead as the github project has just been archived. It is worth noting that the developer stopped answering requests and questions in 2020.
Don’t know what to do about clamtk but I saw that there are alternatives to neofetch.
Regards
François Proulx, Longueuil, Québec, Canada
For neofetch there is a replacement called fastfetch
Yes.
I checked and installed fastfetch. Works as advertised.
Nice. Regards
François Proulx, Longueuil, Québec, Canada
It would be nice if you updated the list of programs available under Hypnotix a little more often.
When I tested it a few weeks ago, over 50% of URLs were no longer in service ;-(
Regards
Hi Philippe,
We’re not an IPTV provider, we just make the app. We can remove the free provider that is there by default if you want no broken channels. I don’t know any free provider which works fully though.
Now that hypnotix allows for custom channels, I guess it could work without any provider set up.
Hi,
The unverified sign in flathub is not very accurate. In fact there are apps that show the unverified sign and are verified by the developer (ie OnlyOffice, in this app’s offcial web page there is a link to download the app using Flathub, if you click on that link it will take to tthe OnlyOffice’s download page in Flathub, and, funnily enough you will see the unverified sign despite the fact that this download is advised on the OnlyOffice website)..
Anyway, there are many unverified apps like Chrome or MIcrosoft Edge that can be safely downloaded from the official web pages (and once they are installed, they add a repo for the updates), so actually there is no reason to take unnecessary risks by downloading them from flathub.
Regards from Spain.
I’ve never installed a flatpack at any time.
Seems I was right to mistrust the whole flatpack idea.
Perhaps I should uninstall the flatpack installer for an extra layer of insulation?
If you do that it removes some functionality of the Software Manager.
Another thing that is somewhat worrying is the fact Ubuntu is going into a direction that it will possibly be “snap-only” system.
It started with Firefox, now there’s Chromium, Thunderbird, and it seems LibreOffice as well.
Won’t this be problematic long-term for Cinnamon?
Too much issues to be worried about: GTK4, theming issues, libadwaita, flatpak malware, unverified flatpaks and also the snap issue.
For Mint, not for Cinnamon.
It’s just more work. Ubuntu does Ubuntu, if that means less packaging, we need to do more packages.
Hey clem, have you considered communicating with the XFCE,MATE and other interested projects about possibly forking GTK3 completely?
I know it’s not an easy task but i don’t think GNOME is leaving you much of a choice for the future.
GTK3 is forked already (not by us). We’re talking with as many people as possible right now, including Xfce of course, but also GNOME developers.
MATE is not on Matrix but we’re hoping they’ll join the discussions as well.
I don’t think our priority should be to focus on picking a global solution for everybody. We want to start by creating a space where people talk and are able to start smaller collaboration projects.
Personally I think the solutions will be varied. We’ll want to support forks, but also improve Qt integration, talk with GNOME about potential GTK4 non-GNOME libs etc.. whatever helps making compatible software available widely really.
Please keep Zenity in Mint. It’s really useful for having a simple GUI interface to imwheel, something that is still missing in the Cinnamon settings, and I also use it for enabling/disabling CPU boost without neeeding the CLI.
Zenity is a GNOME project. In Mint 22 it’s still GTK3, but comes Mint 23, in 2 years, it will be a libAdwaita version.
Hi Clem,
Mint could fork Zenity and keep it as GTK3. Feature-wise, it’s pretty much done for what it’s useful: making small GUI frontends for CLI scripts. Developing something that is compatible to Zenity scripts would probably be more work.
Yes, Zenity has many useful features. And frankly, I wouldn’t mind if Mint came with something else, like yad or whatever allows making simple GUIs for scripts. It’s not a particular tool that is important, but its capability. I like making GUIs for simple stuff that allows less knowledgeable people to correctly execute some command(s) without touching the terminal.
Even an old version of Zenity would be worthwhile – it already generates pretty ugly windows etc
Will you please ensure that the 22 release will work in Older Machine (Laptops), as I have tried twice to install
21.1 into an old HP 620, and failed; Seems there is a problem, which doesn’t exist up to 20.3 versions.
I have an HP6530b of similar age (2008) and LM21.3 is running on that happily. The only issue is I cannot plug in an external monitor as both screens go black after the LM log on boot. Other than that it is fine though i did upgrade it to an SSD and 4GB RAM
It seems to be a problem, look through the reports. Here may be a Pointer:-
https://www.reddit.com/r/linuxmint/comments/wnsqsx/nonsystem_disk_or_disk_error_error_on_installing/
Tried installing 19.1, no problem; Both from DVD’s..
Hi David, Interesting, in the BIOS of my machine I can (and had) deselected UEFI, maybe that will fix the issue you are having if that is in your BIOS? May be worth a look to see if there is any such thing?
When you say Font Viewer, is it https://fontmanager.github.io?
The best way to not use Flatpak, Snap, AppImage… is to make more Debian packages. Is it still effective to use Ubuntu as a base or to have more time to work on LMDE?
You just managed to address a lot of the concerns that have been creeping up on us for a while now in a very reasonable manner. Thank you very much for all your hard work! Looking forward to the next releases.
“I don’t know if you remember the mess Mint 12 was and MGSE, we certainly do.”
Oh yes, me too! I started with Mint 11 and was a fan from the first minute, and then the “chaos” began… MGSE was a crook and helped a bit, but I was not glad. And then came Cinnamon! It started as a beta but had big potential from the beginning and I stayed with it all the years. Thank you for all the well thought decisions and I’m always curious what’s coming next.
My look about the XApps situation is a bit different. Well, I mean, almost every mint application could be an Xapp: why not make mintUpdate a generic XUpdater for all debian(apt)-based Linux distros? Same for mintinstall, mintnanny…and if these should become XApps one day, then a big separation between Mint and XApp wouldn’t make this much sense.
There is a typo: “1Gbps per second”
Thank you.
Hey Clem! Longtime user of Mint Cinnamon here and I have an issue that I’ve wanted to bring to your attention for a while now:
Ever since Mint 21 released and Muffin was rebased, the graphics performance of Cinnamon took a nose dive. It becomes really stuttery and drops a lot of frames when doing simple max/minimize animations or using the “Show all windows” view. It doesn’t make the system unusable, but it’s very noticeable compared to Mint 20.
So my question to you is, has this issue been acknowledged yet? If so, are there any plans for Mint 22 in regards to increasing the graphics performance to at least be at the same level as Mint 20? I had to re-install Mint 20 on a not-so-old laptop just to avoid running Cinnamon at 5 fps T_T
Thank you!
Hi Erick,
No, that’s not what we saw/heard. It’s possible it’s hardware specific? The old muffin was more customizable in terms of composition method choice and had better compatibility with older hardware, we lost that with the rebase. Do you get any warning when starting Cinnamon from the command line (cinnamon –replace)?
[Spanish language]
Hola saludos,
Linux Mint debería ofrecer únicamente KDE Plasma y desechar GTK para siempre.
Feliz día.
Oh, wow, another person saying “you should do just what I like and throw away anything else”. Great advice.
Dear Clem,
Thank you for the info on flatpaks. I thought they were safe, since they were sandboxed. Do you mean we have to be careful on using flatpaks? For instance, is it better to use zoom app as a deb, rather than its flatpak version? Because there are some must use apps that we have to install as a third party app or through flatpaks?
I am really curious about your answer.
Thank you and thanks to all the devs for this lovely, easy to use, and “conservative”:) distro. It’s been more than 10 years that I am not using any other thing and I really love LM.
Best
Hi,
Zoom is unverified, you can see it here: https://flathub.org/apps/us.zoom.Zoom. Our biggest problem right now is that:
– We show it to you by default.
– We don’t even tell you it’s unverified.
Click on links -> manifest.. dig around. Nick Richards? Then decide if you trust Nick. Personally I definitely would, but it’s just an example. This is what it takes for you to make your own mind up, finding the actual maintainer and digging around to see who they are and if you trust them based on how popular they are, what else they’ve done on the Web..etc.
When a .deb is in the repositories, before it gets to you, it means it has a Debian maintainer and it went through Debian experimental, Debian Sid, Ubuntu BETA, Ubuntu Stable and Mint BETA. It doesn’t mean everybody looked at it in details and scrutinized every bit of it, but it had a long time to be looked at. So yeah, this is much safer than Flatpak, especially if they’re not verified.
I’m not an expert at all when it comes to sandboxing but:
– Any app can keylog you in Xorg anyway
– Most apps come with permissions given. On Flathub check “Potentially unsafe section”. If you don’t review that there’s no need to think you’re protected by sandboxing, you’re only protected on the perms not given. Permissions are another thing we really need to show in mintinstall. We’re working on that as well.
So maybe it’s better to show only verified flatpak apps in Software Manager:
flatpak remote-add –if-not-exists –subset=verified flathub-verified https://flathub.org/repo/flathub.flatpakrepo
I’ve thought the solution a lot of GTK-based environments need to consider is migrating to CTK (https://github.com/cafe-desktop/ctk) rather than trying to work around GNOME’s changes. As it is even GTK3 was already modified (dare I say it, BROKEN) to suit the interests of the GNOME Project. Certainly their anti-theming hostility made GTK take on a lot of the bad aspects of MSWin10’s UI (maybe even MSWin8).
Migrating to an already-existing GTK-fork would mean being able to undo all the changes that broke things for everyone else. Let GNOME do what they want to do with *their* code; if the rest of us take our own direction there’s no longer any problem.
Hi Clem:
First of all, congratulations on the excellent work you do.
I have a request, would it be possible for you to come up with a simpler system to verify the integrity of the isos? I find the one available on your site a bit difficult and confusing for a Windows newcomer.
Tails ISO verification is the simpliest system I ever meet: https://tails.net/install/dvd/index.fr.html
I wonder it that GTK4/Gnome/LibAdwita problems means you will fork GTK 3 into XTK for XApps ?
Uhh, I hope this won’t be the same mess as when gnome2 changed to gnome3. Back then ubuntu was still developing on unity which didn’t work very well in the beginning either. So many windows users wanted to move away from vista and were disappointed by unity and gnome3. Now we have a similar situation with windows 11. Not an easy situation, especially for you (Mint-Team). But I’m sure you’ll find a good way! Maybe an approach or co-operation with debian? And no, I’m not saying “switch to debian”. That’s just a thought.
As Ubuntu relies more and more on snap, switching to Debian someday may be a better choice
Regarding Flatpak apps:
1) Many of flatpak apps available in LM does not work as expected (one example for all, Skype flatpak often crashed and need repeated login). Generally, deb based apps still far more reliable than flatpak version.
2) Flatpak verification is very important, but the kind of verification described here by Clem probably does not solve the above-mentioned problem with poor reliability and functionality.
Flatpak is excellent choice for users which requires latest version of apps or need apps which are not provided via deb packaging, but the level of reliability is still unsatisfactory.
Is there any chance how to provide via Software manager only fully functional flatpak apps???
Of course, Flathub verification flag is a good starting point, but it still does not guarantee the full reliability and functionality. For example, Xournalpp app is a proud holder of verified flag, but it is still suffering by reliability problems.
I don’t think there is anything Mint can do about Flatpak reliability.
I don’t think we will have Flatpak reliability anytime soon.
It will probably take 3-5 years for it to mature, and for app developers to learn how to use it properly.
In the meantime I stick to appimages or PPAs, they tend to be much more reliable. App devs do a much better job with those.
I’m not anti-Flatpak and I hope it improves, but right now it has way too many downsides (security problems, massive size, broken apps) and almost no upsides.
2 glitches since I updated to 21.3 (on a Lenovo X1 Carbon that had no issues earlier); sorry I have no idea which if any repo I’d need to log these against:
1. The fingerprint reader doesn’t work on initial login but does afterwards (I installed fprintd etc earlier)
2. If I switch between two wireless networks the Update manager seems to remain stuck on the old one; restarting it doesn’t resolve but a reboot does.
Thanks for the detailed exposition of the decisions about future directions. Much appreciated.
Please omit my surname or just delete the last post; apologies.
Forgot to note that I’m using 5.15.0-106 kernel.
I was having problem with Libre Formula Editor recently which was showing black text in black background (see here: https://bugs.documentfoundation.org/show_bug.cgi?id=158181 ). It turns out that it was a Mint-Y Dark theme problem and a lot of users are commenting that linux mint’s dark themes don’t inform correctly the apps about the theming. The problem was solved when I set “Adwaita-Dark” for Applications in the “Theme settings”. So if you are planning to remove adwaita theme from next Linux Mint release, keep in mind that Mint’s dark themes have issues and you will not allow the users to fix problems by using adwaita themes.
Why not taking System76 in the discussion too? After all they’ve forked Gnome to remain indipendent from their decisions and now they are developing Cosmic
How about try speak with Gimp and Inkspace teams about forking Gtk3 ?
Linux Mint’s Philosophy is really great, I’m fully behind it – this is the reason that I’m still (>10ys) on Linux Mint as my Main System and daily driver.
I looked around, but many other Distros which seems to be attractive too do not fulfill my criteria I expect from a Linux Desktop: Functionality, Stability, Social Responsibility.
I also like the realistic view on the topic Security (Supply Chain Attack) in Flatpak area.
Go on Linux Mint Team – you are great, you are on the right way!
Why forking gtk3 instead of gtk4? Beyond the fact that some widgets are gone on the latest gtk4 version there isnt a whole lot to lose from the migation. You can still make classic applications with gtk4 n apply ‘themes’ on them. The fact that most developers are chosing libadwaita over pure gtk4 is their own decision, no one is forcing anyone to do anything. Everyone is free to think what they like, but if we’re gonna make accusations is better to back em up with facts
PS: My comments are not getting posted for some reason
Seems like it was the email address
Some ideas on the topic of security:
1. Android/Graphene OS style app permission granting. FlatPak does some of this already to my knowledge, but it could be expanded to all apps.
2. There should be separate app permissions for harddisk wide access and access to a fake disk folder that is the only one the app can access to save files or games to or whatever.
3. In the spirit of open source software it would be cool if not just the developer could sign apps, but also reviewers. Code that has been signed by both the developer AND trusted 3rd party code reviewers could then have a higher security ranking or score.
XApps:
1. I think it is a good idea to make it independent and work with others. I honestly thought you did the latter from the beginning… but everyone’s a critic.
2. Pinta is superior to the Mint Drawing app in most regards. I think the only thing Drawing does better is that it easily allows you to scale and rotate selected pixels.
In Pinta it only does so for the whole image.
Maybe Pinta could be forked into an XApp with any features from Drawing ported over?
GrapheneOS/Linux phone, just some ideas here that came to me now I mentioned it:
1. Maybe you could work with that developer to create a Linux PC/Phone eco system that works well together. For example maybe Graphene OS could come with Warpinator by default?
2. Maybe the software for creating a Graphene OS phone could come with Linux Mint so you just had to plug in your Android and it could automatically have Graphene OS installed or even rooted on any Android device.. or at least the supported ones.
3. Music sharing/playlist sharing/blue tooth speaker stuff?
4. Easy/automatic setup of Syncthing between phone (eg. images/music/docs) and Linux Mint?
5. Automatic calendar syncing? Also via Syncthing config perhaps?
6. Graphene OS devs could help with expertise for sandboxxing apps.
7. Sync emails between phone/PC?
8. Biometric/2nd auth via phone to PC?
9. May other ideas could come from what Apple does.