It is supported on GrapheneOS. I've used it infrequently on a Pixel 8A. It's worth noting it only mirrors the screen, there's no extend option or DEX like experience.
Edit: There is a DEX-like desktop mode in beta, along with Linux VM with graphical app support.
Yes, and alongside formatting challenges, PDFs commonly only include the glyphs from the font that are actually used in the document.
So if you had PDF with "Hello World" on it, you could feasibly change it to "Hello Hello", but wouldn't be able to change it to "Goodbye World" (as the glyphs for "G", "b", "y", and "e" are not included in the PDF)
Sure, you could do a bit of detective work to figure out which font it was from the glyphs or something and lookup and insert new glyphs into the PDF, but I can't imagine a generic PDF editor being capable of doing this for you.
Some editors get around this but just straight up switching the font(s) for the whole PDF, so they'll look different after saving.
How would you do the things mentioned in the article using Guix?
You could write your own custom package definitions, extending the default to change up compile flags and allocators, but then you need to do this for every single package (and maintain them all). I'm not sure Guix gives you much here, though maybe that's fine for one or two packages.
The most pain-free option I can think of is the --tune flag (which is similar to applying -march=native), but packages have to be defined as tunable for it to work (and not many are).
If you want it to be permanent, then you can use a guix home profile (that's a declarative configuration of your home directory) with a patch function in the package list there:
You can also write a 10 line guile script to automatically do it for all dependencies (I sometimes do--for example for emacs). That would cause a massive rebuild, though.
>The most pain-free option I can think of is the --tune flag (which is similar to applying -march=native), but
> packages have to be defined as tunable for it to work (and not many are).
We did it that way on purpose--from prior experience, otherwise, you would get a combinatorial explosion of different package combinations.
If it does help for some package X, please email us a 2 line patch adding (tunable? . #t) to that one package.
If you do use --tune, it will tune everything that is tuneable in the dependency graph. But at least all dependents (not dependencies) will be just grafted--not be rebuilt.
I think I'm like your co-workers, I'm really interested in Clojure, but admittably have that (probably unreasonable) JVM aversion. Do you mind sharing why I shouldn't?
The JVM is an excellent general purpose, multi-threaded runtime, with a large ecosystem of open source libraries, and its well suited to many types of "back-end" workloads, which is why it was the initial target for Clojure back in 2006/2007. Clojure's great interop with its host platform made it easy for people to get up and running while leveraging all the existing Java libraries they were used to.
The JVM is still a great choice for all those reasons, but its a little heavier than Node.js which specializes in IO bound use cases (i.e. the back-end-for-front-ends that sit between the browser and the heavyweight back-end systems). Node.js is also probably better suited for smaller services, lambdas, and other light-weight scenarios (IOT?).
I'm interested in promoting a full-stack approach to ClojureScript because the JavaScript/Node.js ecosystem is everything that the Java ecosystem was 15 years ago. It has lots of developers, lots of libraries, and a "bad" language. And by sticking with Node.js, its one less hurdle for JavaScript developers to clear when learning ClojureScript. They still get to use all the same libraries they did before (via ClojureScript's great interop), and the runtime characteristics they are used to. Plus, if they then decide to start looking at Clojure on the JVM in the future, they will have already learned the language.
[0]: https://gitlab.freedesktop.org/mstoeckl/waypipe