I have enough disk space.
Plus my /tmp is a ramdisk and sometimes I compile large things in there (Firefox) so it is nice to let it be flushed out to disk if there are more important uses for that RAM than holding a file that most likely won’t be read again.
is framework agnostic
But it isn’t, because they depend on framer-motion and React. JSX is, but the icons aren’t.
You can trivially provide on-hover animations using CSS in SVG then your icons are framework agnostic. Not to mention smaller to download and more efficient to execute.
There are three parts to the whole push system.
My point is that 1 is the core and already available across devices including over Google’s push notification system and making custom push servers is very easy. It would make sense to keep that interface, but provide alternatives to 2 and 3. This way browsers can use the JS API for 2 and 3, but other apps can use a different API. The push server and the app server can remain identical across browsers, apps and anything else. This provides compatibility with the currently reigning system, the ability to provide tiny shims for people who don’t want to self host and still maintains the option to fully self host as desired.
% free -h
total used free shared buff/cache available
Mem: 125Gi 15Gi 90Gi 523Mi 22Gi 110Gi
Swap: 63Gi 0B 63Gi
I’ll use it eventually. Just gotta let the disk cache warm up.
Must be because Factorio released 2.0 and the Space Age DLC recently.
IMHO UnifiedPush is just a poor re-implementation of WebPush which is an open and distributed standard that supports (and in the browser requires, so support is universal) E2EE.
UnifiedPush would be better as a framework for WebPush providers and a client API. But use the same protocol and backends as WebPush (as how to get a WebPush endpoint is defined as a JS API in browsers, would would need to be adapted).
Why are these TypeScript + JSX rather than just SVGs? It seems that the paths are defined as SVG but they are using some JavaScript framework to define the animations rather than just using SVG or CSS animations.
Why WASM? It seems to me that the attack surface of WASM is negligible compared to JavaScript (and IIUC disabling JavaScript will also disable WASM).
Third-party frames is definitely a good way to reduce your attack surface though. Ad embeds are often used to distribute exploits.
What are you running MS-DOS? laughs in multi-tasking.
I just drag my vi terminals to another workspace and launch a new editor.
More like re-purchase it for twice the price on the next console’s eShop
Yes. As this is a workstation the memory use is highly variable, >95% of the time I would probably barely notice having 32GiB. But other times it is a huge performance win to have that capacity available. Sometimes I am compiling lots of stuff and 32 compilers running + ample disk cache is very important. Other times I am processing lots of data and other times I am running a few VMs.
It is a bit of a luxury. I think if I was on a tighter budget I would have gone for 64GiB. However the price difference wasn’t that much and at least a handful of times I have been quite happy to have that capacity available. And worst case I just have everything sitting in disk cache after a warm up which is a small performance win on every small task.