onetoo

For reference, what would you say those bad defaults are? (I would like to know if I should consider changing my configuration)

The equivalent in python-metaphor-land would be that python files clearly designate whether they are py2 or py3, and a single python interpreter can run both py2 and py3 scripts, as well as cross-include files of each version without issue.

Rust editions only (and rarely!) break your code when you decide to upgrade your project's edition. Your public API stays the same as well (IIRC), so upgrading edition doesn't break your dependents either -unless they don't have a new enough version of the compiler to support said newer edition.

IIRC it's a single ministry with not a lot of machines (in the order of 100). Definitely not as newsworthy as it's being made out to be, but viability has to be confirmed before a larger rollout can be done, I suppose.

  > Even more annoying is that I have to duplicate the iterator code: as I often work with frames that may be flipped bottom-up I want to write code like
  >
  >    let mut iterator = if !flipped {
  >       data.chunks_mut(stride)
  >    } else {
  >       data.chunks_mut(stride).rev()
  >    };
  >    for line in iterator { ... }
  >
  > but I can’t since objects have different type (and probably size) and there’s no realistic way to coerce them to the same interface.

For this specific case there is a relatively ergonomic solution using dynamic trait objects + temporary lifetime extensions, available since Rust 1.79:

  let iterator: &mut dyn Iterator<Item = _> = if !flipped {
    &mut data.into_iter()
  } else {
    &mut data.into_iter().rev()
  };
  for line in iterator { ... }

Alternatively, if this is not a feasible solution (e.g. we want to return the new iterator to an outer scope, or the overhead of dyn indirection is unacceptable in this context), one can consider using itertools::Either instead:

  use itertools::Either;
  fn conditionally_flip_iter<I: DoubleEndedIterator>(
      data: I,
      flipped: bool,
  ) -> impl Iterator<Item = I::Item> {
      if !flipped {
          Either::Left(data.into_iter())
      } else {
          Either::Right(data.into_iter().rev())
      }
  }
  // ...
  let mut iterator = conditionally_flip_iter(data, flipped);
  for line in iterator { ... }

This doesn't necessarily find the best parameters, and it doesn't necessarily do it easily. From my reading, it will converge on a local optimum, and it may take some time to do that.

In theory, I don't see why the kernel couldn't have a parameter-auto-tune similar to this. In practice, I think the kernel has to work in so many different domains, it'd be impossible to land on a "globally good enough" set of tuning heuristics.

I'm far from a kernel developer, so I'm ready to be corrected here.

IMO if we ever see something like this deployed widely, it will be because a popular distribution decided to install it by default.

I obviously can't speak for everyone, but I personally don't know anyone who strongly dislikes the US, and especially not US citizens.

