969 karma · joined May 3, 2013
You'll still need to play with modifying some of the code to get it to run, but `dream.py` works for me. Funny enough, I got only img2img effectively working with the lstein branch; it broke txt2img for me.
Similar goes for quirks of Tensorflow that weren't taken advantage of. That's largely the work that is on-going in the OSX and M1 forks.
Great for short-lived values in a cache that are frequently accessed. If all of your values always have the same expiration period (i.e. expires at insert time + N period) then it's super efficient.
More or less you have an array with a head and tail. Every "tick" (usually each second but you can customize it) you move the read pointer ahead by 1 array slot. The tail is then evicted.
If you have a highly accessed part of your code, you can be lazy and avoid using an extra thread and just tick ahead the read pointer when the time changes.
1. Managing 'heat' in the system (or assuming that you'll have an uniform distribution of requests)
2. Recovering a distributed system from a cold state and what that implies for your caches.
3. The obvious one that people that do this type of thing spend a lot of time thinking about: CAP theorem shenanigans and using Paxos.
Reminds me of the Grugbrained developer on microservices: https://grugbrain.dev/#grug-on-microservices
Good luck getting every piece working on the first major recovery. My 100% unscientific hunch is that most folks aren't testing their cold state recovery from a big failure, much how folks don't test their database restoration solutions (or historically haven't).
Of course, for how delightfully simple this one is, your approach is definitely faster/better!
At a score of 1,619 the ball is moving so fast it no longer works! I switched to a new tab (hoping that the event loop would be sent to the background/context switch/whatever) and ta-da - it misclicked. High score of 1,637.
Imagine we're bottling soda in plastic bottles. There's an X% chance that a bottle explodes during the process. We also know if we over-fill a plastic bottle with CO2 the start it makes it slightly more elastic, and empirically it reduces that rate by Y%. We're not really sure why they were exploding, but we know that stretching them works.
Do you care about the other parts of the bottling process?
Yeah, so I went with the stats we did have data for. I didn't speculate since I'm not omniscient and that's ignorant at best, disingenuous at worst. Both COVID cases and deaths are under-reported.
> Drunk driving is far, far, far more common than the arrest rates would suggest. Like, its actually insane how common drunk driving is. Cops are not gods. They do not catch everyone. One million people were arrested in 2016 for drunk driving; its likely that 50 million+ people drove above the legal limit in that same year, multiple times each.
The link I gave called out that 111M people self-reported drunk driving. That's an unreliable stat, so I went with the arrest rate which is a known quantity.
I wasn't "convinced" of anything. I chose the closest stats that we can get, which are definitely NOT perfect. What real-world data is "perfect"? Only when systems are self-reporting is data even close (e.g. latency, HTTP status counts, etc) and even those can be wrong due to log loss, servers failing, networks failing, etc.
You work with the data you have, and try to make informed decisions, instead of wildly guessing.
You do realize that drunk driving is illegal, right? Do you think drunk driving should be legal because it's "unlikely" to cause harm to others?
> I say it doesn't.
628k confirmed deaths in the US from COVID. 37.8M confirmed infections. That's a death rate of 1.66%.
In 2016, 10,497 people died from drunk driving. 1 million people were arrested in 2016 for drunk driving. That's a rate of 1.0497%. So COVID is literally more dangerous than drunk driving.
Drunk driving stats: https://www.cdc.gov/transportationsafety/impaired_driving/im...
Obviously you have to be using CloudFormation, so if they're using i.e. Terraform they're out of luck.
Most people bought a phone from their carrier because it was so heavily subsidized and the plans were so expensive. If you broke your phone, you were out a huge amount of money, AND you had an expensive plan to boot.
T-Mobile did the right thing and gave consumers an option.
"Is this person trying to solve a problem, or are they trying to be heard and commiserated with?"
There's also so much extensibility that someone implementing it could just throw away all of the default fields in a patient's record and create their own, and we're right back to a mess of records that are useless across systems without having custom handlers.
Wave was launched to a ton of fan-fare and seemed like a first-order product, similar to Hangouts... which is now also dying a slow death.
I've often questioned if spending 8+ hours a day writing software was the right thing for me to do, when I get so much more gratification from physically manipulating something. It was a welcomed read.
While I haven't played his games, I don't think the game play really matters as long as it's "good enough". Most games aren't going to be the 0.01% smash hit; you just need a regular audience that appreciates what you're doing, and enough eyeballs that are caught to say "hey, I'll gamble my $5 on something that looks fun".
I think this is partly hubris. I see startups fall into the same pattern - "well it's a great product so our customers will evangelize", "if we add X feature we'll get more sales [even though no one has asked for it]", "if only it was faster, we'll get more sales [even though no one complained about latency]".
No, you need to figure out who you're selling to and how to make the customer aware you even exist. It's a big pond.
As far as I'm concerned, this is the same with AI.
You can imagine an AI that is smarter, bigger, more capable than humanity, but realistically we can't describe that.
We can't create something that is greater than our own limitations, the same way we can't create a color that we can't perceive.
Humanity is bound by it's own intellect, so any AI could only ever be as smart as we are.
My job provides me with an HP Ultrabook. When I type on it, the plastic near the trackpad creaks. If I bought it retail it's something like $1400. And it creaks.
If I'm spending $1400 on a piece of technology I expect to have for 3-5 years, and I'm going to be hauling it between locations (on-call schedule) I really need to feel like "Yeah, this won't get broken if I accidentally put something a little heavy on top of it (e.g. in my bag)".
It's partially a performance story, but I rather pay an extra $100-200 for a solid chassis that makes me think the motherboard won't bend when I put pressure from my wrists on it.
I used my first OSX machine ever earlier this year. I wanted to add some extra keyboard commands, so I had to download a 3rd party program that had to unlock accessibility controls and essentially take full control of the machine. That's absurd to me.
I also hit tons of external display problems. Things wouldn't connect or sync right, desktops not correctly moving to the right screens, no window snapping even though it's a high res screen, etc.
I hit way more beach balls/lags than I do with my modern Windows machines.
Windows 7 was solid, Windows 8 was a bit of a mess (as has been every 1st iteration of Windows [98, 2000, ME, XP, Vista, 7, 8, 10]), but Win 10 is really enjoyable.
It's unfortunate that the BSODs caused largely by shitty drivers in Windows 98/XP has hounded the Windows ecosystem for over a decade, even though the driver verifier has fixed the vast majority of those.
It seemed like a "decided not to pursue" case, as opposed to a "not guilty" case before.
Does anyone have any insight into recent hacks that could link back to data in those emails?