It is not just hate because of EPA requirements. These engines are more complicated and prone to failure. Small time operations can not afford the expensive repairs combined with loss of income during repair downtime.
As a result, only corporations remain or the few remaining owner operators avoid any engine newer than the year ~2000. These older vehicles also have the added benefit of having minimal electronics, sensors, and ECMs.
The "more prone to failure" seems to be driven by some abjectly terrible implementations (eg the notorious Kubota B3350). And it's certainly understandable that someone who knows how to repair things based on mechanical linkages would rebel against digital electronics.
But we're on a technology website. We shouldn't really be scared by a extra sensors, a CAN bus, and an embedded controller - assuming all of these things are openly documented and usable with freedom-preserving systems. In fact we should welcome them, as extra telemetry can help avoid downtime and effect repairs.
> And it's certainly understandable that someone who knows how to repair things based on mechanical linkages would rebel against digital electronics.
They're pretty right to be incensed that something that used to take one skill set now takes two.
>. We shouldn't really be scared by a extra sensors, a CAN bus, and an embedded controller - assuming all of these things are openly documented and usable with freedom-preserving systems
At what cost? For what benefit to the user?
>. In fact we should welcome them, as extra telemetry can help avoid downtime and effect repairs.
Oh, great, so the someone at the OEM can decide my model correlates with a higher $$ use and jack up parts cost. I don't trust you not to do this and I don't even own a tractor. Someone in middle america who's been on the receiving end of the raw deal that the "educated" classes have been peddling for the past 40yr has even less reason to allow your telemetry.
If you had bothered to pause grinding your axe, you might have read the part of my comment where I said "assuming all of these things are openly documented and usable with freedom-preserving systems"
I think regardless of implementation, if the added complexity reduces reliability and introduces forced failure modes it's reasonable for people to avoid these systems altogether. For example, EGRs causing fouling or DEF engine throttling.
This may be true for our group, but I know numerous blue collar workers at the poverty line struggling due to these systems. Corporations / manufacturers have no incentive to make these systems more accessible. Even if they did, more complex -> more expensive to repair.
> Corporations / manufacturers have no incentive to make these systems more accessible
That's the exact point of actual right to repair legislation.
> Even if they did, more complex -> more expensive to repair.
No, this is not true as a general rule. For example if problems can be diagnosed easier (or even ahead of full failure) with digital controls, this brings down the cost of maintenance. Or if the hardware shrinks in complexity while the software grows in complexity more, this can still be a win as individual bits of a digital controller aren't likely to break down.
But on this topic we aren't actually talking about manufacturers being able to resume production of the previous non-digital engines. This would require actually repealing the Clean Air Act, and probably even directly mandating that manufacturers remove such systems from their current designs.
Rather the only thing this declaration seemingly does is remove one excuse manufacturers have for having locked down their systems with digital restrictions, with the goal of allowing customers to "disable" those extra controls "temporarily" - not really an actual win for any of the repairability or cost issues you bring up.
This is the same fundamental dynamic I've observed in all of the destructionist policies - large print that performatively throws a bone to those suffering, but the actual details don't even try to unwind the poor dynamic - never mind attempting constructive solutions (in this case, straightforward right to repair legislation).
I'm actively in the process of setting this up for my devices. What have you done for off-site backups? I know there are Borg specific cloud providers (rsync.net, borgbase, etc.). Or have you done something like rclone to an S3 provider?
No off-site backup for me, these items aren’t important enough, it’s more for “oops I broke my computer” or “set my new computer up faster” convenience.
Anything I really don’t want to lose is in a paid cloud service with a local backup sync over SMB to my TrueNAS box for some of the most important ones.
An exception is GitHub, I’m not paying for GitHub, but git kinda sorta backs itself up well enough for my purposes just by pulling/pushing code. If I get banned from GitHub or something I have all the local repos.
Good to know! I have shifted more to self hosting, e.g., Gitea rather than Github, and need to establish proper redundancy. Hopefully Borg Backup, with it's deduplication will be good, at least for on-site backups.
I am much more in-between. I don’t mind cloud stuff and even consider it safer than my local stuff due to other smart people doing the work. And I’m not looking for a second job self hosting, except for my game servers.
I mostly just don’t want to be stuck with cloud services from big tech that have slimy practices. I’d rather pay for honest products that let me own my data better. With the exception given to GitHub which I guess is out of my own laziness and maybe I should do something about that.
If you’re using gitea you might be interested in Forgejo, it’s a fork and I think it’s well regarded since gitea went more commercial-ish IIRC?
As a result, only corporations remain or the few remaining owner operators avoid any engine newer than the year ~2000. These older vehicles also have the added benefit of having minimal electronics, sensors, and ECMs.