Still not correct. The path is perfectly correct. Even using full path. This method EXPECTS a repo package, not a file. I already figured the answer, it’s in this thread.
I think you have confused the apt command with the apt-get command. apt-get doesn’t handle files, while apt has it since the very first version. This is one of the important differences between the two commands. This was one of the main reasons why I have been using only apt for years.
Again, incorrect. The answer is above. And still, you haven’t read the thread. This is NOT about getting rescuezilla to install in the current PC. This is to get it to install in a DIFFERENT PC, which happens to be OFFLINE. So apt by itself will FAIL when it tries to resolve dependencies.
I don’t but i note increasing difficulty in upgrading/keeping prior extensions to the new version of gnome.
For example, “recent files” extensions for the top bar used to number in the threes I think. With the last gnome version there was only one which wasn’t the most useful of the lot. I use it because it makes it easier beginning again the following day, rather than the extra step of opening the file mangler. I’ll probably go with the majority and drop it once I upgrade to Fedora 39.
Looks like gnome is becoming more useful to people in basic guise, incorporating many of the extension functions within the main GUI, and so the once popular extensions are becoming unmaintained.
See I found that but I still could not figure out the install process. I finally figured that libsixel was the newest one but it still seems unmaintained. I ended up compiling it from source as it was not in the fedora repos. At this point I am more confused about the correct version of sixel to use. Libsixel is the only one I can really find
hopefully they’ll design some package manager incompatible with android at the most basic level - and then double down when it’s proven to be a huge mistake. a good tick upwards for dev jobs, but the time for actual competition was over 10 years ago. this will fail miserably.
Nice! And they will probably differentiate from the competition by allowing GPL applications and sideloading, and having a total control for your privacy and no tracking, right?
Yes, but those minor traces are easy enough to remove, especially if you don't care about being "ceritified" by Google (i.e. are not planning to run the Google services).
If my device is compatible, does it automatically have access to Google Play and branding?
No. Access isn’t automatic. Google Play is a service operated by Google. Achieving compatibility is a prerequisite for obtaining access to the Google Play software and branding. After a device is qualified as an Android-compatible device, the device manufacturer should complete the contact form included in licensing Google Mobile Services to seek access to Google Play. We’ll be in contact if we can help you.
Google services are entirely missing from Android open source. The Google Play package is what contains the entirety of Google’s services.
Not sure if anyone remembers but back when cyanogenMod was the go-to, early versions had Google services included. Google sent a cease and desist notice and said it was a license violation. You cannot distribute it as part of the OS by default. The next release of cyanogenMod had it removed. Users had to flash the package if they wanted it.
Right but the topic was about google’s data harvesting and what I meant was that you can’t just grab any AOSP distribution if you want to minimize that, you need to pick one that replaces the parts that send data to google. LineageOS for example still phones google for quite a number of services.
As far as “easy to remove” goes, I think that’s kind of debatable if you want to do it in a way that’s sustainable long term considering the effort that goes into e.g. GrapheneOS or DivestOS.
Edit: here is a list of the kind of stuff you need to watch out for if you want to minimize the data sent to google
I was answering under the assumption/the context of of "Amazon wants to release an Android-based OS that doesn't contact any of Googles services".
So, when I said "easy enough to remove" that was relative to releasing any commercial OS based on AOSP, as in: this will be one of the smallest tasks involved in this whole venture.
They will need an (at least semi-automated) way to keep up with changes from upstream and still apply their own code-changes on top of that anyway and once that is set up, a small set of 10-ish 3-line patches is not a lot of effort. For an individual getting started and trying to keep that all up to do date individually it's a bit more of an effort, granted.
The list you linked is very interesting, but I suspect that much of that isn't in AOSP, my suspicion is that at most the things up to and excluding the Updater even exist in AOSP.
linux
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.