Chobbes @ Chobbes @lemmy.world

Posts

0

Comments

465

Joined

2 yr. ago

Seriously? Boo :(

There’s something kind of funny about one of the largest expenses being SMS and voice calls to verify phone numbers when one of the largest complaints about signal is the phone number requirement. I wonder how much this cost factors into them considering dropping the phone number requirement.

Okay, I couldn't look at this table when I responded last night (I thought you were referring to the zip files, not the PDFs at the bottom). Got a chance to look at them on my computer today!

Would you call the point where I_x = 1/2 I_0 the life expectancy at birth? In the life tables you link to (direct link to the 2020 table) there's an "expectation of life at age x" column which differs! My understanding is that in official metrics of "life expectancy" they usually mean the "life expectancy at birth", which is calculated in the "expectation of life at age x" column in this data set, do actuaries use a different definition?

In this table "life expectancy at birth" is estimated at 74.2 for men in the USA in 2020. This is calculated in this table by computing T_0 / I_0, which is the arithmetic mean for the ages of death in this period. The estimate for the median age of death in this table is between the ages of 79 and 80. There's about a 5 year difference between these two numbers, and furthermore only about 40% of the population of men has died by the ages of 74-75 in this table, which is quite different from 50% if we assume "life expectancy" is this arithmetic mean. These are pretty big differences, and I really wish people / articles would be more clear about how the number they're quoting was actually calculated and what it means! The estimated median age of death from the point I_x = 1/2 I_0 is a useful measure too, but I have no idea what a random person or article intends when they say "life expectancy" :|. I've grown to deeply distrust any aggregate measure that people discuss informally or in news articles... It's often very unclear how that number was derived, what that number actually means in a mathematical sense, and if it even means anything at all.

That marks the median age of death, but I don’t think that’s the definition of life expectancy (though maybe the term is used loosely or imprecisely to mean the median age of death or the average (mean) age of death in different situations...). The definitions of life expectancy I found claim it’s the mean age of death, which would make sense because the expected value of a random variable is the arithmetic mean. That said, the median on the life tables that I have found seem to correlate much more closely to the age of 77 versus the life expectancy at birth which is much lower (78-79 for the median and 74 for the life expectancy at birth for 2020 data)… but the actual paper is behind a pay wall so I have no idea what they’re actually computing for 77 years of life expectancy… my guess is that it’s the median and not the mean, but maybe they’re considering people over a certain age or something… either way, the mean / median getting confused is an issue and I wish people were more clear about what metric is actually being communicated.

Well, the definition of the mean and median of a sample doesn't depend on the particular data set, and there's plenty of non-age related causes of death in the world which would logically skew the distribution to the left! You can look at actuarial tables to see this in action:

https://www.ssa.gov/oact/STATS/table4c6.html

Male life expectancy at birth in this table is 74.12, but you'll notice that you don't get to 50% of the population dying until somewhere between the ages of 78 and 79.

This website has a pretty good chart showing the skew for a 2019 dataset:

To me mean = average, so the two statements are the same.

Are you talking about median age of death?

The median is the midpoint of a sample, not the mean. So, the median point represents the age where 50% of people will live to, the mean does not represent that (it's often relatively close to the median assuming the data doesn't have too much skew, but it can be way off).

When child mortality was very high (pre- 20 century) that was definitely the case. I am not so sure that it is now. I feel that average life expectancy will be a lot closer to 50% survival rate (median age of death) than it was in the past.

There are still plenty of people who die young, even though child mortality is less of a factor in wealthy countries right now. Plenty of people die in car accidents at a relatively young age, for instance. I'm sure the median and mean aren't like 10 years off of each other, but I wouldn't be surprised if they're 3 or even 5 years off, which could be pretty significant in this context.

That figure is average life expectancy. IE 50% of US man are expected to reach 77.

I can't access the full paper that this is in reference too, so I'm not sure how they calculate it... but isn't life expectancy usually the mean age of death? I would expect the distribution to have a left skew from people who die young, which should mean that more than 50% of US men are expected to reach 77.

Watching a play through would be kind of terrible to be honest. It would really spoil the game (more so than pretty much any other), and I just don’t think it would be fun to watch a play through of at all.

Hope you have a good time with it! It’s pretty cool and it’s probably one of the games that I have thought about the most after playing it. There’s a lot of really interesting sci-fi concepts in it. That said I will warn you that while I think this game is very good and very worth your time (especially since it’s a fairly unique experience), I do think that the game is really hyped up by people… and I’m on the fence about whether it deserves it. It’s a little rough around the edges and clunky in ways that detract from the experience a bit in my opinion. If you go in understanding that it’s going to be a little clunky and awkward I think you’ll have a better time — it’s not a perfectly polished masterpiece, but it is an interesting piece of work that’s something you won’t really find elsewhere.

Yeah, I don’t have good answers for you… I honestly don’t know what the best way to get people into it is. The resources really are not great.

FWIW I think when it does end up clicking everything is a LOT less complicated than it seems at first. Nix is sort of all about building up these attribute sets and then once that really sinks in everything starts to make a lot more sense and you start to realize that there aren’t that many moving parts and there isn’t much magic going on… but getting there is tricky. A lot of people recommend the nix pills, and honestly I think it’s the best way to understand nix itself. If you do earnestly read through them I think there is a good chance you will come out enlightened… they just start so slow and so boringly that it’s tempting to skip ahead and then you’re doomed. They also have a bit of a bad habit of introducing simple examples that don’t work at first which can be confusing, and eventually some of the later stuff seems like “ugh, I thought we already solved this” but it’s building up nicer abstractions. The nix pills give a pretty good overview of best practices in that sense, I think… so maybe it’s the source of truth you’re looking for (or part of it anyway). I think the nix pills are a bit more “how the sausage is made” than is necessary to use nix, but it’s probably the best way to understand what all of these weird mkDerivation functions you keep seeing are actually doing, and having an understanding of the internals of nix makes it a lot easier to understand what’s going on.

I think Lutris can install its own versions of wine which is probably why it’s not included (also you don’t need to use wine at all with Lutris). I guess I’m not surprised you ran into these issues on Arch. I wouldn’t expect this on the more mainstream distros a new Linux user would be likely to use, since these distros are more likely to take a batteries included approach to packaging. I’d hope running into missing dependencies when launching a program is a fairly uncommon experience, at least for anything installed with a package manager on most systems.

I am annoyed whenever I launched something from dmenu and I don’t get error output or logs anywhere.

I do wonder why you would have missing dependencies for all of these applications? Shouldn’t your package manager handle that…?

For sure! I don’t think we’re actually in disagreement at all, just the limits of text communication :). NixOS is certainly less important to me and I don’t really care if people use it or not at all (it’s nice but there’s enough differences that you have to be aware of that it’d be frustrating to some people — even if ultimately those differences are something that can be worked around… If you’re well versed in nix and Linux NixOS is kind of a no brainer, though). Nix for development (or something like it) is legitimately enough of a game changer to warrant some of the evangelism in my opinion, particularly since as you mention it’s pretty much free to try on any (non-windows) system, and adding nix to a project doesn’t harm non-nix users (more than they’re already harmed anyway, haha). I’ll admit that I worry about how “nix ugly and unintuitive” seems to be a huge problem for adoption, and frankly I don’t blame people for bouncing off of nix (I bounced off of nix in 2011 or so and didn’t come back to it for like 10 years — though it was a bit of a brain worm nagging at me the whole time). That said I think the impression people have of nix being this horrible and completely ugly language (an impression I’ve had in the past as well) is also somewhat untrue. The nix language itself isn’t so bad, but the expectation is for it to just be yaml because “I just want to list dependencies”, which is fair and it might be nice if we had some better abstractions to make that more clear. All of the phases in a nix derivation are confusing and poorly documented, and some operations on attribute sets should probably just have nice special syntax instead of these fancy update fixpoints that the average developer isn’t going to understand… ultimately I’m a little unclear on how much of this is “the nix language sucks and needs to be thrown out” and how much is “we really need a better introduction to what this is and how to use it, especially with some beginner examples and best practices for different languages”. I worry a bit about non-nix nix package managers just from the perspective that it’s really nice to have the one tool to rule all development environments, but maybe fragmentation won’t be a huge problem.

