tmzt

What about using a .well-known path and standarizing via internet draft heading towards RFC. (Assuming there's even a registry for these paths.)

The format could be a simple json file listing supported dictionary items in order grouped by the key used in the JWT json itself.

Maybe a special claim could point to the url or use "wk" as a special value to direct it to the .well-known path on the issuer?

It seems there is more than one plugin for using Rust in vscode and they don't have the same level of support LSP and RA. It could be more clear which is considered "official" from RA's point of view. Also, one of the likely candidates only gained support for RA recently, in the last couple of versions.

From the article:

> Because our code winds up running in other people’s apps we don’t use a full-fledged async runtime like tokio or async-rs since those are optimized for “use all available resources” scenarios like network servers or client applications.

Have you considered the recent alternative, smol [1]?

Do you have any plans to share source or build scripts for the glue components?

How have you been able to incorporate native functionality such as media codecs and screen capture with shared logic written in Rust?

Has Rust worked well when you also need to integrate with runtimes such as React Native or Flutter?

[1] https://github.com/stjepang/smol

It sounds like they mean running X apps on the Linux host displayed in a Windows VM.

Thanks, but I'm looking for alternatives to the ElasticSearch in that diagram.

Vector looks like a good choice to fill the index, and should be easy enough to modify to support Meili.

Are there any that fit the log searching use case, apart from loki which doesn't do full text searching?

Does that include Go? The speed of the compiler and some of the syntax suggest that it should be possible.

People are reporting receiving them (the bravehert edition with near final hardware) now in #pinephone on the pine64 discord.

The EG25 has two cores like most Android devices. One is running Qualcomm AMSS and the other a Linux kernel. The Linux side apparently converts AT into QMI messages, and provides endpoints for NMEA and other protocols.

It also uses an android bootloader and partition layout, and can support adb connections.

https://osmocom.org/projects/quectel-modems/wiki/EC25

If you go this direction in future, take a look at ofono.

There are QMI as well as AT/RIL drivers in the works.

It could probably be implemented aa a plugin for Telepathy, which already has mobile-focused UI for multiple platforms.

There are libraries like [1] that expose a Vulkan api/abi on a Metal backend.

[1] https://github.com/gfx-rs/gfx

Could Treble enable a containerized environment for OSS distributions on certified Android-shipping hardware?

I'm thinking of something using an upstream kernel with cgroups and other required options to run containers enabled, libhybris or similar for low-level drivers.

There would be a default e911-capable dialer that would provide basic phone capabilities when other containers aren't running.

The containers would share fullscreen access to a wayland socket or similar arbiter of the display device.

Users could support Android in a container, and any X or wayland-based userland.

You can use a site like https://unpkg.com/ to include files from most npm packages using a script tag.

Reading up on Loki, it seems it lacks full-text search, prefering something called 'distributed grep'.

I'm also looking at sonic, which is a new full-text search engine in rust with less overhead than Elasticsearch. It's lacking a gui focused on log search.

Could they work together somehow, maybe as an alternative backend to you distributed grep?

Sonic does not store the original content, so it could store a reference into your compressed chunk.

S3 compatible on-prem storage like minio might work for you

It's one reason to favor Go over Rust for a particular project, It's much easier to set GOOS and GOARCH and run go than to download and install a complete target with rustup assuming the target is actually available to install.

Could cranelift or similar allow rust to support multiple targets easier than llvm?

there's an interface that looks something like this (including vcpu) as part of KVM, accessed through the /dev/kvm device with ioctl's.

You can see part of it here: https://github.com/torvalds/linux/blob/master/arch/x86/inclu...

Anybody know if Paint from 3.1 is available like this, the one with the color replacer tool?

The ! indicates the object you are "calling" is a macro, which essentially replaces that call with the equivalent syntax which is produced by applying the macro.

In addition to the older hygenic macros (which have their own syntax to define them), Rust also supports proc_macros, which are actually code that is executed by the compiler and can preprocess a struct or function.

For more information, see the Rust Book (second edition) section on macros:

https://doc.rust-lang.org/book/second-edition/appendix-04-ma...

Since the parent mentioned installing using a package manager, could it be default in that case as well as in the `cargo install` case where cargo essentially controls the binary?

If not default, could it be more easily chosen with a shorter option?

Is a rust heap/runtime packaged for distros like Debian which have packaged binaries of some crates?

Note, I'm not in favor of making dynamic default for `cargo build`.

Maybe a Flutter port would make sense here?

The shell might be the least neccessary to mechanically port as it could be easily implemented in the target language and probably doesn't change that much.

The core is where the real compatibility issues lie and where it makes the most sense to translate, as well as where the core vulnerabilities that can be remotely exploited lie.

Rust has a complete #nostd mode where most of it's ergonomics are still usable without any runtime. It also supports pluggable allocators, as well as replacing most of the builtin functionality of other language components (lang items).

It's story around panic and debug handling is also improving, including cutting out formatting code for things like println! and debug! when targetting embedded platforms.

Thanks, you inspired me to take a look at Google Pagespeed as well as shrink the images further.

I personally can't wait to see The Boring News.

Working on that, thanks for the feedback.

What about grpc which requires additional trailers but is still http2?

Is the issue with a length limit on data: uri's? something with the CSP?

Will there be some kind of session storage or is it completly stateless?

Is WASM support in the cards? This would be awesome for isymtope.org but the engine is in Rust.

I think you just launched the next serverless resolution ;)