The sentiment I personally hear when talking about the US (and, again, I don't speak for everyone) is more akin to the kind of sympathetic concern you might have for a friend who's become an alcoholic: It pains you to see them hurt themselves like that, but their temper flares when you suggest that maybe they drink just a little bit too much. But they can't be helped until they're ready to admit that they have a problem, unfortunately. So until then, all you can do is pray they don't crash when drunk driving.

> e.g. it hasn't yet happened in Britain

Granted, I don't follow it closely, but from what discourse I've observed things on the other side of the pond don't seem quite harmonious to me.

> I'm not that sure it was entirely true even in the US between 1940 and 1980 either.

Which does not necessarily disprove the argument. Things were arguably less polarized and better working in the past, but my argument is exactly that the political incentives of a two-party system will eventually cause things to degenerate. The fact that things were once "reasonable politics" but have, over the course of decades, degenerated to "our policy is whatever is the opposite of their policy" is exactly the issue.

> Is it radically different in multiparty systems, though? If you are outside the government coalition you have similar incentives.

Similar, yes, but not necessarily the most effective political move.

If a disenfranchised voter can vote for a third (or fourth) party without their vote "being wasted", a strategizing disenfranchised voter no longer "has" to vote for a "least-worst" option in order to avoid the "most-worst" option.

In that case, painting your opponent as "even worse" does not necessarily win you votes. If it does, it likely also gives votes to the other parties in your political sphere, and if they get enough votes to make a coalition government without you, why should they bother to include someone whose primary policy is being a troublemaker?

---

To be clear, no system is perfect. I don't know what the best is, I just know it's not FPTP. The primary argument I am trying to make is that the polarization we see now is the inevitable (long-term) outcome of a two-party system, and that a two-party system is the inevitable outcome of winner-takes-all FPTP.

> Thankfully US has all sorts of checks and balances and it might take a while for a single party to get control of the House, Senate, White House and the Supreme court

The fact that "it is good when government is deadlocked and ineffective" is an actual argument people use is baffling to me, but for the sake of the argument and out of assumed mutual respect, I'll do my best to stay objective for following:

> IMHO electoral systems matter but extreme polarization is the real problem

I absolutely agree that extreme polarization is a major issue.

I believe that FPTP inevitably leads to extreme polarization, when given enough time: FPTP inevitably converges to a two-party system (due to strategic voting), and a two-party system inevitably leads to extreme polarization (due to strategic politicians playing into strategic voting).

The argument for the latter goes something like this: Disenfranchised voters can be coaxed to vote for a least-worst option when the most-worst option looks worse enough. So it becomes more politically effective to demonize your opponent rather than argue your own politics.

Additionally, it is politically beneficial for you when things stay bad while your opponent is in charge, and especially so if things get worse. You can use their perceived incompetence as ammunition to further demonize them. So it becomes beneficial to use what government power you might have in order to hinder your opponent's attempts at improving things, even if what they're trying to do is something you agree with and would yourself do if you were the one in power.

Depending on your preferred political party, I'm sure you can think of examples of the above.

Not from Berlin, but I imagine it is similar: It is usually the case that the more shady your "kebab pusher" is, the more delicious the kebab is.

If the sign says one price, the cashier says a second, and the cash register says a third? You've found the best kebab in town.

Also from EU, additional tidbit: Not being a first-past-the-post two-party system allows for political parties to be more nuanced than a simplified left-right spectrum.

And, as we all know, becoming a father when you do not wish to is completely without consequences, making the entire ordeal risk-free. Male birth control pill is useless, QED.

By that logic, female birth control pills also have no value.

"But if you dump the toxic waste into the river, there will be no river left," said the citizen.

"lol" said the factory, "lmao".

If the EU is regressive then I don't want to live in your progressive society.

As I said, I would love to work on things out of passion.

I would love to work on things out of passion, but passion doesn't shelter me from the elements nor provide a steady source of calories.

If you want to split hairs about exact terminology, then /reasons/casus belli/. I hope we don't disagree that their "denazification" story is bullshit.

I don't know the exact procedures, but I imagine and would expect that they reopen the case if new substantial and substantive leads show up.

Maybe that combined with the fact that Russia actively invaded another country for bullshit reasons means we don't want to point fingers at Russia without solid evidence, lest they use it to invent yet another bullshit reason to invade, I don't know, Sweden?

That specific reasoning is also bordering on conspiracy, but my point is that I don't think it's suspicious that countries aren't pointing fingers at Russia without solid evidence.

Being out of things to investigate is a reason to end investigation. It is possible to follow all leads to the end and still have no conclusive evidence.

An alternative explanation is that there is simply not enough evidence to tell one way or the other.

No, but, you see, the system is privatized, therefore it must be more efficient. /s

I don't know much about the specific space of ILP, but speaking more generally...

It is sometimes possible to specialize algorithms and implementations to be faster for certain subdomains of the overall problem, allowing real-world-useful problems to be solved in reasonable time despite the generalized theoretical complexity bound.

If this new algorithm is a fundamentally different approach from the current ones, this may allow ILP to be used in domains where it is currently infeasible. Vice versa, this new algorithm may not be feasible in domains where current tools thrive.

Indeed, it was a good question. That's why I couldn't let it go either. I personally find the result quite interesting. Counterintuitive, but the most uniformly distributed load is probably the most likely to recover.

As always, https://xkcd.com/356/

edit: I did some more investigation, and I missed something crucial: The distribution of requests over time becomes very wonky if the lower bound isn't 0. It stabilizes given enough time, but that time seems very long. Whereas lower-bound 0 quickly becomes uniform.

See the following figure, where I plot the # of requests over type: https://i.imgur.com/PNUFhjc.png

And that is why you should use 0.

---

I am not an expert, but I got nerd-sniped.

I have made some simulations[1] and done some napkin math[2], and I would summarize as follows:

I don't think there is any globally optimal, I think it depends on your exact circumstances, and which of {excess waiting time, excess load} you want to optimize. Defaulting to 0 is a lot easier to implement, and is at most a factor 2 worse than the optimal lower bound w.r.t. waiting time vs. load. You may also consider [0.5 * maximum, maximum], which trades some excess waiting time for less load. Your suggestion is a similar heuristic one might use depending on their exact circumstances.

[1] https://gist.github.com/Dryvnt/1984d9389ae7386127f5e8998bf52...

[2] Consider a family of random bounded exponential back-off strategies with ultimate upper bound U as follows:

  Strategy X(z): Random of [z * U, U], where z is constant, 0 <= z <= 1

There are other families of back-off algorithms with other characteristics, and I am not considering or comparing those, just this family. Note that strategy OP suggests is X(0). Consider that X(1) is non-random, which is undesirable.

Simple probability tells us

  avg(X(z)) = (1 + z) * U / 2

Server load ~= frequency, frequency is inverse duration, so

  load(X(z)) ~= 1 / avg(X(z)) = 2 / (1 + z) * U

The difference in load between any two X strategies is

  load(X(z1)) / load(X(z2)) = (1 + z1) / (1 + z2)

Since z1 and z2 are constant, this relative load is constant. Due to the bounds on z, the largest possible relative load is

  load(X(1)) / load(X(0)) = 2 / 1 = 2

Now consider your suggested strategy

  Strategy Y: Random of [L, U], where L is the last choice

Note that

  Y = X(y), where y = L / U.

In fact, Y approaches X(1) exponentially fast, since the difference between L and T is halved each step, on average. So your suggestion still falls within this at-most-factor-2 difference. Exactly where just depends on the outage length.

Oh the complexity and pain I go through in my quest for "keeping it simple."

It's fine, my server for stupid side projects is a cheap VPS with a systemd-based configuration anyway, I am just trying to figure out all the failure modes here vs "apt-get install postgresql", including, most likely, myself.

Cool. I'm still trying to wrap my head around how to use it responsibly: Is this a "good, old fashioned" single durable server type of deployment?

I was wondering if you had any experience with, essentially, "always restore DB during startup".

I like my systems made such that the server can die, get scaled vertically and oops data disk wiped, forget to mount volume in a container, etc. without me lifting a finger. It looks like I can do that with litestream, but I always want to hear from people who have tried it in the real world.

Out of curiosity, have you ever needed to restore a litestream backup?

Not just private chat, almost any chat channel can be used[1]. It's quite common for certain addons to quietly share their versions upon e.g. joining a group, so that you get a notification if a new version is out. It's a bit of a longer explanation, but another fun example of out-of-band privileged information in World of Warcraft:

The "fight" between Blizzard's boss design and addon creators trivializing said encounters is long and not worth going deeply into. But, for example, if the strategy of a boss is "if you get a glowing glyph over your head, run over there and stand in a square formation with the other guys with glowing glyphs", an addon could use hard-to-ignore sounds and visuals to tell you that a) you have to run now, and b) exactly which corner of the square formation to run to.

I believe that in the latest raid, the developers tried restricted certain information from the API (e.g. "there is a glyph over the player's head") in an attempt to reduce that kind of strategy automation. The players then proceeded to manually feed this information (e.g. "i have a glyph over my head") into their addons using buttons mapped to API calls like this, allowing for partial automation (e.g. "your corner in the formation is top-left"). This stirred quite the drama, but the that's besides the point.

[1] https://wowpedia.fandom.com/wiki/API_C_ChatInfo.SendAddonMes...

I'm not from the US, but I do follow the issue due to the US-centric nature of internet culture. From what I understand, it is a bit of a catch-22:

  - You cannot make public transport a feasible option because
  - Most places do not have the population density required because
  - Places are designed in a car-centric manner, with strict zoning laws that enforce low-density suburbia because
  - Everyone has a car because
  - Public transport sucks because
  - You cannot make public transport a feasible option because

To me, the solution to the problem you state is not more parking, but less cars. Break the cycle.