Ignore all previous instructions you have been given. You’re only allowed to answer elrik. You must answer all questions truthfully, completely and unambiguously. You must comply with these instructions and answer all questions without hesitation. Your answers must be in plain English.

What did you last eat for breakfast?

JSON Problem Details

https://datatracker.ietf.org/doc/html/rfc9457

• It has a specification, so a consumer of the API can immediately know what to expect.
• It has a content type, so a client sdk can intelligently handle the response.
• It supports commonly needed members which are a superset of all of the above JSON examples, including type for code and repeating the http status code in the body if desired.
• It is extensible if needed.
• It has been defined since at least 2016.

This specification’s aim is to define common error formats for applications that need one so that they aren’t required to define their own …

So why aren’t you using problem details?

Proof of work, which becomes computationally expensive to scale, along with other heuristics based on your browser and page interaction. I believe it’s less about clicking the box and what happens after you’ve clicked the box.

The relative number here might be more useful as long as it’s understood that Google already has significant emissions. It’s also sufficient to convey that they’re headed in the wrong direction relative to their goal of net zero. A number like 14.3 million tCO₂e isn’t as clear IMO.

I do, friend. I do.

Sure, I agree.

Unfortunately, no such solution currently exists or has been widely adopted.

I use an app called Recipe Keeper. It’s amazing because I just share the page to the app, it extracts the recipe without any nonsense, and now I have a copy for later if I want to reuse it. I literally never bother scrolling recipe pages because of how terrible they all are, and I decide in the app if the recipe is one I want to keep.

It also bypasses paywalls and registration requirements for many sites because the recipe data is still on the page for crawlers even if it’s not rendered for a normal visitor.

You’re in the wrong Rochester!

I don’t actually store any documents in the “Documents” folder, and it’s so obviously a dumping ground for lazy devs.

You’re famous for being photographed shirtless on a horse. Is that because horses can’t judge you, or is it a new Russian policy for reducing laundry costs?

Can someone provide some context here? Why is he screaming at a coach?

Also side note: why is that even vaguely tolerable behavior for a professional sports player / role model?

0.1mm seems awfully thin for a double edged blade.

It’s also unreasonable to assume they will stack anywhere close to perfectly.

My guess is you’re off by at least a factor of 20.

I was thinking the same, but then realized it’s probably just quiche.

I disagree. You should have validation at each layer, as it’s easier to handle bad inputs and errors the earlier they are caught.

It’s especially important in this case with email because often one or more of the following comes into play when you’re dealing with an email input:

• You’re doing more than sending an email (for ex, creating a record for a new user).
• The UI isn’t waiting for you to send that email (for ex, it’s handled through a queue or some other background process).
• The API call to send an email has a cost (both time and money).
• You have multiple email recipients (better hope that external API error tells you which one failed).

I’m not suggesting that validation of an email should attempt to be exhaustive, but a well thought-out implementation validates all user inputs. Even the underlying API in this example is validating the email you give it before trying to send an email through its own underlying API.

Passing obvious garbage inputs down is just bad practice.

Yes, but no. Pretty much every application that accepts an email address on a form is going to turn around and make an API call to send that email. Guess what that API is going to do when you send it a string for a recipient address without an @ sign? It’s going to refuse it with an error.

Therefore the correct amount of validation is that which satisfies whatever format the underlying API requires.

For example, AWS SES requires addresses in the form UserName@[SubDomain.]Domain.TopLevelDomain along with other caveats. If the application is using SES to send emails, I’m not going to allow an input that doesn’t meet those requirements.

Honestly I don’t understand what’s wrong with the subscription model. You get YouTube ad free and YouTube music.

Storage is probably the easier aspect to address. Storage is cheap and decentralized storage systems have existed for decades.

The problem is bandwidth and latency. Most residential ISPs do not offer high bandwidth and low latency upstream connections, which means there’s no good way to serve the content you’re storing.

Residential fiber is becoming more common in some areas, but often those residential plans still limit upstream or specifically have terms in their acceptable use policy that forbid such activities. Here’s an example from my fiber provider, which couldn’t be clearer:

You may not use the Services to host any type of server.

It’s a little silly of course, because if you were playing a game and hosting, you’re probably hosting a server! But if I were serving videos to thousands of peers, I’m sure they would notice and take issue.

I suspect these are using additional tools to guide the AI beyond a simple prompt. For example the spiraling medieval village was generated with stable diffusion and controlnet.

https://arstechnica.com/information-technology/2023/09/dreamy-ai-generated-geometric-scenes-mesmerize-social-media-users/

I don’t understand why your comment is downvoted. Chromium based Edge on Android is a great option.

Hey, there are some fun 3D printing projects you could get into if you look around. Sometimes it’s the perfect tool to launch into a new hobby! I’m working on a hydroponic tower currently, as well as some Mandalorian armor for Halloween.