If you want to see or try CRiSP, visit http://www.crispeditor.co.uk and try one of the longest established and functional editors on the web! Or subscribe to http://crtags.blogspot.com for a blog on technical articles and joy of computing (sometimes!).

13:50 As an aside, I think QUIC is not a great protocol

> It's essentially a whole network stack because the classic network architecture has failed to evolve. QUIC needs to have a kernel-level support to succeed, and I don't see any push into that.

The problem is that the protocol designers first and foremost wanted to be independent of any operating system due to the time it takes to deploy their updates. Having the whole network stack in the browser allowed them to perform extremely fast iterations. Even BBR benefited from QUIC's fast turn-around and improved fast thanks to this ease of deployment. My understanding is that as soon as QUIC gets even basic support in a kernel or in a NIC, it will be considered as ossified and will be obsoleted and replaced by something purposely incompatible.

But I agree that the costs are huge. Ideally such protocols should be designed jointly with kernel network developers so as to figure what building blocks are necessary to offload their processing. It could be the ability to receive and send multiple messages from different sources / to different targets, etc. With that said, we already have UDP GSO now, but it doesn't to everything of course. I think for example that an efficient API would permit to pass multiple packets in a single large buffer so that the kernel performs the address validation only once. That's just an example of course, much more is needed.

13:50 As an aside, I think QUIC is not a great protocol

> it is hard to correctly pace packets going out (you need a certain TC scheduler - not guaranteed it will be there).

Yeah this is among the areas where kernel support could improve via a better API, because basically you have to arbiter between GSO and pacing. I think that having the ability to work with a ring shared with the kernel, in which packets are laid out with their expected date of output and a pointer to a 5-tuple to use with them could be an alternative that would allow the kernel to do GSO when multiple packets are for the same 5-tuple, which would also depend on timings etc. This would be cheaper than sendmmsg(), and simplify the operations all along the chain, and possibly not depend on codel being enabled.

13:50 QUIC network debugging

> It would have been sufficient to leave the ACK information in the clear as additional-data, but still protected by the AEAD authentication. Then it could not have been modified, but would still be easy for people to debug networks.

It could still be dropped. That's why TCP/IP is a fossil - the *protocol* is designed to be extensible. The hardware (routers) have turned the environment to ice (aka any attempt to modernise TCP/IP is detected by hardware you don't control, which treats evolution as damage, and gets rid of it).

That's why the Internet was complete rubbish a few years back, as router manufacturers proudly sold kit with "we never drop packets", while the internet protocols relied on dropping packets to detect congestion. The result being the entire internet behaved like spaghetti junction in a bad rush hour. Which is why we're paying for an entirely unnecessary superfast backbone we don't need ... I know spam is a problem, but most of the internet capacity is probably there not for spam, but to make sure that slowdowns (that the protocols were *designed* to detect and deal with) don't happen.

The Internet as a whole is actively hostile to any attempts to improve it, and seeing as that hostility is hard-baked into hardware with maybe a ten-year (or more) life span, that's presumably why (in part at least) QUIC is designed to make sure that hardware has no idea what's passing through it.

That's why pretty much the entire internet now runs on port 80 (and a few others :-) - the mechanism that was designed to enable new protocols doesn't work because the wider world of hardware says "I don't recognise it, I'm going to drop it".

Cheers,
Wol

13:50 A path towards removing the concept of "essential"

One approach could be to have a metapackage called "base-essential" (akin to the existing "build-essential").

Then packages could either depend on base-essential or to explicitly depend on individual packages.

That would make answering the question "what breaks if we remove foo from the essential packages?" question simpler - you'd only need to audit those packages which declared an explicit dependency or which depended on the metapackage.

Also I guess you'd only need the metapackage to be declared "essential" in such a world.

I suppose the biggest immediate impact would that it would make the dependency tree quite a bit larger and therefore slower to process?

13:50 Complex and bloated

It's a bit annoying how all these applications eventually became monstrously complex and bloated. It's really not a good sign that a application focusing on integration cannot integrate in any standard distribution. I don't want to run it in a KVM virtual machine. Modern day solution is to set up containers. Many services also support native installation. It's puzzling how a platform independent high level scripting language would break with minor updates to the host OS.

