dormando

Does anyone run these "at home" with small clusters? I've been googling unsuccessfully and this thread doesn't refer to anything.

So a non-quantized scout won't fit in a machine with 128GB of RAM (like framework or mac studio M4). Maverick is maybe a 512GB M3 Max mac studio. Is it possible (and if so what're the tradeoffs for) running like one instance of Scout on three 128GB frameworks?

Half on topic: what libs/etc did you use for the animations? Not immediately obvious from the source page.

(it's a topic I'm deeply familiar with so I don't have a comment on the content, it looks great on a skim!) - but I've been sketching animations for my own blog and not liked the last few libs I tried.

Thanks!

:'(

At some point the OBSD CVS server was something I donated. Don't think it's in this picture as I don't think it was a Dell. Never saw a picture of the thing in action actually, doh.

I avoided spending a quarter mill on F5's by deploying OpenBSD as firewalls/L4 routers but I was able to keep some of the budget... For a year there I would e-mail them every 6mo and ask what they wanted. Sad when I changed jobs and had to stop.

I just got one a few weeks back but haven't gotten to spend a ton of time with it yet. It's taking some adjustment but I'm liking it so far.

- had 1440p + 1080p monitors on stands side by side before. Now just this one on an arm (which is excellent), that I can adjust to keep my position from being static.

- not having to hold my neck angled while reading my side monitor is helpful.

- realistically there are a few "modes" of working on here. While coding it's pulled a bit closer, while in CAD or similar creative I might push it back a bit and get more of the monitor in view.

- I recline slightly so the monitor is tilted a bit which gives me a solid view of the bottom 60-70% of the monitor. The top is a bit out of range at close distance.

- For coding so far I have the middle-ish of the monitor as a 1440p code-only view. Below that are a few windows for manpages/reference/interactive debugging/repl/etc. On the top end which is normally slightly out of view I have compilation and long running test output which I glance at by moving my eyes.

I like not having to page between desktops while coding when possible. The bottom view is also large enough to hold a browser window or simulator window. Need to also try pushing it back a bit with slightly larger text and see if that's any better.

I don't intend to game on it, maybe windowed mode in the middle or something.

edit: well, also it has this mode where you can split it into two 1440p monitors on different inputs (which you can hook up to the same computer), so depending on the game I might do that as well.

client ecosystem is definitely a sore point now. I've just sort of started working on a replacement for libmemcached to hopefully cut down on the complexity... but then that's a migration and nobody wants to do that.

Pinterest should drop me a line if they're interested in sponsoring work though :)

I can say with certainty this isn't strictly true. The failures should be relatively rare; when I say relatively I mean on the level of natural node failure. If natural node failure isn't survivable without special systems to quickly replace downed nodes you don't actually have an N+1 redundancy system. Thus, the pools aren't large enough :) Or, in this case, if they really are failing this much then having them always lose their cache is a major reliability hole.

It's a subtle difference. I think many operators get used to node failures being extremely common when they don't necessarily have to be. I suspect the note on "if they come back on their own ensure they're flushed" meaning they have something unusual causing ephemeral failures. If that's just "cloud networking" there isn't much they can do but it's almost always fixable.

Now a more philosoraptor style comment: I see Mcrib is a service built to quickly detect and replace memcached's. I treat memcached in infrastructure as a very stable service. Meaning it is infrequently necessary to upgrade it, and it will generally not fail on its own. If it does it will be highly infrequent compared to services with higher churn or more complexity/dependencies. This means if they're failing often enough that you need to rapidly detect and replace them you have a more fundamental problem.

From a structural standpoint I think my technical comment can be useful. If things really are failing this much A) you should figure out why and slow that down. B) if you have a generally stable system and understand the typical rate of failure, you can add tripwires into Mcrib to avoid over-culling services and loudly raise alarms. Then C) you can improve technical reliability with redundancy/extstore/etc.

I've also seen plenty of times where folks have a dependency of a service determine if that service is usable, which I disagree with quite strongly. Consul being down on a node should trigger something to consider if the service is dead. It's important both for reliability (don't kill perfectly working things because you end up having to design around it), and for maintainability as you've now made people afraid of upgrading Consul or other co-dependent services. Other similar failures are single-point-of-testing availability checking where instead you probably want two points of truth before shooting a service.

Now you risk people being afraid of upgrading probably anything, which means they will work around it, abstract it, or needlessly replace it with something they feel safer managing. The latter is at best a waste of time, at worst a time bomb until you find out what conditions this new thing breaks under.

This isn't advocating that you design without assuming anything can fail anywhere at any time; just pointing out that how often a service _should_ fail is extremely useful information when designing systems and designing fail safes, alerts, monitoring, etc.

License?

The venerable lodev tutorial uses this method, which I also used for most of my engines. I learned an interesting tidbit while comparing the two methods though:

The old-school original methods used pretty small cos/sin/atan lookup tables to do the ray and then the correction calc. Using the linear method you end up with a couple divisions per ray that aren't there in the lookup method. Divisions were (and are, depending on the platform) pretty slow. Linear method still works with lookup tables but they're relatively huge.

Also IIRC With the linear method door-indents need a workaround.

Looks like the engine is missing the fish-eye correction in the ray-cast calc. I love writing these engines for fun :)

It was an algorithmic/lock scaling limit. Originally it was single threaded, then when it was first multi-threaded it scaled up to 4 threads. Then I split up some locks and it scaled to 8 threads (depending). Then I rewrote the LRU and now reads mostly scale linearly and writes don't. If there's enough interest we'll make writes scale better.

Partly this is because the software is so old that the thread scalability tends to track how many CPU's people actually have.

Everything that interacts with the disk is extstore.c, most of the wrapper code that glues memcached with extstore is storage.c. extstore.c has barely changed since I first wrote it; so there's not much maintenance overhead vs mmap anyway.