zserge

Same, and I thought it's a clever play on words on the classic "Attention is all you need" - https://arxiv.org/abs/1706.03762 - which led us to what we have now

That's impressive! Seems like we're back to ELIZA again, only with a more versatile dataset format and better NLP/search

Nice! A while ago I was doing something similar - https://habit.zserge.com/ - turns our printed habit trackers serve way better as motivators or reminders than phone apps.

I'm building my own - https://git.zserge.com/fierj - and for a few weeks it's hosting itself. Still working on patches workflow and CI, but it's quite usable already. I try to make it "minimally federated" - only threads (issues/discussions etc) are federated via ActivityPub, for PR there is old-school patches workflow, for CI just chroot and a shell script. A lightweight personal git forge in ~4KLOC. Can't say everyone should use it and can't recomment it, but building a personal forge is very realistic. Or you can run cgit as a frontend to your git remote on a server.

    Location: Munich, Germany
    Remote: Yes
    Willing to relocate: No
    Technologies: Fullstack, distributed systems, embedded (C/Zig, bit of Rust), ML (torch, tinygrad, edgeAI/tinyML)
    CV: https://zserge.com/cv.pdf
    Email: hello <at> zserge <dot> com

I'm a generalist with 15+ years of experience, usually on a pragmatic and minimalist side of tech. Looking for contractor work, preferably fully remote, but open to other options, too.

I suppose one of a few examples when a picture is totally not worth a thousand words, if a picture is made by me

I guess I miscommunicated it. I meant I'd call everything a tensor but for some smaller dimensions we have specific names. Of course, 1D can still be a tensor and so is 6D or nD.

I wish we used something else but Python as the default ML language, so that some advanced type system would work for us to ensure tensor shapes and compatibility.

Not in a general mathematical sense, of course. Rather carthesian tensors. Seems like for most libraries it's `numpy.ndarray`: https://docs.tinygrad.org/tensor/ or https://docs.pytorch.org/docs/main/tensors.html

Was doing a similar thing for plain HTML zines: https://github.com/zserge/zine - write each page as html, render as page previews in browser and as a folded zine when printed

Reminds me of a good old arduino shell, Bitlash - https://github.com/billroy/bitlash/wiki/commands

A slightly larger implementation at the end of the post does that to some extent - https://github.com/zserge/kalk (CSV import export, Excel-like "locking" of rows/columns like $A$1). If there's a need for such a project - I'm happy to add ODF or XLSX, more compatibility with Excel formulas etc. I'm not sure about Vi keybindings, I personally find spreadsheets easier to use in a non-modal manner.

It's a common CPU vs RAM decision to make. Dependency graph consumes memory, while recalculating everything for a number of iterations could happen on stack one formula at a time in a loop. On 6502 it mattered. On modern CPUs, even with RAM crisis I'm sure for 99.9% of spreadsheets any options is good enough. Say, you have 10K rows and 100 columns - it's 1M calculations to make.

https://zserge.com - little toy projects and stories on various software topics with minimalist aftertaste, not to be ever used in production or taken seriously

A little computer vision library for embedded systems, by magnitudes smaller than OpenCV, but still practical enough to do feature tracking or cascade detections. Works well on ESP32 and cheap ARMs with low-resolution grayscale cameras.

https://github.com/zserge/grayskull

I think that's how it all started: https://github.com/rust-lang/rustlings

You might be right, but the only place where regexps are applied in code is for validating resource text fields (which is optional). Those regexps are defined in read-only schemas by the developer (if needed). Schemas are immutable. There seems to be absolutely no connection between the data transmitted over the API (i.e. what user can inject) and regexps. I'm not dismissing the idea that there might be plenty of other possible vulnerabilities in other areas of this toy project.

In hindsight, JSONL would have been much easier to deal with as a developer. But I still don't regret picking CSV -- DB interface is pluggable (so one can use JSONL if needed), and I deliberately wanted to have different formats for data storage (models) and data transfer objects (DTOs) in the API layer, just like with real databases. I agree, CSV is very limited and fragile, but it made data conversion/validation part more explicit.

Like others have guessed, I limited myself to what Go stdlib offers. Since it's a personal/educational project -- I only wanted to play around with this sort of architecture (similar to k8s apiserver and various popular BaaSes). It was never meant to run outside of my localhost, so password security or choice of the database was never a concern -- whatever is in stdlib and is "good enough" would work.

I also tried to make it a bit more flexible: to use `bcrypt` one can provide their own `pennybase.HashPasswd` function. To use SQLite one can implement five methods of `pennybase.DB` interface. It's not perfect, but at the code size of 700 lines it should be possible to customise any part of it without much cognitive difficulties.

To be fair, the project is linked to the blog post I recently wrote, so it's merely a tiny personal/educational project.

I tried to experiment with an API similar to what k8s api server offers: dynamic schemas for custom resources, generated uniform REST API with well-defined RBAC rules, watch/real-time notifications, customisation of business logic with admission hooks etc.

I also attempted to make it as small as possible. So yeah, I don't try to compete with Pocketbase and others, just trying to see what it takes to build a minimally viable backend with a similar architecture.

The choice of the "database" is dictated by the very same goals. I deliberately made it an interface, better databases exist and can be plugged in with little code changes. But for starters I went with what Go stdlib offers, and CSV is easy enough to debug.

So that things like React could be distributed as a collection of hundreds of interconnected single-function tiny modules?

So, it's only Liechtenstein and Monaco being the correctly mapped European countries?

A while ago I created an even smaller typeface (2x3) but that is barely readable without memorising certain glyphs:

https://zserge.com/posts/tiny-font/

I appreciate the fact that it contains shortcuts for such words as "endeavour" (EDV), "ecclesiastic" (EC), "notwithstanding" (NWG) or "vehemence" (VMC) being a dictionary of the "basic and most frequently used words". Also, the suggested abbreviation for "sex" is "SEX".

I hike across Liechtenstein from time to time. A very light but picturesque set of trails for one day (30-50km). I usually start at the south border in a Switzerland town, cross the country up north and enter Austria.

On a much lighter category, someone "hiked" Monaco in a straight line: https://magamig.github.io/posts/crossing-an-entire-country-i...

Would it be possible to train an LLM from scratch that would speak Toki Pona? 120 word dictionary over a reduced alphabet would mean a tiny number of possible tokens and theoretically a model could be smaller than the ones used in "tiny stories" experiment (where a simplified almost childish English has been used). Maybe even a local machine would be enough to train it. I wonder if there is a large enough dataset for Toki Pona or if there is a sensible way to synthesize one? I'm no expert in LLMs or Toki Pona, though.

https://zserge.com -- minimal software, learning how things work by building them

A similar toy git in Go (but probably smaller and more limited): https://zserge.com/posts/git/

There's also https://github.com/zserge/fenster which is fairly minimal and comes with Go bindings out of the box.

The wiki page says it all, but I'll highlight - Contiki has been written by Adam Dunkels, the one who invented Protothreads (coroutines using Duff's Device), uIP, lwIP and a TCP stack that fits into a single tweet - http://dunkels.com/adam/twip.html