Marvin Krause

Talk about freelance, business. Posting writings about everything interesting at

[Marvin Krause @mkrauseorg]

Wer hat seinem Grok Bot einen Obsidian Vault gegeben und was ist das beste Setup?

[Marvin Krause @mkrauseorg]

Vielleicht sollte ich einfach auf Deutsch und Englisch posten, je nachdem wonach mir gerade ist. Die automatische Übersetzung per Grok sollte ja sowieso in beide Richtungen funktionieren, oder nicht?

[Marvin Krause @mkrauseorg]

Habe mir gerade die neue zusammengeführte X Subscription genehmigt.

Ab jetzt ist das aufbrauchen vom Grok Bot Kontingent mein Produktivitätsmaßstab.

Immer schön die AI Mitarbeiter beschäftigen.

[Marvin Krause @mkrauseorg]

Just spotted a new call button in the menu! How cool is that? X is really becoming central for my productivity. Grok Bot and Cursor have the biggest impact of course.
How long till I can potentially replace Google Workspace?

[Zach Daniel @ZachSDaniel1]

In programming, "speed" is not so simple to measure. There are a few measures you look at:

Concurrency: The number of things your system can handle at once.

Throughput: The actual number of requests served per second in real world conditions.

Latency: How long it takes for any one request under real world conditions to complete. This includes queueing delay.

Queueing Delay: How long a request has to wait at the front door before your system even starts processing it.

You typically are playing a balancing act between maximizing throughput and minimizing latency on any single server, while increasing number of servers (capacity) to account for actual load.

A system under load does not behave the same as a system with spare capacity. Raw speed doesn't save you under contention, because "just do the thing as fast as it can possibly be done" is just insufficient.

Instead, you have to write your code in such a way that any one given thing can "yield" to other things. If you don't, the requests you're working on finish quickly, but once all of your threads/processes are fully utilized, you have no way to handle more load without introducing queueing (which eventually becomes failures/timeouts) on callers.

This brings us to queueing delay. When the system is processing all of the data that it can, the callers have to all just sit there and either wait, retry or fail. If your system were able to accept more concurrent work, you can lower this queuing delay under heavy load. If you can't do that, you end up trading away too much of your goodput (requests that actually succeed within their deadline) in exchange for consistently low latency for the operations that you do handle.

When building systems at scale, the general guiding light is keeping the queue delay low, and keeping goodput as high as possible.

To do this, you accept as much work as the internal system can track (increasing memory usage typically), allowing latency to go up, in order to accept more concurrent traffic internally. You still need backpressure and load shedding, since no scheduler saves you from arrival rates that permanently exceed what you can serve, but within those bounds you keep goodput maximized.

For this to actually work, your internal schedulers need to be able to do something called "preemption". This is where any given operation cannot take an entire CPU core for longer than some given period of time, or for some amount of operations. A "preemptive scheduler" balances work fairly across all of the operations that are asking for CPU cycles. (Work stealing, where idle cores pull queued work from busy ones, helps too, but plenty of cooperative runtimes have that. Preemption is the key part.)

The BEAM is a powerhouse for this. It preempts processes by counting "reductions," so no process can hog a scheduler. Immutability and share-nothing processes make that preemption cheap and harmless: a process is never paused while holding a lock someone else needs, and every process has its own heap and garbage collector, so there are no global stop-the-world pauses. This allows BEAM applications to achieve maximal goodput, with very low failures due to queue delay, while spreading latency across all work fairly.

Without that preemption, you would see a huge spread among the latency of your system. i.e some requests happening practically immediately, while other requests take pathologically large amounts of time to complete.

I get that people want programming language not to matter these days, but at a very minimum you cannot escape the limitations of your runtime. The BEAM's runtime is built for operating at scale, and will always be smoked on benchmarks for tight loop operations where there is no resource contention.

#ElixirLang

[José Valim @josevalim]

What frustrates me the most is the lack of curiosity.

People saw the numbers they wanted to see and ran with the story. They didn’t ask about the process. They didn’t question the results. They didn’t explore the code. They didn’t look at the history.

You could have even asked a coding agent to do an initial investigation.

There has never been a better time to be curious, dig deeper, learn... but this is what we’ve got now.

Oh well.

[Marvin Krause @mkrauseorg]

Rebranding AI to SI could be the move to escape the strange regulation jungle that the EU AI Act and data protection laws have become.

Just by not throwing LLMs and the rest of the very broad machine learning into one bucket.

Paper categories love this.

[Marvin Krause @mkrauseorg]

So, it's super intelligence now?

[Marvin Krause @mkrauseorg]

They are absolutely not. Most people still don't know that AI exists, that you can chat with it and don't get me started on them finding their personal use cases themselves.

Average AI courses consist of a few LinkedIn guru basic prompts and data protection and processing warnings. They think they're informed if they know that uploading customer data is bad because of GDPR.

Finding use cases is hard when you don't know what's possible because the individual technical ceiling for most average people is barely handling excel.

[Marvin Krause @mkrauseorg]

Would be a blizz to have X Money in Europe / Germany as another dependable neo bank and getting things set up easily

Paying 50 euro / month for a business account is a relict

Germany has to do everything to make entrepreneurship easy and joyful

[Marvin Krause @mkrauseorg]

Telling grok to swap into Elon mode makes the answers more to my liking. Way more actionable. Especially when it's about law and bureaucracy stuff.

Cuts out much of the repeating warnings and mentions that everything is dangerous and requires a lawyer or consultant.

[Marvin Krause @mkrauseorg]

Paper: https://t.co/1Mrquy06VW

[Marvin Krause @mkrauseorg]

The current research on migraine says that it's a chain reaction caused by energy deficit.

Either by supply being to low or demand too high.

The reason is migraine brains require more energy for sensory and signal processing.

