On continuous-release 

I like continuous-release (Live in the head), which means on the master branch, a commit is equal to a release.

It requires/provides:

1. A published API & functionality will _never_ be deprecated.

2. New additions have to be very careful

3. Downstream programs will never worry about update dependency

4. Testing suite/pipeline has to be as complete as possible. Once the tests passed, it should be able to automatically deployed.

5. The main developers must be very _smart/prolific/experienced/knowledgeable_.

6. Project have to focus, rather than become a mission creep

7. Zero backporting burdens.

8. In case of something have to change, downstream can upgrade progressively rather than brutally.

9. A clear definition of "internal" and external APIs. External API is guaranteed to be reliable.

10. A longer initial development stage which allows changes, (or very stable project convert to continuous model, rather than "maintenance mode")

*** For dramatic improvements requiring major refactor, a new project should be established, rather than alter the current codebase.

A few public project use this model:

openQA from openSUSE
watchman from Facebook
GoogleTest from Google
C++ from the committee

There should be more, but I have no idea about others.

"Software freedom isn’t about licenses – it’s about power."

by GPU expert & Mathematician Alyssa Rosenzweig


I like the idea from gnu awk's maintainer Arnold Robbins -> "Fork My Code, Please!".

However, unless your fork is 2x or more superior than the original software, it is unlikely for your fork to be included in Linux distros.

This is one of the archlinux's superiority which is maybe unintended :

Your fork and the original software are all inside the AUR. They are in an _equal_ position, rather than

"the one in the official repo"


"the one from 3rd party PPA/OBS/random repo, or require some weird install script".


Yet another project (3k stars) got fucked hard by GNOME people and now become ashes.

In KDE, you have full-power Konsole, so there are no useless forks in the first place (there are at least 5 alternative gtk terminals) and you can also embed it into any apps, like dolphin & kate.


slbtty✅ boosted

Bjarne Stroustrup on the _bloating_ and _sinking/rising_ of C++ and decision process.

"How can you be so certain?"


"Giving it Away: How Red Hat Software Stumbled Across a New Economic Model and Helped Improve an Industry"

An article written by Bob Young, one of the founders of Red Hat, about the origin of Red hat and its business.


Alternative link


slbtty✅ boosted

#Gemini is a really simple free and open application layer protocol for very simply formatted hypertext. It is like the world wide web in the early 1990s.

I am not surprised that the best Gemini:// client is written in Qt, and the one written in GTK-rust is shit.

After reading a few articles gated behind this protocol, I think it is OK.


Most extensions of GNOME is just an icon plus some functions.

The difference between them and traditional tray icons is that they are not cross-platform and locked with GNOME, which will trash your extension in near future.

Show thread

It seems to me that GNOME didn't remove the tray or indicators, since there is a complete implementation inside gnome-shell's source code. And they comment it as "System indicator" :)

The right way to let your app have a notification icon on GNOME-shit-topbar is simply writing an extension.

In conspiracy theory, this is a SHIT-tier strategy of vendor locking since this type of extension is GNOME-only. If app author only use GNOME, then users on other DE must put extra effort to port those "icons extension".

Examples: Syncthing

1.) GNOME don't have tray, so native GTK/Qt Syncthing doesn't work.

2.) someone implemented this by an extension

4.) xfce/mate/lxde/i3/sawy users suffers for not having this.

5.) Everyone suffers as the community have to split for two different implementation of exactly the same thing. They could have been enhancing the same codebase together.

This already happens -> GSConnect is locked with GNOME. GSConnect was written simply for an icon in the name of "Integrate with SHIT" which can be avoided completely.





A reminder that GNOME still use a hard coded list of terminals inside GLib and force you to use GNOME-shit-terminal.

If you use GTK/Glib, you will lose the _freedom_ to use whatever terminal you want.



And the maintainer refuse to add new terminals to this *shit* solution ??? 10 years, no joke at all:)

ps: KDE let you use any terminal you like :seyana_2:

@haeckerfelix Rewrite trash with a better language doesn't change the fact that it is a trash.

Invoking Transmission's API and replace the GUIs doesn't make you a good programmer either.
QT: mastodon.social/@haeckerfelix/

Felix Häcker  
I'm currently rewriting Fragments in Rust with a completely new network-oriented architecture. To follow the development, it's the perfect time to...
Show older

Have fun and play together~