Of course, there could be more helpful changes that would complement the above:

• Return to educating users about https + domain names. It is way simpler and more effective than what is taught now (a form of "email psychology").

• Return to the practice of putting subcontracted IT services under the contractor's own domain. None of this stuff we see today where a Firstbank.com user gets shunted off to myfunkybankingsvc.net without warning. Same for outfits that deliver documents via email on behalf of a primary org.

• Improve security of personal devices (esp. PCs, phones) with new architecture that can isolate threats much more simply and strongly; namely microkernels and bare-metal hypervisors. Proliferation of malware on personal devices undermines society's confidence in mundane net security measures (as described above), pushing people towards snake oil remedies and/or authoritarian control (see Apple & Google app stores).

TBH, looking at the above, the impact of phishing and malware could be a fraction of what it is today for relatively little effort. Somewhere over the course of the last 25y the IT industry talked itself into selling dubious palliatives that took the place of properly engineered security developed in accordance with computer science.

If I could be granted one magical wish for the Internet it would be to change every web browser so that it refuses to access a site until the user adds it to their bookmarks, and the bookmark dialog will show the site domain/https in bold 24pt font and it will have a delay so the user cannot just click-through.

I would also change domain name rendering so that characters which don't belong to the language of the first character in the domain show up as boxed or bright pink etc. This makes homoglyph attacks look obvious and inauthentic.

A little could go a very long way...

#infosec #phishing #internetculture

"Linux/BSD is going to conquer the non-techie users" bs is very tired.

Listen to yourselves: You are asking users to identify with a component buried deep in the stack, to navigate a bewildering forest of different package formats and user interfaces. And because of the UI-agnosticism, they have to adjust to receiving tech advice centered on the CLI, oftentimes leading down rabbit holes that include instructions for patching and compiling.

This get-users-to-love-unix-clones model hasn't worked for the past 30y, and it isn't going to now. Putting candy over the chaos still leaves users with chaos, and they're not up for your tech-adventurism. At most, it can succeed with tech enthusiasts and govt/corp environments where the UI and package choices are locked down.

If a product or movement identifies as "a Linux", its dead in terms of mass appeal.

PS - I've now gotten some replies from enthusiasts and pros about what they think is good for themselves. Please re-read the top of this post and if you were thinking of adding another "techie life" anecdote then put a cork in it.

#linux #linuxmobile #bsd

Note also that the dynamic I described above – which I believe will come to pass, if not here already – negates the traditional advantages of open source development, which is that public exposure leads to better input and more opportunity for revolutionary innovation.

Instead, the LLMs will nag and accuse developers who take unusual or controversial approaches. This will contribute to splitting communities, who may choose the LLM-inspired fork when the glass is 1/4 rather than implement a radical vision (leaving the original devs unjustly discredited and without funding). Of course, its down to the LLM users, but I honestly don't think that lead devs will be able to choose or moderate people on the basis of responsible LLM use.

Proprietary projects that are developed and maintained in secret will have the upper hand since they are more insulated from spurious and surreptitious input. They may even have the advantage of taking the ideas from LLM-attacked FOSS projects that have folded as a result of the added cognitive dissonance.

RE: https://fosstodon.org/@deepfryed/117203975441085657

At first glance I tend to agree.

However, there is a more insidious problem: LLMs amplify bias, so using them for analysis with any regularity could ruin projects, given enough time. I think that is just what they are likely to do: they will shift the code of independent projects in broken or unhealthy ways because that is what the oligarch designing the LLM prefers. The 'fixes' they offer will increasingly demand trade-offs that compromise the independence, security or viability of independent projects.

The problem is, when we say 'No' to these trade-offs, the LLMs (esp. 'agentic') are poised to conduct PR offensives in the form of issues and pull requests against those of us who refuse too often.

The saner approach might be to just say 'No' to all of it. Or at least to impose strict limits such as special 'LLM recon' periods lasting only days or weeks, where the devs are specially focused on dealing with LLM input and its biases. Then shut down the process at the end of the period. (No, I do not think that restricting anytime LLM use to trusted individuals will work; that is just a recipe for compromising your trusted devs.)

#LLM #claude #postgres #opensource