What about having an intermediate server running on the same box as the browser, that connects to CDP using a pipe, and forwards messages to the Redis server, instead of modifying Chrome s source ? It's painful to maintain Chrome patches.
Really cool project in any case, seems like working at Pikkit must've been a lot of fun ! Thanks OP for sharing.
This would work. We started prototyping this way and it worked well to an extend. The main issue you're going to have, is you need to have both chromium and the forwarder process to run at the same time. This makes it difficult to track what is running exactly.
If you're forwarder is running but the browser crashed, it will still appear as available on the Redis side. While if you're making the browser setting a key with expiration itself, if it crashes, it will stop appearing on redis side.
Those are the kind of stuff you get modifying the source, and that will be hard to do with dual process type of setup.
This is simply not true even when hyperoptimizing for cash.
I always had this gut feeling of using GrapheneOS and QubesOS but decided to go with an iPhone and MacOS because of this idea that I should optimize for cash first and then only I should buy private devices.
Truth is: I started ignoring my "tech intuition" and stopped enjoying programming at all, which obviously led to a decrease in both happiness and revenue.
I started picking up tech that I'm interested about (GrapheneOS, QubesOS, Rust) and I've had a big boost in productivity as a result.
Same can be said with AI adoption; I was forcing myself to use it to be more productive but it had the opposite effect given that it weakened the exceptional intuition that gave me my incredibly privileged position.
Some people need to just execute, but some people are meant to explore, learn and gather new ideas and innovations. Sure, I am not a R&D researcher but everything I learn our of pure joy ends up being useful to my coworkers who are more the "get shit down" type and don't bother learning new tech.
There is a cost to ignoring your intuition and taste! If you feel like implementing privacy and security into your product or your digital life, you will pay a cognitive price by ignoring it.
Hi, had to create an account just to answer. Vendor lock-in is not that much of a problem with macOS; you can install pretty much anything you want and it looks like it will still be in the future unlike mobile platforms.
MacOS is very easy to get used to so the transition shouldn't hurt :)
If your only concern is vendor lock-in, I think you should be good with macOS.
I am saying this as someone who switched to Asahi because I wanted more freedom relative to the desktop environment (wanted a real tiling window manager). MacOS + Apple hardware is an incredible combination that has not been reproduced anywhere.
Maybe one thing to be careful of: you cannot install Linux on M3 and M4, so if you want to make a switch later on, you won't be able to. Ah and btw you can dual boot Asahi on M1 and M2!
Oh, thank you very much for chiming in! That twist on Asahi x M3+ was interesting - is that because something wasn't ported yet and the support will be there one day, or there'll be a hard block for Asahi forever for M3+?
From what I understood, the CPUs are different and need work for them to be supported. There is no hard block, but sadly, two key people resigned from the Asahi Linux team.
I am not even sure if there is someone even trying to work on this.
Another example is microphone support on M2 series that's not there yet.
Many issues with Asahi are also that there is an incompatibility in page sizes (16k on MX vs 4k on most CPUs), and combined with the usage of ARM, software compatibility is an actual problem if you want to use VMs, DAW software (nothing will work there except Reaper ...)
(Maybe this paragraph was a bit ranty, but I'm actually very glad we got Asahi in the first place. It's my daily driver and I'm relatively happy with it)
TL;DR: no hard blocker but there is a people "problem"
