nhanb

>And for the UI I just pipe everything to the system's "less" command.

I never thought of that as an option. Thanks for the tip haha.

By "it" do you mean landlock or fil-c? Also elaboration would be nice.

I read somewhere that Hacker News should have been named Startup News, and sometimes interactions like the one upthread reminds me of that. I'm not saying it's wrong - if you're good at something don't do it for free and all that - but it's kinda sad that in-depth discussions on public forums are getting harder and harder to find these days.

That's gross misrepresentation. He wrote _lots_ of helpful educational articles on zig that painted it in a good light. I would know because I learned a great deal from his posts when I started with zig. Recently he posted a grand total of 2 articles expressing his confusion/skepticism of new zig features, that's it.

Idk, Andrew's comment seems fair enough to me.

I once explored doing just that: https://github.com/nhanb/boast

However I never got around to finishing it, mainly because I couldn't decide on where to stop: should I also generate commits from all non-master branches etc.

I flirted with the idea of a browser-side repo viewer too, but re-implementing git packfile parsing in js didn't seem like something I'd want to spend my time on, so I moved on. Glad to see others pondering the same thing though.

FWIW he _is_ an example already: https://rsync.net/

A static site generator: https://hi.imnhan.com/s4g/

Not the most original of ideas, but I was really sold on djot [1] and wanted something less fussy than pelican [2], so it just happened.

[1] https://djot.net/

[2] https://getpelican.com/

Husky (android app) does support multi-account. I'm using it right now. I imagine there should be something equivalent for ios. It's not rocket science.

> I didn't get a larger monitor just so that everything can waste more space with giant text.

That's what the outer min() is for: it makes sure the font size caps out at 1.3em which usually translates to 16 x 1.3 = 20.8px, which is well within the recommended size range for prose anyway.

What that whole snippet does boils down to exactly what they said in the article:

> The main global stylesheet uses the browser default font size, smoothly scaled up to 130% on higher-resolution displays as the baseline for the body text of the whole document.

On a low-dpi screen, nothing changes. On a high-dpi one, if you haven't set your browser text size to something larger, this snippet saves you from tiny unreadable text. Also note that ctrl+ and ctrl- to zoom still work just fine. It's not as dramatic a change as the sibling comment said. You can try it out on their site to see for yourself.

You misread. They said the opposite:

> Websites in the, (late), 1990s were characterised by many things, but a typical list might include:

> - Serif fonts

I would only use this kind of thing on the root element, then size all other elements relative to the root element e.g. `h1 { font-size: 1.5rem; }`. It's more manageable that way IMHO.

Thanks for the tip on `clamp()` by the way, TIL.

I've always liked ExoticSilicon's design, but not until this post did I realize their smart bit of CSS for default font size:

  font-size: min(max(1em, 1.3vw), 1.3em);

Which explains why it looks just right on my high-DPI Chromebook even though I haven't configured a big enough default font size for the browser.

This is going to be the default font-size for all of my websites now (preceded by a fallback for maximum compatibility of course).

Yeah that's the one!

Not GP but one disadvantage of updating one huge file is it's harder to do efficient incremental backups. Theoretically it can still be done if your backup software supports e.g. content-defined chunking (there was a recent HN thread about Google's rsync-with-fastcdc tool). If you choose to store your assets as separate files instead though, you can trivially have incremental backups using off-the-shelf software like plain old rsync [1].

[1]: https://www.cyberciti.biz/faq/linux-unix-apple-osx-bsd-rsync...

I honestly didn't know about that. TIL, thanks!

More languages should do this tbh.

> Or do you mean that your implementation of fs.FS generates the content on-demand, when net/http serves it?

It's closer to this. The actual content was already written to an sqlite db, and my read-only FS allows reading that data back out but as a filesystem.

The admittedly not that interesting (and probably bad - I'm new to Go) code is here[1], and this "BlogFS" is used in 2 places:

- During "export" where it generates the static site. "Folder A" is my FS and "Folder B" is the destination i.e. an actual folder on the real filesystem.

- In a preview server that just serves "Folder A" directly.

[1]: https://git.sr.ht/~nhanb/bloghead/tree/40b70cadb01c14f1e3bf5...

Go's io/fs[0] design is one of the more successful ideas inspired by Plan 9 imho. If we can't have a 9p-centric OS, the next best thing is a 9p-like interface in a language's standard library.

For example, I have been developing a static site generator where I implement the output folder as an fs.FS[1]. The output generating code is now a simple function that copies from folder A to folder B, without even knowing that A is a virtual filesystem. Now how do I implement a preview server? Simply pass said filesystem to the standard library's http.FileServer. Done. (okay you actually have to pass it through the http.FS() adapter, but that's only because http.FileServer predates io/fs)

Of course this kind of abstraction can be done in any language, but Go explicitly specifies this interface, which can already be used by multiple utilities in the standard library (e.g. http.FileServer, go:embed). This nudges people to the same interoperable interface, and I'm all for it.

[0]: https://www.youtube.com/watch?v=yx7lmuwUNv8 [1]: https://pkg.go.dev/io/fs#FS

Could you share your current phone model and OS?

For python we've been using poetry[1] at work. Dep resolution is a bit slow but otherwise it works well enough, definitely a saner choice than pulling in a completely different stack just for one tool.

[1]: https://poetry.eustace.io/

cttet probably meant this: https://github.com/mdgriffith/elm-ui

That's in extremely bad taste.

As a web developer, I use VMs to have a completely isolated and reproducible development environment for each project. Vagrant [1] is a popular tool to achieve this, so take a look if you're interested :)

[1]: https://www.vagrantup.com/

The github repo description says "Deprecated!" [1]

Seems like there's not much activity lately either [2]

[1]: https://github.com/appjs/appjs [2]: https://github.com/appjs/appjs/commits/master

For those interested, someone has been maintaining a list of such acqui-hires:

http://ourincrediblejourney.tumblr.com/

(I already posted this reply on his blog, but seems like it has been deleted along with a bunch of other disagreeing comments there)

What if you want to add a new element at the top? And even when you need to add it at the end, if you use a decent editor, it won't make a difference. For example, with vim:

(Place cursor on last element) A,<cr>myNewElement

As opposed to left comma style: o,<space>myNewElement

Only 3 extra keysrokes for both cases. (<cr> is the Enter key, by the way)

I can't believe this kind of post could make it to the front page of Hacker News.