> we had to spend time fixing the broken test even if the changes had nothing to do with the initial change. In response to this problem, it was decided to break out the code for each destination into their own repos.
One could also change the way tests are run or selected. Or allow manual overrides to still deploy. Separating repos doesn't sound like the only logical solution
Right let's add more layers that always solves everything.
No language or abstraction is perfect but if someone prefers pure functional coding, Rails and Django are just not it, don't try to make them. Others like em just as they are
If you have to pass data up and down, back-and-forth the chain and rely on mutation, sure, yes. That’s ball-of-yarn in a nutshell. There is such a thing as reducto ad absurdum in software.
Nevertheless I’ve found far more God classes that could be refactored into clean layers than the other way around. Specifically in the context of Rails style web app as GP is specially discussing. Batteries included doesn’t necessarily require large tangled God classes. One can just as well compose a series of layers into a strong default implementation that wraps complex behavior while allowing one to bail-out and recompose with necessary overrides, for example reasonable mocks in a test context.
Of course this could then allow one to isolate and test individual units easily, and circle back with an integration test of the overall component.
Oh that's one of the best news in the smartphone world in a long time.
It's impossible to escape the Apple/Google duopoly but at least GrapheneOS makes the most out of Android regarding privacy.
I still wish we could get some kind of low resource, stable and mature Android clone instead of Google needlessly increasing complexity but this will over time break app compatibility (Google will make sure of it)
Edit: I do think Pixel devices used to be one of the best but still I'd like to choose my hardware and software separately interoperating via standards
I have been trying to come off of google and cloud by building — quite slowly — my own nas server which has 2 nodes in two geographic regions where I am building certain services like cloud storage and backup, webhosting etc. But I think there are a few key things that need to be community driven to really get rid of this duoply.
0. A privacy first approach would be something like this:
`You+App --Read/Write-> f_private(your_data) <--Write only- 3p` and App cannot communicate your data to 3p or google/apple.
Think of Yelp/Google Maps but with no _read_ permissions on location, functions can be run in a private middleware e.g. what's near an anonymous location or ads based on anonymous data. You can wipe your data from one button click and start again for EVERYTHING, no data is ever stored on a 3p server. Bonus: No more stupid horrible permission fiascos for app development that are just plain creepy.
1. An opensource data effort that can support (0) with critical infra e.g. precise positioning, anonymous or privacy preserving functions that don't reveal their data or processes to 3p.
Here is my favourite open source effort: Precise Location Positioning. A high recall, opensource, 3D building and sattelite-shadow Data-Infra effort[3]. This world class dataset on shadows and sattelites are a must. Most geo-location positioning tied to Radio signals is just a bandaid and fraught with privacy issues — thought there are heroic privacy first efforts in this direction[1][2] which though amazing will be playing catch-up with google already deploying [3].
It means any 3rd party even the app provider cannot read your data or the output of the function run. They can provide some data/resources like say map tiles, PoI data and a function to run.
I'm not knowledgeable enough -- what would it take to escape the Apple/Google duopoly?
I'm imagining a future where you buy a smartphone and when you do the first configuration, it asks you which services provider you want to use. Google and Apple are probably at the top of the list, but at the bottom there is "custom..." where you can specify the IP or host.domain of your own self-hosted setup.
Then, when you download an app, the app informs the app provider of this configuration and so your notifications (messenger, social media, games, banking, whatever) get delivered to that services provider and your phone gets them from there accordingly.
There are some good stuff on the software side that people mention, but a big one is the driver support. We would need device makers to upstream support so there is less worrying about reverse engineering or needing to run modified ROMs based on old builds. Or just publish specs on the hardware that is enough for implementation. Sure, you can buy a specific phone and run a de-googled android or linux, but that only really works for the hobbyist who wants to spend time doing this. Which makes it difficult to create a market that encourages developers of software to port their software or write new software. With out being able to broadly support devices, most people are gonna be better off running Google's android.
It's not the right solution long term, but you can't expect the entire ecosystem to appear overnight. Using it allows deferring the driver issue a bit while building out the rest of the ecosystem.
Any one of us here could learn the skills to design a smartphone. It won't necessarily be good, but I remember that years ago, someone made one with a touchscreen hat and GSM hat atop a Raspberry Pi, rubber-banded to a power bank. I'm sure any one of us HN users could do this. And it worked. Quality only goes up from there.
The problem is it won't run any apps, so you'll need to carry this open-source secure phone in addition to your normal phone.
This is not as simple as you're saying. Making a new phone not relying on proprietary drivers tied to Android is impossible without a huge effort: https://news.ycombinator.com/item?id=21656355
Or use everything via the web browser; but yes, I think apps are the main reason we can't just have a generic Linux phone OS on an open hardware platform
Apps make or break operating systems and app stores. Just ask Microsoft (Windows Phone) or Huawei (HarmonyOs). IIRC amazon was paying devs to publish to their app store or something like that.
Thankfully, some apps have both web and native mobile versions but for a modern digital life, the critical apps are sadly not on both versions.
No. There are a few that claim to, but none of them are actually any good. Waydroid, for instance, requires that your kernel is compiled in basically "Android mode" (e.g. binder enabled).
> Waydroid, for instance, requires that your kernel is compiled in basically "Android mode" (e.g. binder enabled).
Waydroid needs you to have a single kernel module, which is in mainline Linux and just happens to be disabled in many desktop builds. That hardly makes it an "Android mode" kernel, and I certainly see no reason why it should make the system no good.
> Any one of us here could learn the skills to design a smartphone.
Unless you're Fabrice Bellard who literally created a 4G softmodem - no. It takes a whole lot of people (or, again, one genius Fabrice Bellard clone) to design a smartphone. You'll need AT THE VERY LEAST:
1) a SoC that has reasonably open device drivers and specifications - without that, all attempts are moot
2) a hardware engineer to deal with the PCB
3) a low-level system engineer to deal with the initial bringup (aka, porting u-boot and maintaining it)
4) an RF engineer to deal with the black magic that is designing ultra high performance PCBs that deal with the RF stuff (2G-5G phone networks, BT, WiFi, NFC, GPS) and high-frequency buses (storage, RAM, baseband, USB, PCIe, CSI/DSI)
5) a GPU driver engineer of the class of Alyssa Rosenzweig to get the GPU drivers to behave (she literally provided better-compliant drivers than Apple)
6) a battery engineer to ensure you don't end up with something like the ill-fated last Galaxy Note (that had to be fully recalled due to battery issues)
7) a ton of software engineers to get the basic things running that people expect from a smartphone (e.g. phone calls, 911, SMS, MMS, a browser and enough userland libraries so that third-party developers can begin to port games)
8) hosting engineers that deal with reliably delivering OS updates, application updates and A-GPS data
9) a skilled purchase and finance department to acquire all components as well as skilled QA people to make sure you don't get screwed in your supply chain by someone cutting corners or trying to engage in outright fraud
10) plastics and metal design engineers for the housing and other related engineering, and you'll probably also need engineers specializing in mass production and assembly as injection molding is a skillset on its own
11) engineers specializing in low power domains to get something that doesn't eat through the entire battery in a matter of hours
12) UX, UI designers to get something people can actually use (partially, that's also compliance stuff - think of accessibility laws)
13) testers to test your device against an insane load of other things - headsets, headphones, consumer and enterprise wifi, car head units, mice/keyboards, game controllers, USB hubs, monitors, projectors, adapters, dongles, IPv6 in its various abominations, phone network-side vendors, how devices behave in trains, cars, airplanes, cruise ships, in temperature and humidity extremes, under water, in back pockets (bending!), in dirt, dust, rain, being drenched in all kinds of beverages, muck, snow, fog, right next to extremely powerful broadcast radio transmitters, high magnetic/electric fields, teeth both human (toddlers) and animal (cats and dogs)...
14) logistics experts to deal with shipping, returns, refunds, recalls
15) customer support
16) psychoacoustics and acoustics engineers to make sure your device doesn't sound like shit (both what you hear, and that includes safeguarding the speakers from burning out, and what others hear from you, aka the beamforming stuff that the Asahi people reverse engineered)
17) video/colorspace engineers to make sure the whole darn thing isn't off color
18) camera/optics engineers, even if you acquire camera units these need to be integrated properly
19) lawyers and domain experts to deal with the compliance crap: RoHS, CE, FCC, India's regulatory authority, licensing, binary blobs, video codecs, audio codecs, carrier compliance testing, HDMI, HDCP, the RF compliance crap that's needed for US compliance [1], tariffs, sanctions laws... the list is endless
20) advertising (although admittedly, word-of-mouth could be sufficient), and PR in general (including websites, print media, AtL/BtL marketing)
21) deals with app developers, lest you end up like Windows Mobile
22) security testers/experts to make sure your devices don't get 0wned by cellebrite, mossad, nsa, cia, ...
23) human resources experts ("people engineers") to herd all the cats
24) packaging engineers to make sure the product arrives at the customer's hands both looking appealing and undamaged (tbh, that's at least four distinct skillsets as well)
You're looking at a minimum of 2-4 million $ for the engineers alone, another 4-5 million $ for the compliance crap, many millions for the app deals and way more in upfront cash for components and logistics chains.
That's why every attempt at a reasonably open source phone design has either failed or is many years behind the mass market. And the list of organisations attempting to do so include household names of the likes of Mozilla. And that is also why/how ODMs exist... they all have figured out some "minimum viable design" that gets tweaked a bit for the customer brand, and that's it. Everyone else went bust. Including, as mentioned, Microsoft. Including former powerhouses such as HTC. It's simply too complex to keep up.
On HN, we could probably drum together people of all these skillsets, no doubt (it took me half an hour to think of all these people and I'm pretty certain I've missed important aspects still!), and even ones with enough money to burn. But even then: the competition are the richest companies on the planet: Apple, Google, Samsung. Good luck...
(And yes: a minimum viable phone - probably a lot of people here including myself could whip that up using a COTS 5G modem, a Raspberry Pi and a power bank. But that's a MVP, not something you can sell to anyone less nerdy than Richard Stallman, and it's based off of the work of a lot of the people I just spent 58 minutes to think of and write down)
As I wrote: that's a MVP, not something you can sell to anyone less nerdy than Richard Stallman, and it's based off of the work of a lot of the people I just spent 58 minutes to think of and write down.
Good luck getting that to perform. Or even boot. High-speed buses are the darkest of the dark arts to design, at the kind of frequencies particularly PCIe runs even the slightest trace length mismatch, impedance issue with the PCB itself, vias, or even external RF sources can, do and will mess with your sanity.
That's my entire point. It's not easy to design a complex thing such as a smartphone.
> I'm not knowledgeable enough -- what would it take to escape the Apple/Google duopoly?
At this point? Reliable emulation that can run 99% of Android apps, to provide a bridge until the platform is interesting enough for people to develop for it "natively".
I think the easiest way to do that would be to run Android in a VM.
> I think the easiest way to do that would be to run Android in a VM.
The problem is the critical payment and government ID apps that will never run in an Android VM because they intentionally break without hardware attestation.
The private key used for attestation is stored in the secure element hardware, which runs its own OS, completely inaccessible to the main hardware's OS, even with root.
Some apps don't actually check the attestation signatures, so they could be spoofed for now, but if spoofing became common, apps would just get strict about checking attestation.
Why not run Android directly, such as using Graphene OS. It's decades ahead in both OS architecture, developer tools, and developers compared to non Android based Linux operating systems.
Graphene uses the Google codebase, so Google is choosing its long-term development strategy and standards it will support. It's like choosing Chromium to escape Chrome.
If someone is making a new browser, considering you want to support the same web standards as everyone else, being independent is pretty low on the priority lists. In fact it is more of a liability since it could make for compatibility issues.
The same can be said about the Linux codebase. Tomorrow Linus could private his branch and stop supporting public releases. If AOSP goes closed source then people can fork it and continue to maintain it.
I do agree that each company's influence in case of the kernel is much lower, than Google's relevance in Android, but there are other big-ish players in the space as well, like Samsung.
Well if you rely on running Android apps, you still rely on Android.
Actually, if you rely on the app, you really on the Android SDK which is not open source.
Now if you could run AOSP but your own apps built with an open source SDK, that would be a different story. Some people seem to really want to do that with PWAs. I personnally tend to hate webapps, but I have to admit that they can be open source.
You could, but using containers requires that your kernel directly provide and secure Android-compatible functionality, such as binder. A VM gives you more options for abstracting that functionality.
If you expect to be "essentially android, but a little different", containers make sense. If you want to build an entirely different mobile OS, but provide Android compatibility, I think a VM is much more likely to give you the flexibility to not defer to Android design decisions.
> I think the easiest way to do that would be to run Android in a VM.
Sony's cameras used to have an Android userland that they used for their PlayMemories apps. No idea how exactly that one was implemented though, but it should be possible to get Android apps without going into being an Android fork.
How do you run WhatsApp or Signal without a smartphone? Pretty hard.
If your answer is "don't use them", then you're not living in a country where the vast majority of communications are done on WhatsApp or Signal, good for you I guess.
Yes that's fair. I have a an old iPhone without a sim that I use as my master for those apps, but I keep it in a drawer since the desktop apps work fine. Funny enough the phone the app is installed on doesn't have to be the same phone you use to register by number, so the number I registered with is my flip phone
Access to Signal and Bitwarden are the only two apps I really need daily that keep me on a smartphone. I have tried using a feature phone in the last couple years, but honestly I might as well just not have a phone at that point as almost all my communication is via Signal.
Well honestly that's part of the flip phone lifestyle, if someone doesn't want to call me, that's fine, they can send me an email. We don't have to bring Google or Apple into this relationship, it's a choice people make because the prefer texting and being available to everyone they ever met 24/7
> We don't have to bring Google or Apple into this relationship, it's a choice people make because the prefer texting and being available to everyone they ever met 24/7
You're changing the discussion now.
The original point is this: Given that people want to be able to text with their friends in what is perceived as a normal way, how can they do it without a smartphone?
If you change the rules ("Given that people are fine being disconnected"), of course it changes everything.
I don't think that 24/7 availability is universally perceived as "a normal way". A large number of my contacts will answer several days after a message. In my experience it is usually only inside the nuclear family that people expect answer within 2 hours and these are the kind of people who can always choose to call instead of text if they know their child/sibling/parent is not usually text available.
I don't know how many time I would have to repeat it, so I'll do it one last time.
The beginning was:
> what would it take to escape the Apple/Google duopoly?
To which someone answered:
> Has no one mentioned not using a smartphone as an option?
To which I answered that in a ton of situations this is just not an option.
And yet I keep getting answers that give examples of when it is an option. Sure, sometimes it is an option. Now for the majority of normal people who don't consider "not having a smartphone" as an option, I was saying that it is very, very hard to escape Apple/Google.
I am NOT saying that most people would die on the stop if they suddenly did not have access to a smartphone. I am saying that there is no solution to that that most people would consider viable.
> I don't think that 24/7 availability is universally perceived as "a normal way".
I never said 24/7 availability. I said "not having access to WhatsApp/Signal [in one's pocket, some of the time]". The part in brackets was implicit because we were talking about smartphone operating systems.
Doesn't really make sense in a conversation about security (the HN post was referencing security).
Traditional desktop OSes (Windows, MacOS, traditional Linux distros) are just at an entirely different level than modern mobile OSes (Android OSes, iOS) and ChromeOS. They also often run on less secure hardware, especially compared to a Pixel.
They don't publicize it because they'd rather sell all the data they don't have already through your payments and bank movements but many still send you a dedicated device if you mention you don't have a smartphone.
You can escape the duopoly by using a GNI/Linux phone, Librem 5 or Pinephone, but don't expect any support from Google or Apple for them. I'm using the former as a daily driver.
GrapheneOS doesnt really proactively attack GNU/Linux. What happens is that there are posts on the internet about GrapheneOS or mentioning GrapheneOS in which or under which completely wrong comparisons between GrapheneOS and GNU/Linux get posted. It makes sense that you care to clarify or correct if you spot people are talking about your project and are (intentionally or unintentionally) spreading wrong information about it by making comparisons based on misconceptions or falsehoods.
The thing you link about restricting network traffic doesnt make much sense. GrapheneOS has a proper network permission which other OSes dont have. The outbound traffic restrictions to certain destinations which are being referred to are just a bad approach. You can send the traffic to one server and just process it there and send out to other servers.
You also say :
> Also, if I explicitly don't trust Google with anything, GOS is extraordinarily insecure for me until a new vendor
If thats the case, dont opt for GNU/Linux either given the large code contributions made by Google. Also avoid any software built with LLVM, written in Go, written in Flutter, using Angular, ...
The two "problems" you link arent really huge security issues. How is GrapheneOS having access to the embargoed patches and being able to ship them a security issue? Also the planned sideloading restrictions dont even apply to GrapheneOS. It would only apply to certified OS that license Google Mobile Services. Also, that isnt even a security issue. Its a freedom issue.
> How is GrapheneOS having access to the embargoed patches and being able to ship them a security issue?
This is not the actual issue. The actual issue is that existing patches for a known vulnerability become unavailable, because Google decided so, making GOS potentially insecure. Patches without the source code shouldn't be trusted.
> It would only apply to certified OS that license Google Mobile Services.
Until Google alters the deal.
> Also, that isnt even a security issue. Its a freedom issue.
There is no security without freedom. If you're protected by a steel door, but you don't have the key, you aren't safe: You're imprisoned. You can't protect yourself from Google without having freedom to run what you want on "your" device.
Im not trolling. You say you dont trust Google at all. Thats your position. Then my argument is to not trust their code, regardless of which project its submitted to. How is that unreasonable. Your argument is the unreasonable one. You somehow think contributions by other companies to Linux would balance out or erase your trust issues with the Google code? Why would that make any difference.
> This is not the actual issue. The actual issue is that existing patches for a known vulnerability become unavailable, because Google decided so, making GOS potentially insecure. Patches without the source code shouldn't be trusted.
The issue gets patched. Whether the code is published doesnt change the code... People can also sti reverse engineer the code. Its not a black box. Its often just Java code. You can easily decompile Java, bytecode maps easily to the source code. Its an effort you have to do, yes, but so is reading and properly auditing the source code as well. You seem to think publishing the code somehow magically makes it more secure. While that isnt true. People would still need to properly audit it. It barely happens in practice. And it can also perfectly be done with compiled code.
> Until Google alters the deal
If Google were to put the restriction in AOSP, GOS can simply remove it from the code... And if its not in AOSP than it doesnt impact GOS.
> There is no security without freedom. If you're protected by a steel door, but you don't have the key, you aren't safe: You're imprisoned. You can't protect yourself from Google without having freedom to run what you want on "your" device.
This metaphor doenst make any sense in relation to the planned sideloading restrictions. I suggest reading the blogposts from Google about what the process will look like.
> You made a general statement about attacks from GOS on GNU/Linux.
No, I provided two specific examples, one quoted and another linked to. None of them happend in the context of wrong comparisons being made.
> You say you dont trust Google at all. Thats your position. Then my argument is to not trust their code, regardless of which project its submitted to. How is that unreasonable.
Your argument is completely unreasonable. Google has full control over Android and therefore GrapheneOS. It has very little control over Linux. All their contributions to Linux are carefully verified by many independent
parties and suspicious things not accepted by community are rejected. The latter doesn't happen in Android, see my examples above.
> The issue gets patched. Whether the code is published doesnt change the code...
Only if you 100% trust Google. I see you do and promote them. I wonder why you would defend a trillion-dollar, monoppolistic megacorp hostile to its users.
> People can also sti reverse engineer the code.
This takes huge effort and time. One can't rely on it to be secure.
> If Google were to put the restriction in AOSP, GOS can simply remove it from the code...
The effort to keep a hard Android fork up-to-date will grow exponentially. I don't expect that GOS team will manage to do it for long.
> This metaphor doenst make any sense in relation to the planned sideloading restrictions.
This is exactly what is happening with Android right now. Users are constantly loosing their control over the device in the name of the false sense of security.
> I suggest reading the blogposts from Google about what the process will look like.
This is not even funny. Are you working at Google? I suggest you to read blog posts by a non-profit instead: https://eff.org.
> No, I provided two specific examples, one quoted and another linked to. None of them happend in the context of wrong comparisons being made.
You made a general statement here ("being known for"). You put a link there indeed with a quoted example and another link.
> Indeed the GrapheneOS community is known for attacking the GNU/Linux mobile with false claims, https://news.ycombinator.com/item?id=45562484.
You have to look at the parent replies of what you link. Read the thead properly, please. Like I said , "What happens is that there are posts on the internet about GrapheneOS or mentioning GrapheneOS in which or under which completely wrong comparisons between GrapheneOS and GNU/Linux get posted". Replies that were literally mentioning GrapheneOS got a reaction. Thats not an unfounded attack. The statements that those other options are less secure are clearly backed up with technical information.
> All their contributions to Linux are carefully verified by many independent parties and suspicious things not accepted by community are rejected. The latter doesn't happen in Android, see my examples above.
That's really not how it works in practice. There is a ridiculius amoumt of code and code changes. Systematic proper exhaustive auditing doesnt happen. Also, you distrust Google and think they are malicious. Google can do their best to hide bad stuff in their code so quick reviews wont notice it. Do you think malware developers write functions called doTheBadStuff()?
> I see you do and promote them. I wonder why you would defend a trillion-dollar, monoppolistic megacorp hostile to its users.
I am not promoting Google. I am just countering your posts critizing Google using bad arguments. Google is a multi-faceted compamy some of the things they do are good for end users, some aren't, most things will be liked by some and disliked by others.
> This takes huge effort and time. One can't rely on it to be secure.
Reading and properly understanding source code also takes huge effort and time. And like I said, if you dont trust the devs, you cant trust function names, variables names and code comments to give a faithful portrayal of functionality anyway. So do you really lose that much if you decompile Java bytecode and mainly just miss naming and comments? It can even be argued it will remove preconceptions and let you read the code with a more open mind. Its a hurdle and annoying for sure, though. I would prefer Google to lower the embargo as well. But, public source availability just isnt the magic silver bullet you think it is.
> The effort to keep a hard Android fork up-to-date will grow exponentially. I don't expect that GOS team will manage to do it for long.
You dont need a hard fork for that. If the sideload restriction were to be put in AOSP you can remove that in a soft fork.
> This is exactly what is happening with Android right now. Users are constantly loosing their control over the device in the name of the false sense of security.
I agree Googles plans arent a good approach. But it isnt a false sense of security either. Registering app IDs and associated public keys is a usefil thing. There are other, begger approaches though, tbat dont have the downsides of what they planned.
> This is not even funny. Are you working at Google? I suggest you to read blog posts by a non-profit instead: https://eff.org.
Based on what you were saying and your bad metaphor it is just clear you arent accurately informed or up to date about what the sideloading restrictions will be. The best place to read what the procedures will be is in Google's blog posts and documentation. I am not saying you have to go read that to make a value judgement on the merits. You just need to read that to understand what is actually being talked about. I dont like Google's plans either but I am aware of what they are.
Something being a non-profit doenst automatically mean all posts they write are of good quality. EFF does many good things but I dont see why their posts about things are somehow automatically good and authoritative because of their non-profit model. Best to judge individual posts on their merit.
Google has implemented lots of privacy and security features in AOSP over time. The app sandbox and permission model has evolved a lot, in a good direction. The codebase is also modernized with the increasing adoption of memory safe code. At least Google seemes to have a thought out development strategy to enhance security and privacy, contrary to the projects you mentioned elsewhere in this Hacker News thread.
Also, what you link doesnt prove what you think it does. Manifest V3 is a very good thing for privacy and security. It restricts and controls the access of extensions much more. With MV2 you have much less control over your data.
> It restricts and controls the access of extensions much more.
You mean, it restricts users even more and gives to websites the freedom to track you? I won't engage in further discussion with you, you're just trolling.
You link three things, that doesnt equate to "every independent organization". One of your links is a post by Brave and Brave isnt independent in this. The unsubstantiated fear of people for MV3 is beneficial for them, it could grow their userbase because they keep the support for MV2.
Content blocking (ad and "tracker" blocking) are convenience features, they dont foundationally improve security. Defining what a tracker is is difficult and you cant list them exhaustively. Also smart businesses and organisations can just shift to sending all data to the main domain and handling it server side to send it onwards to other domains, including third-party domains. If you dont trust a site to not send data to third party domains directly, why do you trust it to not send it indirectly?
No, I meam it restricts extensions because it does. Vouching for MV2 is like vouching for an Android OS without a proper permission model. MV3 helps against tracking, its good for privacy and security. If you want the convience of content blocking, uBlock Lite still works good enoough for many people. Though, you still lose on security and meaningful privacy (again, define a tracker and list them all, impossible) because extensions in general hurt site isolation and increase your fingerpint.
> You link three things, that doesnt equate to "every independent organization".
Seriouslu, is this the only counter-argument you could invent? I didn't have the goal to list all independent organizations in the world. Now, you have to find one saying the opposite to EFF.
> If you dont trust a site to not send data to third party domains directly, why do you trust it to not send it indirectly?
Against tracking by whom? By FLOSS add-ons intentionally installed by user and verified by the community? In contrast to random, untrusted websites running megabytes of proprietary JS?
Ad blocking is necessary to avoid malware and spyware which is spread by google adsense all the time. It's not just convenient, most trackers won't go out of their way to improve their tracking if a few users start blocking it. Get real and stop parroting
If you're stateside and want a shipping Linux phone today, [FuriLabs](http://furilabs.com) is another option.
Graphene is in a class of its own compared to both of these though and there's frankly no reason to bother unless you're trying to improve those ecosystems.
I admit to being shocked that such a common phrase isn’t widely understood, but this site has plenty of international traffic so I can only say thanks for the context comment. :)
Yeah, it's funny how our contexts shapes what we believe to be universal :) I had the same experience with "ground floor" and "first floor", where seemingly every country has a different understanding and way they use those. Or even what "Caravan" actually is seems to differ too. Language is fun :)
> but still I'd like to choose my hardware and software separately interoperating via standards
This is why I can’t do GrapheneOS. Pixel devices do not suit my needs (& aren’t available). 2 of the big appeals for my going Android was 1) device options 2) ability to customize (appearance, apps from other sources, root access). Google has basically done everything to prevent #2 & GrapheneOS prevents #1. …This is why I also have a Linux phone to just leave these restrictions.
The success of an OS is inevitably linked to the availability of apps. A "smart" phone today is basically useless if it can't run either iOS or Android apps. Projects like Waydroid can make Linux phones viable, but since there are approximately zero native Linux apps for phones, you might as well use Android as a FOSS base. This is precisely what Graphene and Lineage do.
I have an Xperia with Sailfish OS. The Android app support ironically ends up what makes it usable, but the new patch isn’t released with kernel support that actually makes the IO work properly. Its own app selection is pretty small. It would be cool if all desktop Linux didn’t need an entirely new skin to work at this form factor, else I could get what I needed. I also use Nix to smooth over some of the repository shortcomings.
Sailfish OS just takes the wrong approach, to be honest. It makes more sense to have the more secure OS at the host (Android) and the less secure as a guest for compatability (traditional Linux distro). Its also problematic that the app compatability delivered via the Anseood support uses an outdated Android version etc.
Totally agree. Pixel devices are probably still the best Android offering, but I originally got into the ecosystem because it was less confined and that appears to be changing. While I'm likely not representative of most consumers, I would love it if I could choose both the right device and right software for my particular needs .
Pixel phones currently have the additional benefit of a full Debian OS running via AVP. This is (imo) on par with or better than having Termux on a rooted device. It's still fairly off-the radar which makes it a really good time to be exploring it's uses.
I agree, it has been lots of fun testing around in the KVM. Recently a GrapheneOS update even included the Button to attach to the "screen" of the VM. It also has GPU passthrough iirc?
When i have more freetime during the holidays i will test further. I especially want to try how it works when i combine stuff like steam + fex + Proton or run other GPU stuff
Cloudflare does both but some providers do one or the other. You can use any CDN no matter if you use Cloudflare or not (shout-out to Bunny CDN btw, very happy with them - they do one thing and do it well)
While Rails indeed tries to support old versions for a while I found that many devs are eager to stay on top of upgrades (which also has been less painful the last few years and definitely when done incrementally)
Fair there will be some old never updated backend only services, but that seems like a stretch that those will need a FE library all of a sudden
Solar and battery for refrigeration seems a waste.
If you own a house I'd look into very old school options like digging a deep hole to store your food in a dark&cool place - forgot the name for it but it'll work for weeks or months without a single milliwatt
That sounds really inconvenient (am I going to keep my food down there all the time, or is the plan to carry the entire contents of my refrigerator down there in an outage?) not terribly effective (RIP all the frozen stuff) and probably not any cheaper. Plus the hole can’t be used for other things like charging my phone.
That's very smart and might end my quest for a truly quiet bedroom fridge, if it really only runs two minutes in an hour. (Light fridges marketed as "quiet" just produce near-constant annoying fan noise, quietly.)
One could also change the way tests are run or selected. Or allow manual overrides to still deploy. Separating repos doesn't sound like the only logical solution
reply