#FreeSchool <---> Hashtag @freeschool@qoto.org

People who complain but don't do try or trust much, sometimes are choosing the problem of dictatorship etc by doing nothing.

Not always but often /trying/ to find solutions is the difference between staying victim and not. Giving things better chance.

#Mastodon #Suggestion #Feature #Upgrade #Worries

I wish I could pick and choose features in Mastodon instead of worry for asking for features and perhaps getting upgrades that might change other things too much.

● So to make posts self-destructive for example would make for a lot of clarity and even save some space.

I could set a default expiry time (especially if it didn't involve upgrading Mastodon to change existing requirements - like a plugin or just checkbox to enable feature).

● I think newer Mastodon's have this but haven't see screenshot -
anyone know / seen how it works?

I don't like things that need the latest browser

WHY / RESULTS:
Self-cleaning / Less:
██ Low Quality Messages
██ Ethereal / Temporary remarks
██ Clutter in timeline / better Pruning as-you-go rather than WTF after years of crap

Mark for deletion after 1 week etc... would helps

Making Public Timeline presentation of each profile better is the aim here,.

People hiding their shit replies from main timeline to leave their best ones... even after a week could help see the best stuff

Users could go around deleting and pruning timeline from time to time but really setting it from beginning makes sense as that is time *you know* your message is not meant to last...

Vocabulary for Marking as Messages:

█ Perishable Messages
█ Self-destruct Messages
█ Time-expiring Messages
█ De-cluttering

#QUESTION Has anyone ever gone through their photos and done something practical with them?

(is it all mostly just storage we never revisit until once in a moon remember a specific picture?)

“No #morality can be founded on #authority, even if the authority were #divine.”

— A. J. #Ayer, Essay on #Humanism

Authority is an interesting point tied to morality.

Nice story from @robpike on his blog about how simplicity can be seen as harmful 'productivity'.
How less code can be bad!

ℹ️ Also I have feelings of being very good at my work (in the past) and efficient but coming up against management frequently as a result of that, asking them "what's the problem" because it really did seem to change the whole stand, perspective and even the company I was working for... and that isn't often 'good' though didn't stop me lol!

From Robs @robpike blog...

"He reduced the complexity of the system. Less code, less to test, less to maintain. His coworkers loved it.

But there was a catch. During his performance review, he learned that management had a metric for productivity: lines of code.

Tom had negative productivity. In fact, because he was so successful, his entire group had negative productivity. He returned to Research with his tail between his legs.

And he learned his lesson: complexity is endemic. Simplicity is not rewarded."

https://commandcenter.blogspot.com/2023/12/simplicity.html

------------------------------
The rest pasted below for longevity Creative Commons Attribution 3.0 License.. I really recommend visiting his blog also so you get to keep this and get more of the same logic and gems.
------------------------------

FULL VERSION:
Wednesday, December 06, 2023
Simplicity

In May 2009, Google hosted an internal "Design Wizardry" panel, with talks by Jeff Dean, Mike Burrows, Paul Haahr, Alfred Spector, Bill Coughran, and myself. Here is a lightly edited transcript of my talk. Some of the details have aged out, but the themes live on, now perhaps more than ever.

---

Simplicity is better than complexity.

Simpler things are easier to understand, easier to build, easier to debug, and easier to maintain. Easier to understand is the most important, because it leads to the others. Look at the web page for google.com. One text box. Type your query, get useful results. That's brilliantly simple design and a major reason for Google's success. Earlier search engines had much more complicated interfaces. Today they have either mimicked ours, or feel really hard to use.

That's google.com. But what about what's behind it? What about GWS? How you do you invoke it? I looked at the argument list of a running GWS (Google Web Server) instance. XX,XXX characters of configuration flags. XXX arguments. A few name backend machines. Some configure backends. Some enable or disable properties. Most of them are probably correct. I guarantee some of them are wrong or at least obsolete.

So, here's my question: How can the company that designed google.com be the same company that designed GWS? The answer is that GWS configuration structure was not really designed. It grew organically. Organic growth is not simple; it generates fantastic complexity. Each piece, each change may be simple, but put together the complexity becomes overwhelming.

Complexity is multiplicative. In a system, like Google, that is assembled from components, every time you make one part more complex, some of the added complexity is reflected in the other components. It's complexity runaway.

It's also endemic.

Many years ago, Tom Cargill took a year off from Bell Labs Research to work in development. He joined a group where every subsystem's code was printed in a separate binder and stored on a shelf in each office. Tom discovered that one of those subsystems was almost completely redundant; most of its services were implemented elsewhere. So he spent a few months making it completely redundant. He deleted 15,000 lines of code. When he was done, he removed an entire binder from everybody's shelf. He reduced the complexity of the system. Less code, less to test, less to maintain. His coworkers loved it.

But there was a catch. During his performance review, he learned that management had a metric for productivity: lines of code. Tom had negative productivity. In fact, because he was so successful, his entire group had negative productivity. He returned to Research with his tail between his legs.

And he learned his lesson: complexity is endemic. Simplicity is not rewarded.

You can laugh at that story. We don't do performance review based on lines of code.

But we're actually not far off. Who ever got promoted for deleting Google code? We revel in the code we have. It's huge and complex. New hires struggle to grasp it and we spend enormous resources training and mentoring them so they can cope. We pride ourselves in being able to understand it and in the freedom to change it.

Google is a democracy; the code is there for all to see, to modify, to improve, to add to. But every time you add something, you add complexity. Add a new library, you add complexity. Add a new storage wrapper, you add complexity. Add an option to a subsystem, you complicate the configuration. And when you complicate something central, such as a networking library, you complicate everything.

Complexity just happens and its costs are literally exponential.

On the other hand, simplicity takes work—but it's all up front. Simplicity is very hard to design, but it's easier to build and much easier to maintain. By avoiding complexity, simplicity's benefits are exponential.

Pardon the solipsism but look at the query logging system. It's far from perfect but it was designed to be—and still is—the only system at Google that solves the particular, central problem it was designed to solve. Because it is the only one, it guarantees stability, security, uniformity of use, and all the economies of scale. There is no way Google would be where it is today if every team rolled out its own logging infrastructure.

But the lesson didn't spread. Teams are constantly proposing new storage systems, new workflow managers, new libraries, new infrastructure.

All that duplication and proliferation is far too complex and it is killing us because the complexity is slowing us down.

We have a number of engineering principles at Google. Make code readable. Make things testable. Don't piss off the SREs. Make things fast.

Simplicity has never been on that list. But here's the thing: Simplicity is more important than any of them. Simpler designs are more readable. Simpler code is easier to test. Simpler systems are easier to explain to the SREs, and easier to fix when they fail.

Plus, simpler systems run faster.

Notice I said systems there, not code. Sometimes—not always—to make code fast you need to complicate it; that can be unavoidable. But complex systems are NEVER fast—they have more pieces and their interactions are too poorly understood to make them fast. Complexity generates inefficiency.

Simplicity is even more important than performance. Because of the multiplicative effects of complexity, getting 2% performance improvement by adding 2% complexity—or 1% or maybe even .1%—isn't worth it.

But hold on! What about our Utilization Code Red?

We don't have utilization problems because our systems are too slow. We have utilization problems because our systems are too complex. We don't understand how they perform, individually or together. We don't know how to characterize their interactions.

The app writers don't fully understand the infrastructure.

The infrastructure writers don't fully understand the networks.

Or the apps for that matter. And so on and so on.

To compensate, everyone overprovisions and adds zillions of configuration options and adjustments. That makes everything even harder to understand.

Products manage to launch only by building walls around their products to isolate them from the complexity—which just adds more complexity.

It's a vicious cycle.

So think hard about what you're working on. Can it be simpler? Do you really need that feature? Can you make something better by simplifying, deleting, combining, or sharing? Sit down with the groups you depend on and understand how you can combine forces with them to design a simpler, shared architecture that doesn't involve defending against each other.

Learn about the systems that already exist, and build on them rather than around them. If an existing system doesn't do what you want, maybe the problem is in the design of your system, not that one.

If you do build a new component, make sure it's of general utility. Don't build infrastructure that solves only the problems of your own team.

It's easy to build complexity. In the rush to launch, it's quicker and easier to code than to redesign. But the costs accumulate and you lose in the long run.

The code repository contains 50% more lines of code than it did a year ago. Where will we be in another year? In 5 years?

If we don't bring the complexity under control, one day it won't be a Utilization Code Red. Things will get so complex, so slow, they'll just grind to a halt. That's called a Code Black.

More money you spend, worse productivity you are doing working with people directly...

(above a certain amount of comfort or trying to live, just change of the people's mentalities to choose better things to do from there and for better/more measured reasons)...

So with 'fairly minimal' stuff like a Mastodon instance, it is possible to maximise advancing people's mindset and upgrading to better thoughts by talking more often like a therapy to it all of history we have come to absorbing and being aware of.

Mostly as 2 measurable ways to help my statement
(and this is not a rant just logically 2 main things!):

█1.█ Spending money means you are unlikely to be doing the people work (measurable and guesstimated by adding all sectors and how much money goes to humanistic work and how much not. So is it for profit and taking advantage of people (and even war?) or is money for helping consciousness and compassion and perpetuating that to the next generations? <--- LOL you know the answer ! Near 0 or even whatever good cause lesser than this with 'charities' even having to turn over a profit before anything)

█2.█ Money is bad material or:

M=[M x debt]

so = infinite / constant debt?... as a power balance... deliberately?

Quite a shitload of debt
= shitload of depressed people RIGHT?

And overall giving power to others as currency turns everything into tax obviously IS UNcaring / actually help people war using currency/our labour as their main source, even if you can't imagine living almost exactly the same without your government taxing you on everything so heavily.

█ℹ️█ If none of the above makes sense ask yourself if you like Banks or think giving debt is a service to the world an good way of doing things?

Internet and Electricity keeps the magic of us alive, and can also be cut dead.

What we do NOW without these outages, disconnections, shut down will be importance for when we do.

So what do you do or will do without so much Internet time or with limited connection?

And could you live with people around you as main source of entertainment etc? Would they listen?

(Many escaped to internet because people around were not understanding and even punishing (even though internet has that too) - maybe that's the good work to be done offline also but seems impossible actually to convince real people if I'm honest and wait for them to get old and die)...

BEST POINTS ABOUT INCOMING COMMERCIAL INVASION: 💣 💥

💥 THREADS/FACEBOOK INVASION

💥 BLUESKY INVASION

ℹ️ UPDATED 15/02/2024 - Best first below.....

(will re-draft weekly - let me know if it's unwanted to be CC-d in, because I respect your comments and think you can be game-changers so add acc name here for now so you get credit)

This is almost like dial-up and broadband all over again!

--------------------------

Follow and optionally notification 🔔 for similar topics.

--------------------------

█ Opt-out is not consent.

Everyone knows this and yet many #Mastodon admins continue to abuse us.

Where are the good guys?

● @happyborg
https://fosstodon.org/@happyborg/111926784690582141

--------------------------

█ Native #openweb is "permissionless" this is how #ActivityPub works and why it works. Is #bluesky native to the #openweb?

● @witchescauldron

--------------------------

█ ⚔️ This is a "trust" vers "control issue and yes people are pushing #closedweb thinking and code, we need to think this through better.

● @witchescauldron
https://kolektiva.social/@witchescauldron/111926403671342182

--------------------------

█ Signing up for #Bluesky was a mistake. I have gotten so many #spam calls in the past few days. The sudden spike only makes sense if they're selling the phone number I used for 2FA.

● @o76923
https://kitty.social/notes/9pok05pec10yv5uv

--------------------------

█ QUOTE> The point of the fediverse is to connect with others, with full control and safety. It's for making connections between networks of different sizes and implementations."

I say, bc at some point, it might matter that this isn't quite the system you want.

● @maegul
https://hachyderm.io/@maegul/111927386224381574

--------------------------

█ It's not the federation that is the issue... [snip] But "copy this data of mine to a non-AP company network via a bridge where the rules are different" is a different question, and checking with someone first is reasonable.
[snip]

It's beyond the scope of reasonable expectation to assume "usage implies opt in".

● @Crell
https://phpc.social/@Crell/111926941771490396

█ [snip...] Not to mention that a lot of Mastodon users don't understand how Mastodon works. They think it must have a pool of all accounts and all posts and all that somewhere, and the BridgyFed Bluesky bridge will give Bluesky unlimited access to it all.

They also think that Bluesky will be able to post nasty stuff to everyone, even those who aren't connected to anyone on Bluesky.

They think the same about Threads, because in their heads, they're still on Twitter where the secret-sauce algorithm would probably allow for that to happen.

● @jupiter_rowland
https://hub.netzgemeinde.eu/item/b59ac1d1-100c-4b2f-a6d6-825e8fceb9e1