And don't forget the Snap crap on it. I moved from Ubuntu to Debian and I'm more happy. I'm using Debian Testing and I find it more stable and less problematic that the Ubuntu (LTS or not)
You are incorrectly assuming the Esclade isn't on 32+" tires with 285+mm width and the Wagoneer isn't on pizza cutters. Tire size has increased greatly on SUV and light trucks, which exerts less ground pressure.
It's not realistic to do this on a heavy truck, which run 110+ PSI on heavy wall tires and why they cause the power law damage to roads.
No way does the Escalade exert less ground pressure!
Firstly, a Wagoneer is never on pizza cutters. You can't put a 4500lb car on pizza cutters even in 1990! It came with 235/75R15 tires. They are big sidewall donuts, but no pizza cutters.
The Escalade runs 285/40R24 tires, that's wide and low-profile.
Widening a tire increases ground pressure, because low-profile tires have massive amount of reinforcement to prevent that wheel from cracking. This stiffness adds to the pressure the road feels.
Tire contact patch is a function of weight and tire pressure. A 205mm width tire has the same contact patch as a 285mm tire, given same weight and pressure. The only thing that changes is the shape of the contact patch, which becomes wide and short instead of narrow and long.
The 6000lb Escalade runs its 285/40R24's on 35 psi, the Wagoneer runs its 235's at 30 psi.
So assuming even weight distribution, the contact patch per tire is 6000lbs/4/35psi=42.8in^2 inches for the Escalade, and 4500lbs/4/30psi=37.5in^2. So the contact patch is only 14% larger on the Escalade, yet it carries 33% more weight!
If you look at the road wear formula, it's entirely a function of weight. So the width of the tires only impacts surface-level abrasion. And with the power law, that's still 3.16x of Wagoneer's wear (or 216% increase).
So the wider tires do virtually nothing to protect the road from the extra 1500 lbs weight.
In fact, the dynamic load when hitting potholes is greatly exacerbated by the 285/40R24 low profile tires, because instead of of absorbing the bumps within the tire, the stiff sidewall low-profile tires absorb way less.
The spring rate of the Wagoneer tires is ~1200-1500 lbs/in, the spring rate of the Escalade tires is ~2500-3500 lbs/in, so that's a 2x stiffer tire! As a result, it transmits twice as much force when hitting the same bump.
So as a result, an Escalade accelerates road cracking considerably worse than the Wagoneer, not even in the same league.
Yes, the heavy trucks wear the road outsizely, incomparably to the SUVs we are discussing. However, we have roads that do not allow trucks (parkways) or see little heavy truck traffic.
The tire spring rate is not what is "felt" by the road every bump, there is forward motion and coilover suspensions in modern cars running low profile tires versus solid axles and leafs on the Wagoneer, but yes nearly every modern vehicle ships on low profile tires unfortunately.
We are talking a few hundred pounds of weight difference per tire, it simply doesn't matter in the real world. I maintain private roads and even if your parkway is placarded everything is subjected to vocational vehicles and HDTs whether signed or not, because work needs to be done and local deliveries are exempt from transit restrictions.
The road wear model is obviously simplified versus the real world, the power law accurately enough extrapolates to HDT axle loads. You can drive a vehicle above snow, or move million pound super loads without causing excessive wear by thinking in additional dimension.
Typical meme. Passenger vehicles of any type cause negligible road wear. The weight of a sedan (say, 4000lbs) versus a light truck (say, 6000lbs) is just not significant, further the ground pressure will be close due to tire sizing (https://en.wikipedia.org/wiki/Ground_pressure)
Correct, one of those “fun facts” of public policy is that (at least in the US) taxes and other fees, including on fuel, paid by heavy commercial trucks don’t come anywhere near paying for the damage they do to roads. The rest of us subsidize shipping-by-road with our taxes.
(Whether this is a good idea or not is debatable, but it’s the way things work right now and the fact that we subsidize truck shipping to the tune of a large amount of money is not widely known)
People found this worked in the past and it gets copied around. There is no reason to disable some of this. Bridge will automatically disable LRO and find the common set of other offloads. TSO is not useful for a bridged guest.
Generally people get more excited any time a major release of anything comes out. But FWIW HN has always had favorable front paging for anything related to FreeBSD and OpenBSD.
Not disagreeing, but if the release was a few months ago, then the poster is quite correct - there is a recent "surge" of FreeBSD related posts. And these are not quite ... how shall I word it somewhat nicely ... not quite as fascinating to, say, a wider linux community as such. With that I don't mean "because we use linux, we are snobs", but that what the FreeBSD guys talk about, seems a little bit ... outdated. The heavy use of shell scripts for instance in this post here - I never understood that focus on shell scripts in general, including on Linux. I transitioned into using ruby (or python, but mostly ruby) to replace all shell script needs a long time ago. Every time I am assumed to have to write a shell script I wonder why I would want to cripple myself when I can use a better programming language instead. Many of these shown "innovations" are also not really groundbreaking. To me it seems as if there is a distinct lack of FreeBSD users out there compared to Linux users. As a consequence Linux simply has a lot more information and news (a lot of which is also low quality of course; I am not saying it is all pancakes and sunflowers in the Linux ecosystem either).
> The heavy use of shell scripts for instance in this post here...
There's exactly one in the post. It's ten non-blank/non-comment lines, and the author says of it
This is not well designed but it gets the job done.
My least favorite thing to see in the world is a Ruby, (worse) Python, or (much worse) Go program that could have been a very simple shell script.
When my sysadmin programs get more complicated, I reach for something more suited (like Erlang), but if the shell script is simple and only has deps on other standalone programs, then I write a shell program.
No conspiracy, I think it just happens. One person posts something, maybe someone else reads it and gets into a rabbit hole on a topic, or maybe someone sees an opportunity to throw more conversation pieces at something hot.
Depends what you are accounting and optimizing for. At the high end of computing this is generally true but occasionally vendors get pretty far in front of their skis to goose performance like current Nvidia hardware or the P4 of yore. There are plenty of SoCs over the last decades that use a few watts that can do useful work. An MSP430 of any vintage could run for years on a battery bank. If the desired work meets a small power envelope newer doesn't automatically win if you are working in small quantity like home projects.
This seems like an evergreen content topic. It's obvious that IPv6 adoption is high enough and critical for some industries in particular (i.e. cellular providers) with lots of endpoints. Increasing endpoint adoption is good. But service providers need to care about the remaining percentage. Say you get to 80, 90, even 99% adoption. An SP still can't flip IPv4 off. So what does it matter? It really doesn't warrant much concern.
Yeah. There's a type of person who's obsessed with "cleanliness". For such a person, the goal is to have exactly one protocol on The Internet.
Such a person would lose their goddamn minds if they had to actually work as a WAN administrator or datacenter operator.
One of IPv6's purposes is to reduce pressure on the IPv4 address space. I don't expect IPv4 to get deactivated within the lifetime of any current HN reader; there's really no point in doing so. I expect the future for noncommercial sites to be "globally-routable IPv6 service, and IPv4 service by way of a CGN", which is how things are set up today in some parts of the world.
IPv6 will be the default, with v4 as a fallback for folks need to talk with others who can't be bothered to update their software or kit.
When you get to high 90s adoption you can start to run v4 as an overlay on a V6 native network. That's what the big US mobile carriers do, when they use 464XLAT, the edges get v4, but it all gets tunneled/translated to v6 in the middle.
It allows you to put the deferred logic near the allocation/use site which I noticed was helpful in Go as it becomes muscle memory to do cleanup as you write some new allocation and it is hinted by autocomplete these days.
But it adds a new dimension of control flow, which in a garbage collected language like Go is less worrisome whereas in C this can create new headaches in doing things in the right order. I don't think it will eliminate goto error handling for complex cases.
reply