Whether you’re really passionate about RPC, MQTT, Matrix or wayland, tell us more about the protocols or open standards you have strong opinions on!
I’m really into CloudEvents because I love event-driven systems, and since events can come from, or be consumed by, so many different services, having a robust spec is super duper useful.
XMPP
You’re going off-topic from the OP question :-) But to answer your new question : I do not trust Matrix enough when it comes to privacy. I know that this link is old but still. https://disroot.org/en/blog/matrix-closure
Then again I do not trust Signal that much either but sometimes compromises need to be made to get things done. With XMPP the end user can host their own server if they wish to, without meta data going to a centralized point. And video calls via XMPP and Conversations were a pleasure to use when I used it during the Covid-19 pandemic.
Why should this be at the editor level? There should be a linter that applies all these stylistic formatting changes to all files automatically. If the developer’s own editing tools or personal workflow have a chance to introduce non-standard styles to the codebase, you have a deeper problem.
Why should this be at the editor level?
Because for every programming language there’ll be people using text editors, but you’ll never succeed in even creating code formatters for them all.
The greatness in this project is in aiming low and making things better through simple achievable goals.
I want both. When I am typing code in my editor I want it to follow the styles of the project. Then when I run the linter/formatter it will fix the mistakes.
The last thing I want is to start a new if foo { statement and the indent is half of the indent of the if above. That would be too distracting.
Remember SOAP? Remember XML-RPC? Remember CORBA?
Those were not very good.
I’d love to see more adoption of… I2C!
Bazillions of motherboards and SBCs support I2C and many have the ability to use it via GPIO pins or even have connectors just for I2C devices (e.g. QWIIC). Yet there’s very little in the way of things you can buy and plug in. It feels like such a waste!
There’s all sorts of neat and useful things we could plug in and make use of if only there were software to use it. For example, cheap color sensors, nifty gesture sensors, time-of-flight sensors, light sensors, and more.
There’s lmsensors which knows I2C and can magically understand zillions of temperature sensors and PWM things (e.g. fan control). We need something like that for all those cool devices and chips that speak I2C.
I2C is a bit goofy though. As a byproduct of being an undiscoverable bus you basically just have to poke random addresses and guess what you’re talking to. The fact lmsensors i2c detection works as well as it does is a miracle. (Plus you get the neat issue where even the act of scanning the bus can accidentally reconfigure endpoints)
Yeah, the lack of proper discoverability on i2c truly sucks. You have to just poke random addresses and hope for the best to see if an i2c device exists on the bus. It’s a great standard but I wish it would get updated with some sort of plug and play autodetection feature. Standardized device PID/VID system like USB and PCI would be acceptable or a standardized register that returns a part string. Anything other than blindly poking registers and hoping you’re not accidentally overvolting the CPU or whatever because the register on your expected device overlaps with the overvolt the CPU register on the same address of a different device.
I’m curious. There was some i2c connected memory devices before. Is there some forgotten spec that allows for a flexible device lookup / logging capability. Something that acts like device tree but stays specific to the bus. It wouldn’t be practical for a lot of applications but I could see it being useful for some niche stuff.
If you have an unused VGA port, you can use the DDC pins for I2C. Be sure to add ESD protection if you do this. An I2C isolator would be even better.
I2C is really not meant to be used over cables. It has a very limited common mode input voltage range and it can’t handle much capacitance on the bus.
Except that in the case of VGA (and DVI, HDMI, and DisplayPort) the i2c interface is intended for use over the cable. All of those ports have a pair of i2c pins and corresponding wires in their cables. The i2c interface is used for DDC/EDID which is how the computer can identify the capabilities and specifications of the attached display. DDC even provides some rarely-used control functionality. Probably the most useful of which is being able to control the brightness of the display from software. I use the ddcci module on Linux and it lets me control my desktop monitor brightness the same way a laptop would, which is great. I have no idea why this isn’t widely used.
Edit:
This i2c interface is widely used to control the lighting on modern graphics cards that have RGB lighting. We’ve spent a lot of time reverse engineering these chips and their i2c protocols for OpenRGB. GPU chips usually have more i2c buses than the cards have display connectors, so the RGB chip is wired to one of the unused buses. I think AMD GPUs tend to have 8 separate i2c buses but most cards only use 4 or 5 of them for display connectors. There is also an i2c interface present on RAM slots normally used for reading the SPD chip that stores RAM module specifications, timings, etc. This interface is also used for RAM modules with controllable RGB lighting.
