"Just use the terminal" is somehow simultaneously a defence of windows while being a attack of linux. If I have to engage with the system on a deeper level I rather not do it on the proprietary blackbox with opaque knobs playing whack amole.
In what ways does LineageOS trail behind AOSP in terms of security? I looked at the comparison chart you linked elsewhere and the privacy/security sections only seem to list advantages over OEM Android (not AOSP), with the exception of secure boot [1], but AOSP (not OEM Android) doesn't have that out-of-the-box either. Unless you are comparing Lineage with OEM Android?
They do provide installation commands for every platform that aren't vulnerable to homograph attacks due to GitHub not allowing Unicode characters in user/repo names :)
A simpler solution: examine the URL displayed in the browser window before copying terminal commands from the page. E.g. "starts with github.com" -> "trusted GitHub UI indicates the repo is the official one for this project" -> "URL points to the official project README" -> "terminal commands are most likely not malicious, and if they are, there's a bigger problem here".
Of course, more secure installation methods should be preferred, but those are not always available. I am simply comparing the provided solution to homograph attacks with another solution to the same problem.
The whole point is that someone could put a Cyrillic "i" in "github" and your eyes can't tell the difference. The actual GitHub link might be real and valid and you checked; you might still hit "g[cyrillic i]thub.com" and not the real GitHub.
It does make running commands from an untrusted website a little safer, which is nice. I imagine it's not uncommon to copy installation scripts from random StackOverflow comments or blog posts, for example. But that's still not safe even with this tool. Homograph attacks aside, how can you tell if a URL you're pasting into your terminal is the official source for something? It's trivial to create fake GitHub accounts or organizations.
The linked article seems to imply that this remains a good design choice even today:
> The use of this rule can be seen for example in MacOS, which always places the menu bar on the top left edge of the screen instead of the current program's windowframe.
I guess now that the browser is the one app you probably spend the most amount of time in, it might make a little less sense? Android's lack of a menu bar system makes it make very little sense there.
Apple's design never made sense. It's fine when apps are maximised but it gets very confusing when apps are not maximised and the menu is very far from the app that it belongs to.
Since it only works well for maximised apps, the UX is much better if you just merge the menu into the title bar of apps.
I found it to not at all be confusing once I got used to it—-I find it less confusing and more reliable in practice.
Speaking from 20+ years of Windows use with a local menu bar and 7 years of Linux desktop where I switched to a global menu bar—-it was an instant improvement in quality of life.
I no longer have to hunt for a narrow menu bar strip, just throw the mouse all the way up, and hope to never hunt for it ever again.
We should all be taking full advantage of the amazing capabilities of the pocket supercomputers we all carry around with us at all times (even if the companies who make them don't want us to or don't care about us). Anything less would be silly! Now Linux and Windows users (the majority of iPhone users) can do easily do so, and that's great.
To install your own personal homebrew apps without Apple's approval, use AltStore (Windows) or SideStore (Linux):
True, it's far from ideal, and not entirely without Apple's approval. You need an Apple ID, to accept Apple's EULA (which probably forbids such activities), to accept the risk of your Apple ID being banned [1], to accept the risk of Apple breaking things (intentionally or not), and to continue asking Apple's server for new signatures every week into the foreseeable future.
Still better than nothing, for those already fully immersed in the Apple ecosystem, with no hope of escape? (I still use and recommend Android, but I have a spare iPad to play around with, so I enjoy seeing stuff like this come out.)
Most laptops run Linux, but few provide official support for it. The Gen 12 and 11 did, and you could get Linux pre-installed. But there's no "Linux" option on the Gen 13 store page.
> RCS may require access to certain SIM card information, which only pre-installed apps can do
> because they don't want to implement RCS themselves.
Sounds like they can't implement RCS themselves even if they wanted to, not simply that Google doesn't provide an open source implementation? (Referring to app developers here, not custom ROM devs.)
They can't implement RCS for every carrier, but they can implement it for some. Others require nothing more than a network call to a predefined HTTP address over a data connection.
Although Google may dislike it, I don't believe Google's RCS implementation (the one most of the world uses) requires elevated permissions. Their activation sequence is proprietary and closed source, though so I'm not 100% sure.
Just having a base implementation for custom ROMs would be a start. Given that Google will block custom ROMs from RCS in their app (I believe because the spec says to), there is a need for an independent implementation if this makes RCS popular enough under American users.
Someone will have to inventory the activation mechanisms for each carrier to see if there really is a disadvantage. I'd start with mine, but all of the carriers in my country have shut down their RCS servers a decade ago.
I am not familiar with RCS, but considering the plethora of messaging apps available that just work, why did they choose the most complicated way for users to use it? And what do you mean it is not available on every carrier and needs SIM access?
I haven't seen any indication of that at all. There's sort of an API, but it's basically restricted to Samsung's messenger only.
The EU won't get involved unless a significant chunk of the user base uses Google Messenger. I don't think EU users will reach that threshold because most of the EU uses basically any chat app except for SMS/MMS. Things like receiving verification SMS messages still work using the existing API and I have a feeling that that represents the majority of SMS use in the EU.
Do those capabilities require a more expensive edition of Windows?