Matching decompilation is a verifiable target that ensures feature parity but it says nothing about being reasonable non slop decompilation.
Disassembler output can relatively easily match original binary, I doubt anyone would consider it decompilation.
Let's say you add requirement of being higher abstraction language than assembly. You can translate the assembly code 1:1 with simple string substitions to C code which would provably replicate the behavior of program perfectly. I would consider that more of hard coded emulation, opposite of JIT like ahead of time code translation. Just because the intermediate langauge is higher level language than assembly doesn't automatically mean that the program text operates at higher level of abstraction than assembly.
I have seen plenty of decompilation projects where you start reading the code many functions contain nonsensical variable reuse (and name that match the register names), address calculations and memory casts and array calculations, arrays of function pointers, offsets within structures which strongly mirrors the assembly code.
The problem is that you can't draw a hard line how good do the variable/function names need to be so that it can be considered decompilation instead of hard coded emulation. It's hard to draw a line for how much of higher level language features you need to use to be considered decompilation. It's hard to define how logical the control flow needs to be. The line becomes blurrier by system programmers approaching it from the other side. Sometimes an extensively optimized code can contain a lot more manual memory mangling, index and offset calculations, manual unrolling than the language requires. So many C programs with homebrew systems of emulating virtual functions using structs of pointers. In such situations it's hard to tell if decompilation is incomplete or whether program was written that way from start.
Another possibility of junk decompilation (which perfectly compiles to byte identical copy of original executable) is program which depends on exact program layout in memory or undefined aspects of programming language. It would perfectly replicate original behavior on original hardware/compiler, but provide 0 insights in intended program behavior and fail miserably when attempting to modify the code or port it to different hardware/compiler. For example the "decompiled" code might intentionally peform out of bounds array access thus touching completely different variable or depend on fallthrough between functions lacking return statement.
Taking it to the extreme would be something like:
```
char data[] = {0x10, 0x12, 0xab, 0xcf, ...}; // bytes corresponding to majority of original program.
int main(){
((void*())data)(); // cast the array to function pointer and execute it
}
```
It might behave exactly like original program, but that's junk decompilation.
You could add additional restriction that C program isn't allowed to exploit any undefined or machine specific behavior, but then there is very high chance that even original program wouldn't satisfy it.
Original program might also contain parts of it written in assembly for performance reasons or because that was only way to access certain hardware features. What does it mean for decompilation? Is decompiled code not allowed to use the same techniques. If decompiled code is allowed to have some pieces of assembly what stops it from using it for everything. There is no way of knowing precisely how much assembly the original program used.
There are two bad properties in terms of interactivity (and for other uses).
In some configurations hyperbezier explodes towards infinity or at least way outside the bounds of control points. Cubic beziers don't do that, if control points are bounded the curve will be as well. This is direct result of how cubic bezier can be calculated with series of linear interpolations.
Other issue was that there were discontinuities while moving through parameter space or at least very sudden jumps, small changes of control points caused curve flip to completely different shape.
Even if you ignore the nonavoidable copies which happen during normal usage of digital files there is no way they don't dozens of different real copies of their training dataset across many different servers accessible by many people.
It's a blog of a niche computer peripheral company not a store listing. And it's not their first product either, only blog is having problems rest of website is still wotking and in the store you can get a pretty good picture of what their typical kits look like. Most likely only sensor, the only through hole component needs soldering. They also ofer fully assembled versions, although initial preorer batch might be kits only .
All LEDs are like this. It's horrible. The only good thing about it is that every professional in the entire industry has come to expect that if it's an LED, something somewhere will be wrong with it.
By all LEDs do you mean addressable and other multipin LEDs? Never seen anything weird with classic 5mm/3mm. The flat side+leg length is quite reliable. 0805/1206 smd LEDs also seem mostly fine.
The cathode marks are basically randomly assigned. This is because each company more or less designs one leadframe/package structure per size or type of LED. Sounds reasonable, right? But LED dice aren't made of silicon. They're made of weirdo high-bandgap materials, and every color is different in its own way. From physics alone, some of the colors end up with cathodes on top of the dice and some of the colors end up with anodes on top. They all get bonded in to the package the same way. So... that marking built in to the package? That's always the "top of die" wire next to it. But "top of die" might be cathode, or it might be anode. Flip a freaking coin!
If you want to see this clearly, find a datasheet that covers an entire series of LEDs. Vishay often does this, here's one: https://www.vishay.com/docs/82437/vlmo1300.pdf . They'll tell you the marking locations for each color individually. Notice how they're all completely different? Yeah.
Could the manufacturers do better? Yes. Yes, they could. We all wish they would do better. But they do not. So LEDs are the stuff of nightmares for people who assemble boards.
Through-hole parts are somewhat better (but there are certainly rogues!), but this is 2026: the volume's in surface mount.
Multipin LEDs are no better. The SMD no-lead versions are again fairly randomly marked. The PLCC-4 types are usually "cutoff corner near pin 1", but I've seen it as pin 4... or pin 2... constant vigilance is the only solution. Constant vigilance!
Generic GPS transponder (containing GPS receiver + some kind of data connection) will have limited battery life.
Systems like Tile, AirTag can last much longer with smaller battery and overall dimensions by offloading GPS and long data transmission to other devices. Strength(and dangers) of devices like this is in the size of tracking network not necessarily the hardware itself. Even better if you don't have to plant the tracker onto victim, because victim bought it and is intentionally carrying with themselves.
Some of the not quite 90 slopes seem to be due to arrows representing more of topological structure not necessarily accurate geometric representation. Could be elevators with doors on both sides, connect doors on opposite sides and you will get a bit of slope. Some of them might spiral stairways. The vertical spacing between floors is likely also exaggerated for clarity. Underground there might be larger gaps since the train tunnels need to go over each other under the rivers and what not, but there is no way 3 above ground floors (4f-2f) have empty gap 5x the ceiling height of individual floor.
1) Make an ambiguous text
2) Feed it to AI and see which of the 2 it picks
3) If it detects both repeat step 2 using minor adjustments or different AI model until AI responds with one of 2 message
4) Make a blog post claiming that AI chose dummy and other message was the real one
Scammers can also trick the victim into reversing the roles and telling password to scammer. Even banks ocassionaly get this wrong. I have had my bank call me and ask me to read numbers from number card. If a trained bank employee following a script designed by (hopefully) an expert cant get it right, the chance of elderly relative spotting mistakes in protocol is close to 0.
The bank is trying to authenticate you, while you're trying to authenticate the bank. The bank calls and tries to authenticate themselves to the callee by saying "is your birthday such and such?", they're risking sharing PII with an unauthorized third-party. The solutions are a non-trivial amount of effort that no one really wants to put up with, unfortunately.
I used to have a residential mortgage with two other people and my name was stuffed into some ancillary field as a co-holder and they refused to give me any information or transact over the phone. I eventually figured out I needed to tell them to look in some extended info field, and the whole endeavor was annoying but ultimately I was appreciative of the strictness (that the entire mortgage data model—at the time (25 years ago), I don't know what it's like today—seems to assume that it will only ever be two people of opposite gender who are married will be on a mortgage was much more disappointing. The other two people were assumed to be married and the woman was seemingly by default listed as the non-primary).
Hah, I had a background check company for a previous employer send me an email saying:
"Hi Firebeyond, we're doing a background check. Can you confirm the following info you entered into our portal?" then proceeds to list full SSN, drivers license, DOB, etc., etc., etc.
"... and can you also confirm that this is the correct email address we have on file?"
All the while they had reached out by FB Messenger to my partner (not that she was in any of the info I submitted, and this was just a standard BG check, not a security clearance) to ask her if she knew me...
Luckily, my new employer was as horrified as I was, apologized profusely, and fired the background check company.
Disassembler output can relatively easily match original binary, I doubt anyone would consider it decompilation.
Let's say you add requirement of being higher abstraction language than assembly. You can translate the assembly code 1:1 with simple string substitions to C code which would provably replicate the behavior of program perfectly. I would consider that more of hard coded emulation, opposite of JIT like ahead of time code translation. Just because the intermediate langauge is higher level language than assembly doesn't automatically mean that the program text operates at higher level of abstraction than assembly.
I have seen plenty of decompilation projects where you start reading the code many functions contain nonsensical variable reuse (and name that match the register names), address calculations and memory casts and array calculations, arrays of function pointers, offsets within structures which strongly mirrors the assembly code.
The problem is that you can't draw a hard line how good do the variable/function names need to be so that it can be considered decompilation instead of hard coded emulation. It's hard to draw a line for how much of higher level language features you need to use to be considered decompilation. It's hard to define how logical the control flow needs to be. The line becomes blurrier by system programmers approaching it from the other side. Sometimes an extensively optimized code can contain a lot more manual memory mangling, index and offset calculations, manual unrolling than the language requires. So many C programs with homebrew systems of emulating virtual functions using structs of pointers. In such situations it's hard to tell if decompilation is incomplete or whether program was written that way from start.
Another possibility of junk decompilation (which perfectly compiles to byte identical copy of original executable) is program which depends on exact program layout in memory or undefined aspects of programming language. It would perfectly replicate original behavior on original hardware/compiler, but provide 0 insights in intended program behavior and fail miserably when attempting to modify the code or port it to different hardware/compiler. For example the "decompiled" code might intentionally peform out of bounds array access thus touching completely different variable or depend on fallthrough between functions lacking return statement.
Taking it to the extreme would be something like:
```
char data[] = {0x10, 0x12, 0xab, 0xcf, ...}; // bytes corresponding to majority of original program.
int main(){ ((void*())data)(); // cast the array to function pointer and execute it
} ```
It might behave exactly like original program, but that's junk decompilation.
You could add additional restriction that C program isn't allowed to exploit any undefined or machine specific behavior, but then there is very high chance that even original program wouldn't satisfy it.
Original program might also contain parts of it written in assembly for performance reasons or because that was only way to access certain hardware features. What does it mean for decompilation? Is decompiled code not allowed to use the same techniques. If decompiled code is allowed to have some pieces of assembly what stops it from using it for everything. There is no way of knowing precisely how much assembly the original program used.
reply