Nice work! I'm also a fan of the runtime only frameworks. They might not be as efficient as the compiled counterparts on paper, but in my experience the performance loss is almost negligible compared to the rest of the stack.
I built my own frontend framework for similar reasons: https://github.com/fresho-dev/mancha. It was meant to adress the lack of lightweight solutions that worked both on the frontend and the backend. The main goal was to start with client side rendering and, only if you reach the point where you need it, switch to server side rendering. It also includes a drop in replacement for TailwindCSS except it won't yell at you for doing everything client side.
What I really wanted was a better maintained version of PetiteVue. But that highlights another problem: I simply can't trust anyone in the frontend JavaScript ecosystem, I've been burned too many times. It took a while to get to the point of it being usable, but now I know no one can pull the rug from under me. I use only the most basic APIs possible, only 1-2 third party dependencies, and as little hacks as possible.
It still has a few warts here and there but I hope to be able to call it a 1.0 stable version soon enough.
Corollary to your statement: of the very small (<1%) group of users running such ancient versions of Android, 100% read HN and will be responding to your comment. As if it invalidated the stats on actual usage: https://apilevels.com/
What hardware are you using? I recently finished a project myself and I'd like to do more with e-ink but the hardware "driver" that plugs into the pi costs as much as the e-ink display.
You can use Wikidata and its Sparql query language for this. Although it's not straight forward for all countries, e.g. some have especial properties for regional breakdowns that are not defined as ISO standard subregions.
> Does it work with Raspberry Pis and the CSI cameras? What about my Logitech USB camera?
I don't know details about the Raspberry Pi cameras, but if it's a UVC camera (quite likely) then it should be supported by this library according to the documentation. A USB Logitech camera should also be supported. The gotcha is that unless those cameras expose advanced functionality (3A, multiple stream support, etc) then you don't get any benefit over using the standard V4L drivers.
> Would it support receiving a picture from eg a flatbed scanner over a parallel port?
I don't think scanners identify themselves as camera devices, but someone can correct me if I'm wrong.
I'm surprised to see such big emphasis on support for Android. Most camera modules come with their own drivers that already provide Android support. One benefit could be the licensing, but after a quick inspection it is unclear to me what license this library is under -- there is a licenses folder with 4 different licenses in addition to a developer agreement.
The design seems to be heavily inspired by the Android camera API: per-frame configuration, 3A, multiple stream support, device enumeration, etc.
> The HAL will implement internally features required by Android and missing from libcamera, such as JPEG encoding support.
That is interesting, since most camera modules will have a hardware accelerated path to encode frames directly to JPEG. If it's done internally, it will be much slower than all other implementations I'm aware of.
Maybe someone can take a second look at the paper. I couldn't find the published version, just a manuscript[1] (kudos to the authors for making it available under CC license). But... The only reference I could find about the sample size says:
> "To prepare a single RNA injection, the pleural-pedal and abdominal ganglia were removed from 4-5 sensitization-trained animals—or from 4-5 untrained controls—immediately after the 48-h posttest"
4-5??? I really hope that I'm missing something here, otherwise I find truly depressing how low the bar is for scientific journals.
I haven't read the paper in full detail, but reading between the lines I'm guessing that there's a significant portion of manual processing and hand waving involved. From the abstract, emphasis mine:
> the second stage uses a pixel-wise nearest neighbor method to map the smoothed output to multiple high-quality, high-frequency outputs in a controllable manner.
My interpretation is that they select training data by hand and generate a bunch of outputs. Repeating the process until they like the final result. From the paper:
> we allow a user to have an
arbitrarily-fine level of control through on-the-fly editing of
the exemplar set (E.g., “resynthesize an image using the eye from this image and the nose from that one”).
By your definition, how can a REST API be idempotent? Say that GET(user) = john so, what I'm interpreting is that: GET( GET(user) ) = GET(john) = john. That doesn't seem valid to me.
I fail to understand the need to re-use terms from other fields in a completely twisted way. For those like me wondering what an "idempotent API" is: making multiple identical requests has the same effect as making a single request[1].
Then you have other people using the exact same term to refer to a (seemingly) totally different concept: An idempotent operation completes no more than one time[2].
Maybe I'm thicker than the average web developer, but I think that there must be a simpler way to explain this concept. Specially without reusing a term that, formally, means something completely different[3] than any of the possible interpretations that I have come up with so far.
I'd say that the Windows equivalent is https://chocolatey.org/. It has the largest amount of "packages" from all other similar efforts that I have seen.
The EULA for it is the same, but the underlying system is totally different. I am 100% sure about this :-)
But, as you noted, a lot of the telemetry instrumentation has been backported so that argument is lost for someone wanting to avoid upgrading to Windows 10 from an earlier version.
Also wrong. The telemetry in Windows 8 was just in critical components that had been instrumented long ago, such as Windows Update, crash management, etc. None of those were using the current universal telemetry system. In fact, I don't know if all of them moved to the new telemetry infrastructure shared with the rest of the OS or if they kept what they had and just added the new telemetry on top.
All that said, I agree with your last point about upgrading being a fair compromise compared to staying in Windows 7 or gasp Windows 8.
Thanks for sharing that! Some of them are just a big pile of CSS which I don't know if it's a better option than JavaScript... But others were pure gold and a very clever use of HTML (like the carousel)
Actually, no. Microsoft instrumented essentially every OS component (and sharing backend infrastructure, universal telemetry client, etc.) starting in Windows 10. Prior to that, it was just a few isolated pieces that had their own kind of telemetry.
Shameless plug: I have been working on my own code editor as well, I wanted something between Notepad++ and Jupyter Notebooks; I called it TeIDE: https://github.com/omtinez/teide
Fully open source, built on Polymer and currently working on a plugin/action model to enable users to execute custom commands on the underlying shell.
Accepting pull requests and all forms of feedback :-)
Shameless plug to my own runtime (and compile) micro framework: https://github.com/fresho-dev/mancha