mid-kid

It stings how much I relate to this.

They used to go work on homebrew for nintendo consoles instead. Times change.

I've been using it for a decade at this point now. Used to stay on top of all the additions and changes, but at this point it seems crystalized out. One of my favourite open source projects on android.

I've seen a few russian pirated game releases for linux do this, they just bundle a copy of wine (downloaded from the same places as e.g. lutris gets it from), and a start script that sets the WINEPREFIX variable to a pre-populated prefix, with the game already installed and all the needed registry configurations already present. I suppose you could bundle all this in an AppImage, the annoying part however is that the WINEPREFIX is supposed to be read-write, so you'd have to set it to some place specific to your app, to avoid messing with the user's main prefix. These prefixes are huge (hundreds of MB upon creation), so I'm not sure I'd consider this a desireable solution.

If this is your distribution method, consider having the user install wine before running your app.

~€25, Moondrop Chu 2 headphones. Really good quality for the price, with a bit of care have lasted me for ~3 years now. When one side was going quieter, I could unscrew and clean it. The clear plastic cord is yellowing now unfortunately, will try to buy a new one.

~€80, Anbernic RG35XXSP: Handheld games console that runs (mostly) open source linux distros. Reinvigorated my retro gaming on the go when the OG consoles are too inconvenient to carry around and emulating on a phone just feels bad. Having syncthing on-device means I'll never lose my saves again, and putting new games on it is as easy as dragging and dropping on my PC.

~€5, Mini media keyboard from aliexpress (just any, really): It works like garbage, but I never realized how badly I needed a remote with access to all of the MPV shortcuts for when I hook up my laptop to the TV.

I almost ignored this post because I can't stand this particular war, where examples are cherry picked to prove either answer.

I'm very happy to see the nuanced take in this article, slowly deconstructing the implicit assumptions proposed by the person asking this question, to arrive at the same conclusion that I long have. I hope this post reaches the right people.

A particular language doesn't have a "speed", a particular implementation may have, and the language may have properties that make it difficult to make a fast implementation (of those specific properties/features) given the constraints of our current computer architectures. Even then, there's usually too many variables to make a generalized statement, and the question often presumes that performance is measured as total cpu time.

they were using hyperbole

You can tell someone was angry by how often they wrote [sic] in the quotes

Including this one.

TIL that the green color means the account is new. I always thought it was a special marker somehow, like the equivalent of a blue checkmark.

I usually make do with `man` pages for C (very comprehensive), and the `python-docs` package in my distro (you can download a static copy of the python documentation, and even the search will work offline). As well as whatever PDF manuals I need for what I'm doing.

As I use Gentoo I also usually have the source code for anything on my system, so I can dig into that if I'm missing some docs, as there's frequently a docs/ folder in the archive.

If I'm missing documentation, I make a note of it and see if there's a way to make it available locally, somehow.

I used to commute 1h40m one way, which accounted for 50mins in a train (+10min avg waiting). While I ususally did pull out my laptop, the productivity just wasn't there - I can't consistently work while groggy/vitamin-d deficient during winter mornings, or in the evening being cooked after having worked for 8 hours (I have an office job, but not programming). The seats are cramped and uncomfortable, not being able to raise my arms enough to use the keyboard without bothering the passanger next to me, so I'd have to put it away during the crowded parts of the ride, and I'd be very frustrated if the train was unusually crowded. Having your "flow" be broken by arriving at the end stop and having to rush to pack your things is awful. The only conversation someone's struck up with me was a guy who insisted he'd never understand what I was doing even if he tried.

Suffice to say, after almost two years of this, I was extremely tired and sleep deprived as this ate away at my available time more than what is reasonable. Using the time for personal projects didn't compensate for it. Never again, it's really not worth it.

Of course not, but unlike chat services, everyone has an email address or phone number, so if I need to reach out to them for something other than a casual chat, e.g. an invitation, a birthday felicitation, or a document that they should review later, email is a method through which I can reach all of them.

Similarly, reaching out to companies for support also often happens over email.

This post is AI sludge and by the third bullet list I couldn't keep reading. This is stuff I deeply resonate with but jesus christ please respect my time and don't drown me in extremely verbose prose goop.

