Markdown only makes sense for us meatbags becuse it's easy for us to edit and version control, but if you're sharing anything where the audience is an agent publicly, HTML must be just as interpretable.

I want evidence that proves "it's about cheap layoffs" or "it's about real estate" or "it's because they want to monitor people" or ""

Once we have evidence"it's about layoffs" then we can debate whether it's ultimately helpful or harmful to cull headcount that way.

I also found results suggesting flexible working policies had positive properties like higher employee satisfaction, retention , and a wider applicant pool.

I'm not interested in hearing why the choir here at HN thinks companies are making these decisions, I want to see evidence of their rationale so I can put myself in management's shoes.

  func OrderedLoop[A, B any](in <-chan A, done chan<- B, n int, f func(a A))

  func OrderedLoop[A, B any](in <-chan A, done chan<- B, n int, f func(a A, canWrite <-chan struct{}))

Offline order history is only a marginal improvement on the e-commerce experience from a customer and business perspective, so it's more appealing to us engineers who appreciate it as a feat of engineering prowess.

In other words, offline isn't PWAs killer feature. Besides, native apps can do it too.

PWA's killer features are circumventing the app store and the app store tax and not maintaining two codebases for Android and iOS.

Another Hacker News client would be a good example of a good PWA that you might install to your phone. It could have niceties like "save for later" or special styles applied to your favorite commenters. Offline support would be useful too, of course but not the main reason to develop a PWA.

Uncensored, paid content is another significant use case.

If we're talking about wealth not income, then no, not really. We don't usually think of asset seizure as "taxes". In other words, one "taxes" flows (like capital gains and wages) and "siezes" stocks (like bank deposits and equity).

"You seem to be positing that it's entirely expected and understandable"

I wasn't making value judgement, but yes, if you look at it with the assumption these wealthy individuals are cold, calculating, self-interested actors, then it's "expected and understandable" to me.

"That seems counterintuitive to me, at least."

I think you're using "intuitive" as a shorthand for "the way things ought to work in a righteous world", where I find incentives and disincentives to be a more intuitive way of understanding the world.

"wealthy individuals in well functioning systems should commit fraud to the detriment of the system that brought them their wealth"

To be fair, it's not necessarily fraudulent to have offshore accounts or to conceal your identity (it can certainly be depending on the circumstances). Technically I have an "offshore" account, I just happen to be living outside the US and a US citizen. I also use mechanisms to conceal my identity when registering domain names, for example. Is it the same thing, no, but these people might not technically be doing anything illegal.

It isn't necessarily true that those systems "brought them their wealth" either. Plenty of them likely inherited wealth that was accumulated long before the current systems were put in place (granted, it could very well have been accumulated illegitimately 300 years ago).

(Again, I'm not saying any of this is how the world should work, I'm trying to look at the world dispassionately and describe how things seem to be)

At the level of wealth we're discussing, these individuals probably have to think about "diversifying" among nation-states. Instead of worrying about whether to short the tech sector, they're worried about a country being invaded and the new puppet regime deciding to nationalize the hydroelectric dam they financed. Or they may be worrying about whether their country of residence will pass a law that the biggest national telcom must sell the government a majority stake (i.e., their share) at a government-mandated price denominated in an inflating currency... with expert bureaucratic efficiency.

So... no, not really taxes.

  "This suggests a counterintuitive result: use of offshore finance is driven not only by negative political conditions such as corruption and lack of civil justice, but by positive conditions, such as regulatory enforcement and civil justice."

Given so many of the comments here about tracking the offshore accounts down and confiscating the contents, it's no surprise.

Irrespective of whether their practices are immoral, unethical, unfair, or unjust, they're definitely not counterintuitive.

It's genuinely hard for me to understand how the authors could believe otherwise.

My conclusion is exactly the opposite. In-house developers can be expected (read: cajoled) to do things the "right" way, like follow links at runtime. You can run tests against your client and server. Internally, flexible REST makes independent evolution of the front end and back end easy.

Externally, you must cater to somebody who hard-coded a URL into their curl command that runs on cron and whose code can't tolerate the slightest deviation from exactly what existed when the script was written. In that case, an RPC-like call is great and easy to document. Increment from `/v1/` to `/v2/`, writer a BC layer between them and move on.

Links update when you log in or out, indicating the state of your session. Vote up/down links appear or disappear based on one's profile. This is HATEOAS.

Link relations can be used to alter how the client (browser) interprets the link—a rel="stylesheet" causes very different behavior from rel="canonical".

