1,032 karma · joined January 5, 2013
* GPT-3 is conceptually simple: the effort to invent it and engineer it amortizes well.
* Once the model is trained, it can be reused to very different tasks.
* Querying doesn't require programming knowledge.
Let me close my argument: neural network techniques developed in the last ten years are super useful here and now, they are used by billions of people every day and they do make their lives easier.
If https://en.m.wikipedia.org/wiki/Google_Translate does not seem like having business value to you, then I don't understand what you mean by "business value".
https://slatestarcodex.com/2014/07/30/meditations-on-moloch/
"With containers, you are responsible for figuring out which ones need which packages and how to re-build them."
Yeah, you need to know how to rebuild your world in ANY CASE. It's not an argument against containers that they require an approach that is the best practice.
The value of every corporation primarily reflects expectation of future profits. That's the reason P/E ratios differs a lot even for established companies.
[1] https://docs.microsoft.com/en-us/sql/linux/tutorial-sql-serv...
I also agree that the chosen transmission mechanism of money creation (buying bonds and stocks by central banks) might have lead to worsening inequality. I like the Yudkowsky treatment at https://www.lesswrong.com/posts/tAThqgpJwSueqhvKM/frequently... .
But I still think that the inflation is low and if we want to describe the problems that are happening even though it's low, we should create new language, not shift the current one.
Microsoft allows you to publish a web application from Visual Studio project to Azure.[1] It's very simple, but more much opinionated. It's a great trade-off for an individual developer who needs to focus on functionality. In the context of this discussion, there's an important distinction -- it's not an interface, it's just a feature. It's tightly coupled to Azure from one side and to Microsoft dev stack from the other.
[0] https://knative.dev/ [1] https://tutorials.visualstudio.com/aspnet-azure/publish
It's good to have properly defined, stable, open interface for compute workloads (containers as defined by OCI), so we don't have to lock ourselves into whatever shape of runtime environment our current cloud provides for their flavor of FaaS. So we don't have to learn cloud-provider-specific tooling, getting certifications for handling various tasks at AWS, becoming 2010s variants of Cisco-certified network engineers of the previous age.
But it's even better to have a properly defined, stable, open interface for orchestration too. To be able to run stuff locally. To be able to extend things. To ease the lock-in cloud providers currently have. To be able to actually understand what happens under the hood. And last but not least: to enable rise of open source solutions for higher-level abstractions, like KubeDB.
If there is a climate catastrophe going to happen, but no government is going to punish companies responsible, it won't make sense to try to do that for yourself -- in the same way bad corporations are freeriding on climate, bad investors are freeriding on your efforts to punish such corporations.
These active investors don't even have to realize their strategy is based on going against nice guys -- they might be led purely by statistical performance.
I'm not trying to be needlessly cynical. I like effective altruism for example. I'm just not sure stock market is a good battleground for ethics.
The difference between "we should abstain from our moral values because everyone dies anyway in the end" and "we should find ways to pursue our moral values effectively" is substantial. You don't have to be nihilistic to not accept cheap signaling being sold as a solution to real problems.
Few corporations deciding to not do dirty work, just providing their lower-level cloud resources to thousands of smaller firms who will gladly compete for any kind of money -- that does not solve anything.
Stuff like GDPR can change at least something.
Classic example in favor of monorepos is shared internal library. You should be able to change its API in one step, because that's the way to not having to care about compatibility at all. Compatibility concerns only happen if there's a time difference and with atomic company-wide update, this just doesn't need to happen.
In my example, backend and frontend can be deployed together. And we can discuss whether they should -- I would say there is little benefit of maintaining such single-purpose, wide interface just for getting the ability deploy frontend changes only, but this would depend on care the team put into configuration of cluster orchestration.
Contract testing is good, but not as good as testing against the real thing. Very much depend on the circumstances though.
If you put frontend and backend into different repositories, you need to make two PRs for every new feature and -- for much worse -- you make integration testing much harder as you don't have atomic product merges to run automation against.
Don't laugh about this example, my corporation is doing stuff like this (backend only repo tightly coupled to frontend repo) all the time.
So maybe we can steelman the argument into "good vertical concern separation doesn't force you into doing multiple PR for single feature, as opposed to horizontal frontend/backend/repository splits."?
But I'm still not sure. Wide integration testing is necesity for reliable microservices. It's difficult to do that with dependencies being out of the scope of the change.
Of course, what in the end really decides about the strength of your concern separation is the shape of your CI, but alas, repository granuality is just much more visible then CI checks.
Is this really the case? I mean, is there any research on this? I would guess exactly opposite is the case: I personally don't care about background music in most situations, but if I'm watching a film for two hours, I'm going to be very selective.
That means that Netflix in its current state is useless for me. As much as I applaud them for some of their production, the combination of half-empty catalogue and forced subscription model is going in the exactly wrong direction. I would pay one-time fee for Roma. I would pay subscription for a good catalogue.
Now, I don't state that it's not the case that most consumers does not care about what they watch as much as they care about what they listen. I'm just interested in some empirical data on this.
See http://blog.ploeh.dk/2016/04/11/async-as-surrogate-io/ for further discussion. Regular programmers are not using Task<T> as IO-monadic marker consciously, but they are surprised when a usage differs from that model.
Even in your example, are those phone calls the substantial costs, or is it customer confidence in your product being lost the main motivation you should do something with the bug? If so, what's the dollar value of this confidence? Also, do you have monitoring good enough in place to see how many customers are hitting the problem every day without telling you? Do you think these customers are less or more frustrated than the one they are calling you?
Can you attribute lost customer to a particular feature not present, to a particular bug the customer experienced just before they refused to deal with your software anymore?
With Mastodon, you can quickly create account you can send notes, links or images into. This account lives on the open web without registration required. You get Atom feed you can use to re-display the content in any way you want at other sites, or to share the content with people who don't use ActivityPub yet. You get "comments" for free for users willing to get ActivityPub account.