k_bx

Still not clear why not just take any webassembly-friendly UI framework like https://www.egui.rs/ (btw compare how much faster it starts).

Ah, I see. Another thing I would expect normal announcement to include is the command I need to run instead of graaldb

Also, why would they do that? I mean, I understand adding more languages, I understand stopping the project. But killing Java and adding other langs? Why?

Can someone explain, do they ditch the project, or do they move it elsewhere? It's hard to understand from the announcement. I need to compile java to native binary to not have to install runtime on my servers for the small service I use.

I personally care because it’s Rust based and that means I’m likely to participate in development and feel comfortable with the tooling.

As a broader picture — it matters since the creator is System76 which sells laptops and desktops and moves towards giving a full Linux on Desktop polished experience. You really can only go so far if you are not deeply involved in the DE yourself.

p.s.: your question is very legit imo, don’t get the downvotes

Interesting to compare against ZeroFs

You just need to watch the video to get the hype: it's the specific person leading the hype, with pretty good presentation and loyal audience. At least to me it made sense once I've seen it (the hype made sense, not the distro).

This. Maybe they could actually make some infra money out of this. Make token-based free tier download, pay if you break it.

No apt repo, C#.. kinda worse than kvrocks in that sense

Yes, but why pay for it if `sudo apt install zedis` works? Many use-cases for redis growing out of memory would actually be ok if it stores old values on disk for you and keeps hot items in cache (and does compression).

Most projects need to start with something and know that they will "be good". Many will hit RAM limitations earlier than kvrocks latencies or single-threaded CPU limitations (if they will – usually author doesn't need advice). Most would benefit from "moving fast" (in terms of development).

Redis-compatible protocol guarantees that you can think about the things you've mentioned later. If project is successful – you'll find money to pay for RAM and move to pure Redis. If it's CPU-bound – you'll find multi-threaded alternatives.

So this is a pretty nice niche IMO actually.

Sorry if somewhat off-topic, but might help with getting more users. Redis is actually good enough and easy to install for most projects, but it has downside that it's "memory-only" (needs to fit in ram), and if you're in a tight container/vm – you'd better not rely on it solely.

So, there's another project – called kvrocks https://github.com/apache/kvrocks , which is for people which don't need in-memory perf of redis but would like to use its protocol and be still very performant. However, its devs never packaged a release in deb and other formats.

So, if you were to implement something similar ^ which will implement the protocol, have ability to grow on disk, and be available in distro repos (ideally) – would definitely hold a niche of many little projects which benefit from redis-like thing I've done.

I understand that it's mostly for enterprise users, but please also add ability to limit which databases can a user see and add a "write-only" access.

Or maybe I'll contribute this piece myself when I'll have time :)

p.s.: btw, I love Greptime so far, thank you for the product!

After jumping from no-embedded-knowledge to a forced situation where I needed to produce something working, I've played a bit with Rust-for-Embedded, and it has exactly this approach when working with various ports and devices (UART, clocks etc.). And oh by is this approach practical! While still very possible, it does make a large move towards compiler not letting you shoot in the foot.

I'm evaluating Greptimedb in prod and while I hate to have a needless component like OTEL-Collector in general, it serves as a read-only gate between the database and the user, so that greptime keeps listening to localhost only, and OTEL-Collector guarantees nobody will write to the database directly.

If it were to give more fine-grained control over write-only access -- would probably just write directly and let it handle the load.

Been driving my use for the last year or so, perfect as a thin wrapper around tmux (which is the same on macOS and Linux).

I'll give iTerm2 another try, has many shiny features like touchID-sudo and such, otherwise don't understand what could possibly be better in ghostty/kitty

Can you stick it into type-c of macbook air and work on a sunny outside environment?

Yes but if there's going to be something lightweight and correct-by-default I'd prefer that, mostly because I have many machines to manage and a team of people to educate. I'd like default to be good instead of wasting time and risking.

Yes but if there's going to be something lightweight and correct-by-default I'd prefer that, mostly because I have many machines to manage and a team of people to educate. I'd like default to be good instead of wasting time and risking.

Can you explain a bit more? The user passwords are inherently not strong enough so I disable all ssh via password and only use private keys (id_ed25519). If cockpit allowed me to use one I'd be ok, but if they don't – I at least want some scary auto-generated password only for cockpit, not the system user's one (which is often very weak).

While I am using cockpit every time I need to remotely manage the machines, I couldn't get it to log me in via something other than user's login/password, which are not that safe, and it listens to 0.0.0.0 by default too.

So I have to ssh into machine, start cockpit service, use it, and then stop the cockpit.socket once I finish.

Would be great to have something which has its own users/passwords (to have strong password in bitwarden) and doesn't listen to 0.0.0.0 by default. If it's also lightweight – even better!

I hope Rust Embedded will get funding. From my limited experience, Rust was such a great fit to do embedded programming, but APIs change too often and nice libraries still rely on older ones, projects like embedded_hal and their dependencies need some support/funding to keep it more mature.

What's your swappiness ?

Disabling swap on servers is de-facto standard for serious deployments.

The swap story needs a serious upgrade. I think /tmp in memory is a great idea, but I also think that particular /tmp needs a swap support (ideally with compression, ZSWAP), but not the main system.

Tried Podman. It looked quite promising, but failed me: https://github.com/containers/podman/discussions/26899

Trying Incus now

My current production systems are running Ubuntu 22.04, and there is no official images with systemd for them in Podman. So it does feel like second class citizen.

On another hand, if ubi’s work fine — that means there should be no technical limitation to keep Ubuntu working.

I’ll keep playing with Podman for now, but will switch to Incus if that will fail

It looks a bit confusing. There’s LXC, LXD and Incus. I should look for Incus, right?

Seems a bit less popular and supported, I also like that Podman has strong backing from Red Hat and potentially seamless macOS integration.

Otherwise if Podman will fail I’ll take a look at Incus.

Update: I looked at it. Overall it looks very promising on paper.

However, the bootstrapping process is so much work that I've ended up ditching it for now. I don't want to "automate the automation" yet.

Trying out podman now.

If the world is moving towards open models which are "good enough" – the main winner will be the one controlling the distribution. So if you're controlling the web browser, the editor or the OS – you are the winner.

Obviously, the risk here is very high from this perspective, since nothing guarantees anything.

I don't know what's DeltaDB, but if it will be able to show when a commit is simultaneously a refactoring and a change of code being refactored (moved into another module) – I would love to see that! At the moment if you refactor you punish the people reviewing the code, which reverses the motivation for cleaning things up.