Isn't road wear scale with the 4th power of vehicle weight?
EV vehicle weight definitely moves some needles in the wrong direction.
A Toyota Corolla weighs about 3,000, the Tesla model 3 weighs 3,500-4,000 depending on which model you buy. So a 16-33% increase in vehicle weight.
A Corolla will do 8.1 x 10^13 'damage points'
A light model 3, 1.5 x10^14 'damage points'
And a heavy model 3, 2.6x10^14
So moving to EV vehicles would move the damage done by the average commuter by an order of magnitude.
There are of course much heavier vehicles on the road as well, such as a standard empty garbage truck weights around 33k pounds and will do 1.2 x 10^18 damage points. So significantly more wear per mile traveled, but there are also far more vehicle miles traveled by those lighter class vehicles as well.
EV are probably still a net positive, but the real solution is to stop designing our cities and transportation systems exclusively around low occupancy vehicles. Walking, biking, and transit, also need to.be options for getting around.
Being free does not exempt a project from criticism. It's not like they were yelling about how terrible the project team was, just saying the issues they were having when trying to use it.
Agreed, but that’s not the point I’m making here. It’s not like this is some closed-source commercial product where the community can’t do anything about bugs/lack of features. My observation is simple: all of this time people spend complaining could be better spent helping to improve the project instead
Why can't people voice criticism and then work on the projects they want to work on instead of having homework and needing to learn the entire Jellyfin code base?
Nobody is personally insulting the devs as being lazy or incompetent. The devs can listen or not and they should have absolute control on what they implement and when. Its entirely reasonable that things they think are fine are pain points they don't realize exist because they've just gotten used to them. They also might not realize that some "wouldn't that be nice" thing they were thinking about implementing in the far future is actually something a lot of people want in the near term instead. There might also be things they just never even thought of.
The users of the software with criticism also aren't forced to use the software and should not be expected to implement anything they want unless they want to contribute. The project being open source ensures that in the future the project can be continued, if someone wants to continue it.
I do not disagree, there are horrible free projects with actively user-hostile documentation out there. But jellyfin is not that. Most criticism of it that I have heard falls either under a matter of taste ("I would do it differently"), a specific hardware setup not being supported or a skill issue during the installation which has more to do with administration of networks and Linux servers than with jellyfin.
And as a user of jellyfin myself I don't think these are particularly fair points of criticism.
Same thing that praise does. It's a discussion board, there's nothing wrong with people discussing the shortcomings of a project as well as its good points.
Not just extrajudicial punishment, but overlooking corrupt acts and crimes from fellow officers. That it's more important to maintain the 'brotherhood' than to arrest an officer caught driving home drunk.
And you don't have to pick just cloud or on-prem, you can utilize both. Use cloud for your bursty workloads, or for it's CDN/edge, and then your on-prem for consistent workloads. As long as you're not using cloud specific services you can run open source versions on-prem (such as minio for S3, or your own Postgres cluster, or kubernetes + what ever operator)
>but anyone running a mirror could hypothetically replace the package with another (potentially malicious) package, leading users to install malicious tooling.
I thought all packages were cryptographically signed, and that the package manager would compare the hashes of artifacts downloaded from mirrors to the hashes listed in the package index (which is also signed). This is not an attack that needs reproducible builds to mitigate.
A better one would probably be accounting and spread sheets. Having common formatting conventions between spreadsheets (and code files) allows your brain to filter out the noise better. Obviously you can get too down in the weeds on "what are the best conventions" but the most important part is to have them and stick to them.
The bulk of the pain is going to be felt by normal people and working class. Best case scenario you will only solve the problem at the airports the rich and wealthy use and leave the rest of us out to dry.
I mean, there's really no justification for the Get-Help cmdlet. The -h flag has been universal for decades. If it were a replacement for 'man' it would be defensible, but not when most programs do not acknowledge -h
EV vehicle weight definitely moves some needles in the wrong direction.
A Toyota Corolla weighs about 3,000, the Tesla model 3 weighs 3,500-4,000 depending on which model you buy. So a 16-33% increase in vehicle weight.
A Corolla will do 8.1 x 10^13 'damage points' A light model 3, 1.5 x10^14 'damage points' And a heavy model 3, 2.6x10^14
So moving to EV vehicles would move the damage done by the average commuter by an order of magnitude.
There are of course much heavier vehicles on the road as well, such as a standard empty garbage truck weights around 33k pounds and will do 1.2 x 10^18 damage points. So significantly more wear per mile traveled, but there are also far more vehicle miles traveled by those lighter class vehicles as well.
EV are probably still a net positive, but the real solution is to stop designing our cities and transportation systems exclusively around low occupancy vehicles. Walking, biking, and transit, also need to.be options for getting around.
reply