4 ms·
We don't need agreement for this. In the past, hardware was limited, and you could only really implement one (maybe two) network stacks before things got silly.
by wizzwizz4 1y ago
We don't need agreement for this. In the past, hardware was limited, and you could only really implement one (maybe two) network stacks before things got silly. Nowadays, a software-defined radio can speak ten thousand protocols, for a lower cost than saving a cat video to your hard drive.
We only need that the standards are open, and described clearly enough for a schoolchild to implement, and that we are not prevented from adding additional protocol support to systems we acquire.
Hardware protocols are a bit different, but I actually dislike the USB-C standardisation. We already had better de-facto standards (e.g. small, "fixed-function" devices like feature phones and e-readers all use Micro USB-B for charging). Our problems were mainly "this laptop barrel charger is incompatible with this other laptop barrel charger", and proprietary Apple connectors.
The most important hardware protocol is power supply, which we can fix by requiring well-documented, user-accessible contacts that, when sufficiently-clean power is applied to them, will power the device. These could be contacts on the motherboard (for something designed to be opened up), or something like Apple's Smart Connector (without the pointless "I'll refuse to charge until you handshake!" restriction).
Requiring open, well-documented protocols which aren't unnecessarily-complicated is imo more important than requiring standard protocols.
- lwhi 1y agoWe're not just talking about hardware here. Any standard that is developed closed-source and is protected or proprietary, can and will prevent consumer choice further down the line. Interoperability of data, choice between vendors, and the ability for smaller players to compete with established larger players are all directly negatively affected by a lack of open standards.
- wizzwizz4 1y agoThey're negatively affected by a lack of openness. Some proprietary XML nonsense that's well-documented makes interoperability a week's work, maximum. Meanwhile, Microsoft's incomprehensible "open standard OOXML", supported by every document editor I care to name, is a huge impediment to interoperability. Limiting myself to even the well-designed ODF format means there are features I can't implement in my software: standardisation comes at the expense of innovation. In software, the problem is closedness, protectionism, and undocumentedness, not proprietary wheel reinvention.
- lwhi 1y ago>In software, the problem is closedness, protectionism, and undocumentedness, not proprietary wheel reinvention. Quite simply, the first three problems are actually caused by proprietary wheel reinvention.
- wizzwizz4 1y agoCorrect. But proprietary wheel reinvention is necessary (albeit clearly not sufficient) for progress, so we mustn't prohibit it!
- lwhi 1y agoNo it isn't necessary for progress. Standards can be (and are) developed cooperatively and these still allow and encourage progress.
- wizzwizz4 1y agoC23 would not be nearly as good as it is without proprietary C compiler extensions, and other non-C programming languages. Sure, C23's versions of some features are better than many proprietary implementations, but they wouldn't exist at all if the lessons hadn't been learned from that exploration. Once upon a time, Jabber was the messaging protocol. But what killed interoperable instant messaging wasn't a shift away from Jabber: it was a shift away from interoperability. Requiring all chat communication systems to be Jabber wouldn't have helped, and it would have prevented IRCv3.
- lwhi 1y ago>Once upon a time, Jabber was the messaging protocol. But what killed interoperable instant messaging wasn't a shift away from Jabber: it was a shift away from interoperability. And how is interoperability possible without agreed standards?
- 1y ago