JavaScript provides even provides "code on-demand" as it's called in Fielding's paper.

From that perspective, REST is incredible. REST is extremely flexible, scalable, evolvable, etc. It is the pattern that powers the web.

Now, it's an entirely different story when it come to what many people call REST APIs, which are often nothing like HN. They cannot be consumed by a generic client. They are not interlinked. They don't ship code on-demand.

Is "REST" to blame? No. Few people have time or reason to build a client as powerful as the browser to consume their SaaS product's API.

But even building a truly generic client isn't the hardest thing about building RESTful APIs—the hardest thing is that the web depends entirely on having a human-in-the-loop and your standard API integration's purpose is to eliminate having a human in the loop.

For example, a human reads the link text saying "Log in" or "Reset password" and interprets that text to understand the state of the system (they do not have an authenticated session). And a human can reinterpret a redesigned webpage with links in a new location, but trivial clients can't reinterpret a refactored JSON object (or XML for that matter).

The folly is in thinking that there's some design pattern out there that's better than REST without understanding that the actual problem to be solved by that elusive, perfect paradigm is how you'll be able to refactor your API when your API's clients will likely be bodged-together JS programs whose authors dug through JSON for the URL they needed and then hard-coded it in a curl command instead of conscientiously and meticulously reading documentation and semantically looking up the URL at runtime, follows redirects, and handles failures gracefully.

Step 1: Post discreetly to a forum with minimal information and an absurdly short deadline

Step 2: Phone your friend, the former board member, to make your case on LinkedIn

Step 3: Ring up a friendly journalist and give them a tip

Step 4: Reference the insuing chaos as justification for keeping your project funded

Note that the article carefully avoids pinning the blame on DOGE or the Whitehouse while heavily implying it. MITRE is technically a private entity, albeit a non-profit. And the very last paragraph of the article states:

> A CISA spokesperson told CSO, “CISA is the primary sponsor for the Common Vulnerabilities and Exposure (CVE) program… Although CISA’s contract with the MITRE Corporation will lapse after April 16, we are urgently working to mitigate impact and to maintain CVE services on which global stakeholders rely.”

To be clear, the point isn't to say that the CVE program isn't valuable, nor is it to say that it's good for a shenanigan like this to be necessary.

The point is that, unless you're directly involved in this subject (not impacted—involved), it's probably best to maintain a "wait and see" attitude rather than succumb to catastrophizing this news.

Perhaps I'm wrong, but I believe HTTP streaming is for chunking large blobs. I worry that if you use this pattern and treat streaming like a pub/sub mechanism, you'll regret it. HTTP intermediaries don't expect this traffic pattern (e.g., NGINX, CloudFlare, etc.). And I suspect every time your WiFi connection drops while the stream is open, the fetch API will raise an error as if the request failed.

However, I agree you probably don't need WebSockets for many of the ways they're used—server-sent events are a simpler solution for many situations where people reach for WebSockets... It's a shame SSEs never received the same fanfare.

I want to delete my account—not unsubscribe. It's a cool idea, but only accessible to me between 00:39:00–03:39:00 (UTC-01:00). I'm too old for that! :P

I assume there is a way to delete my account behind the login wall… but I can't log in outside of the "open" hours.

Therefore, I'm stuck: I can't be online during the "open" hours and the login button is disabled and reads "Log in (unavailable)" during the "closed" hours.

I also tried to reply to your email with a data deletion request, but the delivery failed. There is no support email on the homepage, nor a way to message you directly via HN.

Each project gets its own Docker Compose file. These allow you to set up whatever project specific services and configuration you need.

None of your projects need to expose a port. Instead each project gets a unique name like `fooproject` and `barproject` and the container listening to port 80 is named {project-name}-web.

It all gets tied together by a single global NGINX/Traefik/Caddy container (you choose) that exposes port 80 and 443 and reverse proxies to each project's web container using Docker's internal hostnames. In pseudo-code:

  https://fooproject.example.site 
  {
    reverse_proxy fooproject- web:80
  }

  https://barproject.example.site 
  {
    reverse_proxy barproject-web:80
  }

  127.0.0.1 *.ddev.site

It may seem overcomplicated (and it is complicated). But since it's a de-facto standard and well-maintained, that maintenance burden is amortized over all the users and projects. (To the naysayers, consider: PopOS/Ubuntu are quite complicated, but they're far easier to use for most people than a simpler hand-rolled OS with only the essentials.)