locutous

It's bad on both sides. As a parent. If your child ends up in a class where other children are abusive there is almost no recourse for changes and you are treated poorly for trying. Ditto if the teacher is abusive, which also happens.

Most of the time the only recourse is to pull them out.

That's the grammar Nazi hat.

Pedant hat off.

> That’s going to be hard to argue. Where are the copies?

Discovery will show exactly what the base images for training are. You can view that the outputs are derivative works.

I don't think the mechanism is going to shield the violation, and frankly it shouldn't.

License your source material for the purpose and do it right. Doesn't everyone know it's wrong to steal?

In many cars fog lights and high beams are mutually exclusive. You can't turn on both even if you wanted to.

Some generalizations.

Home cooking is generally going to be better than particularly fast food because you are not reheating the same oils over and over.

Coconut oil is generally held as better. Cold pressed oils otherwise. Prepare to pay more for them. Be aware that food packaging labels have been known to lie about oil origin. Basically, fewer steps between growing the food and your mouth the better.

Preparing food at home is going to reduce a lot of the processing and reprocessing that happens to commercial packaged foods. I think that's going to be a net win.

Maybe get a feel for exactly how much oil is required and keep it to a minimum.

App store discoverability is very poor. Web discoverability is much easier to manage. It's something you have more control over and can buy easier through marketing via any channel you want. App store pages just don't convert well.

I haven't seen one that has done it well personally. Missing in this is so much of how it might be done right. There are so many dragons. Vendor lock in, logging, debugging, development (can I run the application on my laptop?), versioning. How far will out of the box tooling get me vs what I have to build. Etc etc etc.

When the "new shiny" effect wears off you usually find a turd that smells worse than what came before. Which is why we see this thread ever month or two and will until the tooling catches up and companies stop creating the distributed turds or the method falls out of grace because people finally realize you can scale simple systems pretty far vertically.

Jim Keller mentioned this problem in the hardware space. Basically when people breach the interface design and couple things and how that coupling limits your ability to grow the design.

When he helped set the tone for the Zen architecture he took AMDs existing people, set them on a more aggressive path and one of the cardinal tenants was you could not cheat on the interfaces. This is one of the nuggets you can pull from his interviews.

It's possible. It happens. And the end results can be industry changing.

> If done right microservices is a way to transform part of your organization challenge into a technical one, which for many organizations is the right move.

Famous last words, if done right... Or you just multiply your organizational issue with a technical one.

> Servers can only get so big. If your monolith needs more resources than a single server can provide, then you can chop it up into microservices

200 threads, 12TB of RAM, with a pipe upwards of 200GB/s. This isn't even as big as you can go, this is a reasonable off the shelf item. If your service doesn't need more than this, maybe don't break it up. :)

I believe that this level of service can no longer accurately be described as "micro".

> As a user I've seen and used this crap. My understanding of the market is much better than yours, it seems, because I approach it as a user. And yeah, you definitely don't listen to the users.

Declaring that you always know best. When you are asked for evidence your only cited evidence is yourself. That your personal experience is representative of the primary needs of entire markets of users. And that you know better than what transpired between myself and hundreds of users. You seem to be remarkably arrogant.

This isn't productive, I'm done.

Good day.

> They can. You just don't know how to listen.

I've worked on many mobile products. This has been true of none of them. Please provide some evidence of otherwise?

> Does this happen with native apps? You betcha.

Something I agree with. It is the indian and not the arrow. I've seen native, multiple cross platform apps of different flavors, and web views. All of the major problems were due to institutional shortcomings. If our app is bad, it isn't a tooling problem it's because we fail to execute.

> It is significantly more prevalent with web because web has never been and never will be an app platform.

Ummm... I sell web apps. Many major vendors have products that are, at heart, web apps. Progressive web apps, web apps, electron, phone gap, Cordova, capacitor, etc. I find this observation a demonstration of your ignorance of this market.

If my customers don't really need a Ferrari, then making them pay for one is expensive. Most cars work just fine for most people.

Software is expensive. People resent high rate subscriptions as it is. Including on here. They resent it a lot more than lack of native toolkit. Ironically, price resistance on mobile is at legendary levels.

But so many can't seem to escape the gravity pull of dev strategies that blow up budgets like multiple code bases, micro service backends, etc etc.

Very very few of my customers actually want a Ferrari with the accompanying price tag. They want stuff that is convenient and works, the car is less important than the destination I can take them to. They don't really care about the last 5% percentile UI flexibility that is a native toolkit.

> Is it? Native buttons also come with things like affordances, accessibility, recognizability.

And web views come with things like scaling, accessibility, page/document search. The recognizability and discoverability is up to the designer. Between the two, I miss browser features a lot more than native look and feel.

Then let's not forget the privacy nightmare that mobile apps have been.

I can also often fix poorly built web with some css or other hacks that I cannot do on mobile for poorly built apps. I helped a user do just that the other day, if it had been native he would not have been able to work around the design issue.

The native bias here is crazy. Most users just don't care and can't tell if they are on something that's native vs a web view. What they care about is, does this provide me value? That's real UX. Not blowing out development budgets on duplicating the same features on 3 platforms. You can spend that potential budget on refining and improving the features.

Does it matter sometimes? Yes! The are limits to what you can reasonably do in a web view. But most of the time a web view works fine.

> This will never be as nice to use as a native app, because you cannot replicate all of the small details of how native UI works on each platform.

Not sure how much of that is necessary. I mean, a button doesn't "look native", so what? It's a button.

Apps written to require network requests to resolve a navigation are much worse than JavaScript handling a user event.

> And say you manage to get close to emulating a native app on one platform — when the OS UI updates, you’ll be behind again.

Not really the goal. You have this backwards. Keeping up with OS churn is one of the reasons to use an abstraction like this. It doesn't break your app nearly as much. The browser is a much more stable target than native mobile APIs.

> I get that it’s inconvenient/expensive for you to build three UI layer. But that’s the only way to do this well.

Inconvenient is dramatically understating the case. 3x spend is flat out impossible for many places.