I don't think I need a new $4000 refrigerator with an ad-spewing tablet and barcode scanner.
I do think a $100 device with a barcode scanner and a tiny LCD screen that attaches magnetically to the fridge and has 3 buttons: "Buy More", "Empty", "Expired", where you scan an item then hit the appropriate button it syncs to a backend service that helps build shared grocery lists would be a winner.
Mostly that VLC has had noticeable issues with displaying some kinds of subtitles made with Advanced SubStation (especially ones taking up much of the frame, or that pan/zoom), which MPV-based players handle better.
Note that, while I haven't had time to investigate them myself yet, IINA is known to have problems with color spaces (and also uses libmpv, which is quite limited at the moment and does not support mpv's new gpu-next renderer). Nowadays mpv has first-party builds for macOS, which work very well in my opinion, so I'd recommend using those directly.
It says in passing As the Metal backend is only supported on Apple Silicon devices, GPU and CPU share the same memory in the part talking about the differences between the Direct3D and Metal render pipelines.
Not sure why though, because Metal 3 is still supported on a bunch of Intel Macs...
If anyone has read the Iain M. Banks novel Excession, this feels somewhat similar to the funnier parts of it where a bunch of AI's embedded in spacegoing vessels have chat discussions back and forth, with a fair bit of shade thrown.
Has anyone calculated or measured the input lag of ADB vs other protocols such as PS/2 or USB? This is unfortunately hard to search because most references on the web to ADB are for the Android Debug Bridge.
From the numbers given, it seems like ~2ms to send a packet (my math may be off), which is quite good when compared with other contemporary/modern protocols (see: https://danluu.com/input-lag/ for examples)
I may actually try my hand in conciliation court against them on this one. I received a test kits back around 2015 from a family member, but was disgusted at the idea that there was no possible way they 1) wouldn't go under and sell my data 2) be breached. I feel like these sort of outcomes for these types of services are very obvious as highly likely to anyone who works in proximity to tech, and especially startups.
Anyway, I never submitted the test. But I know for a fact that family has. It's really annoying to that others can make these sort of linked decisions for you - especially as we are now acutely aware that this type of data can, will and I'm sure is being used in ways that basically nobody would consent to.
If you want even more minimal, Gerrit is structured as a Java app with no external dependencies like databases, and stores all it's configuration and runtime information on the filesystem, mostly as data structures in the git repos.
Shared filesystems is all you need to scale/replicate it, and it also makes the backup process quite simple.
I might be one of the few that is intrigued by this being that it’s Java but this looks really neat. Does it do git repositories like gitea, GitHub, etc, or is it more of a project management site for the repositories? They describe it as “code review”, so I wasn’t sure.
I’m a little put off on the google connection but it seems like it could run rather independently.
It's hyper-focused on code review and CI integration, which it does really well.
It's not focused on all the other stuff that people think of in code forges (hosting the README in a pretty way, arbitrary page hosting, wiki, bug tracking, etc.) but can be integrated with 3rd party implementations of those fairly trivially.
> I’m a little put off on the google connection but it seems like it could run rather independently.
Yeah, its actually a really healthy open-source project, google contributes usually around 40% of the code, but you have other companies like GerritForge(disclaimer, I work here), Nvidia, SAP, Qualcomm, Wikimedia foundation, all contributing heavily to it.
Coming from Github myself, I cannot imagine going back to it after using Gerrit for even just a few days.
The workflow in Gerrit really makes a lot of sense, unfortunately its the workflow in GitHub that has screwed up everyone's idea of what code review should look like[1], even by one of GitHub's co-founder own's admission.
I personally find the rebase and stacking commit focused method of integration that Gerrit uses to be easier and cleaner than PR's in GitHub.
Having done CI integrations with both, Gerrit's APIs send pre- and post-merge events through the same channel, instead of needing multiple separate listeners like GitHub.
reply