Messages

Thing is, those features can also be added without changing the GUI interface, like adding another line in a drop-down menu. Simple as that. This is why I love OfficeLibre, it keeps the old school drop-down menus that just *work*.

And when usability is sacrificed for the sake of "clean, fresh design", then I truly howl in pain. We have to do stuff via screen shares, so please let us have bigger fonts and better contrast between elements! Faint text and colors that are too much like the other colors will reduce the usability and productivity with the tool.

Over the years, I've worked with a number of products. Some of them start out easy to use and stay easy to use. Some of them started out easy and then got harder because they added a bunch of features and didn't take time to clean up the GUI when integrating them or - worse - there's a totally different GUI for the add-on and it's way different from the one I got used to. And then there are the ones that didn't add features, but they did ruin the GUI and chose to double down on the crap instead of rolling back to what I was comfortable with.

A change in GUI is like inviting the competition in if the product doesn't have a "revert" button. I can see wanting to have a new look for marketing and sales purposes, but the daily users of the product likely have lots of memories attached to what they're doing and how they're doing it and changing everything makes them feel useless. Replaceable. Unimportant. Judged by the makers of the product and found wanting. And that makes it easier to burn a bridge and move on.

Indeed. I just got my foundations of AI cert from ISC2.

That part about increasing denials for services stings, as AI has shown tendencies to amplify human biases evident in historical data. And if that's the training the AI model gets, it'll be aggressive in denying treatment not accidentally, but by design. Likeliest to be denied would be major procedures for people with poor health histories. Least likely denials would be minor procedures, prescriptions, things like that.

Heads up from the web host:

"The maintenance process will begin Thursday, October 2nd at 12:00 AM (midnight) PT and will run until 4:00 AM PT. You may experience approximately 30 minutes of intermittent connectivity within the above 4-hour window."

https://thebulletin.org/2025/09/the-risks-in-the-protocol-connecting-ai-to-the-digital-world/#post-heading

model context protocol (MCP) is comin' to town, best get ready.

It runs on HTTP according to docs here: https://modelcontextprotocol.io/docs/getting-started/intro

So, I hope it can also run on HTTPS, but then there's the fun times about making sure all the encryption is done right and is made quantum-resistant when those ciphers are ready.

Communicates via JSON over HTTP.

I need to read the rest of the articles now... 

Congrats. Was it one of the ISC2 certs? Those are pretty well recognized.

-Otanx

This was a Qualys one. I'm next planning to do some AI Security courses with ISC2.

I picked up my first cloud security certification. Feels good.

Well, I signed on at ISC2 and I'm going to work on clearing the intro cert for cybersecurity and then going on to the cloud and AI certifications, whatever they got there. This is self-directed training on my own dime and time.

Internally, I'm going to work more on product training in Cloud / AI areas and getting up to speed in those venues. Traditional network stuff I got down very well, and finding out that AI security is basically an IPS/WAF for the AI inputs and outputs helps to put that security in context.

I recycled my old gear. Getting 50 bucks and postage wasn't worth lugging it around and trying to ram it into a box.

Well, time for me to do a deeper dive into CRCs...

In networking, the CRC is typically calculated on the fly as the data goes out of the network interface and is added to the end of the transmission. There is a SHA checksum with the data that is actually used to check for data integrity, so the CRC in networking is for the datalink to determine if there are any bit errors. CRC itself is too lightweight to do a proper integrity check, which is why the SHA checksum is included with the data set proper.

In environments with low to non existent error rates, CRC can be seen as redundant, especially with TCP data being sent with a SHA checksum on it. In operational technology (OT) environments, however, where the gear is thinly provisioned and data transmission is a priority, the CRC is used on the OT protocols as a quick and easy way to determine if the data arrived completely or if a retransmission is required.

For your case, the maths are by the sending system. Honestly, it does not matter what algorithm is used, so long as it's the one for the protocol being transmitted. Humans do not calculate CRC.

The data, 1010, will be manipulated until the system gets 0 and a remainder. The remainder are the CRC bits.

https://en.wikipedia.org/wiki/Cyclic_redundancy_check#Computation shows a sample calculation.

But in the real world, we don't look at the CRCs. We *will* look at CRC error rates on a device and, when they get too high, will consider corrective action on the hardware or connecting media.

To find the answer, I found this: https://en.wikipedia.org/wiki/Dijkstra%27s_algorithm

And it's a fun little article about how Dijkstra thought it all out and made the algorithm. There is a step-by-step calculation that runs until one of the calculated paths reaches the destination. That first path is therefore the shortest.

The algorithm also works, with modifications, to present ranked-choice alternatives to the shortest path, should it become unavailable or degraded.

Other shortest-path solutions are discussed here: https://en.wikipedia.org/wiki/Shortest_path_problem . Solutions don't necessarily fail, but are rather perhaps better for some applications than others.

Start with 92-100. If no ack, then retry those a third time.

It's the "sliding window" idea. If transmissions are good, send larger and larger chunks up to a limit. If there is an interruption, start small again and see if that gets through. If not, then there's no point in sending all the other stuff.

End to end means being able to track things in a system. In the case of TCP communications, it's confirmation messages. For UDP, as it does not have confirmation messages, then being able to detect breaks in the communication path will enable an administrator to determine if messages are being delivered or not.

NAT is a tricky thing, though. Used one time with the Internet connection, it is manageable. If it is used a second time for masking internal traffic, then problems develop. Problems multiply if address spaces are re-used in different areas and NAT is employed to mask the IP address re-use. This last scenario is common in industrial environments.

In the K3S cluster, how many nodes are being used? If the number is over 64K, then we may want to instead go with IPv6 instead of IPv4 with NAT.