In case you weren't aware, MacOS uses zsh as the default installed shell. The bash version that comes with MacOS is some ancient 3.x version, from 2005.
Just that it would be `.zshrc` since zsh is already the default shell in the context of this post unless you enjoy a mid-2000s existence and none of the nice bash features of this generation (in which whatever `.bashrc` you've crafted is likely broken by time passing).
Maybe I'm underinformed, but I don't personally know any Linux users who convert to zsh, instead opting for fish or something else (oilsh? nushell?).
Yes, I'll throw my hat into this group too. Bash is fine.
YMMV but I have found using zsh too frictitious to be helpful. Sure, theoretically zsh living in a bash world (lets face it, all scripts are bash) is completely fine but reality seems to differ. Copied a one liner from shell history into your script? Crash. Use arrays? Weird bugs. Use shell builtins? Whoa unexpected interactivity!!! Etc...
Bash is absolutely fine as a default shell. As an added benefit, you don't feel like an invalid once logged in to a container or server.
I also think that it sends the right signal in terms of "Hey, this really doesn't need to be an app". I don't need an app for my newspaper, I need a shortcut/bookmark to its web page.
And once you start thinking about it, the same thing goes for a surprisingly large amount of apps.
I feel like in the coming years the facade big A and big G put up in order to push everyone into their distinctive walled garden of apps will crumble in public opinion.
It never was "yeah, it needs to be an app because the web platform doesn't have an API standard for it", geez, apple even forced a single web engine. They could have easily allowed access to their APIs on the browser. It just never was in their corporate interest to do so.
Okay, this devolved into an anti corporate rant without it being my intention to... So, go web!
I don't really know how to articulate exactly how I'd classify into one bucket or the other but I think there are two types of "app" and I tend to have differing preferences on whether they should be native apps or web apps as a result.
One is where relatively-static content is the priority, deep-linking is important or essential and the web platform is pretty ideal for those. News articles or blogs or Wikipedia pages or those sorts of things. Things where I might want to be switching between tabs or forgetting about for a while and coming back to later.
The other is where the app is primarily interactive or where the content is a lot more likely to be real-time or ephemeral. Not least because if you're on a low-bandwidth or high-RTT connection, navigating between web pages or having interactivity blocked behind a backlog of XHRs (particularly where caching isn't permitted) is utterly miserable. My experience is that native apps usually continue feeling responsive to input even when the network itself is not responsive but that is often not true with many clickable elements in many web pages.
PWAs might be the middle-ground here but they feel a lot like Electron apps to me: still foreign to all platforms, not responsive in the way that native UI controls are, weird/missing "back" behaviours and still no better support for deep-linking than the average app would have.
PWA was an awesome idea and should have been the way forward.
Unfortunately both Google and Apple very early on identified that it was in their best interest to keep the concept around in a half-dead state and ensure nobody really built on it...
You get notification. You can autoplay video/audio. You get whaterver video or element full screen with all necessary UI. You get rotation lock. You have a fullscreen to do what ever you want for any purpose. You probably can't touch hardware APIs(for example: bluetooth/nfc) like native app. But that isn't really needed for most apps either.
On the other side. Apple seems sabotage the PWA as much as possible. You can't autoplay video/audio. You can't even fullscreen anything other than video, and when fullscreen video, UI is ignored. Also there is no way to disable gesture so your app will misfire system gesture. And you can't lock the rotation either. There is no way to auto rotate the video player or whatever when maximized either.
It's really a golden example for pretend to do something while actually not. It seems you can do pretty much everything with ios pwa. And when you try to do it. You will figured out it will have a worse experience than native app because all sort of issues.
To be fair, Android also sabotages PWAs, it's just done behind your back. You see, in order to get a PWA to properly install, you'll have to use Chrome, and you'll have to have a Google Play account and Chrome will submit the PWA manifest for validation to a Google server, which in turn will decide whether the PWA is worthy, and if it is, it will generate a so called WebAPK, which is then installed on your device. If it's not worthy however, then it will become a bookmark instead, and many of the features that can be described in the manifest will not work at all.
So if you wanted to use a different browser or install a PWA without a connection to the internet, or without Google Play, all you get is a bookmark.
In my personal experience, it only validate whether manifest is malformatted though. Although it's still up to google if they want to do something wonky.
I saw someone claim on SO that they were not able to get a PWA to install properly until they changed their IP address, supposedly because they were from Iran, a sanctioned country.
To my knowledge, every PWA installed from Firefox on Android will become a bookmark. For Firefox I believe that means for example that if you try to open a link elsewhere that is within the manifest scope, it will not open in the PWA. That's because it's not possible to deep link to the PWA without it having an AndroidManifest with a corresponding intent filter, which is what the Chrome WebAPK achieves and why they can support for example custom protocol handlers or share targets or launch handling options.
AS I said, YMMV. PWA install has seen many a regression. Last Android release it didn't work for me, this one it does. I presume a lot of it is due to ecosystem variations and API changes.
Google invented PWAs and broke their back trying to make them a thing. I'm not a fan of Google but credit where credit is due.
They were also highly incentivized to develop the APIs that make it all work as Chromebooks are basically hosts for browser apps. Apple, as well as the other tech giants involved in the W3C had no such incentives and were dragging their feet.
Admittedly I am not up to date on the latest developments but as far as a couple years ago the PWA runtime on both ecosystems was significantly stymied in comparison to the APP runtime. No access to real storage functionality, significantly less platform APIs, yada yada.
Sure, you could build "better (installable) websites" but even to get standardized stuff like background execution or notifications working was either impossible or a long series of jumping through hoops. Even installation prompts bugged out way too often.
But to be clear, if that isn't the case any more I will be positively surprized by either platform provider.
Did you check the stuff murena has on offer? Most if not all of their phones come with an unlockable bootloader and the OS they come with isn't that bad to start with either.
Does it? If it looks equivalent to "stock" Android but you can do what you want with is, including removing bloatware, then it's arguably more secure and thus a better alternative than most. It might not be the most secure but it's already a step.
Hmm... that looks like a pretty skewed comparison. It's as if somebody took the security features that make Graphene stand apart and compared everything else to them.
No contention that Graphene is safe, but categorizing other OSes as "pretty bad when it comes to security" because they don't copy Graphene is a bit of a stretch.
Eylenburg's site is focused on privacy and security for the comparisons. GrapheneOS is the only privacy and security hardened OS included in the Android-based OS comparison. None of the other operating systems listed in that comparison keep up with Android privacy/security patches or provide significant OS level privacy or security improvements. Many GrapheneOS features aren't listed by the table or are grouped in huge generic categories such as "Hardened system components". An example of a major privacy feature not listed by the table is closing the leaks in Android's standard VPN lockdown mode. GrapheneOS fixes all 5 of the known outbound leaks in VPN lockdown mode, CalyxOS partially fixes 1 of them and the others don't touch this since that's not their focus. It's a privacy and security focused site comparing an OS focused on improving those in the OS layer to ones which mostly aren't.
Operating systems lagging far behind on privacy and security patches are definitely quite bad when it comes to security. For example, the official releases of /e/ for the Pixel 7 are still based on Android 13 and do not include any of the Pixel kernel, driver of firmware patches released from October 2023 and later. Eylenburg's table doesn't put much emphasis on this since it's contained within a couple rows which do not adequately communicate how delayed the updates are and how much that matters.
In addition to the official Android and OEM privacy/security patches, there are also major privacy and security improvements in each major Android release. Android also doesn't backport most Moderate and Low severity patches which are no longer given CVE assignments. Most privacy patches are considered Moderate or Low severity if at all. Many privacy improvements also aren't considered to be bug fixes since they're improvements to the intended design of the system. Only bug fixes considered to have a High or Critical severity security impact are backported. The comparison table could cover a bunch of standard Android privacy/security improvements to emphasize the importance of keeping up with the only actual LTS branch.
Pixel 7 is a fully supported device with Android 16 QPR1 available for it via the stock OS. /e/ is on Android 13 on the Pixel 7 without the kernel, driver and firmware updates released for it from the Android 14 launch and later. /e/ is a fork of LineageOS with drastically worse privacy and security.
LineageOS rolls back the security model and features a fair bit but does it far less than /e. LineageOS doesn't implement major privacy and security enhancements so a comparison of non-standard improvements in those areas is going to show that. LineageOS lags behind on providing the AOSP and vendor security patches, but far less than /e/.
The table covers the patch delays for both AOSP patches and device patches. It's showing how far behind they are on kernel, driver and firmware patches released for a device, not anything to do with end-of-life devices. Being multiple years behind on those patches for the Pixel 7 on /e/ has nothing to do with supporting an old device as long as possible.
I'm going to echo the sibling comment that this comparison conveniently centers on GrapheneOS while conveniently ignoring anything they don't do; for example, a firewall using root is useful, but since they've decided user's can't be trusted with control of their devices that's right out.
Eylenburg's site has comparisons between a bunch of different types of software and services with a significant focus on privacy and security rather than aesthetic customization features, etc.
For the Android comparison, GrapheneOS is the only privacy and security hardened OS included in the comparison. DivestOS used to be included before it was discontinued. An OS not including Google Mobile Services and branding itself as private based on that is a much different thing than a privacy and security hardened OS. Which other Android-based hardened OS could be included in the comparison?
None of the operating systems listed in the comparison include app accessible root access. Giving unconstrained root access to a huge portion of the OS including the application layer including a GUI application for managing firewall rules is not a well secured to implementing it. Managing firewall rules is entirely possible to implement while following the principle of least privilege and not substantially reducing OS security. In fact, Android has standard support for it and all of the operating systems included in his comparison rely on it if you want to do fine-grained traffic filtering.
RethinkDNS is a good example of an app providing support for local filtering via the VPN service app feature without losing the ability to use a VPN. RethinkDNS supports using a WireGuard VPN or even multiple chained WireGuard VPNs while doing local filtering of both DNS and arbitrary connections. It can filter connections based on the results of filtered DNS resolution. That's the approach that's used by Android so that's inherited by every OS in the comparison.
GrapheneOS is the only OS that's listed fixing all of the leaks for standard VPN lockdown feature which is needed to prevent leaks for firewall apps including RethinkDNS based on the VPN service app feature. That's not listed by the table, although it could be and it would make sense for someone to file an issue proposing listing it. Many GrapheneOS privacy and features are not listed by Eylenburg's comparison and a lot of what's listed are under huge categories such as "Hardened system components".
> For the Android comparison, GrapheneOS is the only privacy and security hardened OS included in the comparison. DivestOS used to be included before it was discontinued. An OS not including Google Mobile Services and branding itself as private based on that is a much different thing than a privacy and security hardened OS. Which other Android-based hardened OS could be included in the comparison?
I was arguing on the other axis. It's got good coverage of OS options, but the list of features is indistinguishable from someone saying "okay, this is what GOS does; how do others compare to each of its selling points?"
> None of the operating systems listed in the comparison include app accessible root access.
There is a difference between not shipping something by default, and being actively hostile to it.
> Giving unconstrained root access to a huge portion of the OS including the application layer including a GUI application for managing firewall rules is not a well secured to implementing it.
Agreed, that would be foolish. Thankfully, nobody is suggesting that. Just use a permission prompt, like every android root solution has for... over a decade? I don't think I've ever seen anyone not putting root behind a permission prompt, actually.
> RethinkDNS is a good example of an app providing support for local filtering via the VPN service app feature without losing the ability to use a VPN. RethinkDNS supports using a WireGuard VPN or even multiple chained WireGuard VPNs while doing local filtering of both DNS and arbitrary connections.
AFAICT, RethinkDNS demonstrates the problem quite nicely. On, say, my laptop, I can configure arbitrary VPNs and firewall rules, and I can configure them independently. Android conflates them such that - if not using root to work around the official way - your firewall app and your VPN app must be the same app. It's nice that RethinkDNS has specifically added wireguard support to its firewall app, but the fact that they needed to is a symptom of a poor design.
> I was arguing on the other axis. It's got good coverage of OS options, but the list of features is indistinguishable from someone saying "okay, this is what GOS does; how do others compare to each of its selling points?"
That's not what they're doing. Their focus is privacy and security, but they've only included a single OS in the comparison aligned with that focus. They don't want to include less known operating systems such as forks of GrapheneOS.
> There is a difference between not shipping something by default, and being actively hostile to it.
GrapheneOS doesn't do anything that's hostile towards users having root access. It provides official support for it in userdebug builds, which we recommend doing with ro.adb.secure set to 1 rather than using the default Android userdebug configuration.
> Agreed, that would be foolish. Thankfully, nobody is suggesting that. Just use a permission prompt, like every android root solution has for... over a decade? I don't think I've ever seen anyone not putting root behind a permission prompt, actually.
That's not addressing what was said. Having a permission prompt to grant unconstrained root access to apps still involves giving root access to a massive portion of the OS, greatly harming the security model and losing a bunch of the security features. It inherently regresses security in an enormous way which having user-accessible root access alone does not. Making it accessible to apps through the high level OS UI is a far different thing from having a very well protected way for users to have root access.
> On, say, my laptop, I can configure arbitrary VPNs and firewall rules, and I can configure them independently.
There are major issues with VPN leaks without these things tightly tied together and having multiple things configuring firewall rules is going to cause major conflicts. Android provides support for having a per-profile VPN with built-in leak blocking where the OS takes on most of the responsibility for it and can properly integrate it everywhere that's required.
> Android conflates them such that - if not using root to work around the official way - your firewall app and your VPN app must be the same app.
No, it does not have to be the same app. It's a choice the app developers are making to not provide an extensible system interoperable with other apps but rather to do everything themselves. It's also not a conflation of these things but rather it needs to be implemented as an OS API to do it properly.
> It's nice that RethinkDNS has specifically added wireguard support to its firewall app, but the fact that they needed to is a symptom of a poor design.
It's not a poor design but rather a much better design which avoids the very broken approach of multiple applications including VPNs trying to configure firewall rules. It's impossible to get right without all of those applications closely coordinating which is not what happens. Having VPN support built into the OS with a well defined API for apps to implement it with leak blocking support built into the OS is a far better approach which can be done correctly instead of the mess on laptops/desktops you're talking about. Android doesn't have a great implementation of all this upstream but the high level design approach is a far better one. It needs a major overhaul to heavily use network namespaces instead of the current messy approach built on a legacy design. That does not change that providing the VPN leak blocking within the OS and an API for VPN implementations is definitely a better approach. Built-in WireGuard support would be nice too but should be done properly.
Giving root access to a huge portion of the OS including the high level application layer and to actual apps running on top is always an insecure approach to this. It's a lazy shortcut to skip having to implement a proper system following the principle of least privilege where the GUI portion of the OS does not simply have unconstrained root access to manage everything at a low level in incorrect, racy ways. The correct place for firewall management is netd with user-facing interfaces which end up controlling what's done by netd. netd has CAP_NET_ADMIN and is in fact contained by SELinux without access to much more than networking configuration. Giving unconstrained root access to the GUI portion of the OS where minor UI bugs can give permanent root access to an attacker where there's no way to revoke it if they want to stop it is definitely not the right approach to implementing more user-facing firewall controls.
> When someone’s standing in front of a potential buyer trying to look professional, a slow-loading app isn’t just an annoyance. It’s a liability.
I've been there myself as a Dev and later on as a manager. You have to really watch out not getting locked into local minima here. In most cases its not bundle size that wins this but engineering an app that can gracefully work offline, either by having the user manually pre-load data or by falling back to good caches.