13:50 Complex and bloated
> It's puzzling how a platform independent high level scripting language would break with minor updates to the host OS.

Why is it puzzling? They are using âœeasy to useâ and âœflexibleâ language which have zero guardrails that may help against breakages on upgrade. Why wouldn't it break randomly?

For C we have LibAbiGail. For Rust we have Cargo Semver Checks, Crater and many other things... what do we have for Python? Wishful thinking and prayers?

âœHigh level scripting languagesâ are not designed to survive upgrades... and distros are very much built around the idea that everything have to be updated. They are fundamentally incompatible. > It's really not a good sign that a application focusing on integration cannot integrate in any standard distribution.

It's not good sign. It's great sign. That's exactly how winner of these games should look like.

When you start an integration project you, essentially, have two (and half) choices:

Nice set of rules, everything is done neatly, things are guaranteed. 100% guaranteed failure.
You have as few rules as possible, you invite non-professionals and embrace awful things in the hope that they would improved later. That thing may succeed.

But...Â what is a success here? Success would be a state where that horrible mangled monster that is threatening to collapse and unravel at any moment have enough supporters to keep it going, somehow.

Because if chaos, inherent in the approach needed to achieve success, overwhelms developers and the whole thing collapses and couldn't be salvaged... well, that's it, it's no longer a success, obviously.

And if you impose enough rules to support proper upgrades, nice interaction with distros, and other things that may effect the desire of unprofessional contributors to join... you would lose to some other, more chaotic and more âœforgivingâ, project.

Only when certain niche if âœfully filledâ, with many projects that do what one needs or wants, competition on quality begins (and former leader, closest to collapse, may be replaced with something nicer...Â think pile of SysVinit scripts vs systemd). And home automation niche is far from being âœfully filledâ, even Home Assistant is very far from being at the stage where one may honestly say âœyou may buy whatever your want, any IoT gadget - and Home Assistant would support itâ. > It's a bit annoying how all these applications eventually became monstrously complex and bloated.

That's how winners in these races look like, it's 100% inevitable.

People like small and neat solutions... till they find out that something they want only works with a bloated monster...Â and then they switch.

Bloated monsters win, everything else loses... it's inevitable.
Hide

03:49 As an aside, I think QUIC is not a great protocol

> 1. There is no length field for frames. This makes it impossible to decode a QUIC packet once it contains an unrecognised frame type

This is not a problem because in this case 1 QUIC packet = 1 UDP packet. Coalescing is not allowed for (most) short-header packets. Unless I'm missing something?

> 2. Data is acked by packet number, but packet numbers can only increase. Levels of indirection (CPU + state) to handle ACKing. Also rejiggling of packets when you have to reTx.

I don't think you can make it better without other types of trade-offs. One quirky idea that I heard was using rational numbers for subflows for acks :)

> Personally, I think QUIC will not last. It's over-complex and quirky.

It's essentially a whole network stack because the classic network architecture has failed to evolve. QUIC needs to have a kernel-level support to succeed, and I don't see any push into that.

03:49 QUIC network debugging

That's great, if:

a) You control at least side of the connection
b) The software supports SSLKEYLOGFILE and you can easily set it
c) You don't need to go back in time to set it, to debug the packet trace you got (e.g., were sent)

03:49 QUIC network debugging

Not being able to obtain much information from just a packet capture is intentional. It prevents middleboxes from interfering with the evolution of QUIC.

03:49 Automation madness

If you find the built in automation thing a bit limiting you can always drop in the Node-RED integration and really go to town! It arrives nicely pre-setup with lots of handy widgets. You just have to follow some pretty simple instructions to add in the agent within HA itself and off you go.

As big Jon mentioned, you can run HA "Supervised" which means you get to run it on a full OS which is very useful. He perhaps over-looked the bit about Debian current being the only supported option! They do get a bit forthright about this. I redeployed a couple of ill advised Ubuntu based VMs with Debian and restored from config backups.

