JoeyJoeJoeJr @ JoeyJoeJoeJr @lemmy.ml

Posts

7

Comments

124

Joined

2 yr. ago

Can you describe your use case more?

I don't think format matters - if you've got multiple processes writing simultaneously, you'll have a potential for corruption. What you want is a lock file. Basically, you just create a separate file called something like my process.lock. When a process wants to write to the other file, you check if the lock file exists - if yes, wait until it doesn't; if no, create it. In the lock file, store just the process id of the file that has the lock, so you can also add logic to check if the process exists (if it doesn't, it probably died - you may have to check the file you're writing to for corruption/recover). When done writing, delete the file to release the lock.

See https://en.wikipedia.org/wiki/File_locking, and specifically the section on lock files.

This is a common enough pattern there are probably libraries to handle a lot of the logic for you, though it's also simple enough to handle yourself.

You mean with config files stored in your home directory? Or something else?

When you install, whatever you install, partition your drive so that /home is it's own partition. Then if/when you reinstall, distrohop, whatever, you don't have to worry about copying over your data. Just use the same /home partition, and format the others. You can actually use this to try multiple distros at the same time - you can install them in different partitions, but have every install use the same /home partition. This is a nice way to test new distros without blowing away your stable install.

Now, for my distro recommendation - Ubuntu gets a lot of hate, but honestly, after 15+ years of Linux, and having tried Mint, Fedora, Arch, Manjaro, and many others, I always end up back on Ubuntu. It's easy, it's stable, and it stays out of my way.

The defaults are good, but you can customize as much as you want, and they offer a minimal install (as of 23.10, it is the default) which comes with very few applications, so you can start clean and choose all the applications you want.

Unless you are excited to tinker, I'd really recommend starting simple. Personality, I just want the OS to facilitate my other activities, and I otherwise want to forget about it. Ubuntu is pretty good for that.

They are explicitly trying to move away from Google, and are looking for a new option because their current solution is forcing them to turn off ad-blocking. Sounds to me like they are looking for a private option. Plus, given the forum in which we are having the discussion (Lemmy), even if OP is not specifically concerned with privacy, it seems likely other users are.

As for cookies, searxng can't do any more than your browser (possibly with extensions) can do, and relying on your browser here is a much better solution, because it protects you on all sites, rather than just on your chosen search engine.

"Trash mountain" results is a whole separate issue - you can certainly tune the results to your liking. But literally the second sentence of their GitHub headline is touting no tracking or profiling, so it seems worth bringing attention to the limitations, and that's all I'm trying to do here.

You mean between their instance and the final search engines? Or between them and a public instance of searxng?

In either case, I'm not sure it buys you anything in terms of privacy you wouldn't get by using the VPN and going directly to the search engines.

It looks like a few people are recommending this, so just a quick note in case people are unaware:

If you want to avoid being tracked, this is not a good solution. Searxng is a meta search engine, meaning it is effectively a proxy: you search on Searxng, it searches multiple sites and sends all the results back to you. If you use a public instance, you may be protected from the actual search engine*, because many people will use the same instance, and your queries will be mixed in with all of them. If you self host, however, all the searches will be your own - there is then no difference between using Searxng and just going to the site yourself.

*The caveat with using the public instances is while you may be protected from the upstream engine, you have to trust the admins - nothing stops them from tracking you themselves (or passing your data on).

Despite the claims in their docs, I would not consider this a privacy tool. If you are just looking for a good search engine, this may work, and it gives you flexibility and power to tune it yourself. But it's probably not going to do anything good for your privacy, above and beyond what you can get from other meta search engines like Startpage and DuckDuckGo, or other "private" search engines like Brave.

You manage the sources yourself, so if you don't want to search certain platforms, just don't add them.

You can actually sign the F-Droid app yourself, if you use reproducible builds.

There's reasonable odds the signatures still won't match though, because Google requires App Bundles now, and then they build and sign the APK, rather than allowing the developer to build and sign their own APK.

Technically you can use the same key (see "Best Practices" of this page), but it's kind of shady, and requires giving your private key to Google.

This isn't necessarily true - a developer choosing to not include their app in a repo can always opt for a self-updating mechanism.

Don't get me wrong - repos and tooling to manage all of your apps at once are preferred. But if a developer or user wants to avoid the Canonical controlled repo, I'm just pointing out there are technically ways to do that.

If you'd question why someone would use snap at all at that point... that would be a good question. The point is just that they can, if they want to.

The age and obscurity of the library is irrelevant - you could always include libraries bundled with the app, if they didn't exist in system repos. For example, in deb packages, you could include it in the data.tar portion of the package (see https://en.m.wikipedia.org/wiki/Deb_(file_format)).

Libraries with version names baked in are one solution to the dependency hell problem, but that requires support from the language/framework/tooling to build the application, and/or the OS (or things get hacky and messy quickly).

If you read that dependency hell page, you'll see another solution is portable apps, which specifically mentions Appimage, Flatpak, and Snap.

