Linux Gains An Open File Server Implementation For Tractors & Agriculture Machinery

[Volta]

Some sort of a mid-term school break is on after all it seems. lol @ mac os "jibe", your personal doofus

That's why your lol @ linux "tractor" comment happen. Good to see Linux in another market. Not winblows, not macoze, not bsd. If you're looking for a job I'd recommend circus. Clowns are always welcome.

[Daktyl198]

As somebody who used to live near a bunch of farms and loved my neighbors, the sooner we have an open source distro of Linux that can replace the BS that John Deere does to their hardware the better. I'm 1000% on board with reverse-engineering all farm equipment's software and making open source versions of it. Let farmers replace John Deere's firmware like how we all replace Windows.

[Soul_keeper]

I work in a shop on tractor trailers. The most common issue we have is the software codes. Typically they are emissions related (ie: a bad sensor), or harness issues (bad wire/connnector). We have to use a windows laptop with windows software to read these codes. Both the trailers and tractors have multiple computers onboard all connected in a network with nearly unlimited failure points. Almost all this stuff is locked down to vendor specific code and often require that they be fixed by a vendor approved service tech, or warrantied/outsourced. Really it's like you don't own the tractor/trailer. And any repair you can't do yourself costs thousands of dollars, which is exactly how the manufacturer likes it. Also fleets tend to be one make, in our case kenworth/peterbilt, because if you have multiple makes then all your parts and software licenses are not compatible. ie: vendor lock-in. Which is also how they like it.

[toves]

I work in a shop on tractor trailers. The most common issue we have is the software codes. Typically they are emissions related (ie: a bad sensor), or harness issues (bad wire/connnector). We have to use a windows laptop with windows software to read these codes. Both the trailers and tractors have multiple computers onboard all connected in a network with nearly unlimited failure points. Almost all this stuff is locked down to vendor specific code and often require that they be fixed by a vendor approved service tech, or warrantied/outsourced. Really it's like you don't own the tractor/trailer. And any repair you can't do yourself costs thousands of dollars, which is exactly how the manufacturer likes it. Also fleets tend to be one make, in our case kenworth/peterbilt, because if you have multiple makes then all your parts and software licenses are not compatible. ie: vendor lock-in. Which is also how they like it.

When I was a teenager I remember a local mechanic who also had small hobby farm had purchased a large Soviet tractor (the area was wall-to-wall JD mostly broad acre grain.) In hindsight probably a wise investment (cost was 50% of comparable JD) while rough as guts, there were only the most basic instruments and you only needed a 0.5 inch spanner to service it (12mm or 13mm - wouldn't matter much )and a hammer. Not that much went wrong with it and probably still going.

[stiiixy]

More tech equals more problems equals more downtime equals less work being done.

When the muster or the harvest is on, your shit needs to work, and you need all hands on deck fixing anything that breaks (and proper maintenance comes in to play) to get the job done.

No time to call in 'specialists' to diagnose (quite possibly incorrectly) when your window is tight, and you're 1000k's from the service centre.

[stiiixy]

I don't know for this in particular, but my day job involves programming mining equipment. There are often many different computers and microcontrollers on the machine, all talking to each other. You wouldn't want to update each individually. Rather you load the software update into a master node and it sends the updates out to the other nodes. That could be one use for this.

Another use is collecting logs, be they error logs or production logs. Again, I don't know much about agriculture, but in mining the customers are really interested in those, to allow them to optimise how they use the equipment: how hard was it to drill in this particular area of the mine, how much explosives do we need to charge the hole with based on that? Or, when is the equipment just standing still (waiting for fuel? waiting for some other machine to get out of the way?) and could we optimise the mine as a whole so it is in active production more of the time.

I'm actually in the process of working with a team right now going from exploration to drilling, with the expectation the mine is all but going ahead thanks to Biden's recent announcement. Drilling is just to firm up the volume of material.

It'll be all above ground, so won't get to see much of the underground networking mines utilise, and the machinery being used is a custom built self-contained unit (I've yet to see it firsthand) built for purpose, and no idea how it's all controlled (yet...can't wait to get my hands on to it). 20,000 tonnes of alluvial sand a day from just one of those portable plants.

More on your point, what you're saying is pretty much all we did in my old tech days. Collect and monitor logs to a) improve performamce and b) reduce potential issues (which is an art form of it's own right). I managed to wrangle support calls from 1000 a month down to 350 from that simple proactive approach.

And of course I as never thanked; quite the opposite in fact 😁 Never looked back.