> if someone writes an app with a backend service or library, should they be required to document the API for people to build their own tools on top of?
Yes. Network services and client software should be considered two separate products/markets, and tying between them should be seen as anti-competitive behavior worthy of anti-trust enforcement.
That the software industry has been able to develop some brazenly anti-competitive pratices does not constitute an argument that it should be allowed to continue.
Games could clearly be an exception - they're the only place the locked down computing paradigm has a reasonable argument.
The multi-user productivity apps you listed would most certainly be better off as separate clients and services! The entire point is that you shouldn't be forced into using one (often terrible) piece of proprietary client software simply due to the network effects of other people using it. Wouldn't it be nice to use the Slack client in a Teams environment (or vice versa if that's your thing) ? This would produce more competition because companies would have to develop the client software to be compelling itself, rather than relying on the pull of installed deployments with captive victims^wusers.
> at what size or capacity should you be required to document and publish these things?
The reason there is an opaque number in that open source utility is precisely because of a lack of open documentation for that register definition. Independent black box analysis of the messages only got as far as "write this value to do effect X". Whomever developed that utility would have loved to spell that bitfield out, but not at the cost of more days reverse engineering.
But manufacturers aren't reverse engineering register definitions, they're working off of vendor datasheets or protocol definitions they themselves created. All of this documentation has already been produced, as it was used to develop the tractor from its various subsystems. It just needs to be published!
I’ve worked on enough internal and third-party SOA to know that documentation could be in an email, a slack chat, or a hallway conversation. The public docs go through writers and reviews. How many software teams could make their service or library docs public based only on internal documentation and produce anything useful?
Documentation for hardware subassemblies produced by different manufacturers isn't getting conveyed through hallway conversations. Pure software can indeed be quite sloppy, but for vehicles we're talking about large scale cross-stakeholder projects where these things do get formally documented.
At any rate, for things a manufacturer doesn't consider important enough to document themselves then there can be a clear alternative requirement - release whatever upstream documentation they did use to create it, plus the software source code they developed on top of it. If it's not important enough to have been documented as its own product, then it also isn't a significant part of the value they're actually selling, right?
Given how each tractor manufacturer is essentially associated with its own specific country, I'd say this industry is a great example of how mature industries tend to consolidate into monopolies while getting propped up by regulatory capture greased by concerns over natural security. So while the regulatory costs you cite may indeed be onerous, simplistic calls merely for "less regulation" don't bear out.
So the author is looking at one third of the problem (from the perspective of an IT worker), in a comfortable stage-managed experience put on by Deere themselves. A sensor with a disconnected cable - a five minute visual inspection would have also diagnosed the problem!
I'm quite comfortable with computers. And yet when working on my own vehicles, anything that mentions "use the manufacturer software" is avoided unless it's impossible not to. For example my experience using Honda HDS:
1. Spend hours installing Windows in a VM, HDS software from dodgy forums (to avoid the even dodgier "cloud" offering), running an ethernet cable 75 feet outside to where I was working - when my goal was to have my hands dirty fixing the car.
2. Massively slow scan times. We're talking 20 minutes sitting there initializing its understanding of the bus by probing every device every time the software starts up. The software starts up a lot because every time it hits some unexpected condition it needs to be restarted. Every time you choose a different option to check something about another subsystem, the software needs to be restarted. Every time you need to check if you've made a permanent or temporary change, it needs to be restarted. Every time you actually get your hands dirty and make some change on the car, it needs to be restarted. And so on. Companies view these tools as pure cost centers, making it so embedded developers DGAF about any kind of robustness or polish.
3. No actual description of what can be set, or theories of operation of any hardware device. The best you get is references from procedures in service manuals designed to be blindly followed, and the corresponding button in the software that runs some black box procedure.
4. Along with that, the chance of touching a lot of things you don't really want to be touching! HDS made me reenter the VIN number every time it started up (which remember, is often), and I think this was actually writing the VIN number somewhere! I entered it wrong once and it appeared that I had actually changed something.
Now obviously Deere is not Honda, but I don't see a reason to expect this would be any better. And of course this is not even touching:
> Prices start at an annual cost of $195 per individual machine
All this overhead adds up when you're working on one or two vehicles in a personal-bespoke capacity. I'm never going to reach for that software again unless I absolutely have to, even though I know in theory it can tell me a lot in one central place. I'd rather simply model a vehicle's computers as black boxes. I'm sure if you're a Honda tech you develop a model of how the software works, what steps of the procedures to batch and when to pause and check things over, etc. But from an individual perspective where I've got one car to fix rather than one every day? It's utter trash.
Adding digital control networks to vehicles increases their inherent complexity. This is unavoidable, similar to adding any new system (eg ABS, 4WD, emissions controls themselves, etc). I think mechanics could respect that, if it weren't bundled with a whole bunch of unnecessary/accidental complexity including top-down surveillance/control. Knowing a thing or two about technology and engineering, what would I actually expect?
1. PDF documentation with thorough bus diagrams. For every node on the bus, documentation from its manufacturer - its theory of operation, the settings it has, the messages it reads from and reports to the bus, additional message/register definitions for what can be read by diagnostic tools. Everything that you'd get if these were DIP switches and LEDs rather than CAN messages.
2. Machine-readable descriptions of CAN PDUs published by the manufacturer themselves. All the message/register/etc definitions documented in the above files, in a well-defined format ready for use by third party tooling.
3. Third party libre software with the usual `make && make install` install path (ie easily incorporated into every operating environment) that uses those definitions to display bus messages in symbolic form, as well as craft new messages to tickle device functionality.
I think that about covers it - there isn't actually much here, it just needs to be documented! I know interacting with digital vehicle networks would still be frustrating for many, but people would eventually get over it and even embrace it - it should be more convenient to have the computers display what they're reading rather than having to work around them. Checking the computers first would become standard procedure if the tooling weren't so infuriating.
(For more context my own tractor is a Kubota with HP under the Tier IV threshold. I earnestly wish it did have a DPF - less shit to breathe in and less black crap coating my loader. But not at the cost of dealing with the current "state of the art" computer controls! I've also heard horror stories about long term Deere parts availability)
My question is not whether those who voted for Trump 2024 are going to come to their senses and sour on this incompetent, destructive, and corrupt con man. My question is how long their reality checks are going to last before they start leaning right back into the revanchist destructionist feel-good narratives that led us here in the first place. This senseless destruction would not have happened if they had merely listened to their fellow citizens rather than writing us all off as some caricatures of woke boosters as their media propagandists led them to. Was Trump 2024 a true enough instantiation of what they've been demanding that they can finally put their hopeless "lost cause" bullshit to bed? Or are its eminently predictable results only going to remain obvious long enough for another temporary reprieve?
Your understanding of LLCs is a bit off. The LLC (or other corporate) structure does not protect the nurse from liability, nor any of the other directly-involved workers. The LLC protects the owners of the LLC - ie the ones turning the screws that spread workers ever-more thin. Workers generally avoid being sued mostly by custom, following procedures set by the LLC and/or professional bodies, being "judgement proof" (ie not having significant assets), and various types of insurances.
("Replace AI with 'company' and you realize that we're living in that world already." I 100% agree with this, though!)
It's understandable when you see that the ethos is to have software that represents the user in charge of the rendering, rather than centralizing it all on the server. There is a major difference between common "app store apps" or hostile javascript bundled with websites, versus software that's been written to work in the user's interest. However as they use similar delivery methods, it's understandable that it takes a minute to think through and revisit your assumptions that have lead to being default anti- javascript or app.
That makes sense until you remember what "rendering" is supposed to mean. Forming the HTML has no reason to be client side when you're using the site-provided experience. Yes provide a json version for other clients, but for direct viewing just send the paragraph of text in a usable form and let the javascript be an optional upgrade.
Actual terrorists have a right to speak too, you know. Intrinsic to the whole idea of rights is that even people we don't like (or are even mortally opposed to!) still have them. The problem with "firebombs on anti-abortion pregnancy crisis centers" is obviously the firebombs.
I'm sure Islamic terrorists feel the same about gay people and throwing them off buildings. If they didn't exist, nobody would "need" to be thrown to their deaths, right?
Except they did. Votes for Grump in 2016 were completely understandable, sympathizable even. Responsibility for the train wreck of a first term didn't fall at the feet of the voters - it's explainable by one politician being an utter shitbag once in office. And for the most part our institutions did function to contain most of the (direct) damage.
But Grump 2024 was a known quantity. The votes in 2024 demonstrate that the average American is either proudly ignorant of the actual policies they're choosing (ie fully steeped in propaganda that hides/downplays the destruction), or actively malicious towards the rest of the world (while benefiting from a privileged international position). Neither one bodes well for future decisions, even if there is some political will to pull up from the current autocratic destruction.
And no, the "we didn't know how bad he was going to be" of a 33% approval rating doesn't make up for that. Grump was a known quantity for this election, and the only way someone could have "not known" is by actively rejecting listening to their fellow citizens. Which goes right back to willful ignorance.
>The votes in 2024 demonstrate that the average American is either proudly ignorant of the actual policies they're choosing
That's a simplistic take.
Trump had less than 50% of the popular vote even though his opponent was clearly showing signs of dementia. The last-minute replacement had spent too much time being the "defund the police/eat the rich" sidekick to Biden and was clearly not representative of the views of the average American. She still got almost as many votes as Trump, from Americans who wanted to vote "Not Trump".
Seems to me the average American had little choice. All the Democrats had to do was field a candidate that could finish a coherent sentence mirroring the average American sentiment and they'd have landslide victory. But they didn't.
> too much time being the "defund the police/eat the rich" sidekick to Biden
It seems like you're merely demonstrating one dynamic by which people are able to maintain that proud ignorance - buying into simplistic feel good narratives about the "other side" which swamp their reasoning capabilities, absolving them of responsibility for their decision. This is a large part of being "fully steeped in propaganda".
For the actual reality, Harris was a public prosecutor - essentially a police officer's best friend. Neither Biden nor Harris were looking to destroy the federal government. More than anything, they represented the status quo rather than this nonsense you're repeating about "defund the police/eat the rich".
I'm a libertarian who hadn't voted for a major party in a national election until 2020. I had to come to terms with getting older, more conservative, and having to holding my nose and voting for the corpo status quo. But it was the reasonable, responsible choice. I can most certainly understand people who stayed home or voted third party. But voting for the known quantity destructionist and rationalizing it with nonsense propaganda is exactly what I was talking about.
There might be an argument to be made that your argument could be used to placate the rest of the world if we manage to turn the ship around but without Constitutional reforms that would keep the destructionists from gaining power again - "we were tricked" may work yet again. But as far as the actual question, no, people who voted for Grump in 2024 should not be allowed to look away or disown the horrible mistake they chose to make. It is in fact a necessary part of any reconciliation process.
>For the actual reality, Harris was a public prosecutor - essentially a police officer's best friend.
That's not helpful though, as she also made multiple public expressions of support for the defund movement, the protests-turned-riots after the Floyd murder, and the BLM movement.
I can't help thinking that made her a weak choice for both sides of that divide. Is she the tough on crime option or the anti-police one? Where does she actually stand?
I think if she had gone all-in on the tough-on-crime track she'd still have gotten all the protestor votes, and perhaps also the "can we stop police brutality without burning cars" votes. Which I think is a sizable chunk, perhaps even the most common opinion on the matter.
Anyway, all this to say that the explanation for the current situation is not as simple as "half of all Americans are crazy and evil". Current approval ratings clearly say most Americans know they effed up.
My first response was to a German who clearly felt the US as a whole is a lost cause, without acknowledging that Germany is in the process of making the same mistake. I wonder if the Germans will realize they effed up as quickly as the Americans have?
Both sides of the atlantic are throwing stones from glass houses, when we should be cooperating. The dictators are rejoicing...
reply