Additionally, if you read the Debian docs on How to Cope with Conflicting Requirements, the first solution they give is to "Install such programs using corresponding sandboxed upstream binary packages," such as "Flatpak, Snap, or AppImage packages."

Bin the consumer environment? It is nice and good practice but it is nowhere near as important as it used to be.

This is incorrect. The target audience for Flatpak is desktop users: https://docs.flatpak.org/en/latest/introduction.html#target-audience. Flatpaks are explicitly for consumer, graphical applications.

It's worth noting you can bypass the repo, and install snaps that you downloaded from some other source - see https://askubuntu.com/questions/1266894/how-can-i-install-a-snap-package-from-a-local-file.

That doesn't give you a separate "repo," but it does allow you to install snaps from anywhere.

It's actually less about the library being obscure, and more about version conflicts, which is actually more a problem with common libraries.

For example, let's say you want to install applications A, B, and C, and they each depend on library L. If A depends on Lv1, and B depends on Lv2, and C depends on Lv3, with traditional package management, you're in a predicament. You can only have one copy of L, and the versions of L may not be compatible.

Solutions like snap, flatpak, appimage, and even things like Docker and other containerization techniques, get around this issue by having applications ship the specific version of the library they need. You end up with more copies of the library, but every application has exactly the version it needs/the developer tested with.

I have no personal experience with this company, but I've followed them for a few years. I was initially very interested in their laptops, but was also very excited when the phone was announced. In the years since the phone was announced, I've heard and read many negative things about build quality and software on their laptops, and I've seen the shipment of the phones get repeatedly delayed. More recently, https://youtu.be/wKegmu0V75s showed up in my feed. I would recommend anyone considering purchasing from them watch that video, and do a little research into their security/openess claims, as well as customer satisfaction.

Again, I don't have the personal experience to say they are bad in anyway, but I don't want to see anyone get scammed, so I would recommend healthy skepticism and due diligence before making a purchase.

The community forked the core a while back: https://github.com/openVoiceOS/

See also https://neon.ai/, which builds on top of OVOS, and is who the Mycroft company officially passed the reigns to.

If they do not have cell service, they won't be able to set up Signal, or any other service that requires a phone number (they won't be able to receive the text message that verifies they own the number).

Since most phones (if not all), use an encrypted filesystem. With such, no service can't start if the device isn't initially unlocked after reboot, including Find my device.

Android developers can specify that their apps need to run before the pin is entered, via direct boot mode. This is how alarms still work, even if your phone takes an upgrade overnight, and restarts automatically as part of that process.

I can't say whether Google's Find My Device currently does this, but there is no technical reason it can't.

I went through this process for the first time recently. I opened the RFP issue, and got a response from Izzy very quickly. They were very helpful and responsive through the whole process. I was nervous it would be a slow tedious process when I started, but it turned out to be pretty quick and easy, largely thanks to Izzy's help.

Worth noting, they support reproducible builds, which allows developers to sign with their own key:

https://f-droid.org/docs/Reproducible_Builds/

I would definitely recommend going this route if you're starting with a new app. Having the binary on GitHub (or wherever you'd otherwise publish) match exactly the binary on F-Droid is really good for assuring people nothing in your repo was tampered with during the build process (i.e. that the binary was built from the public code, and nothing else).

It should not take extra work to do this. The project generated by Android Studio should already be reproducible. As long as you don't change the build setup and break reproducibility yourself, it'll "just work." When you submit to F-Droid, just be sure to let them know you want to go the reproducible route (if you make the PR yourself, it's a flag in the YAML file).

You might be referring to this? That's what I found from a quick search, at least.

If I understand correctly, this is a little different - from what I recall reading a few years ago, the speculation was that Netflix (and similar apps) rendered the content directly, bypassing the normal rendering stack. It would be the equivalent of, on a Linux system, bypassing the compositor (e.g. Mutter or KWin), and directly rendering the content (I believe SurfaceFlinger is the Android compositor). This means that when something like scrcpy uses the competitor API to capture the content, the content is literally not there, because it bypassed that system altogether.

By contrast, the secure flag just allows app developers to ask the OS to disallow screenshots, to prevent data leakage (e.g. of your banking details). It's all rendered in the standard way, though.

This may not be accurate - it's based on assumptions, and forum posts I read years ago, but it's the best explanation I have right now. If anyone knows better, please feel free to correct me.

It's not exactly what you're looking for, and won't be as seamless, but you might be able to leverage scrcpy.

It uses adb (you may need a fullfat distro for this - lineage may not support it), and allows you to view and control your Android device from a computer. It can also handle audio, and can be used wirelessly. The one caveat is protected content will probably not show up in the mirror - e.g. if you cast your screen and try to stream Netflix, it will likely be unable to send the Netflix video over. The last time I tested, it depended on the specific app, and which APIs they used under the hood (at the time, YouTube worked, Netflix did not).