perspective1

Obviously that's not possible because Vice doesn't give any context. Your line of thinking has me worried-- finding context shouldn't be left as an exercise to the reader.

> I'm struggling to imagine how you think leaving out "in the near future" changes the meaning of that sentence in any way.

You're really struggling to understand how a prediction about the future is different than the state of affairs today?

The actual quote is, "in the near future, cellphones are throwaways." Which is still disagreeable, but substantially different from the manufactured quote of "cellphones are throwaways." This isn't outright sham journalism, but it's not credible journalism either.

I don't know about this one. Some % of culture money comes out of your paycheck but perks can make for brighter days and nicer colleagues.

Nobody's asking for perfection, just something that doesn't get hacked and play pornography for 3 year olds. Nest had polish. Security took a backseat to UX, and here we are.

With all respect, just because the state of the market was terrible doesn’t make a more secure insecure product good for the end user. And more than take market share away from less secure cameras, nest created a great ux helping expand use to unsophisticated consumers.

Answer: cars and highways. It's really hard to spend a lot of money replacing something that already works, even if it works really, really badly. High speed rail will only happen with a federal mandate.

Here, I'll paste the quote that substantiates this entire story-- Vincent Pang (Huawei): “There are some companies talking to us, but it would take a long journey to really finalize everything... they have shown interest."

This is cute but stretches the point too far. Your time is better spent working in Inkscape versus handcrafting a file that is a hundred bytes smaller, more likely to have syntax errors and has to be tested across different browsers. Likewise, frameworks help standardize code and reduce a lot of cognitive overhead once you understand them and their limitations and workarounds. On the other hand, using white-space padding npm packages may be taking things too far.

"They have been unable to migrate to AWS <pause> because it's not good enough." No, Larry, it's because database migration is hard and risky.

I think you're thinking Amazon separates its own SKUs from third party SKUs. That's not the case, it's all comingled.

User beware: "You are granting us with a non-exclusive, permanent, irrevocable, unlimited license to use, publish, or re-publish your Content in connection with the Service."

...and

"We may remove or modify any Content submitted at any time, with or without cause, with or without notice."

I'm torn. On the one hand, scraping helps break down walled gardens. On the other, we're talking about personal details being used in novel ways that no LinkedIn user probably understands. I doubt any LinkedIn user writes their profile expecting HiQ to scrape it, assign a "flight risk" score and alert your bosses.

Take a look at this: https://github.com/llSourcell/The-Neural-Qubit/commit/5f89be...

Siraj copy-pasted the original code without attribution and removed the Apache license. He states, in the readme, "I built off of their variational circuit code by modifying the fock basis truncation, adding an extra photonic quantum layer, and increasing the intial gate parameter seed."

That's comical. In the diff, you see he changed the "depth" variable from 7 to 8, the "fock basis truncation cutoff" from 10 to 9 and the "random initiation" sdev_photon variable from 0.1 to 0.2. I have no idea what any of that does, but it's absurd to say that these are substantial changes, especially without any justification as to why you made them.

Tell that to the enormous heap object you just forgot you made earlier.

You can clone the repo and replace https://github.com/mourner/bullshit.js/blob/master/src/terms... with export default ['.*']

I think it's more about preventing international private entities from profiting. AFAIK, they would get the same anti-monopoly effect just publishing about it because nobody can patent prior art.

More investment leads to higher asset prices, lower interest rates, business growth and more future production. Investing in capital markets just gets the market to allocate your capital, as opposed to if you built a widget factory yourself instead. The end result is the same (but the market is probably more efficient), more production.

The whole situation is a bizarre and I'm surprised any effect was noticed at all. You had to get unlucky enough that this ISP's recursive resolver cache expired in the 1-2 seconds you sent an NXDOMAIN. And then you have your NXDOMAIN TTL set far enough in the future it causes a problem. One possibility is the ISP ignores TTLs, setting its negative ones higher than the SOA settings and the others lower. I think the more likely scenario is weird caching-- either because of geopolitical boundaries or propagation issues on the service provider's side.

Apple's app stores are stuffed with quality apps. They don't need to give developers a quality experience because the supply is there anyway. So they don't. Small development shops have similar negotiating power and position to struggling unsigned music bands.

Tesla. I'm disappointed. You say your cars are the safest on the road. That your self-driving AI is safer than humans. You spar with regulating bodies along those lines-- arguing that you're protecting consumers. And then you roll out a fluff feature that causes accidents.

It's kind of amazing seeing positive things from monopolies and evergreen updates. These institutions can roll out things fast. It's possible in hardware too-- remember Bell Labs in it's hayday?

Love these points. They answer "which language is better for building enterprise services in the vast majority of cases." Go, is simply good enough and makes well-thought out compromises for "non"-zero cost abstractions.

For me, I'm a part-time solo "services" developer using Rust. I've built some terrible projects that I hate peeking into to add features and maintain. But, ultimately that's gotten better and the web-services story is maturing (Actix is somewhat unstable but easy to work with, and async/await will finally hit stable in a few months). I also write non-idiomatic code quasi-functional code that works for me but others would scoff at or at least find hard to maintain. Rust, to me, is an enjoyable language to use and has great tooling (debugging being a major exception). I've become productive in it after a heavy upfront cost. And, although I haven't quantified this exactly, its speed saves me money considering my relatively small single server.

I think, as a sole-developer, the largest issue with using Rust for services is the package support. Python, Go and JS all have mature Redis packages, for instance. Rust's works, but it has some peculiarities particularly with connection management and some Redis commands. It's enough where I could get everything working with enough time. But I don't have all the time in the world. It's a similar story for lots of packages, even in Actix web. You often have to dig into the source code to figure things out. I'm trialing a "microservice"-like architecture solely because it's easier to do some things in other languages. Hopefully widespread WASM support hits soon but I'm a long-time single-server guy now trying to figure out Kubernetes because I find Rust enjoyable.

It's so bizarre seeing measles come back. It's like some terrible thing out of Jurassic Park, "life finds a way."

Ignoring the herd immunity benefit for the moment, most anti-vaxxers are making the decision for their innocent kids and not themselves.

After years of ignoring it, I'm no longer able to fight the cloud urge. What's the best way to learn k8s in 2019?

I wonder how long this could last in a container on kubernetes with a million other microservices. Could the author develop something so rock-solid nobody looked at it until after they left? Then imagine the face on the intern asked to add feature X years later after they dig into the code.

On the one hand I think this is very cool. On the other, I think it's funny that Redis can fit in my RAM and not on my SSD.

Wow. This is amazingly innovative and scary. The "flexible" mechanism could unwittingly lead to very high APRs. That they get the money before it gets deposited to your bank account (and used for other expenses or withdrawn prior to bankruptcy) and the application is instant-- wow.

In two years or less, Chase and other innovative banks will be hitting Stripe APIs and emulating this. But they will never match the ease exactly and they will never have first dibs on the revenue.

Exactly. The article, starting with the title, is pompous and overconfident. Burry made the unanswered point that in a sell-off large index funds will have to dump their smaller holdings at large discounts. We have never had a market crash with passive holdings this large (and consolidated in a small handful of funds)-- we're in unprecedented times. Burry's point is entirely plausible. And although that it wouldn't immediately cause a problem for investors who don't sell (price is not value), the newly discount-price firms may struggle immensely in terms of raising new capital and financing.