Flipper Zero: The Thread. I received a Flipper Zero a few days ago, and since I'm idling here at my parent's house, for the holidays, I spent a lot of time playing with it. This thread captures my impressions about the device.
First: the Flipper should put many hardware companies to shame. The user experience is *so* good. Everything works well at the first try. The Android app immediately connects with the device and updates the firmware. It can stream the screen in real time, access the file system.
The battery is already charged when you get the device. The animations are great, the applications well designed and it never crashes despite the fact it is still beta code. A few selected coders and designers shows how much big companies suck at designing hardware and software.
The device is extremely low-power, the battery runs for days and days while you actively use the device. The CC1101 chip (the sub-ghz frequencies RX/TX core) is very low power, and so is the display and the ARM chip running the device. It never gets even remotely hot.
Before understanding what you can really do with a Flipper, let's talk a bit about the software. The firmware is well written and not bloated, even if the code is absolutely uncommented. This is an issue because it talks with the hardware, so the code does a lot of implicit stuff
However as I said code quality is good enough, and there are many (uncommented) example applications. After a few days of reading the code I was able to write my own application (you can find it on my GitHub). The API abstractions are optional and not too complex.
What you can do with the flipper? It shows you the world of RF communications in a quite interesting way, it's a good learning tool. You can duplicate certain RFID tags, NFCs, copy raw signals from the sub-ghz band (various remotes), decode certain signals.
Many of the above things you can do more effectively by installing an alternative firmware with more capabilities. There are mainly two: Unleashed and RogueMaster. They are very similar and share almost everything with the original firmware. Just limits removed and more apps.
Rolling codes: many remores use rolling codes (such as Keeloq or other proprietary protocols). You can record the raw signal and attempt a reply attack, but it will not work if the receiver saw a given generated code already. What is worrying is that:
Designers of certain receivers thought it was a great idea to black list the key ID sending the same sequence twice, so while the Flipper can't open stuff that have rolling codes (at least not without capturing them before, away from the receiver), it can do a DoS attack.
I believe that if the Flipper becomes more common, car companies will start using receivers that don't blacklist IDs when they sense a reply-attack. That's just useless AFAIK, if the block cipher in use is secure, and dangerous (DoS attack).
Jamming: a lot of people will write that the Flipper can't be used for jamming. I've bad news. I will not explain what I did, but I tried to implement an attack to prevent my key from opening my car and I successfully had this jammer working at quite a distance (10 meters).
That's not good, and script kiddies should be away from this techniques. Fortunately so far who understands how to do such things stay avoid sharing them with random people. Just don't trust who tells you that Flipper TX power is too low. If you know the protocol, you can do it.
Programming the Flipper: it is SO MUCH better than the Arduino / RaspberryPI experience if you just want to hack on something. The device build quality is awesome and you have screen and keys to listen to. You can write real applications for a specific device people use and own.
Also the Flipper ARM processor is quite fast, and you can write real C programs with it, no special constraints or limits. You have malloc and free, you have a CPU that can do real time processing, floats, a good standard library, mutexes, threads, all the cool stuff.
TLDR: the Flipper is an awesome device. I'm kinda sad to understand that its successor is Linux based. This stuff was the perfect spot between semplicity, battery usage, computational power. I wanted it to evolve more towards having a real SDR radio inside.
However for newcomers even the fact it uses the CC1101 instead of an actual SDR radio could be seen as an advantage. The chip talks to you in terms of low and high pulses for a given amount of time. It demodulates OOK / 2FSK for you and that's great to go higher level.
So well, a great accomplishment from the team that built it. Hardware companies, learn from them. It is possible to do things that don't suck with a small team and few resources. Most of you do things that suck with 1000x the resources. "Viva il Flipper".
Sometimes I like to rediscover algorithms from scratch. Years ago I blogged (in Italian language) about the algorithm to enumerate the permutations of N elements recursively (oldblog.antirez.com/post/102). Yesterday I wanted to re-discover the equivalent lexicographic algorithm.
The algorithm is well known and very used in practice, so why tweeting about it? Because when you do the exercise of rediscovering algorithms, you develop an intuition about why it works. This intuition helps to remember the algorithm forever even if you are just told about it.
The lexicographic algoritm for permutations is cool because it is completely stateless. Given a sequence of N elements ABC, it is composed of just a NEXT() function that emits the next permutation of ABC so that lexicographically no permutation exists between ABC and the new one.
We often say: that were the cool times! The one of the Commodore64 and 6502 coding, where every instruction counted, every cycle, every byte of memory. Not now, where junior programmers burn gigabytes and seconds of CPU time to emit a single web page! [Boomer voice]. But...
We can make things like this again. Force your managers to understand carbon footprint of the software you are using and building. Don't put just scalability in the mix, but also performance per watt. This way we can help the environment and return to a more sane coding approach.
When I was in charge of the Redis code base, over the years I spent many days to optimize the CPU usage of idle Redis instances. You know? Redis is so massively popular that there are a huge number of idle instances everywhere. Imagine the cumulative environment cost of all that.
Ready to have fun with a software design exercise? Before even looking at how Mastodon works, try to design, just on paper, a decentralized Twitter replacement following the following steps:
Two architectures:
1. Peer to peer (P22) 2. Decentralized servers with a few accounts each (DS)
For P2P, you are allowed to use N "helpers" in form of servers with known IP address, with N small (max 30). Even if just a few are alive, things must work. Use only for discovery.
For DS, is it possible to scale very big users (with many followers) so that they don't require to stay in big servers? How can other servers help?
For P2P, try finding a gossip protocol that helps with data distribution of small and large users.
I think I need to clarify my tweet about layoffs. I don't mean that people jumping from an IT company to the other, with the goal of getting more and more money, are always *the same* affected by the current layoffs. I'm sad for who loved their job and was recently fired.
What I mean is that we collectively created this situation: by asking for a lot of money without caring about social consequences, on one side, and with an absurd money flow leading to over-hiring on another side. But then if you zoom on the individual, you find everything:
You find, for example, the case of the developer staying for many years at Twitter because they trusted on the social mission of the platform. And to see them fired, especially because of the RSU mechanism, is super sad, of course.
Technologies like Copilot tell us two things: 1. How good AI is getting at reproducing and, in some way, abstracting patterns from a big corpus. GPT-3 and Copilot are stunning examples. 2. How much repetitive and empty of creativity most programming tasks are.
Because while spectacular, Copilot has nothing to do with solving tasks; it's just producing obvious boilerplate stuff for us: things that humans need to write following certain API specifications, googling for the missing bits from StackOverflow pages.
Like certain manual jobs, that should be executed by humans only for fun, and not 8 hours per 5 days to pay the bills (and I hope they will get fully automated soon), something similar is happening with programming.
I wonder if the product team of Twitter agrees against the edit button, or there is a single (or just a few), very powerful person, saying "no" while others disagree (even just in their thoughts).
I say this because the public reasons against the edit button are weak. Tweets only need to be editable for a short time, they can be marked as edited, and if edited after the first like/reply an edit history could be attached, and shown if you click the "edited" label.
Moreover the idea that you can just read carefully your own tweets and avoid any error disregards all we know about how humans work. We tend to filter things we are sure are correct. I would be surprised if the "no edit" position is very widespread inside the Twitter HQ.