Egregoros

@shinyoukai@izu.laidback.moe @lolitechengineer@loli.church @lanodan@queer.hacktivis.me @phnt@fluffytail.org I personally think Hyperbola is a bit of a nutjob project in my opinion.

For example the only reason they are making a BSD version now I think is because they think Rust in Linux is bad. I mean I don't like Rust either, but is it that really enough of a reason to switch to fucking BSD? Wouldn't it be less bad to just remove the Rust parts from Linux?

Hyperbola also does not allow any software that is developed by a for-profit company. Yes this means that Hyperbola does not support basic shit like zstd because it is developed Facebook.

It's bonkers.

If I really wanted to screw up my system using pacman I'd rather install Parabola which seems like a project ran by sane people.

@lanodan @shinyoukai @lolitechengineer @SuperDicq At least with suckless you get what you signed up for. A base piece of software you patch into something that suits specifically you with the provided patches or your own. If you come to them expecting something usable out of the box, you will be disappointed no matter what. Or if you want a piece of software that is maintained but never changes.

With Hyperbola it's removing things for the sake of removing things, because we don't like some abstract interpretation of dumb politics. In a way, it perfectly fits the GNU maximalism mindset. Instead of letting a user choose whether they want to use non-free blobs on _their own_ hardware, we choose for them and remove that ability to even do so, because we are smarter than the user, and because we hate choice, and letting the user patch our patches so that they can do what they really want. Just because we have some abstract dumb opinion on what proprietary firmware is. There's no actual progress made, just removal of options for the sake of
removing them, while thinking you are holier than thou.

And then if you come to the BSD crowd, it is a completely different mindset. Instead of coming to a discussion being dead set on the "only proper way" and arguing only for that, the discussion starts level headed and without predetermined outcome.

@phnt @shinyoukai @lolitechengineer @SuperDicq Suckless did some software that can work, but their community has those kinds of weird "Remove things just because we don't like it, keeping things in a working state? Naaah".

Like take a look at stali, or almost any other suckless distro, there's typically no C compiler at all, and a bunch of suckless software (dwm, dmenu, …) are entirely absent because well no graphical session.
(One exception is Oasis Linux, but not sure how suckless related it is, mcf might just have grabbed sbase because it's simple to compile)

@lanodan @shinyoukai @lolitechengineer @SuperDicq The community is kind of exactly what you expect from wannabe power users that want to feel better than everybody else. A very reddit-esque behavior. They are basically larpers that call everything they don't want or agree with bloat like the meme that died at decade ago.
When you remove the community from the project and its maintainers, you get a pretty high quality pieces of software (except dumb variable names) ready to be hacked on. But that is the case with many projects these days. Look at a certain oxidized language that was interesting and ruined by the annoying community around it.

>suckless distros
Never heard of them and making a suckless distro is the dumbest thing you can do with it. Since the software is made to be patched by a user directly and not properly packaged. The only things that properly work as expected without patching is dmenu, maybe dwm and probably the init system.

@SuperDicq @phnt @lolitechengineer @shinyoukai Well minimalism can be important but it shouldn't be the primary objective and I think that's the point that suckless didn't get, plus well… minimalism to me is something that you do not just in terms of code but also dependencies with a bit of preference for OS-scale from time to time.

OS scale because I think few things in modern systems should be split in more discrete components, specially as corporate mindset has a tendency to centralise policies into huge monolithic software that doesn't cooperates with the rest of the system in an equal manner.

@lanodan@queer.hacktivis.me @phnt@fluffytail.org @lolitechengineer@loli.church @shinyoukai@izu.laidback.moe For example, my fully refactored version of Polygon Love 2 contains more lines of code than the original project did. Even though I actually removed some unused features from the code.

The original project was a giant spaghetti mess. The entire game was contained in only 10 source code files, most of them consisting of giant 3000 line god classes. I split all of those into actual modules and stuff like that so the project is actually readable and maintainable now.

@SuperDicq @phnt @lolitechengineer @shinyoukai > And also GPLv3 license header on every file.

Heh, you know about SPDX headers (and REUSE), right?

And well lines of code have pretty much always been useless and are a metric I love to hate.
Metrics like CPU/memory/… usage make more sense, but are very rarely used even though that's where ressources are scarce and can even make the difference between something which runs and something which doesn't.

Also reminds me that minimalism sometimes gives you two kinds of extremists:
- almost 0 dependencies
- dependency over own module (low line of code kind tends to go there)

Except that can end up just shifting where the complexity is, waterbed theory style.

@lanodan@queer.hacktivis.me @phnt@fluffytail.org @lolitechengineer@loli.church @shinyoukai@izu.laidback.moe I know about SPDX headers and REUSE obviously, but I personally prefer using the full header for the following reasons;

Unless you are already extremely familiar with software development something like # SPDX-License-Identifier: GPLv3-or-later is not going to mean anything to you. Especially considering that I am making a video game you have to assume that whoever stumbles onto this project might not be the most professional programmer.

The full license header actually explains very briefly what free software is, what the GPLv3 does and where to read more about it (the gnu.org website).

So I think it's also good promotion for the free software movement and its ideals to have full license headers in your projects prominently displayed.

@lanodan@queer.hacktivis.me @phnt@fluffytail.org @lolitechengineer@loli.church @shinyoukai@izu.laidback.moe Of course the license is also referred to in the readme file.

But the reason you put a license header in every file is so that when a file gets separated from its project the context of its license is not lost.

This happens very often by the way. That someone just strips out a single module or a single file from an existing project and uses it in another project. In these cases the full license header is the most important.

@phnt @latein @shinyoukai @lolitechengineer @SuperDicq @lanodan The copyright date(s) being accurate is highly important - otherwise the copyright notice isn't valid.

If nothing changed in that file, the copyright year(s) should not be changed for that file.

For a very trivial change, the old copyright year is correct - for changes that are added a year later, that qualify for copyright, the new year should be added so the copyright header remains correct (GNU Emacs can do this automatically for you).