I have deployed quite a few of these beasties for customers. They are so handy for things like printer fleet management and monitoring. There is a card (in HACS) which will automatically gather up all entities and display statuses when a certain trigger is hit. Ideal for many batteries or toner statuses. At another customer, I set one up at the beginning of the pandemic so they could turn their work CAD boxes on and off using WoL and an integration that sends shutdown commands to Windows. The hardest part of that was sorting out MS's idea of power management for NICs.

Grab a slack handful of ESP32 and the like and with minimal skills and perhaps a soldering iron, some wires, breadboard and a 3D printer, you can create all sorts of things. ESPHome is ready to do the programming with a pleasant webby IDE and does all the heavy lifting.

Frigate and a Google Coral is ready to do security cameras and web cams. All covered with an add on and a GUI.

If you get a microphone(s) sorted out then you can setup a wake word "OK computer" and do text to speech and speech to intents. You can, via a Nabu Casa sub, gateway Amazon Echos and the like to take advantage of them but insulate yourself from direct contact.

The ZWave and Zigbee implementations are now very solid. Zwave was patchy in the past but now it is reliable, at least at the HA end.

If you have a static IP or can use dynamic DNS and you can forward ports 80/tcp and 443/tcp, then grab the nginx proxy manager addon and use its Lets Encrypt feature. Or you could spin something up on the host OS (if you have one)

HA is superb for turning loads of phone apps into a single pane of glass. For example my car (*sigh*, yes it has an app - Seic MG4), home power supplier (Octopus) and my car charger (Zappi) all have apps. They also all have integrations for HA. I don't bother with the phone apps much. Another very popular integration is automated rubbish/recycling scheduling. Grab "Waste Collection Schedule" via HACS. It will almost certainly support wherever you live or you can use an .ics file or a manual schedule.

Recently someone added browsers for several discovery mechanisms (DHCP, SSDP and Zeroconf) into the web GUI - genius!

The pace of development is insane but the core product is rock solid with a few wobbles along the way, just like Linux itself or any other huge and complicated software system.

03:49 QUIC network debugging

It would have been sufficient to leave the ACK information in the clear as additional-data, but still protected by the AEAD authentication. Then it could not have been modified, but would still be easy for people to debug networks.

One objection then is you could correlate packets across CID changes, but... I'm not at all a believer in the various bits of complexity to try obfuscate QUIC flows across CID changes. I mean... if hiding flows is a security objective you must have, then you'd be dumb to be relying on those features in QUIC to start off with - you need onion routing.

However, you could do something like add a signed offset to absolute packet numbers in the ACK, that you then send in the encrypted portion, and change it along with CID changes. Though, that would impair the network debug too, but.. your packet analysis software is probably also using the CID to reconcile the QUIC packets to connections. An observer could use the linear relationships to try correlate still, across CID changes, but those are transient and this kind of analysis probably also wouldn't scale up well for an attacker - also, if the communicating parties have this level of concern, they already should NOT be relying just on QUIC, they need a system designed to make correlation attacks /actually/ difficult (which is not QUIC).

03:49 Also: its own container OS!

One _really_ nice feature of HomeAssistant is its own image-based OS (HAOS).

I was initially skeptical about it, and started hosting HA on my own server. But then I had a nightmare upgrade, after a year of not paying attention to it. I needed to manually update dependencies, unbreak my whole OS after accidentally running `chmod` in a wrong directory, etc.

I decided that my time was more valuable, so I got an Intel NUC, set up HAOS on it, and... that was it! It updates perfectly on its own, I can install addons by clicking on them in the "HomeAssistant Store", and I can also firewall the whole home automation in its own VLAN.

It also can back up itself onto my NAS. And it can restore itself! This was super-handy when the SSD in my NUC died last month. I just popped in a new SSD, installed the basic OS, and did a restore.

This is about the most perfect example of a hassle-free "homebrew" IoT experience.

03:49 As an aside, I think QUIC is not a great protocol

> This is not a problem because in this case 1 QUIC packet = 1 UDP packet.

