267 karma · joined June 25, 2015
tfa appears to admit that people are actually _using_ the new Milwaukee flag. This seems like a pretty strong argument that the new flag actually is better than the old flag? It is kinda cool to have a very distinctive local flag, but if the practical upshot of that is that the flag isn't actually used anywhere except a single flagpole in front of city hall (if that), seems like the vexillology people kind of have a point?
Many applications do not require true durability and it is likely that many applications benefit from lazy fsync. Whether it should be the default is a lot more questionable though.
That seems like an important distinction, and makes the rest of the article (which focuses on educational accommodations) look mistaken.
it really takes about 5 seconds of thinking about this to realize why this "analysis" is stupid - he takes an INCREDIBLY expansive view of what counts as "pollution" from food production and then takes the narrowest possible view of what counts as "pollution" from driving a ICE car.
It's frankly embarrassing that econlib would even host this kind of crap which would get a failing grade in an undergraduate econ class.
https://go.dev/doc/articles/race_detector
Edit: at the _end_ of the post, they mention that this is the second of two blog posts talking about this, and in the first post they explain that they caught these by deploying the default race detector and why they haven't been running it as part of CI (tl;dr it's slower and more resource-expensive and they had a large backlog).
https://eng.uber.com/dynamic-data-race-detection-in-go-code/
> A newly minted goroutine is given a few kilobytes
a line later
> It is practical to create hundreds of thousands of goroutines in the same address space
So it's not practical to create 100s of Ks of goroutines - it's possible, sure, but because you incur GBs of memory overhead if you are actually creating that many goroutines means that for any practical problem you are going to want to stick to a few thousand goroutines. I can almost guarantee you that you have something better to do with those GBs of memory than store goroutine stacks.
Asking the scheduler to handle scheduling 100s of Ks of goroutines is also not a great idea in my experience either.
So don't just rush a fix out. Think about what the effects of a configuration change like this might be, and whether you are just making more problems for yourself down the line trying to fix something quickly.
> Mind that the workload was selected to be a good match for InfiniCache properties (large objects with infrequent access).
> The hourly cost increases monotonically with the access rate, and eventually overshoots ElastiCache when the access rate exceeds 312 K requests per hour (86 requests per second).
So this is not a replacement for the most common use cases for Elasticache. It is interesting as a cache in front of S3, but if you want a cache in front of S3...just use Cloudfront?
Honestly if I was AWS I would be ecstatic if people used this, AWS probably breaks even or maybe loses a little bit on optimal usage of this, and makes an absolute killing if someone using this has a traffic spike and ends up hitting their lambda millions of times.
You can say all kinds of dumb shit and sign your name to stupid letters and other people get to call for you to be fired, and maybe you will be! Even after that, you can continue saying dumb shit and signing your name to stupid letters, and I can go write buggy Perl 4 code, and nobody can stop us! Your dumb letters might not get published in national magazines and I probably won't get paid much for my code but in neither case is this a violation of our free speech rights.
I don't think talking about poverty in modern societies in terms of economic sectors instead of trying to address it at a societal level is particularly useful. The point of the article should not be "let's all pay more for food" it should be "give everyone a UBI and if that means food costs more because you have to pay people more to work as cooks or strawberry pickers, that's a _good thing_.
I am going to look into getting those redirects cached though, there's no reason we shouldn't be able to serve them off the edge.
In my case it actually was sort of interesting - it definitely suggested that the redirects don't have the correct caching headers, because they clearly weren't being served off the CDN. However, this redirect is a pretty unusual case for us, because most of our traffic is either from SEO or links from notifications we send users.
I agree that you should be looking at the experience most users are going to have, but if the first experience for most users is a redirect you should probably do something about that.
- the graphics "driver" reads values out of certain registers (AL and AH?) at a set interrupt (maybe every X clock cycles?) and writes one pixel to the screen of whatever color those registers had in them
- by writing values into those registers and aligning the number of operations the program does with the frequency of the interrupts, you can get animation?
Even achieving any sort of flow control so you can switch between the effects is mind-boggling to me.