turtledragonfly

I think there is a class of programs where globals are not so terrible. In particular, one-shot programs that do a task and then exit (like `ls`, `cp`, etc).

You may also notice that some of these utilities will allocate memory, then never free it. They just let the OS handle that on program shutdown. That is also generally not recommended in arbitrary code. But again, it's fine for a one-and-done sort of program.

For these cases, the whole program is essentially one function call, and the global namespace is essentially the "body" of that function (hand waving a bit).

It's all a bit subjective, of course (:

The Lua source code is also a masterclass in C, I recommend it to anyone learning that language. It's big enough to be an involved implementation, but small and focused and well-organized enough to (at least roughly) understand what's going on at the various layers. It's a very solidly-written mass of portable C, with only minor exceptions.

I'm sure you know, but for others reading: even on the same architecture, there is more to floating point determinism than just running the same "x = a + b" code on each system. There's also the state of the FPU (eg: rounding modes) that can affect results.

On older versions of DirectX (maybe even in some modern Windows APIs?) there were cases where it would internally change the FPU mode, causing chaos for callers trying to use floats deterministically[1].

[1] https://gafferongames.com/post/floating_point_determinism/ (see the Elijah quote, especially)

Partly what I mentioned above: a higher rate of development "churn" — incorporating new systems or technology before it's well-baked or well-integrated with the rest of the OS, only to be replaced a few years later with something else. The kerfuffle over WireGuard in FreeBSD 13 (ultimately backing it out of that release) is, I think, one recent-ish example of the FreeBSD devs taking a stance to demand a certain quality bar for such things.

Another aspect for me is documentation. I've been disheartened recently by how some faster-paced changes to the FreeBSD ports system aren't well-documented, so 'man ports' and the handbook are a bit out-of-sync with reality. Being able to read the handbook and the manpages to get an accurate education on the OS has always felt right to me, and the Linux ecosystem doesn't do it nearly as well, I feel.

I think generally it's a cathedral-vs-bazaar sort of difference. I hope FreeBSD stays more cathedral-y than Linux.

> FreeBSD was perfectly fine but it didn't do anything I needed that Linux didn't already do.

I broadly agree, even as a FreeBSD fan myself; things have converged a lot over the decades. But still, I generally feel that while you can get the same work done in both, FreeBSD does things better (and/or cleaner, more elegant, etc) in many cases.

The overall feeling of system cohesion makes me happier to use it, from small things like Ctrl-T producing meaningful output for all the base OS tools, to larger and more amorphous things like having greater confidence core systems won't change too quickly over time (eg: FreeBSD's relatively stable sound support, versus Linux's alsa/pulse/pipewire/..., similar for event APIs, and more).

Though I totally feel your pain about latest-and-greatest hardware driver support. Has gotten better since the '90s, but that gap will probably always be there due to the different development philosophies.

I hope FreeBSD never gets too "Linux-y"; it occupies it's own nice spot in the spectrum of available options.

