[1] https://www.rfc-editor.org/rfc/rfc5465.html

This is a hard one to prove without trying. A lot of people would say that and then buy the cheaper version when the time comes.

If your images use the same base container then the libraries exist only once and you get the same benefits of a non-docker setup.

This depends on the storage driver though. It is true at least for the default and most common overlayfs driver [1]

[1] https://docs.docker.com/engine/storage/drivers/overlayfs-dri...

My experience is that as the car gets older it is common for the vents to lose the capability to stay pointed where I place them. As in: you point them where you want and they flip back all the way to one side as soon as you let go.

(Hot climate here, with several months of "a/c set to max during the whole trip" per year)

[1] https://support.mozilla.org/ca/kb/how-use-firefox-containers

You seem to think that joke is out of date now. Many others don't ;)

If build a cache that gets hits on the first pass, then it won't work for the second and later passes.

a) If you didn't use it (the less bad case you are considering) then why pay for the stat syscalls at every request?

b) If you did use it, apache was reparsing/reprocessing the (at least one) .htaccess file on every request. You can see how the real impact here was significantly worse than a cached stat syscall.

Most people were using it, hence the bad rep. Also, this was at a time where it was more comon to have webservers reading from NFS or other networked filesystem. Stat calls then involve the network and you can see how even the "mild" case could wreak havoc in some setups

- A more complicated nginx configuration. This is no light matter. You can see in the comments that even the author got bugs in their first try. For instance, introducing an HSTS header now means you have to remember to do it in all those locations.

- Running a few regexes per request. This is probably still significantly cheaper than the stat calls, but I can't tell by how much (and the author hasn't checked either).

- Returning the default 404 page instead of the CMS's for any URL in the defined "static prefixes". This is actually the biggest change, both in user-visible behavior and in performance (particularly if a crazy crawler starts checking non-existing URLs ni bulk or similar). The article doesn't even mention this.

The performance gains for regular accesses are purely speculative because the author didn't make any effort to try and quantify them. If somebody has quantified the gains I'd love to hear about it though.

Separating api and "front" in different domains does run into CORS issues though. I find it much nicer to reserve myapp.com/api for the API and route that accordingly. Also, you avoid having to juggle an "API_URL" env definiton in your different envs (you can just call /api/whatever, no matter which env you are in).

Both react-query (that is tanstack query now) [2] and rtk-query [3] include extensive configurability regarding their caching behaviors. This includes the ability to turn off caching entirely. [4,5]

Your story sounds like a usage error, not a library issue.

[1] https://www.npmjs.com/package/redux-query

[2] https://tanstack.com/query/latest/

[3] https://redux-toolkit.js.org/rtk-query/overview

[4] https://tanstack.com/query/latest/docs/framework/react/guide...

[5] https://redux-toolkit.js.org/rtk-query/usage/cache-behavior

chrome://geckoview/content/config.xhtml

- You can't wait until you receive the entire body to be able to compute a signature to then validate the sender as your first line of defense. It is just too expensive and opens you to DDOS attacks. People use IP reputation as a first line of defense because it is cheap, not because it is good.

- You cannot enforce people's behavior through RFCs. I can assure you that random guy next desk will not care about your "this is a top-posting-thread" header and bottom post there. Even if she has to manually copy/paste things around.

- Likewise, auto-generated plain-text versions of HTML (or other rich-text formats) are no better than what screen readers can achieve. Most poeple won't bother writing that alternate version, meaning the obligatory alt text is now less useful than when it was optional and only people who cared inculded it.

- Your largest client may not update their e-mail infrastructure to comply with the latest standards. If that happens, you don't tell them to update or otherwise you won't be answering them because their e-mails go to spam. You do whatever is necessary to ensure that their e-mails don't go to spam. Business always comes first.

Your post advocates a

(x) technical ( ) legislative ( ) market-based ( ) vigilante

approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)

( ) Spammers can easily use it to harvest email addresses

(x) Mailing lists and other legitimate email uses would be affected

( ) No one will be able to find the guy or collect the money

(x) It is defenseless against brute force attacks

( ) It will stop spam for two weeks and then we'll be stuck with it

( ) Users of email will not put up with it

( ) Microsoft will not put up with it

( ) The police will not put up with it

( ) Requires too much cooperation from spammers

( ) Requires immediate total cooperation from everybody at once

(x) Many email users cannot afford to lose business or alienate potential employers

( ) Spammers don't care about invalid addresses in their lists

( ) Anyone could anonymously destroy anyone else's career or business

Specifically, your plan fails to account for

( ) Laws expressly prohibiting it

( ) Lack of centrally controlling authority for email

( ) Open relays in foreign countries

( ) Ease of searching tiny alphanumeric address space of all email addresses

( ) Asshats

( ) Jurisdictional problems

( ) Unpopularity of weird new taxes

( ) Public reluctance to accept weird new forms of money

(x) Huge existing software investment in SMTP

(x) Susceptibility of protocols other than SMTP to attack

( ) Willingness of users to install OS patches received by email

(x) Armies of worm riddled broadband-connected Windows boxes

( ) Eternal arms race involved in all filtering approaches

( ) Extreme profitability of spam

( ) Joe jobs and/or identity theft

( ) Technically illiterate politicians

( ) Extreme stupidity on the part of people who do business with spammers

( ) Dishonesty on the part of spammers themselves

(x) Bandwidth costs that are unaffected by client filtering

(x) Outlook

and the following philosophical objections may also apply:

( ) Ideas similar to yours are easy to come up with, yet none have ever been shown practical

( ) Any scheme based on opt-out is unacceptable

( ) SMTP headers should not be the subject of legislation

( ) Blacklists suck

( ) Whitelists suck

( ) We should be able to talk about Viagra without being censored

( ) Countermeasures should not involve wire fraud or credit card fraud

( ) Countermeasures should not involve sabotage of public networks

(x) Countermeasures must work if phased in gradually

( ) Sending email should be free

( ) Why should we have to trust you and your servers?

( ) Incompatiblity with open source or open source licenses

( ) Feel-good measures do nothing to solve the problem

( ) Temporary/one-time email addresses are cumbersome

( ) I don't want the government reading my email

( ) Killing them that way is not slow and painful enough

Furthermore, this is what I think about you:

(x) Sorry dude, but I don't think it would work.

( ) This is a stupid idea, and you're a stupid person for suggesting it.

( ) Nice try, assh0le! I'm going to find out where you live and burn your house down!

He has already completed all games, but the videos are waaay behind (he's releasing one video/game a week).

[1] https://www.youtube.com/@Thabeast721/videos

If you are ever planning on visiting Barcelona I promise you won't regret it if you can arrange it so you are there on Apr 23rd.

[1] https://en.wikipedia.org/wiki/The_Day_of_Books_and_Roses

Those browsers could have implemented the Home-PWA functionality while maintaining your ability to install plugins such as adblockers within that PWA's context.

Apple has made this impossible by removing the OS APIs that allowed "Installed" (home-)PWAs entirely. This is just so they aren't forced to allow these under a different browser engine.

Of course, this is all done because "think of the children" (i.e.: think of the poor people ticked into using a non-privacy-respecting browser to run their PWAs).

My position is that if you open development to 3rd parties they have to be able to develop for your platform for free. You can charge for the services you provide to the developers (fees if they use your payments platform, your distribution platform, etc), but you should not be able to force them to use such services.

The win-win is that by opening your device to 3rd parties it is made more useful for your users and hence more desirable. Iphones wouldn't be so popular if you couldn't access tiktok, instagram and what not with them after all...