twooster

I'd also consider that this will become increasingly important in the age of LLMs. Want Cursor to one-shot a change? Dollars to donuts the agents of the future will perform a lot better with well-reasoned, well-documented commits to use as reference.

On the other hand, job security?

https://www.benkuhn.net/lux/ maybe?

It seems to me that if, e.g., mandatory arbitration clauses can be binding, then so could a precondition clause allowing particular types of torts (or disallowing particular types of defenses). I imagine it wouldn't be too hard to convince a judge that engaging in a defense explicitly disallowed by the contract in dispute isn't fair play.

I guess the question is whether you can have preconditions at all on blanket licenses?

For example, if I say "anyone who sends me, by registered mail, a check for 50 EUR will be granted a license", and someone just uses my code without even attempting to send the check, is that copyright violation or contractual violation? It seems to me that would be a copyright violation, or else all copyright violations are just latent contract violations, in their most absurd extents ("I didn't sign the licensing contract they offered, but because they offered one at all, it's a contractual violation" seems to be a particularly weak defense).

Would this be fixable by adjusting, somewhat, the terms of the GPL? If the issue is that this is a contractual violation, would it be possible to put preconditions before granting a license in the first place -- such as requiring that legal claims for both copyright violation _and_ contractual violation are explicitly allowed before the license is granted?

Expanding on a sibling comment's reference to Simpson's paradox is the following analysis of the data:

https://www.covid-datascience.com/post/israeli-data-how-can-...

Basically, Israel is doing quite well even still. Yes, there's a reduction in efficacy, and yes there's breakthrough infections, but your risk of serious outcomes is still reduced by ~80%+, even in older populations _when correctly compared to unvaccinated older populations_.

It's been done: https://en.wikipedia.org/wiki/Disulfiram

Not as a vaccine, but as a drug.

https://en.wikipedia.org/wiki/Strong_and_weak_typing

Wikipedia disagrees with you in the opening paragraph about strong and weak typing: it's contentious. For all practical purposes that I can think of, TypeScript creates a strongly typed environment.

The problem comes when you're interacting with non-typed (or, worse, incorrectly-manually-typed) libraries, or misuse `any`. Honestly, I'd be interested to see a pure TypeScript program and where weak typing comes in. There are definitely a couple of language escapes (again, `JSON.parse`, previously `fn.bind`), but these are going away as TS gains better inference and type-propagation logic.

I've seen this take so many times an I simply don't get it. The notion that TypeScript can't be (some form of) strongly-typed because Javascript is (some form of) weakly-typed is just silly. CPUs are entirely weakly typed in this sense and this doesn't impact the typings of languages built on top.

JavaScript is strongly typed in the sense that every value has a well-defined type. It's weak in the sense that it has implicit conversion between types in a lot of cases, but it's not as though those conversions don't follow particular rules if you know the types.

TypeScript gives you accurate static typing on top of that, so long as you don't use `any` as an escape. Arguably, `JSON.parse` returning `any` is the 1-million dollar mistake of TypeScript, because it leads a lot of people to think that they get automatic runtime typechecking for free, which they obviously don't, which leads to comments about how bad/slippery TypeScript is stemming from their misunderstanding.

In my experience, you only need to work around typings in TypeScript when you're dealing with some absurdly designed API that only made sense in the super-flexible world of olden-days JavaScript, or perhaps if you're doing some meta-programming, generating class definitions on the fly or such.

You should almost always be running Bash in `-e` (exit-on-error) mode. This necessitates precisely the construct mentioned in this article.

For example:

  set -e

  var="$( false )"
  if [ $? -eq 0 ] ; then
    echo Ok: "$var"
  else
    echo Not ok: $?
  fi

Instead the following will work:

  set -e

  if var="$( false )" ; then
    echo Ok: "$var"
  else
    echo Not ok: $?
  fi

  if ! var="$( false )"; then
    echo Not ok: $?
  fi

You're right on your first estimation:

P(getting infected per touch) = 1/10000 = .0001

P(not getting infected per touch) = 1 - P(getting infected per touch) = .9999

P(not getting infected after 100 touches) = P(not getting infected per touch) ^ 100 = .9999 ^ 100 =~ .99

P(getting infected after 100 touches) = 1 - P(not getting infected after 100 touches) =~ .01 = 1%

Or, in other words:

1 - ((1 - .0001) ^ 100) =~ .01 = 1% chance of infection

By the same logic, your second estimation is a bit off:

1/5000 = .0002

1 - ((1 - .0002) ^ 100) =~ .02 = 2% chance of infection

That's a far cry off 40%.

To think about it another way, if the chance to get infected per touch is 1/10, and you touch a surface 20 times, is your chance of infection 200%? No, that doesn't make sense. It's 1 - ((1 - 1/10) ^ 20) =~ 87.8%.

That's the problem with statistics -- "everyone can do the math", but it's pretty easy to mix it up and reach the wrong conclusions and spread misinformation.

Was that comment spam, or just snark? But I guess bigotry is okay.

Free speech platform so long as it doesn't step on any in-group toes.

A bigger danger still would be:

  const userPromise = fetchUser(id)
  const itemPromise = fetchItem(itemId)
  // Do stuff, maybe even more async stuff
  const item = await itemPromise
  const user = await userPromise

This is really cool. Yet, somehow, as cool as it is, I find it terribly depressing. In comparison to other "look what I can do" projects -- such code golf, or demo programming, or quines -- which achieve impressive results in a constrained environment because it's challenging, thousands of programmers have HAD to do silly things in CSS because there's no other choice. These amazing-yet-hacky solutions get copy-pasted down through the generations and what should be simple becomes enshrined in the arcane. I look at this and become exhausted in empathy.

So in contrast to the opening line of the article, CSS is not amazing: people's talent for threading camels through the eyes of needles is amazing. Props to this guy for this. May I never have to recreate it.

Sadly they have to operate cooperatively. :/ I've taken great pains to prefix all of my builds with "${CI_JOB_ID}" and add a `clean` step at the end to tear down all created images. It's not perfect, but it works well enough in a trusted environment.

Gitlab gets a lot of love around here on Hacker News. I'm sure there's a lot of people setting up their own servers and maybe running into some questions/problems around setting up Docker-in-Docker style builds. There's some information out there, but I decided to put together a comprehensive-ish guide that maybe could be of use. Let me know if you have any questions!

I believe this is because vim manages drawing the entire screen, rather than depending on its terminal emulator to wrap lines, etc. This may be dependent upon configuration, and the setting `t_ut` (which is the background clearing color).

Anyway, using tmux for selection in vim is a bad idea. You can give vim mouse support by `set mouse=a`, which will prevent tmux from capturing selection and scrollback control if you like. Achieving parity between vim, system, and tmux clipboard (and for bonus points, across a network) is left as a "fun" exercise.

They did? There's expert analysis on the linked page. More in depth than a newspaper article, but more accessible than legalese.

Just because it's a lifestyle that many people would kill to have doesn't mean it's actually worthwhile. It just means it's well marketed. Like living and working in Hollywood, or being a banker in London.

If you drink the koolaid AND you get really lucky, you get to have a profitable business that changes the world for the better. For most, it's actually a job like anything else, just with the added expectation of utter devotion and unwavering belief.

I think her point is that despite the perks, she's just "shoveling it into her body", all of it, and can't quite get over the uncanniness of it all.

Also, I thought Facebook at first too, and thought it was a bit strong, then realized she was talking about LinkedIn.