If that's the goal, the technology for how these agents "learn" would be the most interesting one, even more than the demos in the link.
LLMs can barely remember the coding style I keep asking it to stick to despite numerous prompts, stuffing that guideline into my (whatever is the newest flavour of product-specific markdown file). They keep expanding the context window to work around that problem.
If they have something for long-term learning and growth that can help AI agents, they should be leveraging it for competitive advantage.
You only notice this stuff if you use shell very often, and practically live in the command line. Since I started my career I've been using omz and a fresh install is always snappy but over time it starts getting slow.
Debugging/profiling why it's gotten slow has mostly been an uphill battle for me. I tried using zprof which pointed that compdef and compinit were culprits. I tried changing my config to calculate compinit only once a day since most people reported it to work, but it never worked. This kind of stuff pokes and stabs at you endlessly.
OMZ being shell, and being a maze of a codebase, I couldn't track down if and where compinit was being called from even after the config change above, because all profilers pointed to the possibility of compinit being called twice.
I gave up and started using barebones zsh + starship because I do need a good prompt. Yet the issues persisted.
I recently started using fish + starship on my local machine so that I could evaluate it before committing to it at work. It's the fastest shell so far (maybe because its new, I intend to find out).
My only painpoint now is I have a bunch of utility functions I've maintained in bash that I need to port to fish because of the posix incompatibility.
We keep a precomputed cityhash64 value for a few columns we know are going to be used for aggregations. Rather than relying on ClickHouse to do it internally, this explicity behavior I've found is faster.
Especially if it's a multi tenant architecture, it helps to have the cityHash64 caclulated as a combination of tenant ID and another column, so the overall amount of data scanned is lowered too.
I find this to be a very amusing critique. In my experience, Notion (when I stopped using it 3 years ago) was slow as molasses. Slow to load, slow to update. In comparison, at work, I almost exclusively favor Confluence Cloud. It's very responsive for me.
We have tons of Confluence wikis, updated frequently.
I think it might be the same issue as with WordPress and Jira - terrible plugins. Each company uses own special mix, and encounters issues often occurring in that one specific configuration. And it is the base platform that takes the blame.
In particular a place I used to work had a plugin for threaded comments in Jira. The specific one we were using slowed things down noticeably with the DB on the same server, but not too much to be an improvement in overall usefulness.
Then we decided trying to make our Jira more reliable by splitting the DB out into a separate clustered DB system in the same data center. The latency difference going through a couple of switches and to another system really added up with those extra 1600 or so DB calls per page load.
We ended up doing an emergency reversion to an on-host DB. Later, we figured out what was causing that many queries.
You're referring to the on-prem Jira. That might suck, sure. My experience has been purely using Jira Cloud and Confluence Cloud, both of which I've found to be snappy and responsive.
Amusingly, exactly opposite experience here. That said, our on-prem is jira and confluence integrated with db on same machine, and apache in front doing additional caching. I imagine like so many things it is how you set it up...
If you read my previous comment, I said it was largely the specific poor plugin that caused most of the performance issue with the database queries. I never complained about the overall speed of on-prem Jira. That was the assertion of the person who’s only ever used the cloud version.
My last company switched several teams to Jira Cloud. My current company started with Cloud when we moved over from other tools.
Cloud does not give you the flexibility of your own plugins, your own redundancy design, or your own server upgrades. On top of that, the performance is pretty variable and is far worse than a self-hosted Jira on fast hardware.
It’s interesting to me that your lack of experience to make a comparison qualifies you in some way to criticize the experience I actually have.
When I was in high school, I needed to automate downloading torrents (I was downloading tons). So I plugged together a bunch of tools including:
1. QBittorrent to run a FileBot script once the file was finished downloading.
2. FileBot script was a Groovy script that renamed and rearranged the contents into proper folders and
3. A small Python script that called the Telegram API to send me a notification that the download was complete.
Then I got into college and learnt they had a web portal which showed metrics like attendance (which turned out to be important) and test scores. So I wrote a Telegram Bot that would scrape these figures and save it into a database and run some calculations such as
1. Tell me how many lectures I needed to sit through to get to a required threshold.
2. If I decided to bunk college on certain days, how much attendance I'd end up losing.
Then I opened up this bot to allow my friends to register. Near the end of the first semester, the test scores were only available on the website but there was no direct link to that page from the public portal. I had found it out playing around on it and noticed they had directory listing enabled on some endpoints which led me to those "unlinked" but functional pages.
I wrote a neat feature which would allow querying this page and send a screenshot of it via my bot. I was running this entire thing on a Raspberry Pi 3B at my home and one morning I woke up to see logs from students I didn't know trying to use the bot (and ended up crashing it haha). Word had gotten around that test scores are accessible only through my bot.
It was one of the best projects I ever worked on. At its peak, I had 300 DAUs and I would hear from my friends in other departments that their entire batch is using Telegram solely for my program. I was also able to monetize it towards the end which felt nice.
These projects served as a learning tool for a lot of stuff for me. I learnt how to manage VMs, containerization, async I/O, DB and ORM integration, how to write good docs.
As much as I'd love to daily drive an OS like GrapheneOS, the risk of running into apps that use Google Integrity API thereby making it impossible to run those apps on Graphene is too much of an inconvenience.
I took a look at this curated list of bank apps[1] supported on Graphene OS and I'm glad that a large majority of them work on Graphene. However, just my luck that one of the banks I use on this list isn't supported.
In my country, the state is enforcing a lot of essential workflows to be digital-first (and in extreme cases digital-exclusive) and I dread to think needing these services at a critical moment and the choice of my OS making it impossible for me. This is more of a commentary on my government's choices but it's a reality for me.
In any case, I don't think it's practical to go cold turkey and switch to a privacy focused phone without testing waters first to see which of your of workflows break and then reason about the tradeoffs/workarounds.
I do admire folks who use GrapheneOS as a daily driver, I'd like to chat them up if I find them in the wild.
> In my country, the state is enforcing a lot of essential workflows to be digital-first (and in extreme cases digital-exclusive) and I dread to think needing these services at a crticial moment and the choice of my OS making it impossible for me. This is more of a commentary on my government's choices but it's a reality for me.
If my country did this I would get a cheap used device for this purpose and keep it powered off. I refuse to carry a pocket spy for the sake of convenience. I find that it’s rarely an issue.
Another daily GrapheneOS driver here. I've kept banking apps off my phone anyway, and I do banking via desktop/website (I don't understand why people need to do banking 'on the go') and just use a physical credit card for tap payments when I'm out and about.
I do have older Android devices that I have run banking apps on, that I can revert to if necessary, but there's a fair bit of inconvenience I would be happy to endure to avoid being forced into that final option.
What I would recommend is a slow transition, and just start using it at home. If you have GrapheneOS on it's most paranoid settings (exploit protections) there will be exceptions you'll need to allow for a few apps.
It's very country dependent. In the US, I don't think many banks do that, but I heard in Europe this is used a lot more, presumably due to more regulatory bs.
It's worth noting GrapheneOS with the locked bootloader will meet basic integrity, and that's what most apps need anyway. Strong integrity requires a whitelisted OS by Google and hardware to support it, but there are many older devices that do not meet it, so it will likely inconvenience too many people to be enforced for now.
I worried about that too, but jumped in and it hasn't been an issue at all in two years. Including three bank apps. And it's usually so easy to reset to vanilla Android if you need to that it shouldn't be your moat.
You're blowing this entirely out of proportion. The vast vast majority of apps work without issue with sandboxed play services. Yes it's less plug and play than a stock os. No it's not a life-ending inconvenience.
Problem is that if the app that doesn't work is not fungible (see your gym app, your banking app, your community app, etc) then you are out. The best compromise is to have a backup phone for incompatible non-fungible apps
Just looked - Microsoft Authenticator doesn't appear to work. I might be able to get off of it but it will take some prep. My banks are supported so that's good.
Because many admins are horrible and disable TOTP for "security".
My uni does it and I've had use the only alternative option, cell call, and rigged Tasker to automatically answered and play the needed tone so I don't need to carry it with me.
Microsoft authenticator should work on GOS, I can only find single person saying it doesn't but there's plenty of reasons it might not work for them (vpn, too strict exploit protection settings). And there's multiple people mentioning it working fine.
Provided GrapheneOS is cleared by Google to launch it as an "Android" device. Given the kind of changes GrapheneOS packs, it may or may not meet Android's mandatory CCD (compatibility) requirements.
It's not their own phone. It's an OEM phone that will be supported by GrapheneOS by flashing it. Once you do it, there's no reason to believe it wont have the same play integrity issues that it currently has on pixel devices.
I've used GrapheneOS for years now and it is the easiest-to-use, lowest friction privacy oriented software I've interacted with.
I'm not sure why one banking app not working would be a deal breaker (Can you not live without that specific banking app?) or why things being "digital-first" would be an issue (Are you talking about a government app not working?). The only people I think that it isn't practical for are those that need a specific dual factor authentication app for their job that doesn't work on it or someone that uses there phone for their business as a payment processor that requires an app that doesn't work on it. Otherwise it's kinda install it and forget about it, which is how I wish more privacy focused software worked.
I run GrapheneOS as a daily driver and slowly removed all proprietary software from my device by looking for FOSS alternatives on F-Droid. Luckily, I'm able to access banking and government in a web browser on a dedicated profile.
I do have a second Android device with a stock ROM that I keep turned off in a drawer in case I ever need to use an app that requires Play Integrity in an emergency.
I've seen a couple of apps try to use Play Integrity, get blocked by GrapheneOS, and keep on running. Maybe I'm being locked out of something, but it's not something I use anyway.
Note that I don't use banking or government apps. If I bank online it's via the web.
It does seem like a lot of apps continue to function on GrapheneOS after the "Play Integrity" check fails (or at least after Graphene notifies the user that the Play Integrity API has been called). I suspect either:
A) These apps have implemented only the check so far, and will eventually refuse to run or limit functionality at some point in the future.
B) These apps have noted the failure and certain functionality, especially communicating with servers to load "protected" content, will fail even if the app otherwise continues to run.
Is the app the only way to access what you need? I've never once install the app of any bank I've ever used (10ish) and never found myself wishing I had.
An increasing number of new services are app only or have a web interface with basic functionality. Dating apps and banking apps are commonly in this category especially if they are relatively new
I've been using GrapheneOS for years, I can't go back to another OS due to its ease of use, speed, and awesome features baked into my day to day use now.
There is one banking app that stopped working, and you know what? I dont use it now. I'm not about to let a bank dictate how I use my most personal device. I use a desktop if I need to access that info, and it forces me to be deliberate about it too.
We shouldn't install apps that use the Google Play Integrity or are closed-source in the first place. That's what I do.
The issues with GrapheneOS for me are:
1. They don't support rooting the OS. This is such a basic requirement for me. Why would I use an OS that doesn't let me do anything and everything with it?
2. They only support Google Pixel phones that don't have kill switches for the microphone, camera, radio and so on, as far as I know. GrapheneOS may be very secure, but nothing is 100% secure. Except cutting power to the mic. I'd be fine with physically removing the accelerometer and other sensors that can act as mics, even the mic itself. But newer phones are a bitch to open and close as they use glue instead of screws.
So right now I'm waiting for a Linux phone that's priced normally. I tried the PinePhone a couple of years ago, but it was an awful experience. Hopefully something comes soon. If not - I'll use my dumb phone.
1. It's not possible to root GrapheneOS or any Android-based OS and preserve the Android security model. That would run entirely counter to the goal of the GOS. It can be done but shouldn't.
2. They have implemented kill switches for these on the software level. Afaik there's nothing up dispute these working just as well as hardware switches assuming proper verified install of GOS.
1. I've read that rooting breaks Android's security model, but I have yet to find a detailed explanation of how it actually lowers Android's security, especially compared to desktop OSes that are usually rooted, like Linux or MacOS.
2. Software kill switches are prone to software attacks, aren't they? They can't be as secure as hardware kill switches unless we can prove the software kill switches can't be attacked by software. I doubt anyone can prove this.
Approximately, if the user doesn't have root then there's no way to trick them. They also can't access internal app files which gives app authors tight control over how their software is used.
That's the security model. Giving users root breaks both of those assumptions, hence it breaks the security model.
Notice that it is clearly in the best interests of users to at least have this option. But modern BigTech operating systems are designed around corporate interests, not yours. And security professionals seem to prefer to ignore inconvenient things like user freedom.
> Approximately, if the user doesn't have root then there's no way to trick them.
So not having root (somehow?) prevents phishing and tricking? That doesn't seem useful or relevant for people who know what they're doing. If I'm wrong, please elaborate.
> They also can't access internal app files which gives app authors tight control over how their software is used.
I read that in the security model and I don't care for it. App authors shouldn't have any control over how their software is used. In my opinion, of course, but for my computers my opinion is what matters.
I agree with you of course. The thing I find frustrating is the willingness of the GrapheneOS (and to a lesser extent LineageOS) devs to toe the corporate line, accepting anti-user-freedom bullshit in the name of this non-security.
Android/iOS do sandbox user apps by default, for instance. When you run a script on Linux, it has access to everything your user has.
Access control is also more advanced, e.g. apps need to request permissions to the user. Not saying that desktop OSes are not making progress, but they are behind.
I don't know if Qubes qualifies here. Qubes runs Linux instances in VMs to compartmentalise them, but then each Linux instance has the Linux security model.
I agree with the sandboxing and permissions points, but is that related to the OS not being rooted? This is a genuine question - I'm not trying to make a point here, but to learn.
I think Qubes qualifies from a practical point of view, as modern hardware is powerful enough for it, so it's viable to run Qubes on desktop instead of a baremetal OS. I'd even go further and say there's no excuse not to run Qubes if you're familiar with Linux and can afford a compatible desktop or laptop.
Per-app sandboxing or per-OS compartmentalization is pretty similar with regards to security. There are some security and usability trade-offs, but I like the per-OS isolation model, as it's easier for several apps to share everything within a VM - that way you isolate a whole "project" more easily, as everything inside a VM is only related to that project and you assume all the apps would need access, anyway.
I wonder if it would be feasible to build an automated phone-using robot, and access it remotely for any kind of apps enforcing that type of crap. There is really nothing they can do in terms of device attestation to prevent it.
but who says you have to limit yourself to one device? it's mildly inconvenient to carry more than one, sure, but the added benefit of an air gap between "serious business" and "personal life" is very much worth it, imo.
LLMs can barely remember the coding style I keep asking it to stick to despite numerous prompts, stuffing that guideline into my (whatever is the newest flavour of product-specific markdown file). They keep expanding the context window to work around that problem.
If they have something for long-term learning and growth that can help AI agents, they should be leveraging it for competitive advantage.
reply