I missed this post when it came out in December: In Defense of Blub Studies, benkuhn.net/blub

Some really excellent points:

> Blub studies is a never-ending treadmill of engineering know-how. It’s the fiddly technical details of how Git stores data, or how Postgres locking semantics [work], or why pip install failed this time.…Blub studies is more generalizable than it seems, and has its own way of compounding over time, too. That makes it a lot more useful than you’d expect

living room thermometer does the job in the fridge too, but is not happy about it

TIL: was released in 1990, barely a year after .

(I would have sworn that Zsh was at least a decade younger. But I would have been _confidently_ wrong, which is the absolute worst kind of wrong to be!)

zsh: en.wikipedia.org/wiki/Z_shell
bash: en.wikipedia.org/wiki/Bash_%28

No, , when I said "irclog", I certainly did _not_ mean "IRS login". You're getting to be as bad as Clippy ever was.

I regret my !g

two people putting more thought into this than it deserves 


> Really, in this context "known issue" is just short for "issue known by those working on the software" … So the sentence is really just equivalent to "I think this is a confirmed issue"

But it's also short for her saying "As far as I, a primary maintainer, know, this issue is known to the maintainers". I guess part of what struck me as funny is that, if she knew about it, that pretty much makes it a known issue!

I just observed the following exchange in a bug tracker:

user: *reports bug*
a maintainer: AFAIK, this is a known issue

something about that strikes me as ... circular? ...tautological? I'm not quite sure. Maybe it's that is raises the possibility of something being an unknown known issue?

Dear #Mastomind: Any guidelines on E-Ink / B&W/grayscale / low-refresh rate app design / UI/UX?

I've recently come into possession of an e-ink book reader, and am discovering the joys (seriously) and limitations (dittos) of e-ink displays and software designed for them.

I've just begun looking for any information concerning design guidance for e-ink devices, and am coming up very short. If you're aware of any such resources please respond to thread.

Boosts welcomed.

#eink #uiux #AppDesign #SoftwareDesign #Interfaces #BlackAndWhite #LowRefresh


> I'm not surprised Java/Scala perform poorly on a 'hello world' [startup time benchmark], that's indeed definitely not what they're optimized for. I'm kinda surprised at the difference between Java and Scala - I wonder if that still holds on more recent versions.

I've actually been testing startup times locally, and I get 40ms for javac 11.0.10, and 516ms for scalac 2.11.12 (and 810ms for Clojure, for comparison). I should add Scala Native, though.

Does Scala work with nailgun?

I’ve got a riddle for you. What’s the best way to move 1PB if data from one state to another over a 1gbps MPLS link? I was thinking ZFS send with compression and deduplication, but really I just need anything that reduce the bits on wire as much as possible. Any ideas?


> I’ve got a riddle for you. What’s the best way to move 1PB if data from one state to another

sneekernet, en.wikipedia.org/wiki/Sneakern /a SSD sent via FedEx will honestly probably be the fastest.

If you really need to send it over the wire, then yeah, zfs send seems as good as anything else I can think of.

But I'll boost is case anyone else has brilliant insights.


> So perhaps [a noop GC for short-lived programs is] more common than it may seem at first?

Yeah, that's my overall takeaway from the many interesting examples people have brought up in the replies!


> VMs is like that cookie container that your gramma put all the sewing stuff inside: Needles, threads and even a measuring tape.

I've never heard of storing sewing accoutrements in a cookie jar. Is that a thing and I've just never run into it?

> Containers are like CD boxes:

I enjoy how *this* (and not the part about sewing grammas) is the part of your analogy that is likely to be too dated for


> Scala Native has a 'none' GC, and I think I've heard it recommended for such short-lived programs

Very interesting, thanks! As someone who has never used Scala, I had thought of it as pretty inappropriate for short-lived programs (see, e.g.,
github.com/bdrung/startup-time )

Is that wrong? Or wrong for Scala Native? (which I'm even less familiar with, but sounds like something that'd have better startup times)



> Back in my day the only property that any attribute would take is a string.

good old stringly-typed API

Are there any programming languages/runtimes/frameworks with a "garbage collection" strategy of just never collecting any garbage? (During program execution; obviously the memory would be freed when the process exited)

It wouldn't work for _most_ use cases, but for extremely short lived programs (e.g. CLI scripts) it seems like this would be an easy way to avoid the stop-the-world costs of a GC without any memory safety risks.

Does this exist? Or am I missing some reason it'd be dumb?

Re: Your Privacy 

We care about your privacy.

Your privacy is delicious to us.

Your privacy is juicy-sweet and crunchy and wine-dark red and breathes a rich, savage musk-like scent, heavy on iron and with notes of truffle and mushroom and old, buried bones in the forest floor.

Your privacy dribbles gently down our lips as we chew, and after long, fragrant, eternities, swallow. Gulping, wolfing it down.

We would do ANYTHING to keep you handing us your precious, precious privacy.

Please click.

Show older

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.