rivetfasten

Colorado and a few other states have zero knowledge proof apps capable of this.

This is fantastic, except that the idea of mandatory government software only available on chosen proprietary platforms feels way worse.

If there were a way to crypto-notarize a third-party wallet token etc blah blah, then it would be interesting.

At the end of the day though, this is about protecting the powerful, not the kids.

It seems to me that plenty of privacy-preserving techniques already exist, don't require research level technology, don't take 100x the energy and time...

and average people still can't or don't use them.

I'm excited about HE, and I also think we shouldn't be confused that tangible, drastic privacy improvements are an unsolved research problem.

Also the idea of making LLMs consume even more compute is nauseating. This is still good research mind you, but the same effort put into making local LLMs run better/faster on modest hardware would have more social value.

The discussion about cpu caching challenges etc seems like it's missing the point. Wouldn't it be more likely to DMA the results to a GPU anyway?

I was under the impression they're doing a chiplet thing to get heterogenous processes for that reason.

My b&w laser from brother has been working perfectly for over 10 years. No software installation. Wifi, Ethernet, or USB. Everything I need and nothing I don't. Color would be nice but I've never seen it be worth the hassle to own.

That works fine for some crypto algorithms, but as stated in the paper not for everything.

As I understand it, this proof needs to support conditionals for example.

I use neovim on NixOS and many others do too. I don't see what one has to do with the other.

It blows my mind that Algebraic types are only just breaking into the mainstream. Someone told me Rust invented them, which is funny because Rust wasn't around in 1961!

It's very nice that SQL dbs have the same bones such that a migration between them is even reasonable for a small team.

That said I've led such a migration, and there's no such thing as "standard SQL" in real practice. You're always going to need extras or optimizations.

Rel itself looks really nice, but I have a hard time imagining trying to justify a new query language in business terms. Breaking with SQL completely doesn't seem worth it compared to simply extending or restricting the language like every engine does anyway.

Rel seems to offer more than SQL, it's just hard to assess the value.

A SQL engine whose dialect enforces unique rows and doesn't include NULL isn't even so different from standard.

Knoppix was the first Linux distro I ever tried back in the early 2000s. IIRC it was only a few hundred megs.

At the time it didn't have the overlayfs feature which often felt limiting since most directories were read only. Slax felt like a serious upgrade since you could install more packages after booting the CD.

I think Knoppix was the original live CD distro though?

Cool, I'll have to try it in the next 18 months before they turn it down.

"... the equivalent of a broadcast TV channel that only showed 7 minutes of actual TV content per hour, devoting the other 53 minutes to paid commercials and promotions ... Almost no one would watch such a channel."

QVC exists. That channel is ONLY ads.

Not to detract from the point, which seems to be "yes what this other guy said."

Thanks for the post!

Question: While you would want any official arch built natively, maybe an interim stage of emulated vm builds for wip/development/unsupported architectures would still be preferable in this case?

Comparing the tradeoffs: * Packages disabled and not built because of long build times. * Packages built and automated tests run on inaccurately emulated vms (NOT cross compiled). Users can test. It might be broken.

It's an experimental arch, maybe the build cluster could be experimental too?

I don't know the reason TextFormat was invented, but in practice it's way easier to work with TextFormat than JSON in the context of Protos.

Consider numeric types -

JSON: number aka 64-bit IEEE 754 floating point

Proto: signed and unsigned int 8, 16, 32, 64-bit, float, double

I can only imagine the carnage saved by not accidentally chopping of the top 10 bits (or something similar) of every int64 identifier when it happens to get processed by a perfectly normal, standards compliant JSON processor.

It's true that most int64 fields could be just fine with int54. It's also true that some fields actually use those bits in practice.

Also, the JSPB format references tag numbers rather than field names. It's not really readable. For TextProto it might be a log output, or a config file, or a test, which are all have ways of catching field name discrepancies (or it doesn't matter). For the primary transport layer to the browser, the field name isn't a forward compatible/safe way to reference the schema.

So oddly the engineers complaining about the multiple text formats are also saved from a fair number of bugs by being forced to use tools more suited to their specific situation.

This looks really nice! I'm excited to see it and am left with questions from perusing the site. Let me know if I missed it.

It's simple and also has an excellent choice of where to invest in powerful features. It looks like an elegant, minimal selection of things existing languages already do well, while cutting out a lot of cruft.

The site also mentions two differentiating and less established features that make it sound like more than yet another fp remix: type-based ownership and algebraic effects.

While ownership stuff is well explored by Rust and a less explicit variation by Mojo, this sounds like a meaningful innovation and deserves a good write-up! Ownership is an execution-centric idea, where fp usually tries to stay evaluation-centric (Turing v Church). It's hard to make these ideas work will together, and real progress is exciting.

I'm less familiar with algebraic effects, but it seems like a somewhat newer (in the broader consciousness) idea with a lot of variation. How does Loon approach it?

These seem like the killer features, and I'd love to see more details.

(The one technical choice I just can't agree with is multi-arity definitions. They make writing code easier and reading it harder, which is rarely or never the better choice. Teams discourage function overloading all the time for this reason.)

Thanks for sharing!

> Of course, we've been told to never accept a counter offer at your job.

Do you have a example article? I haven't encountered the advice, but I'm curious if the reasoning matches my guess.

Who reaches for a tool they forgot about?

Few organizations invest in solutions only understood by one or two individuals on their team. This is actually what prevents undergraduate cs knowledge from having an impact. It makes me sad.

Undergraduate CS isn't about the things you do most of the time. It's about enabling the occasions where the alternative is to give up and shrug, or perhaps speculate instead of evaluate.

Undergrads, read this before taking a theory of computation class: https://swtch.com/~rsc/regexp/regexp1.html

I was about to mention this too.

Compare: "import a specific lightweight library and wire together as needed" vs "write the whole app in terms of a bloated framework".

I've been out of the frontend game for a while, but what does react give you that knockout and maybe some url management logic do not?

I guess components are supposed to standardize modularity, so you can easily import some random widget?

The West Wing has such a good clip about this:

https://youtu.be/vVX-PrBRtTY?si=05KQjltJ8fVsqMDw

It's always a matter of chasing the bottleneck. It's fair to say that network isn't the bottleneck for most applications. Heuristically, if you're willing to take on the performance impacts of a GC'd language you're probably already not the target audience.

Zero copy is the important part for applications that need to saturate the NIC. For example Netflix integrated encryption into the FreeBSD kernel so they could use sendfile for zero-copy transfers from SSD (in the case of very popular titles) to a TLS stream. Otherwise they would have had two extra copies of every block of video just to encrypt it.

Note however that their actual streaming stack is very different from the application stack. The constraint isn't strictly technical: ISP colocation space is expensive, so they need to have the most juiced machines they can possibly fit in the rack to control costs.

There's an obvious appeal to accomplishing zero-copy by pushing network functionality into user space instead of application functionality into kernel space, so the DPDK evolution is natural.