Oh that’s such a high horse position lol - I try and learn as much as possible every day by shipping fast and profitably. Learning to be successful in industry is a completely valid (and common) goal.
This resembles some serverless pastebins. Data is serialized into the fragment part, and client-side JS deserializes them. The only practical difference is that this app sets them as HTML while those set them as text.
> So, cyber security of tomorrow will not be like proof of work in the sense of "more GPU wins"; instead, better models, and faster access to such models, will win.
It's not proof of work, but proof of financial capacity.
The big companies are turning the access to high-quality token generators (through their service) into means of production. We're all going direct to Utopia, we're all going direct the other way.
There's no "proof" involved. That's the problem with the analogy. It's not about how much "financial capacity" you have. It's about how many bugs you find or fix. The bugs are there where the models help attackers/defenders or not.
`jj new` works like `git checkout` most by creating an empty revision on the top. `jj edit` on the other hand resembles `git checkout; [edits...]; git add -A; git commit --amend --no-edit`.
I failed to see why this would be something that "comes after Git" from a VCS perspective.
The line-based diff(1)/diff3(1)/patch(1) kit often works, and that mindset thrives and gets carried till today. Many toolkits and utilities have been designed to make it more ergonomic, and they are good. Jujutsu is an example. We also have different theories and implementations, some even more algebraically sound like Darcs and Pijul.
But GitHub the Platform is another story, given that they struggled to achieve 90% availability these days.
Another important aspect is that, without an external library like `wabt`, I can't just open Notepad, write some inline WASM/WAT in HTML and preview it in a browser, in the same way that HTML+CSS+JS works. Having to obtain a full working toolchain is not very friendly for quick prototyping and demonstrative needs.
The same limitation exists with "non-web" assembly. It turns out that having languages that compile to assembly makes a lot of sense for almost every real-world use case than writing it by hand.
WebAssembly is a compiler target, not a human-authored language. There is exactly one audience of people for writing wat by hand: spec and tutorial authors and readers. Anyone actually developing an application they want to use will use a compiler to produce WebAssembly. Prove me wrong and write Roller Coaster Tycoon in raw wasm if you want, but having written and maintained wasm specs and toolchains for nearly a decade, I will never write any wat outside of a spec or tutorial.
There is exactly one case where I'd like to write "raw wat" (and for that matter "raw wasm bytecode"): I'd love to do something like the "bootstrappable builds" project for wasm, starting with a simple wat-to-bytecode parser/translator written in raw bytecode, then some tools wirtten in raw wat for bootstrapping into other languages. :)
If all the app need is to upload a photo of PCB, <input type="file"> is more than sufficient. It's been baseline years ago.
For download, it can download from a blob URI. This is not an uncommon practice.
If (not verified since I'm using Firefox) it claims that "Gerber files are composed of many individual files so that those two don't suffice" and the app does involve Gerber processing, it could have been solved by introducing a zip library.
"Gerbers" are indeed several individual files -- there's one for each layer of the PCB, such as front copper, front solder mask, front silkscreen, back copper, back solder mask, etc, etc.
A zip library is precisely how other webapps that load or output Gerbers handle it.
reply