I like programming too, it’s too bad it is full of trannies. I’m noticing though that a lot of troons in their eternal lust for power and status are switching to engineering
FOSS was dying of mission creep and bloat years before it got sick and weak enough to be opportunistically infected by ideology tards. If you want to trace it back to its roots, look for the transition from unix design principles (e.g. "do one thing and do it well") toward fat design principles (muh year of the linux desktop, muh beginner friendliness). Around the late 2000s we underwent a massive shift from building stable, secure, comprehensible tools and systems and toward opaque convoluted messes that attempted to anticipate and muddle through the most deranged demands that the dumbest, laziest conceivable user might theoretically want.
For example the monstrosity that is systemd was pitched largely as a way to shave 20 seconds off boot times, a thing that only the fattest-brained retard could possibly think was a win in light of the price of entry. Or the gnome project's heroic replacement of useful error reports with the windows style "oops something went wrong" screen because error reports are scary to muh average pc user (read: dumbest person anyone could possibly imagine).
I could rant indefinitely about this.
If you want a better open source, one that delivers at least partially on the initial promise of stability, security, user control, and comprehensibility, you must abandon "user friendliness" and steer clear of everything that pitches that as a feature. That and keep CoCs off your lips.
Thanks for your comments. Could you elaborate a little more on CoCs? To my eye it seems necessary to empower core devs to make these gatekeeping decisions in writing. Good guy with a gun, and so forth.
You don't need a code of conduct. As the maintainer of a repository you already have absolute authority over what goes into it, who may participate, and how. This power is vested in you by the fact that you created it and have superuser access. You don't need a document to empower you to do anything, and nobody has the right to be there but you. Everyone else is there at your pleasure. It's a monarchy, in other words, not a democracy.
Every single promise you make, every document you write, weakens rather than strengthens the power you already have. The good news though is the chains are illusory and you can cast them aside at any time at a cost of nothing other than your reputation with the worst kinds of people.
If the improbable happens and the project grows so large that you can no longer manage the thing directly by yourself, which is a nice problem to have but one you probably never will, then at that point you might pick a few trusted people to help manage it. You can hash out some informal guidelines with them about how you expect them to to the job. Keep your hand on the till.
But what you must never, ever do is empower them to overrule you in any way, nor enable them to appoint more managers without your explicit approval. That is the critical system vulnerability that the entryists will seize on to debase the whole project.
And here's the thing: this is perfectly fair. It's an open source project. If anybody doesn't like how you're running it, they are free to fork it. That is their entire recourse for any disagreements they have, and it's a perfect and completely fair one. If they think they can do it better, they can prove it. 99% of the time, they won't. If you've somehow catastrophically fucked it up, see for example Open Office or Audacity, then forking the project solves the whole problem.
This is a system that already has worked beautifully for 60 years. The concept of the Code of Conduct was introduced to wreck this working system so that open source projects could be bent toward goals other than making good software. We've already seen the product of those efforts, and it's a disaster.
I think Rust will be to C what ARM is to x86, in general. It'll just take some time to get filled out with useful libraries. I don't actually have a problem with Rust itself aside from the people running it and the hubris of thinking it is okay to break everybody's dependencies in the process of adding it to the kernel. The guaranteed memory safety is a great boon, and for that reason alone I think Rust will be sticking around for normal programs and in embedded work for many years.
Alright, then we are on the same page. I'm mostly interested in it from the robotics perspective where I can use it to deploy autonomy algorithms that are traditionally written in C. It could benefit from more libraries, but for me, I can typically get away with more basic things. I'm also in a similar position with Julia.
Rust is perfectly useful for writing systems software. I use it all the time, typically when I get fed up with some bloated shitware sucking away my time, attention and resources, and feel the need to spend a weekend replacing it with some simple CLI tool that does the small part that I actually needed.
The entire cult around it on the other hand are some of the worst most useless people in the world. Avoid at all costs. RTFM, never try asking these creeps and fuckwits any questions. They don't have the answers and they're not fun to talk to.
As a chud who only consumed normie programming content, the downfall of rust seemed a bit weird and random. I don't know why I didn't connect the dots between faggotry and rust but it totally makes sense. Pushing for a language in production that has no support and no guarantee of support in the future is retarded.
I like programming too, it’s too bad it is full of trannies. I’m noticing though that a lot of troons in their eternal lust for power and status are switching to engineering
Right, and they demand lowering of standards so that they can do it, because they can't hack it and they know it. Keep your own standards high.
FOSS was dying of mission creep and bloat years before it got sick and weak enough to be opportunistically infected by ideology tards. If you want to trace it back to its roots, look for the transition from unix design principles (e.g. "do one thing and do it well") toward fat design principles (muh year of the linux desktop, muh beginner friendliness). Around the late 2000s we underwent a massive shift from building stable, secure, comprehensible tools and systems and toward opaque convoluted messes that attempted to anticipate and muddle through the most deranged demands that the dumbest, laziest conceivable user might theoretically want.
For example the monstrosity that is systemd was pitched largely as a way to shave 20 seconds off boot times, a thing that only the fattest-brained retard could possibly think was a win in light of the price of entry. Or the gnome project's heroic replacement of useful error reports with the windows style "oops something went wrong" screen because error reports are scary to muh average pc user (read: dumbest person anyone could possibly imagine).
I could rant indefinitely about this.
If you want a better open source, one that delivers at least partially on the initial promise of stability, security, user control, and comprehensibility, you must abandon "user friendliness" and steer clear of everything that pitches that as a feature. That and keep CoCs off your lips.
Thanks for your comments. Could you elaborate a little more on CoCs? To my eye it seems necessary to empower core devs to make these gatekeeping decisions in writing. Good guy with a gun, and so forth.
You don't need a code of conduct. As the maintainer of a repository you already have absolute authority over what goes into it, who may participate, and how. This power is vested in you by the fact that you created it and have superuser access. You don't need a document to empower you to do anything, and nobody has the right to be there but you. Everyone else is there at your pleasure. It's a monarchy, in other words, not a democracy.
Every single promise you make, every document you write, weakens rather than strengthens the power you already have. The good news though is the chains are illusory and you can cast them aside at any time at a cost of nothing other than your reputation with the worst kinds of people.
If the improbable happens and the project grows so large that you can no longer manage the thing directly by yourself, which is a nice problem to have but one you probably never will, then at that point you might pick a few trusted people to help manage it. You can hash out some informal guidelines with them about how you expect them to to the job. Keep your hand on the till.
But what you must never, ever do is empower them to overrule you in any way, nor enable them to appoint more managers without your explicit approval. That is the critical system vulnerability that the entryists will seize on to debase the whole project.
And here's the thing: this is perfectly fair. It's an open source project. If anybody doesn't like how you're running it, they are free to fork it. That is their entire recourse for any disagreements they have, and it's a perfect and completely fair one. If they think they can do it better, they can prove it. 99% of the time, they won't. If you've somehow catastrophically fucked it up, see for example Open Office or Audacity, then forking the project solves the whole problem.
This is a system that already has worked beautifully for 60 years. The concept of the Code of Conduct was introduced to wreck this working system so that open source projects could be bent toward goals other than making good software. We've already seen the product of those efforts, and it's a disaster.
What are your feelings/thoughts about the future of rust for embedded systems?
I think Rust will be to C what ARM is to x86, in general. It'll just take some time to get filled out with useful libraries. I don't actually have a problem with Rust itself aside from the people running it and the hubris of thinking it is okay to break everybody's dependencies in the process of adding it to the kernel. The guaranteed memory safety is a great boon, and for that reason alone I think Rust will be sticking around for normal programs and in embedded work for many years.
Alright, then we are on the same page. I'm mostly interested in it from the robotics perspective where I can use it to deploy autonomy algorithms that are traditionally written in C. It could benefit from more libraries, but for me, I can typically get away with more basic things. I'm also in a similar position with Julia.
Rust is perfectly useful for writing systems software. I use it all the time, typically when I get fed up with some bloated shitware sucking away my time, attention and resources, and feel the need to spend a weekend replacing it with some simple CLI tool that does the small part that I actually needed.
The entire cult around it on the other hand are some of the worst most useless people in the world. Avoid at all costs. RTFM, never try asking these creeps and fuckwits any questions. They don't have the answers and they're not fun to talk to.
As a chud who only consumed normie programming content, the downfall of rust seemed a bit weird and random. I don't know why I didn't connect the dots between faggotry and rust but it totally makes sense. Pushing for a language in production that has no support and no guarantee of support in the future is retarded.