I don't think it's an apt comparison of the distros, but I agree that both have a cult-like following. I also feel like there's a bit of a difference in the evangelism of both distros... I don't really understand why people evangelize Arch, and my impression is largely that (1) people mention that they're on Arch so others know they might be having different configuration issues, or less charitably (2) people mention Arch as a weird brag because it's seen as an "advanced" distro. In contrast people seem to recommend nix and NixOS because it solves a frankly ridiculous amount of real problems that people experience with development environments, package managers, and system management. I.e., we bring up nix and NixOS because we care about you and think it might actually be useful for you. I don't really want to dictate what other people use or brag about using nix / NixOS, but people complain to me about different problems constantly that are just resolved by nix, so it feels wrong not to mention it. It's frustrating because it definitely makes you seem like you're in a cult, but it really is the right level of abstraction for package management, and as a result it solves so many problems and little frustrations.

Honestly, it's kind of frustrating to watch people not use nix. I have nix set up for the projects at work because I got tired of them not building and people randomly changing dependencies and it taking 3-4 weeks for somebody new to the project to get the thing to compile. Everybody new that I have set up with nix gets the project working instantly, and everybody else ends up spending weeks flailing around with installation. Unfortunately, I've given up on recommending people use nix for the project because a number of senior people have decided that they don't like nix and there's a bizarre amount of drama whenever I recommend a newbie just use it to get set up (even though it has always worked out better for them). It's just not worth the headache for me to stick my neck out, but I feel bad and it's really frustrating how literally everybody else takes 3-4 weeks to get up and running without nix :|.

I think it depends on the user :P. NixOS is pretty hard to get into because the documentation isn’t great… but I’d argue it’s one of the most user friendly ways to configure a system, and it can be really nice to copy configurations from other people.

It’s the probably the best distro for dev work imo. Nix in general is really nice for development. Games work fine — you can just install steam or putrid or whatever, and you can run normal binaries with steam-run.

I would disagree. I feel like nixpkgs has pretty much everything, more so than any other distro in my experience. The differences in how NixOS work can make it a little weird to run something off the cuff, but steam-run has your back in those situations.

Calling NixOS the new arch is needlessly insulting lol.

These things are so awesome. I had one once and it’s burned into my memory far more than it should be.

Trackballs are great! I wouldn’t necessarily recommend anybody switch if they’re happy with what they have, but they work pretty much as well as a mouse for most tasks, can be better for RSI, and don’t need as much desk space because the device is just stationary. I have both a mouse and a trackball on my desk to switch things up, but the trackball gets the most use. My main gripe with the trackball is just that you have to clean the gunk out every so often, but otherwise it’s awesome.

It’s going to depend. If it’s a really old game it’s unlikely to matter. Anything heavy on CPU and particularly single core performance may struggle through a translation layer. A good translation layer on a good chip will probably lead to roughly similar performance in many cases, and most games seem to be GPU limited, so it’s possible it will just work out most of the time. It could always be the case that a critical section of the code somewhere ends up not translating well, leading to poor performance. It would not be terribly surprising for an important loop to end up two or four times slower than it should be, which could cause hiccups.