Why must you attack me personally like this?! ⠀(:

This is super cool, and I like the no-nonsense presentation.

I'm curious to know where he takes the gameplay. He mentions it being digging-focused, and also mentions the digging/terrain deformation aspects in other games like No Man's Sky are relatively low-fidelity. I wonder what a "high-fidelity digging game" looks like (:

Aside, if I may self-plug: I wrote a small series on SDFs, for those who might be interested[1]. I'm also using them in my game engine (though it's 2D, for me).

[1]

* https://festina-lente-productions.com/articles/sdfs-1/

* https://festina-lente-productions.com/articles/sdfs-2/

* https://festina-lente-productions.com/articles/sdfs-3/

The Dreams team made a nice talk at SIGGRAPH 2015, if you want to check it out:

* Slides (good notes): https://advances.realtimerendering.com/s2015/AlexEvans_SIGGR...

* video: https://www.youtube.com/watch?v=u9KNtnCZDMI

I'm reminded of that scene from A Beautiful Mind where someone asks him if he still has his hallucinations. He looks over and sees the fake people still there, and says "Oh no, they're not gone. Maybe they'll never be." And they still would drag him into things again, but he has learned to ignore them and not get pulled in.

So it is with internal demons sometimes, I find. You learn to recognize them, rather than expunge them.

Pretty cool. I haven't dived into the details of this post, but it's a problem I've been wrangling with from time to time in my game.

Below is a series of writings on this topic that I enjoyed, by James Blinn, of "Blinn-Phong reflection" fame (and more). Not state-of-the-art, but an interesting read. It's just for cubics, which is what you need to solve the distance formula for quadratic bezier curves (my particular case), rather than the harder cubic curves of the linked article.

* https://courses.cs.washington.edu/courses/cse590b/13au/lectu...

* https://courses.cs.washington.edu/courses/cse590b/13au/lectu...

* https://courses.cs.washington.edu/courses/cse590b/13au/lectu...

* https://courses.cs.washington.edu/courses/cse590b/13au/lectu...

* https://courses.cs.washington.edu/courses/cse590b/13au/lectu...

From the name, I thought it was going to be about fractal dimensions[1] (:

So on that tangent ... you can measure that value for ordinary objects using the "box counting" method[2], to get a notion of objects being "1.3 D" and such.

[1]https://en.wikipedia.org/wiki/Fractal_dimension

[2]https://pages.cs.wisc.edu/~ergreen/honors_thesis/dimension.h...

This seems fairly culture-dependent, from my experience.

For instance, I've noticed a distinct difference in how sarcasm is received in the Northeast US vs the West Coast. What you described feels more Northeast-y to me (I'm sure it varies by other segments and sub-sub-cultures, too).

There's the saying: "If an Irish person calls you 'asshole,' it means they think you're a friend. If they call you 'friend' it means they think you're an asshole."

Not just for the Irish though, I don't think (:

As an aside, this "robot tentacle" paper was referenced in a recent HN story: "SpiRobs: Logarithmic Spiral-shaped Robots for Versatile Grasping Across Scales"[1]

Seems like a pretty high bang-for-the-buck for versatility and capability with only a few cables controlling it.

[1] https://arxiv.org/pdf/2303.09861

Speaking as someone who has made their own game engine for their indie game: it really depends on the game, and on the developer's personality and goals. I think you're probably right for the majority of cases, since the majority of games people want to make are reasonably well-served by general-purpose game engines.

But part of the thing that attracted me to the game I'm making is that it would be hard to make in a standard cookie-cutter way. The novelty of the systems involved is part of the appeal, both to me and (ideally) to my customers. If/when I get some of those (:

Just tossing in my own recommendation: I use Lyrion Music Server (previously Logitech Media Server (previously Slim Devices/Squeezebox))[1]

It's open-source, self-hosted, has various good plugins (eg: I have some Pandora stations I listen to, as well as my own music collection). You can synchronize music across multiple devices in your home (I just have 2).

Even though the physical devices (Squeezebox Touch, etc) are no longer sold, it's pretty easy to build one yourself with a raspberry pi.

It's one of those cases where a company created something great, and strongly-open-sourced it enough that the project can't die even though the new owners are not giving it the love it deserves.

So, I hope to keep using it for the rest of my days (:

[1] https://lyrion.org/

Go back to /r/vxjunkies/, and take your retro-encabulator with you :Þ

> turning python to PHP.

Why stop there? Go full Perl (:

I think Python needs more quoting operators, too. Maybe qq{} qq() q// ...

[I say this as someone who actually likes Perl and chuckles from afar at such Python developments. May you get there one day!]

Do you use ZFS for root, on Debian? (enabling "boot environments")

I've recently switched my FreeBSD setups to use that scheme, and it's been nice. Would be interested to hear if it's similarly straightforward on Debian (my second-favorite OS :)

Obviously requires support in the bootcode; I'm not sure of the state of that for Linux.

It was a crash bug, but I'm not really sure the details (and it has been some years...). Even at the time, I wasn't personally involved in it, just heard about it through the grapevine.

But yes, my understanding is it was quite expensive and the publisher was none too pleased (:

Video games used to be like this. Once you built the "gold master" CD/DVD/cartridge/etc it was out of your hands. It was kinda nice to have a concrete end to the project [1]. Nowadays, everything is on the 'net, you can send patches, dlc, etc and the notion of a game being "done" is murky.

[1] There was, however, one game I worked on where they had to pull the boxes from stores (delivered, but not yet for sale) and swap out the disk in order to release a critical fix that was discovered too late. Fun times (:

I do this sort of "raw material" note-taking on a piece of paper because a lot of my thoughts I feel most able to express with diagrams, shapes, lines-between-things, visual patterns, etc. I haven't found a good digital equivalent.

It's fascinating to see other people's systems, since it gives a glimpse into the different sorts of minds out there. Doing everything with text feels like a straitjacket to me, but likely the same would be true for other people if they did it my way.

Does anyone else feel like the "thoughts == words" crowd get too much press, sometimes?

> Games are for playing, code is an unfortunate side effect

Boo, hiss!

(I respect your opinion, though :)

That's a good library (I use it myself), but just to be clear for anyone reading: that's a standalone fixed-point implementation, not a compiler-provided one like the article discusses (via -ffixed-point).

This is fixed now, for the record (:

And yet, he says "... I didn’t care about fooling the diners."

I agree with you, that the diner seeing what they are about to eat is an important part of the experience. But Chang seems to be saying that even that is not the point! The results (including diner experience, and the honesty of that experience) don't matter. It is purely about instilling and maintaining a culture.

I don't really buy it, myself. Should they also forge all their knives from iron ore, the long slow way, before being allowed to use them in the kitchen? As other people commented, I think this is more about weaving a story and casting a glamour than anything else.

Author here; thanks for this info! I'll add some references to this stuff in the article.

Author here — I apologize for that; it's on my short list of things to fix.

I actually hadn't fully understood that the "Ctrl+" zoom in desktop browsers shrinks the viewport rather than doing an actual zoom (unlike pinch-to-zoom on a touch device) until I had put the media queries in place — whoops.

----

As an aside, you or another might be interested: you can configure Firefox to do a "pinch-zoom" style zoom when you do "Ctrl+scrollwheel" on the mouse:

Short version: set "mousewheel.with_control.action = 5" in about:config.

Longer discussion: https://www.tenforums.com/browsers-email/204202-firefox-enab...

That way, you can always zoom with confidence that a site won't rejigger its layout as a result.

(but obviously I'll update my rules to make the default behavior better, too)

And it's crazy to think that during that decade, GPU functionality was changing pretty rapidly. So, you really are aiming for future GPUs that don't exist yet as you develop the tech.

Of course, the trajectory of GPU advancements is somewhat predictable, and settled down a little bit relative to the not-too-distant past. Perhaps some luck involved, too (:

I think the SIGGRAPH talk you referred to is: "A Deep Dive into Nanite Virtualized Geometry" (https://www.youtube.com/watch?v=eviSykqSUUw)

There's also this short high-level intro (2.5 min) that I thought was decent: "What is virtualized micropolygon geometry? An explainer on Nanite" (https://www.youtube.com/watch?v=-50MJf7hyOw)

Excellent list; I like the pragmatic and down-to-earth explanations. No buzzwords, no "microservices" (:

I'd say that a good amount of this advice also applies to one-box systems. There can be lots of kinda/sorta distributed sub-components to consider — could be IPC between programs, or even coordination amongst threads in one process. Even the notion of unified memory on one box is a bit of a lie, but at least the hardware can provide some better guarantees than you get in "real" distributed cases.

A lot of the advice where they compare "distributed" to "single-machine" could pretty well apply to "multi-threaded" vs "single-threaded," too.

And on another axis, once you make a program and give it to various people to run, it becomes sort of a "distributed" situation, too — now you have to worry about different versions of that program existing in the wild, compatibility between them and upgrade issues, etc. So things like feature flags, mentioned in the article, can be relevant there, as well.

It's perhaps more of a spectrum of distributedness: from single-CPU to multi-CPU, to multi-computer-tightly-connected, to multi-computer-globally-distributed, with various points in between. And multiple dimensions.