rp1

The article makes no mention of changes to insurance claims.

My searches are mostly for esoteric error messages that I tweak a dozen times to get Google to stop returning unrelated results. Then I usually give up, get lunch, and the answer comes to me when I sit back down.

True, bandwidth is a concern. It might be possible to copy memory directly from disk to the GPU, which may be more efficient.

Ultimately, the developers on Asahi are trying to play catch-up with massive GPU driver teams comprised of dozens of talented engineers. It’s not feasible to catch up, but I’d be happy to be proven wrong.

Bitmaps take memory, but are quite efficient from a runtime perspective because they aren’t encoded.

You still haven’t given an example of how coordinating the two agencies can lead to a bad outcome. If all that can be done is enforce the law, then there is no issue. You keep implying something extra-legal can be done through the coordination, but aren’t providing any specifics.

Having 10 officers beat an individual with clubs doesn’t exactly seem good either…

Normally people say that power is being wielded dangerously when the power is used to do something disagreeable. Simply enforcing the law correctly doesn’t seem dangerous to me.

This is just a small microcosm of what’s going on in the cable TV world. Many channels are raising their fees, but the cable providers are very reluctant to raise the price charged to end users. Instead, cable providers are opting to drop channels. This is leading to an increasingly fragmented cable TV market where it’s impossible to get all the channels you may want to watch. For instance, Comcast just dropped MSG, which is a channel for NY-based sports. The only alternative many people have is to use FuboTV, but Fubo has dropped Adult Swim for the same reason. So now it’s impossible to get both MSG and Adult Swim.

This would be more convincing if you had specific reasons, unrelated to the enforcement, that JPM shouldn’t be punished for this.

That’s not really an answer to the question. It would be nice if all situations could be de-escalated, but that’s obviously not the case. De-escalation also has its own risks for the officer. Again, not saying I support what happened, but it seems so hard to manage a situation with a belligerent person when I imagine trying to do it myself. Even doing something relatively benign, like removing a loitering person, is not something I’d want to attempt.

How else would you subdue someone? You can’t expect all cops to be able to go 1-1 or even 2-1 with someone to subdue them physically. Cops also have guns strapped to their sides that can be reached for. I’m not justifying their behavior, but when I try to imagine subduing someone, I’m not really sure how I would do it. There is definitely room for tools that make it easier.

Almost none of the reasons have anything to do with releasing the source. You can release the source but still maintain central control. They shouldn’t even have posted this. Obviously they want to make money from their products, and that’s fine.

Why are they evil? Or at least more evil than humans? Humans have eradicated wolves almost everywhere due to the danger they pose humans, particularly children. How is this situation different? The monkeys are even targeting the very same species that humans have long targeted.

I think you’re generalizing way too much. Java is old. The libraries are old. There is a lot of bad old code out there, and very little glory in fixing it.

Maybe… but the article had an anecdote of asking Ian Goodfellow for ideas and none of those ideas working. I would assume Ian Goodfellow would have the requisite amount of experience for sufficient intuition.

This question was asked last time the author posted this few months ago. I’m surprised they didn’t update the benchmarks. Kind of makes me think Vaex is faster.

Mortality is often used when talking about the likelihood of dying.

You could write the above easily with a typewriter. The point isn't to use the most primitive method of writing possible. Rather, it's to acknowledge that writing on a computer has a certain set of drawbacks in addition to its benefits.

Your experience rings true to me. It's one of my biggest frustrations with ML at the moment. There are so many ideas I'd like to try, but I know only a small fraction of them will work, and discovering which of the ideas fail and which succeed is a herculean task. Your conclusion that empathy helps may also be true, but I have a different take.

It currently takes way too much time to explore ML-based ideas. I compare this to the early days of computer programming where programmers needed to manually fill out punch cards, and doing anything took days of full time work. There is lots of room for improvement along every step of the ML pipeline, from data wrangling, model choice, training, and evaluation. Good ML tooling will likely bring huge gains in the field.

I don’t think this is a good analogy. Cars can get you long distances quickly. Having this ability means you can have suburbs outside of city centers, travel between cities in a day thus necessitating highways, etc. Cars make possible all sorts of huge, life-altering changes because of how they impact travel.

In terms of long-form writing, word processors make spelling and grammar easier to fix. They also make editing easier, and the internet can be used to reference facts while writing. This comes with a few trade offs, like easily being distracted. Does this impact really seem equivalent to the impact of a car to you?

I’m not arguing. I was just highlighting that you could easily implement a json library that uses go generate instead of reflection. I was positing that such a library hadn’t been made yet because the perf hit of reflection is fine for most people. Also, just an aside, if perf is a concern than JSON isn’t a good choice to begin with.

Hackers can easily get anyone’s phone number. Just Google <name> phone number. There are so many data brokers out there happy to sell this information.

There is a more serious downside that you don’t mention: splitting things into modules takes time and involves making decisions you likely don’t know the answer to. When starting a new product, the most important thing is to get something up and running as quickly as possible so that people can try it and give you feedback. Based on the feedback you receive, you may realize that you need to build something quite different than what you have. I’ve seen plenty of successful products with shoddy engineering, and I’ve seen plenty of well engineered products fail. Success of a product is not correlated with how well it’s engineered. Speed is often the most important factor.

Go could do something similar if you're willing to run `go generate` as part of your build process. For most Go applications, the reflection overhead is a fine price to pay for convenience, just like GC is a fine price to pay for not having to deal with the borrow checker. Obviously, these tradeoffs don't hold for all programs, but Go has definitely found a niche.

This exploit was found within a year of Bloomberg's article being published: https://www.wired.com/story/supermicro-bug-virtual-usb/

Whether or not that was the exploit being referred to by Bloomberg is unknown, but suspicious.

This exploit was found after the article was published: https://www.wired.com/story/supermicro-bug-virtual-usb/

The Go code parsing libraries are quite good though. Not sure what else you could want re. code generation.

That does clean stuff up a bit, but still requires nesting if you need to access more than one value generated in the chain at a time. Go's pattern of val, err := ... is a little cleaner in that regard, but does have a lot of redundant if err != nil checks.

I’ve been doing a lot of rust programming recently, but how exactly is the Result monad better? I feel like I end up with nested match statements for chained results, but maybe I’m doing something wrong.