[Marvin Krause @mkrauseorg]

@libertas_HH Hab letztens einen Wohnwagen auf der Autobahn gesehen, der hinten einen "Wir vergeuden das Erbe unserer Kinder" Sticker drauf hatte.

Da hat's wohl jemand als Programm genommen

[Marvin Krause @mkrauseorg]

DHH promoting now what Elon predicted before

Speech and logic will be compiled to CPU instructions

[DHH @dhh]

Rust is a good prompt compilation target for the moment, but so is C++. And soon assembler. Then microcode. Myopic to think we're going to stop the agentic drill bit until it reaches computing bedrock.

[きよごん @fishing_kiyogon]

税務署「この100万円相当のUSDC、誰に送ったんですか？」
オレ「0x7A3F91B2C8D4E6F0123456789ABCDEF0 から 0xB82D47A1E903CF56123456789ABCDEF0 へ移動しています」

税務署「誰に送ったの？」
オレ「わたしです」

税務署「なんで自分に送ったの？」
オレ「ウォレットを変更するためです」

税務署「それは分かってる。なんで変えたの？」
オレ「管理場所を変更したかったためです」

税務署「なんで変更したかったの？」
オレ「念のためです」

税務署「念のためとは？」
オレ「秘密鍵の管理を分散して、セキュリティリ��クを下げるためです」

税務署「そういうのを聞きたいわけじゃない」
オレ「では何を聞きたいのでしょうか」

税務署「なんで自分に送ったの？」
オレ「自分のお金を自分の別のウォレットに移したかったからです」

税務署「なんでさっきと回答が違うの？」
オレ「同じことを違う粒度で説明しています」

税務署「粒度？」
オレ「もういいです。疲れました」

税務署「なんで疲れたの？」
オレ「話が長いからです」

税務署「では簡単に聞きます。取引履歴はどこにあるの？」
オレ「ブロックチェーン上にあります」

税務署「ブロックチェーンはどこにあるの？」
オレ「世界中です」

税務署「世界中のどこ？」
オレ「ノードです」

税務署「ノードはどこにあるの？」
オレ「あちこちです」

税務署「あちこちってなに？」
オレ「例えばビットコインなら世界中に多数のノードがあって、同じ台帳を保持しています」

税務署「じゃああなたの100万円も世界中に分散してるの？」
オレ「違います」

税務署「今、分散してるって言ったよね？」
オレ「分散しているのは台帳です」

税務署「台帳に100万円あるんでしょ？」
オレ「100万円が置いてあるわけではありません」

税務署「じゃあどこに100万円があるの？」
オレ「どこにもありません」

税務署「？？？」

オレ「正確には、ブロックチェーン上の状態として、私のアドレスがその数量のUSDCを保有しているという記録があります」

税務署「何を言ってるの？」
オレ「ブロックチェーン技術の説明です」

税務署「じゃあその100万円は誰が持ってるの？」
オレ「わたしです」

税務署「どこに持ってるの？」
オレ「ウォレットです」

税務署「ウォレットはどこにあるの？」
オレ「秘密鍵なら手元にあります」

税務署「じゃあその中に100万円が入ってるの？」
オレ「入ってません」

税務署「さっきウォレットにあるって言ったよね？」
オレ「一般向けに説明するとそうなります」

税務署「私は一般向けなの？」
オレ「今のところは」

税務署「では、この送金先の住所を教えてください」
オレ「0xB82D47A1E903CF56123456789ABCDEF0 です」

税務署「住所を聞いてるんです」
オレ「はい。0xB82D47A1E903CF56123456789ABCDEF0 です」

税務署「だから、住所です」
オレ「ですから、それが住所です」

税務署「東京都とか埼玉県とか、そういう住所です」
オレ「それは私の住所です」

税務署「だから送金先の住所です」
オレ「だから0xB82D47A1E903CF56123456789ABCDEF0です」

税務署「そこには誰が住んでるの？」
オレ「誰も住んでません」

税務署「誰も住んでない住所に100万円送ったの？」
オレ「はい」

税務署「なんで？」
オレ「さっきも言いましたよね？」

[Marvin Krause @mkrauseorg]

Omarchy achieves in short time what corporate and foundation driven distros couldn't.

- A usable, flexible system used in business that may be opinionated but that's not crusted and rusted into some stale security focused release two years behind Debian stable

- It actually pulled users away from Mac into the Linux ecosystem

- It's even a bigger phenomenon when we keep in mind that tiling wm and hotkeys have the same effect on most people like garlic and sunlight have on Dracula

- Bringing the ecosystem forward instead of just allocating sponsor money

- Bringing the nerd aesthetics into offices

[DigitalOcean @digitalocean]

Omarchy's production build systems now run on DigitalOcean. 👾

We're joining @dhh's Omacom Foundation as a Founding Corporate Patron and Omarchy's agentic compute provider, donating funding, tokens, and compute credits for three years.

Build servers for packaging, agent runners for PR reviews, Droplets for QA testing. 🔗 https://t.co/5FukdZV4lL

[Marvin Krause @mkrauseorg]

What's the most cost efficient way to serve many gigs of vector embeddings?

Currently I have them in pg_vector but the database is growing too big for the vps drive.

Paying for another instance or larger drive until I get traffic on the project isn't really that attractive.

Where can I park them and serve some low frequency searches? Seems to be like S3 vector is the only sensible thing?

But I'd rather stay on postgres given my current architecture... Question after question :D

[Marvin Krause @mkrauseorg]

Just had the idea that using x402 ordinary people / small companies could easily offer high quality data via the protocol.

That could massively boost citizen and academic research!

Imagine a vast amount of high quality data repositories that don't need to be collected first!

[Marvin Krause @mkrauseorg]

Glorious times are ahead