Same here just swap in Raffi. I wonder if it asks that if everyone top?
960 karma · joined June 22, 2017
Spotify permissions it asks for make sense.
It was really confused by all the kid music I play. Why so much Raffi? Their training set must not include people with children. :)
Old aviation sayings. :) Oh well. ;)
But this has some nice features! For example, it can parse the executables, and show structures:
Disassembler supporting many different architectures ARM32 (ARM, Thumb, Cortex-M, aarch32) ARM64 MIPS (MIPS32, MIPS64, MIPS32R6, Micro) x86 (16 bit, 32 bit, 64 bit)
Just to start, along with a ton of other file parsing, etc.
This looks pretty cool. Compiling it needs a C++20 compiler and no small list of dependencies...but it’s cool.
TLS connection setup is ~10k so if do an 1 HTTPS call/telemetry that's 48 calls home/hour. (11,600/10k = 1,160 https connections/day. There's 1440 minutes/day) Of basically calling home every minute and sending not much.
Ok calling home every minute...but maybe when idle that's not bad for notification updates?
We run long do running TLS connections using MQTT, this works for 5-6 figure of units. And our actual usage when we have good cell coverage is around 25megs/mo, including data. But when you have the qty Google and iOS have....maybe that's prohibitive?
Sucks, was excited to try some games. :/
———
Here is what people have been saying about ctypes.sh:
"that's disgusting" "this has got to stop" "you've gone too far with this" "is this a joke?" "I never knew the c could stand for Cthulhu." You can read more about ctypes.sh and see it in action on the Wiki
I’ve compared relative bitterness of things to a grapefruit. My partner thinks grapefruit is less bitter than beer, or many items I consider barely bitter at all. Yet I find grapefruit to be incredibly bitter, out doing almost everything.
Maybe that’s why I don’t like it much?
> The report shows that q is between 2x and 5x faster than jq in all operations tested and same speed (~1.1x) with huge files (> 100M).
While faster for somethings....that's a pretty large set of caveats!
I don’t think it does the Lua world any favors to be stuck on so many versions. It causes extra work for library developers, makes for poor code samples, and confusion for new adopters. It’s not like Lua is moving quickly with versions either. Every ~5 years for a minor version?
*) yes I know 5.4 is brand new.
Sonic gigabit in SF. I’d say that’s within margin of error. I see 900s on the early AM. Plus my WiFi can’t go that fast so I’m ok with it.
I used to have a report who had a similar train of thought, and ended up writing shell scripts in python which was way more fragile, unreadable and more complicated.
The edge cases are there, but you don’t run into them all that often. Or if you do, you fix your scripts. Take the cp —- 2nd example. You generally don’t start file names with a -. It just makes Unix life annoying so you get pushed away from doing it.
Keep scripts sane and straight forward, you can do really nice and powerful work knowing Unix tools. You can also shoot yourself in the foot some day when you create a file called ‘-rf’.
An enzyme to break down milk seems to be such an easier adaptation compared to a whole series of stomach, which are basically a series of fermenters.
Having raised goats the size of their rumens to body is pretty amazing.
I waste a ton of board space with power supplies. Not everything is personal electronics with custom ICs* in the volume of an iPhone. So this means on my current design there's power supplies for 1v, 1v8, 2v5, 3v3, ~4v, 5v. Each of these the biggest component is the inductor.
I've sometimes joked, I make power supplies with a computer attached.
Edit: since the volume is low we use off the shelf parts which means we tend to end up with a variety of voltage requirements. And yes...reduction of rails is something that's part of components selection, alas....
But so is MicroPython. We were looking for a higher lever than C language for an embedded Linux system* and one engineer was massively in favor of MicroPython. But it’s not python, it’s based on 3.4 so it’s like python but not. It has its own rules and particularities. When I hire a new engineer I’d rather say “here read this book and learn this language” than “ok we have this python work alike/fork, now learn all these exceptions.”
It’s also not a good fit for embedded Linux system programming like Lua is.
*) this is an in production, professional environment, which decision will have years of legacy support and ramifications.
It's incredibly powerful, and a useful feature in Wireshark. Being able to reload/rerun the dissector over packets was amazing and made development really quick and easy, especially in an emergency.
The wireshark docs though, as a bit rough to read, so have a walkthrough is great.
Last time I made heavy use of Digikey was in Australia and it worked really well. I'd order on Thursday and it would arrive by ~Monday, which was pretty awesome. You're right shipping, I remember correctly, was $20-$30, but on $200 of parts it was a small cost.
But as I said, this was done in my professional life, so I didn't blink an eye at it. Hobby world I get is different, but also the cost is frustration as opposed to 1000s, 10,000s of badly built boards.
But $5 doesn't feel bad for shipping to get good parts quickly from a company I trust. But your point is taken. Sucks to put a $0.30 temp sesnor and pay $5 to ship it. =)
Digikey certainly has a premium, but their speciality is small numbers/cut tape/etc and they have a small order size which makes them ok for hobby work, and I've used them for small production runs when I didn't want to end up with a ton of excess materials.
Makes you wonder what other junk is out there, and what purchasing guy figured he'd save $10 and get it from ebay...?
1. Lua embeds well on a small system and gives us a higher level language than C. lua or luajit is ok
2. Lua isn't being used for performant code. If we have performance issues use C.
3. LuaJit is looking for a maintainer and is stagnant. This isn't desirable.
Not sure if this is "best practice" but it summarized how we worked through it.
Lua 5.4 has some appealing benefits for us, we'll give it a few patch releases, but I look forward to moving to it.
Re Performance: We're actually running from 50Hz code in Lua on an old embedded CPU. We haven't re-written that in C yet since it runs just fine. We're been constantly surprised at how well it runs and works for us.
It’s pretty easy to do with NTP synced devices. I’m lucky enough to have a fleet of devices sync with GPS and the PPS signal. It’s pretty amazing to/fun to do latency tests, you grab a time stamp and ship it to far side and time stamp the arrival. Voila single direction latency measurements.
Hiring is nearly impossible, come support our legacy system, and what ever you do, don't introduce Erlang into any other part of the company. Why? We feel burnt on this one project, and god forbid we get any deeper than we are now. What this isn't appealing?
Ah, sure they might be willing, but as a lead I'm not willing to invest in it.
1. I'm not sure I want someone who's got 4 weeks of experience in a language working on system critical infrastructure. Pick your time, does it take 6mo?
2. They have existing work, learning and working on an entire new language _AND_ new project is a huge task. Especially for non-trivial projects.
We could, but in our case it was a better engineering decision was to retire the old system and move on.
Not Elixir, but a cautionary tale from our Erlang project. ~8 years ago a our IoT backend was written in Erlang, this was the early days of IoT, so sure it made sense as a technology, could scale well, handle all the symmetric sessions, etc. It was a good tool for the job and in theory could scale well.
But, there's always a but. We're a Python shop on the backend and C on embedded devices. Engineers move on, there some lean times, and after a few years there was no one left who could support an Erlang system. So we hired for the position, and it's key infrastructure, but not really a full time project, so we hired a Python+Erland person.
But! Now they're on call 24/7 since the regular on call roster are python people and when the Erlang service goes wrong, it's call the one engineer. So, do you hire 2 or 3 people to support the service? No, you design it out. At the time is was 2018, and IoT services were a plenty, so we could use an existing service and python.
Another way of looking at it, let's say it's a critical service and you need at least 3 people to support it/be on call. If each engineer costs $200k/year, that's $600k/year. Does this new language save you that much over using a more generic and widly known language in the org?
It was a small household, no AC, but well pumps, fridges etc and it ran just fine.