It doesn’t yet pair with Gadgetbridge but I imagine it will at some point.

I was wondering this myself. Thank you for that useful information.

Pebble

This isn’t the right community to make this post in, though.

I already made a list

closed source

Bluesky is open source.

I don’t know why it’s being discussed here

It is being discussed to see if things have changed.

If you swipe down from the top using two fingers it takes you directly to the settings drawer.

I guess it would be more akin to a “source code hosting service,” but that would imply that I intend to open it to the internet (which isn’t necessarily the case).

For this website, it seems the only way is by fetching the MP3 URL from the network tab (or a random JavaScript file) and passing it into yt-dlp like so:

yt-dlp "https://audio.usborne.com/audio/Book Readings/Phonics Readers/9781801319591_pho_cockatoos-on-cruise_am-eng_br-pt.mp3"

This will correctly download it.

Let’s not forget: privacy is not a sign of wrongdoing.

Some friends wanted to make a podcast, and asked me to join. I agreed under the condition that I could use a real-time voice changer, because I didn’t want my real voice publicly on the internet. That’s one legitimate use case. Maybe OP is calling a support number, which often monitor and record your calls. OP could also just be calling a friend, you never know who could be listening in.

In any case, voice changers are just software. It’s not creepy unless you know for sure it’s being used for something creepy. Anything can be used for good or bad.

As I mentioned, using rustup requires granting VSCodium more invasive permissions to get it to work. Furthermore, installing it would require layering system packages, which should be done sparingly. Using the Rust SDK is the recommended approach by VSCodium while using their Flatpak, and it is actually the simpler option.

secureblue has native support for containers, although it uses the more modern Distrobox rather than Toolbx. I tried installing VSCodium in this way, but I couldn’t get it to start due to some windowing system issue. Even if I could, it comes at the cost of security. Firstly, user namespaces need to be enabled. Secondly, the app would have less granular permission control (e.g. full access to the home directory). For those reasons, it’s better to avoid using containers unless explicitly required. This method works fine, so there’s no need.

This guide is actually only 3 steps:

1. Install VSCodium
2. Install the Rust SDK
3. Enable permissions

The rest is just extras, like installing rust-analyzer, which you would need to do on any distribution. The reason it’s so long is because I wanted to make it painstakingly simple for anyone to be able to do it, regardless of using the command-line, user-interface, mouse, or keyboard. Depending on how hardened you’ve made your secureblue system, you really could just install everything with one command:

flatpak install -y com.vscodium.codium org.freedesktop.Sdk.Extension.rust-stable/x86_64/24.08 && flatpak override -u --env=FLATPAK_ENABLE_SDK_EXT=rust-stable com.vscodium.codium

secureblue isn’t designed to be fast, easy, or simple. It’s designed to be secure.

Hope this helps!

Will the official PeerTube app for Android ever adopt Kotlin, Jetpack Compose, and Material 3 Expressive?

Fedora isn’t that secure without some effort either.

Fedora’s philosophy is being a modern and security oriented (not security focused) distro. An easy example is that Fedora uses Linux kernel 6.14.2, whereas Debian uses Linux kernel 6.1 (I know they backport fixes, but the point remains).

Unfortunately, I have no way to confirm which one out of them is “more secure”.

Do you have any sort of automated test framework in mind which one can use to test distros against attacks?

Generally trust what security experts say about it, but if you really want an automated test, you can look at Lynis

Why do you rank secureblue over Whonix?

Whonix on its own isn’t very secure. It’s more privacy focused than security focused. It’s based on Debian, which has a host of issues I won’t get into. dom0 in Qubes OS is based on Fedora for its security, and it’s no coincidence that secureblue is also based on Fedora.

Hey, I recognise you now!

Look mom, I’m famous! :P

That was a great post, I had a lot of fun reading it.

Thank you!

If I could follow people on Lemmy I’d follow you.

The best you can do in regards to that is adding my profile to your preferred RSS reader, so you get notified each time I post. A few good ones for android are Feeder, Read You, or (my favorite) Capy Reader.

What do you think about Kicksecure (and Kicksecure inside of Qubes)?

I’m not sure if you mean actual Kicksecure or if you mean Whonix. Either way, if I were to use Qubes OS, I would do Whonix inside of Qubes (until a secureblue template is made).

SecureBlue too but I hear SecureBlue isn’t a big team, not sure how much time they have to address the broad range of desktop Linux security issues

secureblue backports a lot of fixes from other projects (e.g. their browser, Trivalent, backports fixes from GrapheneOS’s Vanadium). Their team is small but mighty.

I personally think that if you were to put GrapheneOS and Qubes OS side-by-side on uncompromised hardware, I’d take Qubes.

GrapheneOS compartmentalizes as well, but in a different fashion. All apps on GrapheneOS are sandboxed, Once GrapheneOS implements App Communication Scopes, apps will be able to be completely* isolated. Without App Communication Scopes, the best way to isolate apps is by setting up separate profiles.

*While APC prevents communication between apps, they are still installed on the same profile, and thus have access to unique profile identifiers. Apps with network access can technically communicate with each other via a third party. Furthermore, apps may be able to directly communicate with each other through a telephone effect (e.g. Pixel Camera tells Google Play Services to tell Google Calendar about the photo you just took). I am massively oversimplifying this, but you get the gist.

I mentioned in my post that security is going to become very interesting with the introduction of the Linux terminal into Android. If GrapheneOS chooses to expand on this, that means, like Qubes OS, GrapheneOS could emulate multiple Linux distros.

Anyways, this is how I would rank them in terms of security (again, oversimplified):

GrapheneOS > Qubes-secureblue > Qubes-Whonix > secureblue

Each project fundamentally has different goals, so there is no one “security” to rank them by.

Though, for desktop, I prefer secureblue, as I don’t have a secondary GrapheneOS device, and secureblue is far more usable than Qubes OS.

https://privsec.dev/posts/linux/linux-insecurities/

That’s a more up-to-date article about security issues with Linux.

TL;DR is that Linux (the desktop, not the kernel) is fundamentally insecure, and so the more secure options for desktop are Qubes OS (Qubes OS is not a Linux distro) or (even better) GrapheneOS used in Desktop Mode. secureblue is about as secure as Linux can get, but the most secure option for desktop itself.

Things also get weird when you consider running secureblue inside of Qubes OS. See my post for more thoughts about that.

Madaidan’s Insecurities hasn’t been updated in a few years, so some of the information is a bit out of date. It is still decent information, but don’t follow it granularly. What you may be looking for instead is secureblue, which essentially does what you are describing but for Fedora Atomic desktops.

Thank you! I will try this tomorrow. I’ve been at this for 7 or 8 hours straight now.

I think so, but I can’t be certain. Is there an easy way to check?

I specifically need CoreOS since I plan to rebase it to securecore. Thanks for the suggestion, though!