That’s not a meaningful comparison because it splits Ubuntu by version but all of Arch is a single category. We’d need to roll up the Ubuntu users for it to be apples to apples.
That’s not a meaningful comparison because it splits Ubuntu by version but all of Arch is a single category. We’d need to roll up the Ubuntu users for it to be apples to apples.
Someone is going back over their contributions, right?
Right?
Debian and Fedora have ports, though not all packages are available, and you’ll probably be doing a lot of porting if you want anything else.
But this bit from the uConsole R-01 product page might be relevant to you:
uConsole R-01 is a highly experimental model and requires some experience with Linux systems & FOSS. We strongly recommend all beginners choose other models.
swapoff, reformat, swapon?
Also make sure the drive isn’t dying.
Even at big companies, devs get flexibility because they need to run a bunch of random stuff that can look sketchy to security software.
Sometimes it can’t connect to the server (which is a completely stupid necessity).
That’s where it does the voice processing. The only processing it does on-device is the wake word and taking commands. Actually figuring out what you mean is done in The Cloud. Doing that on-device would not only make the devices significantly more expensive, but they would also rapidly become outdated.
The rest of your complaints are valid and I’ve experienced them all myself to boot.
Long story short, I can’t use multiple monitor RDP because I have different resolution monitors and they are stacked 2x2 instead of all in a row.
Did you try setting them up as one big display across all four, instead of four little ones? I think that’s something you can do.
Does the multi-mon RDP thing work from a Windows client too? I’d be surprised if it did, Windows’ multi-monitor support is fairly lacking in my experience too.
Why not run sed and pipe to diff to preview changes?
You’d still have to manually copy out the command line to a notes file, but I don’t think that that’s too terrible. You could use a terminal-integrated snippets palette to make it a little smoother.
I’m not aware of any program that does exactly everything you want it to, so you might write your own or extend an existing one, as mentioned.
You would probably get a better answer by asking a Rhino community. But a quick look at the documentation suggests you can choose: https://rhinolinux.org/wiki-rpk.html
⻚⍿⯽⎻⾘⾄♎ⲱ⬆⒍Ⲑ
I hope all your stuff supports Unicode.
I’m not sure if there’s some special calling feature to reach a previously associated provider, but when I’ve been in that situation I just borrowed my roommate’s phone.
Yes, it is possible. You use whatever the provider’s method is to download an eSIM to that device. Usually it’s logging into their app or calling their support to register the IMEI or whatever.
In the store if you’re getting the phone from a store, or somewhere with wifi (home, a friend’s, a cafe) if you’ve gotten it some other way.
If you don’t have any of those, you probably live way out in the jungle, and I’d be surprised if you had service even if you got the eSIM. But in the edge case that you somehow got home delivery postal service in the jungle, you’d probably be able to survive just fine without it until your next trip into town.
In the extreme edge case that you are in the jungle, get service, and your need is critical, I would have an activated backup phone tested periodically and ready to go.
Depends on the phone. The newest ones let you use multiple ones simultaneously, one for calls/texts and one for data, for example. Slightly older ones only let you use one at a time, but they let you activate and deactivate multiple downloaded eSIMs.
Your provider won’t issue a new eSIM?
No, they issue it virtually. Then you download it via their app or via regular cell network provisioning.
Yes.
That doesn’t have anything to do with what we’re talking about.
Because it aligns with most people’s use case. You’re free to patch it out if you’re so inclined.
It doesn’t actually contribute to the discussion.