1 QUIC packet is composed of 1 or more QUIC frames. And packets do often have more than 1 frame. The length of a frame is implicit - you must know enough about a frame type to know what its length is, to be able to decode any further frames. If a QUIC frame is not recognised, a decoder can not decode the rest of the packet - including any frames it /does/ support that happen to be after the unrecognised frame.

This just.. sucks. It's a terrible design decision.

> don't think you can make it better without other types of trade-offs.

You can separate detection of packet loss from indication of what content needs to be retransmitted. And then you don't need to maintain (build, reconcile and update) maps from packet numbers to the content.

> It's essentially a whole network stack because the classic network architecture has failed to evolve.

It's just a transport protocol. Created with some significant quirks, by someone who had a bit of a fascination with over-normalising every thing (including removing 1 from counts, where such a count always has at least 1 - making it annoyingly confusing to read packet traces cause now those count fields are intrinsically off-by-one, for absolutely *no* saving in wire-bytes). - to the detriment of clarity and the fact that more and more implicit state requires more and more computation to maintain that implicit state.

Could we improve on TCP? Sure. Does it need all those quirks? No.

Does it help to have an encrypted UDP transport that middle-boxes can't screw with as much? Sure. Does it need all those quirks? No.

> QUIC needs to have a kernel-level support to succeed, and I don't see any push into that.

The limitations of user-space UDP are an issue, agreed. In particular, it is hard to correctly pace packets going out (you need a certain TC scheduler - not guaranteed it will be there). Plus, you're at a disadvantage against TCP when it comes to reacting to incoming packets - TCP can send ACKs from softirq I think, while user-space QUIC has to wait till the right user-space schedules and gets the packets, so there is much more jitter. QUIC could use hardware timestamping to measure the jitter and somehow use that.

Those are implementation details, which may be fixed one day, one way or another (e.g. via some level of kernel offload for QUIC, as you're suggesting).

03:49 As an aside, I think QUIC is not a great protocol

> In particular, it is hard to correctly pace packets going out

I should have used "precisely" rather than "correctly" there.

03:49 Also: its own container OS!

HA is a proper job!

Your comment is a classic HA experience. You want to take it seriously but didn't have the time at the time and something went wrong. It is engineered properly and hence you fixed your snag and moved on.

I don't think I've ever seen you describe a product in such glowing terms!

03:49 Oregon State is (was?) one of the few places to consider software contributions for tenure.

I'm not yet at a point where I can contribute, but I'd like to point out that OSU and OSL started the discussion on published and *used* software counting towards faculty tenure cases. That has not progressed so far as I know. They have my respect for that endeavor regardless. (And I would love to be wrong about its progression.)

Hide

00:51 Kids Are Short-Circuiting Their School-Issued Chromebooks For TikTok Clout
An anonymous reader quotes a report from Ars Technica: Schools across the US are warning parents about an Internet trend that has students purposefully trying to damage their school-issued Chromebooks so that they start smoking or catch fire. Various school districts, including some in Colorado, New Jersey, North Carolina, and Washington, have sent letters to parents warning about the trend that's largely taken off on TikTok. Per reports from school districts and videos that Ars Technica has reviewed online, the so-called Chromebook Challenge includes students sticking things into Chromebook ports to short-circuit the system. Students are using various easily accessible items to do this, including writing utensils, paper clips, gum wrappers, and pushpins. The Chromebook challenge has caused chaos for US schools, leading to laptop fires that have forced school evacuations, early dismissals, and the summoning of first responders. Schools are also warning that damage to school property can result in disciplinary action and, in some states, legal action. In Plainville, Connecticut, a middle schooler allegedly "intentionally stuck scissors into a laptop, causing smoke to emit from it," Superintendent Brian Reas told local news station WFSB. The incident reportedly led to one student going to the hospital due to smoke inhalation and is suspected to be connected to the viral trend. "Although the investigation is ongoing, the student involved will be referred to juvenile court to face criminal charges," Reas said. TikTok recently banned the search term "Chromebook Challenge" and created a safety message that pops up when searching for the term. The social media company notes that the challenge is on other social media platforms, too.