[1]: https://manpages.debian.org/trixie/gpgme-json/gpgme-json.1.e...
Yes, I know. You could argue that a C compiler is a transpiler, because assembly language is generally considered a programming language. If this is you, you have discovered that there are sometimes concepts that are not easy to rigorously define but are easy for people to understand. This is not a rare phenomenon. For me, the difference is that a transpiler is intending to target a programming language that will be later compiled by another compiler, and not just an assembler. But, it is ultimately true that this definition is still likely not 100% rigorous, nor is it likely going to have 100% consensus. Yet, people somehow know a transpiler when they see one. The word will continue to be used because it ultimately serves a useful purpose in communication.
> This is pretty much the same as (2). The input and output languages have the syntax of JavaScript but the fact that compiling one feature requires a whole program transformation gives away the fact that these are not the same language
It is not really the same as (2), you can't cherry pick the example of Babel and generalise it to every transpiler ever. There are several transpilers which transpile from one high-level language to another high-level language such as kotlin to swift. i.e; targeting the same level of abstraction.
Wonder what this person would say about macro expansions in scheme, maybe that should also be considered a compiler as per their definition.
This website has a comparison of the loading times of the same LaTeX rendered in both KaTeX and MathJax: https://www.intmath.com/cg5/katex-mathjax-comparison.php
By Sequoia, are they talking about replacing GnuPG with https://sequoia-pgp.org/ for signature verification?
I really hope they don't replace the audited and battle-tested GnuPG parts with some new-fangled project like that just because it is written in "memory-safe" rust.
People who realized they actually owned the thing they bought wanted to do what they wanted, which required circumventing Apple's control or "jailbreaking". This differentiator stimulated Google to "allow" installing on Android without "jailbreaking" the device aka "sideloading", giving the illusion of the kind of freedom that was never in question on normal computers.
It is interesting though how this same conversation doesn't exist in the same way in other areas of computing like video game consoles or other embedded computing devices where the controls against arbitrary applications is even stronger.
The fact that mobile phones aren't yet just a standard type of portable computer with an open-ish harware/driver ecosystem that anybody can just make an OS for (and hence allow anybody to just install what they want) is kind of wild IMHO. Why hasn't the kind of ferver that created Linux driven engineers to fix their phones? Is Android and iOS just good enough to keep us complacent and trapped forever? I can't help but think there might be some effect here that's locking us all in similar to how the U.S. healthcare system can't seem to shake for profit insurance.
I'm sometimes surprised at the plethora of cheap handheld gaming systems coming out of China that support either Linux, Android, or sometimes both, and seem to be based on a handful of chipsets. If anybody ever slapped an LTE module and drivers onto one of those things we'd have criminally cheap and powerful, open phone ecosystem.
Yes, there needs to be a lot more uproar for these cases as well. One of the most appalling cases is that of macOS. To distribute your app (as a .dmg for instance), you need to sign up and pay for a Developer ID, sign the app with a Developer ID certificate and then notarize it, EVEN if you don't intend to use their App Store.
Migrating my i3 config to sway hardly took any effort. I was also able to get rid of a lot of xorg specific configurations from various x11 dotfiles and put them directly in the sway config (Such as Natural Scrolling)
[1]: https://itsfoss.com/news/kde-plasma-to-drop-x11-support/.