tmzt

Does anybody have the archive of the original ELKS site with the quote from Linus that Linux is not suitable for anything but 486 or higher or something like that?

Very nice and very inspirational for someone bootstrapping a startup.

The pages clearly defined what you are building and how to use it.

The explanation of platform fees makes sense, though it could more clear if the pricing examples are only based on those fees or are account limits to number of members or dues.

You might want to check your terms of service, they do not list a jurisdiction and have the placeholder [jurisdiction] instead.

Best of luck with it!

Not launched, but building open source components and mucroservices with a closed dashboard and overall backend.

For instance, a Git-like DAG for a config service [1] that supports history and eventually forking and merging on top of PostgreSQL. This was broken out of the larger Go codebase and is currently AGPL3 as a placeholder while I research better licenses to use.

The overall idea is the "nuts and bolts" of a small startup/SaaS app, including metrics, IAM/auth, and subscriptions via a single API and React/JS SDKs.

I hope to do a Show HN on one or both in the near future.

[1] https://github.com/tmzt/config-api

Do you have that example posted anywhere? I'm curious to see it. Also, any support for the Wifi and/or Bluetooth on Pi Pico W from Rust?

Would it be possible to support a custom URL for the local model, such as running ./server in ggml would give you?

This may be more difficult if you are pre-tokenizing the search context.

Very cool project.

Is there a clean way to share an emptyDir between sidecar(s) and main container(s)?

Looking at the logging usecase and want to be able to add a log shipper sidecar to a pod with ephemeral storage.

How are you using TipTap with Monaco instead of ProseMirror, do you have the bindings/plugins working the same way?

How does this compare to something like Milkdown using markdown as a native format?

I see you solved some of the hard problems (tables, etc.) with Yjs and CRDT in general.

Are the backend components also open source?

Could the RP2040 ROM be adapted for RISC-V creating a defacto standard for emulating features that aren't implemented by the specific RV-variant?

I'd also love to see a big-little implementation with a Linux capable RV paired (gateable) with the above M4-class RV and the state machines from the RP2040.

I had the thought years back to layer a Wayland-like surface rendering protocol over X using an HTTP UPGRADE like primitive and XIE extended event IDs.

Basically it would transform the socket to this new protocol which keeps X atoms under a binary ID prefix.

This would keep backwards compatibility, with Xorg DIX replaced with a modern server implementation.

This could be modified to a heavy client approach where direct rendering can bypass the server. Or a client can takeover chrome rendering through an extension.

Starting with this post:

https://community.home-assistant.io/t/using-gpt3-and-shorcut...

I've been trying to adapt it to an offline LLM model, probably a LLaMA-like one using the llm package for Rust, or a ggml-based C implementation like llama.c.

It could even be fine-tuned or trained to perform better and always output only the json.

This could be a good fit with open sourced tovera when that is released.

I like the idea of supporting natural language commands that feel more natural and don't have to follow a specific syntax.

It can also process general LLM requests, possibly using a third-party LLM like Bard for more up to date responses.

What's the fundamental difference between generating Terraform to a spec and "rolling out VMs and DB clusters"?

Would the same apply to a GGML port or are the architechtures too different?

Would that be feasible on something like iOS that doesn't allow third-party JIT?

Could this allow for translating WASM or emulator workloads to something that runs fast with those restrictions?

Maybe something as simple as an active RF emitter in the reflective or similar spikes added to the road surface. It wouldn't require a networked infrastructure, or complex standards. Just something capable of penetrating feet of snow or inches of dirt and grime.

The car would always have other sensors to fallback on, but this would reduce the amount of time that the DDT disengages due to inclement weather or other road hazards.

Add to this emitters in cones and possibly emergency vehicles.

I recently worked on a project using lnx.rs. Simple to setup and use and fast at the scale I was using it. Built on Tantivy with a custom fast fuzzy search feature.

If you want to go beyond meme sites and possibly detect memes in the wild, common crawl might be something to start with.

The RP2040 (Raspberry Pi Pico) has a similar feature, two programmable IO cores.

Not for distributed use, but you can interface with USB and still have real-time signal generation.

I've always wondered why the same logic doesn't apply to using a commercial BIOS. Doesn't the per-unit cost for someone like Compal add up to more than the value in using a customized Phoenix firmware? Even with UEFI the branded option is generally used.

UEFI is also ported to ARM64 and officially supported by Windows on compatible boards.

Does it allow disabling STK apps out of the box or just with modified Linux on the Quectel? Are there any details?

I've wanted to build this forever on top of coreboot. A kvm host (like firecracker), VFIO, and keyboard shortcut to send commands to the VM instead of underlying system.

This would include snapshot, switch systems, and something like snapshot and fork the running system.

Packer and other Hashicorp products support alternative VM drivers including bhyve and support for hyperkit.

The current ruby Vagrant supports plugins, but I'm not aware of bhyve or hyperkit support.

I would assume rewriting in Go means the same VM drivers as packer will be supported.

I would assume it's related to limitations in the early wake word detection hardware and software which require pretraining of the weights, which were usually hard coded into the low power edge system.

Nothing would stop a modern system from training a new wakeword in a cloud system, if enough samples were available.

Maybe something like ballistacompute.org? I can see a language agnostic distributed solution powered by async/await with type definitions constantly automatically compiled to the target language, all wrapped up in an ide with team-level versioning. Native support for event driven, streaming, and batch data with little ceremony. Throw in distributed ipfs-like storage with persistant references and eager caching and a strongly-typed graph database for good measure.

Lambda supports container images now and it works really well for letting you choose what languages and runtimes you want to support.

The next step might be standardizing activation and dispatch, possibly with knative or a common API surface over vendor libraries.

Can you think of a more efficient protocol between the modem and main cpu then the AT-based ril with constant status checks? Is there anyway to make the modem more efficient, since its cpu is just consuming power and not adding much to the functionality of the phone? Can it be a smarter gateway that only triggers a main cpu wakeup when there's something important to notify the user of, like an incoming call or sms?

Interesting. Are these channels related to length (in bases) of certain components?

What is the basis for saying the vaccine were developed "in a day" if this crucial, specific step was required?

Are there good sources with details on those steps and microfluidic chips?

This may be true, but isn't vaccine fundamentally a delivery mechanism for a custom mRNA strand?

If you build up the infrastructure you could quickly deliver a vaccine for another disease or practically any genetic therapy that could be delivered the same way. Moderna also has an advantage in that the logistics required are simpler.

It would be nice to have a #[range(a..b)] version of this that could be standardized.

Hasn't the ios equivalent moved to emulation at this point?

Kernel support is there waiting to compiled for user namespace isolated containers. It would just require an official way to launch them as a normal user.

Maybe maemo with modern ofono (derived from mer?) Would work on pinephone.

Maybe megous has a better idea, but I believe bt requires keeping the wifi radio powered as well? Is there something that could be done at the driver level to separate the power domains?

Maybe using mpd and disabling the UI when you don't need it will help. Most of the gnome players use gstreamer and trigger constant events in their UI.