I wrote this suite of scripts a few years ago and still use them to:

1. Boot into Ventoy and select a Debian Live environment
2. Optional: connect a storage device (local partition, USB drive, etc) for persistent storage
3. Modify cfg/cfg.sh if it’s the first time using the tool
4. Run setup.sh to configure the environment into a familiar/productive state

The tools are flexible on hardware (more directed toward x64 systems at this time), and I (almost) never have to worry about OS upgrades. Just boot into a newer live OS image once it’s ready. They are still a work-in-progress and still have a few customizations that I should abstract for more general use, but it’s FOSS in case anyone has merge requests, issues, suggestions, etc.

Don’t be afraid to enter the water knowing that you are not going to swim forever.

Linux has been ready for some time within various educational programs, but maybe you are referring to relatively early education curriculum in public schools? The general anecdotes I’ve heard from teachers within a variety of grade levels in the USA (mostly elementary and high school levels, but some doctoral engineering/scientific as well) convey that the largest hurdles to overcome are:

1. Teaching the teachers. Teachers are usually very smart and capable, but are often chronically overworked, overstressed, and underpaid for their labor. They have limited mental bandwidth in learning new tech workflows while having the added obligation of teaching these workflows to students which may be at an attention/interest deficit.
2. Challenging the status quo at the administrative level. Schools often receive incentives, grants, steep discounts, etc, for installing certain types of hardware or software packages. The software baselines of some schools are restricted at the district level; many public libraries are restricted by the city/county. Perhaps the best approach here is to install Linux as a “secondary” option (similar to how a smaller number of e.g. Macs may be installed in a computer lab comprised mostly of Windows computers) until it’s more widely adopted.
3. Advocating for equivalent Linux support for popular proprietary software. This is especially true for the creative design community, such as graphic design and professional music production. Adobe is usually the target of criticism here; Linux does not currently hold enough market share to capture Adobe’s attention while their patrons usually have unwavering brand loyalty or are unwilling to make any tooling/workflow compromises as to maintain their livelihood.
4. FOSS-friendly awareness campaigns. Showing people that they can remain productive while not being at the mercy of Big Tech. Not using public funds for private industry.
5. Feature parity case studies compared to proprietary options.
6. Overcoming the stereotype that Linux is only for techy people, shrouded by gatekeepers, or subject to drama/infighting.

¡La chancla!

_{sad richmond noises}

In the meantime, the Liberty phone seems to be the closest option for a US-made smartphone. While not entirely comprised of US-sourced components, the PCBs are manufactured in California, as well as device packaging and assembly.

April 10 update: Right on time, the author of the OP’s linked article has now published an article on the Liberty phone.

If anyone remembers the Mycroft Mark II Voice Assistant Kickstarter and was disappointed when development challenges and patent trolls caused the company’s untimely demise, know that hope is not lost for a FOSS/OSHW voice assistant insulated from Big Tech…

FAQ: OVOS, Neon, and the Future of the Mycroft Voice Assistant

Disclaimer: I do not represent any of these organizations in any way; I just believe in their mission and wish them all the success in getting there by spreading the word.

There is also a NewPipe flatpak available on Flathub.

The Librem 5 offers hardware killswitches on the side of the phone, and the Pinephone offers hardware killswitches in the rear of the device after removing the backplate.

Purism is slowly correcting course regarding refund policies, but meaningful improvements take time. Also, the letter from “Purism” to Rossmann came from a Purism volunteer who had no authority to publicly represent the company.

By Arch, do you use SteamOS on your gaming rig? And if not, what would be the determining factor?

And the sysadmin said “well done, good and faithful servant.”

It’s a valid point that it could potentially create some confusion when a user assumes that everything in Signal is secure. Unencrypted SMS threads could contain an open padlock icon and even an ominous red window border, but someone inevitably will not understand the difference.

However, my frustration has been how both convenience and security is reduced by removing SMS from Signal.

Many people will continue to use SMS for a variety of reasons, necessitating the use of an additional app. So now we have people continuing to communicate over this insecure protocol, but with the additional target vector of potential vulnerabilities in the supplemental app.

Imagine a world where we can adopt a scalable, secure, open communication protocol where users can use whatever app they want. Imagine humanity moving past the diaspora of special-snowflake chat apps and on to better things.

While not a physical radio, a Linux phone such as the Librem 5 in conjunction with an RTL-SDR dongle and external antenna may be a good candidate for a mobile software-defined radio (SDR) transceiver.

SDR frameworks such as GNUradio or REDHAWK are well-established by this point. Newer versions of REDHAWK are designed to run on CentOS/Rocky Linux, however, and they don’t (AFAIK) come with a mobile-friendly UI.

I do know that there are some web-based SDR tools in the wild. I’m not very familiar with them, their system requirements/capabilities/limitations, but they could be worth a look to jump-start a Progressive Web App for mobile devices.