Projects like this are good for everyone even those who don't want to get their hands dirty. That's because these projects will influence and contribute to other projects that you likely care more about.

This is the same logic behind OpenBSD. You don't need to run OpenBSD to benefit from the security posture and fixes that they provide. Consider your life without ssh.

Probably a good reason to consider contributing to these projects.

I'd rather suckless didn't influence anything I care about.

It's fine that it exists for those who want it, I'd rather systemd and all my GUI apps and DEs stay as they are.

Android could use a bit more modularity though, but the SAF makes that a challenge at times.

That's a respectable approach. I feel the same about dbus and systemd - fine that they exist for some, but I'd rather see them not stretch tentacles into libresolv, ntpd, udev, firefox, wtmp/utmp, etc...

It's never been suckless' goal to influence anything. They're advanced tools explicitly written for advanced users. Nothing more, nothing less.

> Consider your life without ssh.

That's actually an interesting example. ssh was made to fix a real problem (password sniffing). What problem is being fixed here?

The problem being addressed is the Moore's Law equivalent of the Hedonic Treadmill.

Some of us don't want EVERY available byte of RAM or clock cycle occupied by bloated window managers, terminals, browsers, init systems, text editors, etc.

Suckless has a lot in common with the Handmade Network's philosophy. Keep it small, keep it simple, stop throwing a billion layers of abstraction on top of each other, give a shit about cache lines, heap fragmentation, pipeline flushes, etc.

We are mired in the Jevon's Paradox of the computing world right now. The faster hardware becomes, the more obese our software becomes to utilize it. And as a consequences, much worse.

Suckless aims to address this.

> Consider your life without ssh.

IPsec and Telnet. Might not have been so bad, if IPsec wasn't such a chore; particularly compared to the ease of getting an sshd up off the ground.

homie ipsec is a trashfire, you couldn't pay me enough to go back to that shit.

A data mesh approach probably wouldn't work in the sort of organization you describe.

IMO - To make it work you need a consistent taxonomy or way of translating from a particular domain to some sort of interchange format.

If you have that then a set of centralized tools can pull from the separate domains using a core set of protocols to produce reports etc.

How about re-framing the problem?

Considering:

Reclamation and recycling technology will improve over time. Similarly the economics of processing recycled material are likely to make it more valuable.

and:

Supposing we can protect the surroundings, water table etc.

further:

Supposing, as other comments have pointed out, the availability of land is not really an issue.

Then:

Is it crazy to think that there is value to be found in safely storing this material until it is more feasible / valuable to process?

At least it seems like a better plan than incinerating it.

This seems to be missing or at least conflating the meaning of idempotence.

The draft correctly identifies idempotence as a "property of certain operations", but what the draft seems to describe is locking and caching.

Locking and caching are important to building idempotent operations, but shouldn't be conflated with idempotence which is a conceptual property of the operation.

I like what the draft describes, but it would be better done in the correct context.

The place for opinion in your product is in its configuration. Applications need to be flexible, otherwise they are useless to anyone who doesn't share your opinion.

Opinions are like estimates. The only things we can be sure of is that they are not exactly right and will likely drift over time.

Similar to a shortcut, opinions can be useful - but should not be a limiting factor.

++ for suspending judgement when one doesn't properly understand the arguments on both sides.

We could use some more of that.

The terms "agile" and "Agile" have two separate meanings.

Big 'A' - "Agile" is waterfall re-branded - an excuse for corporate empire building and business as usual. It involves lot's of meetings and not trusting those who build software to do the right thing.

Small 'a' - "agile" is the implementation of the manifesto, which basically comes down to smart people figuring out how to work together towards a goal, often by taking small steps.

Until the terminology is sorted out the discussion can't help but be confused.

Since businesses are the ones who employ software developers, 'Agile' is the only Agile that matters because that's the definition the people who pay money use.

We can talk all day about principle philosophical differences and what is/isn't 'agile,' but there has been a consensus from businesses in industry that 'agile' is 'Agile.'

Agile has become an excuse for terrible planning and offloading more and more work with ever increasing responsibilities to developers. At some point, enough professionals will reject following these terrible frameworks through different mechanisms. We're definitely not there yet, unfortunately.

The solution imo is to remove those parts of the industry that are driving the mistaken consensus.

Build software in small firms or consultancies who will treat it as a craft.

Maybe more a hope than a solution.

Agree 100%: agile practices can be great.

Hiring a consultant to teach 'Agile' is easy: the change of practices from something completely top-down to something that empowers the people at the bottom is the hard part and some orgs aren't capable of changing. Too many orgs are built around micromanagement, they don't know any other way.

To these orgs it's a matter of trust and power.

In my experience "agile" was a loose rebranding of ideas that had been around for a long while (see all the other non-waterfall approaches that predate it) and "Agile" (i.e. the manifesto) was just one attempt at one of these sort of methodologies.

Once it got popular, "Agile" was co-opted by all the usual players (cf "extreme" before it, to a lesser degree).

The important idea is "agile" vs. waterfall, whether or not that includes anything directly recognizable as "Agile". Or call it something else, doesn't really matter.

Recent history shows you can certainly do things directly recognizable as part of the Agile methodology while demonstrably not being agile, so modulo the no true scotsman fallacy it's a much less fruitful distinction to draw.

>In my experience "agile" was a loose rebranding of ideas that had been around for a long while (see all the other non-waterfall approaches that predate it) and "Agile" (i.e. the manifesto) was just one attempt at one of these sort of methodologies.

You are correct. The Agile term was probably marketed to the management types as a some breakthrough methodology to _finally_ control the budget for software development. Then it took a life of it's own as many things do.

Most good ideas predate their branding.

True, but they were already branded albeit not as successfully. And this is very much one of those things that is somewhat evergreen - it just gets a new branding every decade or so.

I guess I'm saying "Agile" was/is one of several, and that's ok (good even). It's worth not getting bogged down on the "Agile" part and focusing on the more essential things.