If you have enough discipline to make sure you only create threads after all the forking is done, then sure. But having such discipline is harder than just forbidding fork or forbidding threads in your program. It turns a careful analysis of timing and causality into just banning a few functions.
And what do you do with that information? Refuse to fork after you detect more than one thread running? I haven’t seen any code that gracefully handles the unable-to-fork scenario. When people write fork-based code, especially in Python, they always expect forking to succeed.
But not the reverse, if its a bare fork and not strictly using basically mutex and shared resource free code (which is hard), and there's little or no warning lights to indicate that this is a terrible idea that fails in really unpredictable and hard to debug ways.
> The main downside of this was memory usage. You would have to load all of your code and libraries N types and in-process caches would become less effective.
You can load modules and then fork child processes. Children will share memory with each other (if they need to modify any shared memory, they get copy-on-write pages allocated by the kernel) and you'll save quite a lot on memory.
Yes, this can help a lot, but it definitely isn't perfect. Especially since CPython uses reference counting it is likely that many pages get modified relatively quickly as they are accessed. Many other GC strategies are also pretty hostile to CoW memory (for example mark bits, moving, ...) Additionally this doesn't help for lazy loaded data and caches in code and libraries.
I agree with you that they're more or less equal. I don't like the idea of my reverse proxy dealing with letsencrypt for me, personally, but that's just a preference.
One tricky thing about nginx though, from the "If is evil" nginx wiki [0]:
> The if directive is part of the rewrite module which evaluates instructions imperatively. On the other hand, NGINX configuration in general is declarative. At some point due to user demand, an attempt was made to enable some non-rewrite directives inside if, and this led to the situation we have now.
I use nginx for homelab things because my use-cases are simple, but I've run into issues at work with nginx in the past because of the above.
I'm not sure why Apache is so unpopular, it can also function as a reverse proxy and doesn't have the weird configuration issues nginx has.
Some people take this way too far, for instance I've send places compiling (end of life) modsec support into nginx instead of using the webserver it was built for
I got a 4-pack of zigbee power plugs that report usage, and I have a home assistant automation that goes ding (or whatever) when the washer or dryer had been using electricity for at least a few minutes and then stops using electricity.
> In saying “every point,” we obviously have to turn a continuous problem into a discrete problem, and the choice of what level of resolution to use is non-trivial. Right now, when I set that resolution to only make a calculation for each two-yard by two-yard square, I can get the map done in a couple minutes. When I set the resolution at one foot by one foot, the process usually takes over an hour. TL;DR: I can make maps for shots from general areas on a hole pretty quickly, but as I get closer to mapping “every point” on a hole, it gets exponentially more time consuming.
Are you making an assumption that you need to have the same resolution at every point on the course? Maybe there are broad areas of fairway that have similar scores (so lower res is fine) and specific "sharp" areas (you'd probably need finer resolution on the hole-wards side of bunkers vs the side that's farther away from the hole?).
There's lots of techniques in computer graphics for figuring out when you can downsample, and you're going to have lots of opportunities to tune those techniques to the problem of golf course strategy analysis (trees, as you mention, probably cast "shadows" of uncertainty and those shadows would need better sampling).
(disclaimer: I golf <1x / year so I don't even know all the words you used in the article)
OP here. You make a very good point. Most of the holes definitely don't need a consistent gradient across every point on the hole. However, some will. The goal is to reveal that underlying nature of the hazards, and this includes contouring. When we get into the really nitty-gritty aspects of contouring's outsized effects on architecturally interesting areas, the main worry I have is that you can't know where to skimp on the resolution until after you've got the result.
I do think, however, that there should be some relationship between resolution and the "stickiness" of the surface (with higher friction variable, e.g. heavy rough). Given the higher friction areas, there will be less movement in rollout. Less movement in rollout means that the net effect of the contouring is less significant, which means that the resolution is less important, and we can probably save time in these areas.
I'll really have to think about this. It's a good idea.
> The forced changeover from coal gas to natural gas is largely credited with a reduction of suicide by 40% after it was done.
The mechanism of that reduction very well could be reducing the level of depression in the populace and thus suicidal ideation, rather than just making the means less handy (or of course, some combination). Coal gas, like any other gas used for combustion, doesn't burn perfectly and UK homes likely had persistent amounts of carbon monoxide roughly all the time since heat gets used not-quite-year-round.
> Google Talk and Facebook Messenger were XMPP all the way through and worked with vanilla XMPP clients
I remember this, it was great to connect to absolutely every chat platform with bitlbee and pretend that all my chats were just DMs on some irc server somewhere
This is a great explanation; Prosody/ejabberd seem to kind of be "everything to everybody" but because they are so general it's hard to know if they're a good fit for any one particular purpose.
Snikket seems to just be a focus or lens on Prosody that answers that question for the mission statement you gave.
It doesn't seem to request location in a modern-enough way on safari on ios. It just seems to think that it can't get the location and suggests that I go open the Maps app.
reply