Satya Soprano: "Terrible what happened to your document. Be a shame if all these other document got eaten too. Maybe you can pay us for a Notepad Legacy subscription so that doesn't happen?"

Microsoft's goal is to extract as much money from you as possible. Whether you like that process or not isn't something they are concerned with.

I couldn't find that on Internet Archive. Only post-editing versions. That does look like a personal attack. Nothing else they said was directed directly at the author. Primarily, it was apparently factual statements about the flatpak being detected by a virus scanner, guesses about the correctness of the virus scanner's results, and, at most, a statement that the author's profile on some site seemed strange.

Then they apparently mistook the author closing the issue as an attempt to cover it up, which really wasn't called for, and jumped to unfounded accusations of malicious actions. But they later retracted that and apologized.

Rage quitting from that seems over the top to me.

IA is quite slow so I didn't read every snapshot, but I'm not finding a huge thread full of attacks.

Original bug report is short. It's somewhat poorly written and hard to understand. They seem to be saying that the frontend's flatpak binary package is itself detected as a virus (By another scanner? It's not clear.) and they are suspicious of it. They don't outright accuse the author of making malware but do seem to imply a suspicion of it. It's not written in very friendly tone, but I don't see anything that would be described as personal attack. They only reference the author is in a single sentence fragment, "[.] The program[']s author/owner on the official LINUX download site seems strange also, in retrospect." I don't know if I'd really call that an attack. It's probably most correct to interpret that language as as reference the author's profile on flathub (?) as seeming strange and not the person themselves as seeming strange.

There's a reply from the author. To me, it seems a bit overly defensive. They seemed to not realize that the original post was not about the frontend detecting false positives, to which they correctly reply that this would be an issue in the underlying ClamAV software and definitions, but rather that is about the flatpak being detected, possibly correctly or incorrectly, as malware itself. Which might ultimately be blamed on the virus definitions as well, but could have other causes, such as the flatpak generation process being victim to a supply-chain attack.

After that ticket is closed, there's a new one from the original reporter. Where we have these comments from the reporter of the issue:
"Forget this issue entirely. If there is problems with his work- contact him directly, when he supplies more direct contact information."
"Whatever you wish zynequ. I did not not mean to piss you off. The issue is closed in my mind. Your project is off of my laptop disk. Let it rest.
Goodbye."

The first is edited. I don't see a record of what it was originally. Again, not what I'd describe as a personal attack. More like a half-heated apology.

All indications are the project will stop making them. Certain models are no longer available. But that said, the current keywords are from a second round build which wasn't necessarily planned from the start. Perhaps they'll sell quickly enough to justify a third?

While it's not hard to find a 100% somewhere, they've become much less common for mechanical keyboards. I just checked the most recent two dozen keyboard releases on drop. Not a single 100 (or larger) in the lot. Mostly TKL, with some 60s, a couple 75s, and a plank kit.

If you don't want just any 100%, and instead want certain less common key switches or a specific theme or other less common features, it can be hard to find a 100% that has them.

The model F AT, which immediately preceded the model M, had control next to A. So did the model F XT before it. I think the case can be made that the traditional position for control on a computer keyboard was on the home row and capslock was on the bottom.

While key codes can be remapped, it's pretty much impossible to get the correct keycaps to swap control and capslock. The ellipse model F is one of the only ones I know of.

The goal would be to make the leaders care about security issues in the first place.

Right now, they can choose to spend less on engineering and then give the money saved to themselves to buy a bigger super yacht. The consequences of only using the cheapest possible labor and cutting every possible corner is that their routers get hacked easily. But this doesn't hurt the CEO in any way. They keep their super yacht. So why shouldn't they do it?

I've designed many devices that are like this. Bluetooth especially is quite cheap now and it often comes with hardware chosen for other reasons. It wouldn't save any money to remove it. And if there's no money to be saved, there's no option to do it.

I'm at a trade show right now where we've built a device, functioning prototypes at this point, with an unused BT interface. It's got a cell modem, which was intentional and is used. And there's wifi, which isn't really an intended user facing product feature but was very desirable for the development of the product. And there's bluetooth because it comes with the wifi module. I actually went to the trouble to lean down the system and the custom kernel config doesn't include bluetooth support. I imagine most engineers wouldn't bother with that. But the hardware is there. Antenna is even connected because it's the same port as the primary wifi antenna.

To me, the difference is that the ref doesn't know to the inch where the line is when he spots the ball. So he doesn't know which team he's giving it to. When they measure they know who will get it, but the chains are a very accurate and objective device. The chain crew has no power to influence the decision.

We understand that there's no way the ref can tell where the ball was to the inch when the runner went down or forward progress stopped. So really, it's "too close to call" and we'll just flip a coin to decide the outcome. If we let the ref look at flag on the side of the field and directly announce if the yardage was made, it might not be any less "accurate" than the current system.

But to me at least, there is very big difference between, "too close to know for sure, flip a coin," and "too close to know for sure, the ref arbitrarily picks a team to win."

It's all for speed. There's nothing in the press release about it making better calls. The only advantage described is that it can measure 10 yards faster than a chain crew can.

If anything, there is less show, since there is no chain crew to bring up and they won't have that close up shot of the ball and the stick, where we see if they made 1st down or not, that often comes after the measurement. And the 30 seconds of waiting they can fill with ad talk but the audience doesn't tune out since a critical call will be announced momentarily.

Now the offense will know they didn't make before they even get back to area the ball was spot at and will go directly off the field.

You mean like command 0x0003 in Analog Devices BLE controller? https://analog-devices-msdk.gi...

That's a write memory command. They gave it the wrong name. Must be part of a backdoor, being so weird and hidden with the wrong name. You should go write a click-bait article on it full of your made up crap.

And TI's 0xFC0A command is a Non-Volatile write. That means to flash.

If you had any experience actually using HCI commands or writing a BLE host, you'd know all BLE controllers have commands like this.

You aren't nearly as knowledgeable as you think you are. I doubt you've ever programmed any microcontroller on your own outside of a class room. Maybe, if you thought about what those with experience said instead of attacking them for not parroting your fantasy, you would learn something.

While this is entirely true, it's also true for most or all other BT devices. I've developed products with Nordic and ST chips that have BLE, in addition to Espressif, and both those companies' products also ship the BLE controller as a binary only component of the software stack. They are actually more obfuscated than Espressif's binary code. ST's is fully encrypted so you can't even disassemble it. Espressif's isn't encrypted and even has an unobfuscated symbol table in the library.

I'm not aware of any device on the market with a fully open source BLE controller.

The NimBLE project does have an open source controller, in addition to a host which is the part of NimBLE Espressif uses, but don't know of a chip on the market that uses NimBLE's controller.

What commands are so weird?
How about this one: 0xFC0A Write NVDS Parameter
Or maybe: 0xFC12 Read memory info

Here's a list of TI's CC13x2 Vendor Specific Commands: https://software-dl.ti.com/sim...
TI has better documentation than Espressif.

And in that list we see 0xFE82 UTIL_NV_Write and 0xFE87 UTIL_GetMemStats

I fail to see what is so strange about these vendor specific HCI commands. TI has some of the same ones in their controller.

That's not true. I've actually developed products that use ESP32s. I've even done some reverse engineering on those binary blobs to implement RF coexistence between BLE and another RF system, since none of the documented APIs support any of the necessary features.

FreeRTOS is open source and part of the code included in ESP-IDF. The controller is a task that runs under FreeRTOS. Though I think there is a mode where one dedicates a CPU core to the controller, on those ESP32 devices with two cores, and FreeRTOS doesn't manage the controller.

Depending on the ESP32 device, the controller code is either in the mask ROM and/or as a binary library file shipped with ESP-IDF. The older ESP32 appears to have more in the ROM while the newer chips like the ESP32-C6 have less ROM and use more libraries.

There's a performance issue with code in flash memory (which a library compiled into the FW would be), since the ESP doesn't have built in flash on the processor's data bus. It's an external SPI flash chip in all cases, which means possible long latencies when a cache miss causes the flash controller to need to read a block over SPI. Not something a timing critical part of the BLE controller can tolerate. The way around this is to copy the code that can't tolerate flash cache misses from flash into RAM, but there is very little RAM, especially on the OG ESP32. So they add ROM that doesn't have a cache miss issues to hold some of the code. ROM is much cheaper than RAM in a microcontroller.

No, bluedroid or nimble run as a task under the open source FreeRTOS kernel. They talk to the binary blob using a virtual HCI interface. It's not even a binary blob. They ship .a libraries that don't even have symbols stripped for the non-open-source code.

The HCI spec includes an OGF for vendor specific commands, 0x3f, which is what Espressif has used. I fail to see what is strange about vendor specific commands using an opcode set aside in the spec for purpose of adding said commands.

If the controller has some kind of RF triggered backdoor, there would be zero reason to create an HCI command to implement it. The controller code would just do the secret thing when triggered. You wouldn't add a customer facing command called "TriggerSecretBackdoor", which has no purpose other than to let customers activate the backdoor, if you wanted to add a backdoor that was secret from your customers.