I use a browser that had its last release less than a year ago.
It doesn't do CSS, it doesn't do javascript and I love it.
I also love to be able to use the websites I need.
If I am not able to use any digital service or product on a computer that I could have built entirely myself (or had anyone of my choice build for me), running code I could have written entirely myself (or had anyone of my choice write for me), then that is completely unacceptable.
Sorry for nitpicking, maybe you didn't think through the choice of word, but what is a "technical" argument and how is it different from other types of arguments?
I think all arguments about a technology like systemd need to have a technical part (what systemd does) and a (sometimes implicit) personal part (what I think about it). If it doesn't have the technical part then I don't think it's an argument about systemd at all.
The difference I can see between your example arguments is that the "technical" one is more precise. "Not supporting x" is pretty specific while "being bloated" is not very precise. But of course it could be more precise if you say something like "systemd is made of x megabytes of code. I only want the code I need which I think can be implemented in 1% of that" or just "systemd includes parts x, y and z which I don't want".
So did you by "technical" just mean "precise" or is there another meaning that I missed?
After reading a few answers I still feel like I haven't seen an intuitive answer to the question: why does it take so much more energy to go from 1 to 2 than from 0 to 1?
I have been thinking about it and only been able to come up with something that feels intuitive but not at all precise and I don't know how correct.
When you stand still you may use your surroundings to gain some speed, like by pushing against a wall.
When you have speed it gets harder to gain more speed because the surroundings are (relative to you) moving in the wrong direction, so for every additional unit of speed, it takes more effort to get there.
I just started building an operating system that will be written entirely in one text file.
This text file includes in order: a readme, a RISC-V assembly boot code, then the rest.
You run it by compiling the initial boot code with a RISC-V assembler, then you concatenate the binary with the whole text file itself.
Then when you run it, the boot code will compile the rest of the text file (the operating system), including higher level language compilers that the rest of the system will be written in.
This is the kind of project that creates something from as little as possible, where the only things you need to get started are a very basic RISC-V assembler and a computer or emulator to run it on.
I don't have anything interesting to show yet because I just started yesterday, but one day I will show you.
I used to like to rewrite code that I thought was "ugly" because it was not written in the modern way or it was not very generic or whatever.
I thought that doing that was often pretty easy so I thought "why has no one done this already?"
Later I realized that the fact that it was easy to change was what made it good and the changes I wanted to make to it would probably just make it more complicated.
That's the danger; good code is easy to change so it will easily get rewritten until it's not easy to change anymore.
The funny thing is that the things that are not possible to measure will be undone all the time because people can't agree on how it should be.
This means that there will be wasted time.
First we have to write the code this way.
Next year we have to write it in the other way.
Then it has to be done in the first way again.
It's so hard to prioritize things when you ask someone why something has to be done the way they say and they are not able to give a real answer.
I can do my job when option A means faster program and option B means more memory usage but I can't do my job when option A means faster program and option B is just the way it "should" be done.
Yes.
When I worked as a game engine programmer, two of the first things I did were to improve the speed of compiling and starting the games.
When those two things are faster, all development will be faster and more fun.
If I'm going to link statically, I prefer a smaller library, both for size and security reasons.
I was also getting some issues when linking OpenSSL statically and I think (or hope) that will be easier to do with BearSSL.
Interesting to see BearSSL mentioned today because I have just started to replace OpenSSL with BearSSL in my webserver.
The reason for that is that the server and the computer I develop on run different versions of Debian that have different versions of OpenSSL,
so the server suddenly stopped working because the program linked dynamically to a newer version of OpenSSL that the server didn't have.
I tried to link OpenSSL statically but at that point i thought it was better to move to BearSSL.