Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zeroserve: A zero-config web server you can script with eBPF

su3.io

Post reply on HN
Print view View original

31–40 of 69 posts

Re: Zeroserve: A zero-config web server you can script with eBPF

#31

Post by simonw »

ai_fry_ur_brain wrote: post #13
jarym wrote: post #6

I love seeing stuff like this that would probably not exist if not for LLMs making exploring these kinds of ideas relatively cheap and quick to do. My takeaway from this though is that nginx is pretty impressive on its own. Also this stuck out: It's meant to be an alternative to nginx and Caddy, and the design bet is about configuration. Those servers give you a declarative config language - location blocks, rewrite…

Why are you so eager to credit LLMS.. Just because they wrote the article with the help of an LLM doesnt mean they're out here having LLMs do the experiments for them.

The commit history shows plenty of coding agent involvement: https://github.com/losfair/zeroserve/commits/main/

Re: Zeroserve: A zero-config web server you can script with eBPF

#33

Post by shevy-java »

bflesch wrote: post #2

Looks good, nice features. But somehow the spark does not ignite on my side because it feels too artificial. I don't know if the metrics are faked, if the convenience functions actually work, if there is any proper hardening. I can accept if stuff is vibe coded and has autogenerated README. But even the announcement blogpost is AI-generated, and I personally have zero data points to see if your understanding of softw…

> It's a weird world, if this would've been announced without any AI disclaimers some years earlier I would've eaten it up without a doubt. But right now if I see a fancy README with several good-looking command line parameters I immediately wonder if the README is hallucinated and the command line parameters actually exist.

Yeah, that is unfortunate. Recently there was this ffmpeg-wasm project. I tested it. It worked. But it was vibe-coded AI. I can't stand AI. Even if things work.

I decided to stay in the oldschool era as much as possible. Clever people publish software. Clever people maintain software. They don't need AI. That's my niche.

We may die out but I still prefer that. (Oh, and only if these clever people write documentation. Many clever people hate writing documentation. I decided a long time ago that if software comes without documentation, it is not worth my time, no matter how great that documentation is. This refers mostly to on-the-application side; I only rarely looked at the Linux documentation, but others stated that it is not too terrible either, so who knows.)

Re: Zeroserve: A zero-config web server you can script with eBPF

#36

Post by rpdillon »

losfair wrote: post #4
bflesch wrote: post #2

Looks good, nice features. But somehow the spark does not ignite on my side because it feels too artificial. I don't know if the metrics are faked, if the convenience functions actually work, if there is any proper hardening. I can accept if stuff is vibe coded and has autogenerated README. But even the announcement blogpost is AI-generated, and I personally have zero data points to see if your understanding of softw…

Hi, author here - a few critical pieces of this, like async-ebpf, were written long before those coding agents were released. I use AI assistance a lot when creating zeroserve itself, but I manually check AI output and take responsibility for it :)

I'm of the school of thought that if a practicing/retired software engineer (i.e. someone I reasonably believe has experience writing software for "production") wrote it, I've got to show it's trash, rather than assume it's trash. "Innocent until proven guilty" and all that. But I'm in the rather luxurious position of mostly using open source, rather than maintaining it, so I understand that others come down differently on this topic.

FWIW, I like the writeup and concept behind this. Very close to some passions of mine (like serving a website from a single-file archive).

Re: Zeroserve: A zero-config web server you can script with eBPF

#38

Post by rashkov »

Terretta wrote: post #19
rashkov wrote: post #16

Why a tarball?

Well, according to first paragraph of the section titled "One tarball, served in place": The whole site is a single tar file. zeroserve indexes it on load - building a path -> byte-range map - and then serves files by issuing byte-range reads against the tarball itself. Nothing is ever unpacked to disk. The site lives entirely in that one file, so there's no document root for a stray location rule to expose, and a de…

Thanks, I missed that during my read of it

Re: Zeroserve: A zero-config web server you can script with eBPF

#39

Post by rpdillon »

cwillu wrote: post #32
rashkov wrote: post #16

Why a tarball?

It's a simple format easily suitable for accessing resources by byte ranges, that everyone has tooling for, and which _doesn't_ compress things.

It would be interesting to extend it to zip, which is what redbean/greenbean use to serve static assets.

Back in school, I worked on a project called Velox, with a partner - the idea was to take a bz2-compressed dump of the giant XML export of wikipedia, and write a program to serve that copy of wikipedia from disk (this was in 2008-2010? in my master's program, so before Kiwix and the amazing zim dumps they produce). My partner worked on the UI and indexing, and I was focusing on how to parse the bz2 compression format to locate article boundaries in the (giant) XML dump that Wikipedia provides. I ended up putting a lot of time into it because it was a bunch of fun.

Writing this just sent me back to the presentation I made. The slide I wrote back then said:

> Significant original work went into creation of archive access. The Apache BZip2 library that is part of Ant was used as a basis for archive access.

> Modified to support random access to a given byte/bit offset pair within the compressed data stream (BZip2 is not a byte-aligned format) > Extended to index all BZip2 block positions, allowing Java-based pseudo-random access to BZip2 compressed data > Extended to map article IDs to block numbers for constant-time article retrieval, even in BZip2 archives exceeding 5GB in size

> Current article retrieval times are ~2 seconds.

This is back when the archive was ~7GB IIRC. My Kiwix dumps today are ~120GB, but that includes images.

This is the link to the presentation in Google Slides that we wrote back in 2008 or so. The version history shows 2013, but I think some kind of import/conversion happened around that time.

https://docs.google.com/presentation/d/e/2PACX-1vTfrxEqvHbd0...

Post reply on HN