HN user

kilburn

3,477 karma

Contact: myusername@la3·org

Posts6
Comments634
View on HN

do they think if they get the disc, they can just hold and be able to play that disk for decades or just copy to drive they have?

We can legally back-up owned discs to hdd or whatever other media in my country, including to the cloud. I can use the original media or any such backups as many times as I want, forever.

We can also sell a "hard media" copy wheven we want. IP owners cannot take away that right from us. Of course you must delete your backups if you sell the original media.

With digital "purchases" neither of these is true anymore. That's where the outrage comes from.

The harness was absolutely not an issue in my case.

The new pricing model where I got banned from using Opus entirely and half a day of work (with weaker models) consumed the 10$ plan was.

I'm now using a Claude Max subscription and I can get close to the daily limits but I'm fairly happy with the overall plan consumption.

If you enter a bookshop and you ask for a book that does not exist then it's definitely your mistake.

If you ask for a book they don't have it's a different matter.

In any case, when you ask for a book in a library you are using their "search" endpoint. The equivalent to opening a books/1 url would be asking for a specific instance of a book by serial number or so. Then it's clear that you made a mistake uf you do that for an unexistent serial number...

I don't know what kind of breakage was the parent talking about.

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)

Random is prng. They still cannot cache though because they do many reading "passes" through the same data.

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

The recommendation was to disable it because:

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

I don't think this is worth it unless you are setting up your own CDN or similar. In the article, they exchange 1 to 4 stat calls for:

- 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.

Apache's .htaccess is much worse performance-wise because it checked (and processed if it existed) all .htaccess files in all folders in the path. That is, you opened example.com/some/thing/interesting and apache would check (and possibly process) /docroot/.htaccess, /docroot/some/.htaccess, /docroot/some/thing/.htaccess and /docroot/some/thing/interesting/.htaccess.

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).

redux-query is not popular by any means. [1]

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

This is equivalent to about:config and works on the regular firefox mobile version too:

chrome://geckoview/content/config.xhtml

Also, they would school them on actual-world problems in the process:

- 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.

I couldn't resist....

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!

The point is that with EU mandating alt-browsers on iOS, it should have been a possibility to have "Installed" (home-)PWAs where the engine is the alt-browser, not safari/webview.

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).

is that really your position?

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...

You also need to account for:

- Whose turn is it

- If the king is in its initial position, whether the king has moved previously (that player can't castle anymore).

- For the pawns, you may need the previous position/move to allow en-passant capturing [1]

The standard specification used for this is the Forsyth–Edwards Notation (FEN). [2] It was invented way earlier than computers, so it was targeting humans / isn't optimized for digital compression, but it at least specifies _almost_ everything that you need to track.

The _almost_ is because to account for the repetition rule [2] you need to track all previous positions. At this point, the problem changes from "how to efficiently store the positions of the pieces in the board" to "how to efficiently store (partial) games", and you are probably better off listing the moves than the board state.

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

[2] https://en.wikipedia.org/wiki/Forsyth%E2%80%93Edwards_Notati...

[3] https://en.wikipedia.org/wiki/Threefold_repetition

most sites don't care about Firefox compatibility

This is FUD. Can you please name specific sites that don't work in firefox? Even all of google's stuff works fine, particularly when seen thorugh the eyes of non-technical people.

Bun v0.7.0 3 years ago

Can you point to that configuration in the apple store? I can't find _any_ M2 Air that can have more than 24Gb.

Your quote is from the 2002/58/EC directive, which is amended by directive 2009/136/EC [1]. The latter says :

(66) [...] Exceptions to the obligation to provide information and offer the right to refuse should be limited to those situations where the technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user. Where it is technically possible and effective, in accordance with the relevant provisions of Directive 95/46/EC, the user’s consent to processing may be expressed by using the appropriate settings of a browser or other application. [...]

Hence, so long as the use of cookies or similar is strictly necessary for the specific service requested by the user, a website doesn't have the obligation to obtain their permission.

[1] https://edps.europa.eu/sites/default/files/publication/dir_2...