Before they got rid of XUL, this was the sort of thing possible with it.

> makes it impossible for attackers to add new executable files to the system which stops almost all attack vectors

If you have code execution - any kind - you have code execution. It really doesn't matter if a shell is available or not, you're always an open(2), write(2), and execve(2) away from creating and invoking a new executable, or just mmap(2)ing a new executable region in the current process. Yes, most exploits leverage a shell because it's convenient, so you're making it a little bit more annoying by having to first write an executable, but it really doesn't stop attacks like this.

Much more effective measures are those that prevent program takeover in the first place (SSP, ASLR), and things like W^X.

This app's killer feature for me is that it's actually available on F-Droid, unlike its upstream.

Happy user for many years now, thanks for the support!

For some of us software freedom enthusiasts it is worth noting that PebbleOS contains some proprietary blobs for some peripherals in the watch[1]. This is not just firmware you upload to the peripheral but also properietary .a libraries that run on the main core.

Though to be fair to OpenDevices, this is source code they don't have acces to either.

[1]: https://github.com/coredevices/pebbleos-nonfree/tree/57a94e2...

You have never tried to teach kids, smartphone-natives, to use a desktop, have you? The "new user" demographic has shifted from "been taught how to use windows" to "has maybe used an ipad".

The classic start menu/task bar approach just isn't as approachable as you think.

The astounding feat of reinventing Bluetooth...

I'm not sure why the author counts microG as "appeasing google". microG is a full, open source reimplementation and won't send any data to google (or anyone else) unless you specifically enable the parts of the API that do that (notably, push notifications) - and even then, the amount is reduced.

Furthermore, microG can be installed on LineageOS, as can the official play services. Either of these choices gives you compatibility with anything that doesn't require play integrity - just like with GrapheneOS.

As a rooted android user, I don't really have to imagine. It's been a constant fight for the last decade...

Firefox remains very conservative on enabling modern features on X11. Some distributions force them on, but otherwise it's up to the user to figure out how to do that.

It's likely that some hwaccel flag in about:config wasn't turned on by default. Similarly, if you want smooth touchpad scrolling, you need to set MOZ_USE_XINPUT2

The worst part to me is the lack of a scroll bar. Had to dust off the pgup/pgdown keys to check my progress in the article.

> F-Droid couldn't know either

F-Droid is not just a repository and an organization providing the relevant services, but a community of like-minded *users* that report on and talk about such issues.

> Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands. We are gathering early feedback on the design of this feature now and will share more details in the coming months.

I don't agree that this is something that should be restricted to "advanced" users, even. One of the basic freedoms that protects users from the unilateral control of the developers, is other developers (like me) being able to patch apps and distribute them to friends and family, without making a public fork or meeting play store requirements. Take for example, youtube revanced. If I want to help my friends by making a private f-droid or obtainium repository, to save them the trouble of going through the (legal!) process of patching and updating the app themselves, right now I can do this. If this requires going through a lengthy process instead, that may or may not be detectable by apps that will then choose to cease to function (this has happened with rooting), my ability to help friends and family as someone with the know-how and experience gets reduced significantly. There's many things that don't fly on the play store, such as the completely legal NewPipe, AdAway, and Termux applications, and while I can sign up for the developer verification, it's not clear to me under what circumstances the verification can be terminated.

changed the wording a little, thanks

Wouldn't it make sense to wait for (or support) one of the rust-for-GCC ports to become viable? As far as I understand, rust in the kernel won't become mandatory either until it's supported by GCC, and as a boon, with multiple implementations you can be more certain that the language won't move as fast and break things anymore. There's already upstream rust support in GCC, so I don't reckon it's that far off from being usable, at least for projects choosing to target it specifically.

Furthermore, if these architectures are removed from further debian updates now, is there any indication that, once there's a rust toolchain supporting them, getting them back into modern debian wouldn't be a bureaucratic nightmare?

It still exists, and it's gotten way more reliable than in years of yore. Check out ameliorated, and its derivative projects, reviOS and Atlas OS.

There's also projects that modify a system less deeply, like Sophia Script.

These days the default windows install is so garbage that I have little issue running semi-open source customizations like these.

>predictable given how the last 2 years went

QRD? Was it AI?