>> the Tandem tslim X2 requires the user to "prime" the pump tubing with 10 units of insulin every time the pump shuts down or the cartridge is replaced.
> This happens with every pump in one way or another to avoid getting air instead of insulin
The tandem doesn't allow you to finish priming before it's used 10u. Even if you know it's fine, and can see drops of insulin coming out immediately, you've got to wait until it reaches 10u first. I took the author's complaint to be more about that.
I've only had my battery die a couple of times, and I use a fresh line every cartridge, so I've only found it mildy annoying. If you're American and often reusing them, I could see it being more grating.
Yup. It was actually an openjdk crash, which was extra interesting.
I figured I probably could remove some passes, but being a lite user I don't really know/didn't want to spend the time learning how important each one is and how long they take. Ida's defaults were just better.
Leading this by saying I've only used Ida free, I can't comment on Ida pro. I'm also a very lite user of both, I give name functions/vars, save bookmarks, and occasionally work out custom types, and that's about it, none of the real fancy stuff.
I was recently trying to analyse a 600mb exe (denuvo/similar). I wasted a week after ghidra crashed 30h+ in multiple times. A seperate project with a 300mb exe took about 5h, so there's some horrible scaling going on. So I tried out Ida for the first time, and it finished in less than an hour. Faced with having decomp vs not, I started learning how to use it.
So first difference, given the above, Ida is far far better at interrupting tasks/crash recovery. Every time ghidra crashed I was left with nothing, when Ida crashes you get a prompt to recover from autosave. Even if you don't crash, in general it feels like Ida will let you interrupt a task and still get partial results which you might even be able to pick back up from later, while ghidra just leaves you with nothing.
In terms of pure decomp quality, I don't really think either wins, decomp is always awkward, it's awkward in different ways for each. I prefer ghidra's, but that might just be because I've used it much longer. Ida does do better at suggesting function/variable names - if a variable is passed to a bunch of functions taking a GameManager*, it might automatically call it game_manager.
When defining types, I far prefer ida's approach of just letting me write C/C++. Ghidra's struct editor is awkward, and I've never worked out a good way of dealing with inheritance. For defining functions/args on the other hand, while Ida gives you a raw text box it just doesn't let you change some things? There I prefer the way ghidra does it, I especially like it showing what registers each arg is assigned to.
Another big difference I've noticed between the two is ghidra seems to operate on more of a push model, while Ida is more of a pull model - i.e. when you make a change, ghidra tends to hang for a second propagating it to everything referencing it, while Ida tries pulling the latest version when you look at the reference? I have no idea if this is how they actually work internally, it's just what it feels like. Ida's pull model is a lot more responsive on a large exe, however multiple times I've had some decomp not update after editing one of the functions it called.
Overall, I find Ida's probably slightly better. I'm not about to pay for Ida pro though, and I'm really uneasy about how it uploads all my executables to do decomp. While at the same time, ghidra is proper FOSS, and gives comparable results (for small executables). So I'll probably stick with ghidra where I can.
When I used it, the one use case I used it was to automatically launch a Jekyll server - if I'm working on a site I'm almost certainly going to want to look at my changes in the browser. Now that I've switched I just run one extra command, it wasn't a big saving, but it was kind of nice.
The MSVC linker has a feature where it will merge byte-for-byte identical functions. It's most noticeable for default constructors, you might get hundreds of functions which all boil down to "zero the first 32 bytes of this type".
My most common source of unintentional BOMs is powershell. By default, 'echo 1 > test' writes the raw bytes 'FF FE 31 00 0D 00 0A 00'. Not too likely for that to end up in a shell script though.
In normal use it's essentially the same yes. The one interesting edge case that might catch some people out is there's actually nothing special about std::exception, you can throw anything, "throw 123;" is valid and would skip any std::exception handlers - but you can also just catch anything with a "catch (...)".
I recently started working on a repo which historically had 100+ parallel branches. I've been jumping between a few tools recently trying to find something which handles browsing these sanely - I always liked browsing graphs, but the sheer amount of branches ruins most of them.
Currently the best workflow I've worked out is just a plain
git log --oneline --graph -- <dir>
Followed by showing the specific commits. But this doesn't work so well with MRs that touched many files across different dirs. Anyone have suggestions for tools that might handle this better?
An interesting example was Borderlands 2. The game originally had a native port by Aspyr, which worked quite well. 5 years pass and they release a new update and DLC - but they neglected to update the ports. 5 more years pass, then at some point in the past year or two they just plain removed the native Linux packages. They didn't announce it or anything so not 100% sure when. So these days when you install it you always get the (updated) Windows build under proton.
I'm a little sad we lost the native version, but on the other hand running it under proton just works, as I'd been doing for years, and the game would never have been updated otherwise.
If you have an older game which still uses dx9, dxvk can give a decent little performance boost - even if you're running on Windows. It's kind of magical that adding a translation layer is able to improve performance.
In more modern games using dx11/12, I've always noticed a small loss like you'd expect. I haven't properly benchmarked any but I suspect a game with native Vulkan support would do pretty similarly, and might come out on top due to CPU load.
They exist, but one of the problems is they're not particularly good cubes. While it might help you learn the basics, not being able to handle it like a speedcube means they're probably not going to help you get faster.
That being said, while looking up those links, I found out that, since I got out of the hobby, smart cubes have become a thing, and are made by real speedcube manufacturers.
This is an easier problem to solve. I'm not sure if you have to solve it first or if it can identify pieces on power up, but after that it's just tracking rotations, which can be done from the (fixed position) centres alone. But if an actual speedcube manufacturer can already fit those electronics in without comprising performance, I can't imagine it's that much harder to fit some addressable LEDs on some slip-ring-esque connections. Must just not be much of a market.
I'll preface this by saying my experience is with embedded, not kernel, but I can't imagine MMIO is significantly different.
There would still be ways to make it work with a more restricted intrinsic, if you didn't want to open up the ability for full pointer forging. At a high level, you're basically just saying "This struct exists at this constant physical address, and doesn't need initialisation". I could imagine a "#define UART zmmio_ptr(UART_Type, 0x1234)" - which perhaps requires a compile time constant address. Alternatively, it's not uncommon for embedded compilers to have a way to force a variable to a physical address, maybe you'd write something like "UART_Type UART __at(0x1234);". I believe this is technically already possible using sections, it's just a massive pain creating one section per struct for dozens and dozens.
Unfortunately the way existing code does it is pretty much always "#define UART ((UART_Type*)0x1234)". I feel like trying to identify this pattern is probably too risky a heuristic, so source code edits seem required to me.
On a recent 12h Air New Zealand flight I went on they offered free wifi for everyone. They say you can:
- Browse the web.
- Send and receive emails and messages.
- Check and post to social media
In practice I think they just whitelist a few messenger apps. Everything else was unusable - I couldn't even load this site. Only had my phone so couldn't check if I was actually receiving any bytes from other sites, but it at least wasn't immediately blocked.
2800 day streak here, primarily in Finnish. I haven't been a fan of the app for a long time, but the problem I've always had switching is the question: What else? There might be a thousand different Spanish courses, but for less popular languages there just aren't many choices, the fact that they still host one is great. Yes I haven't really learnt much, it's more maintaining what I do know, but I'd've lost it without.
Incidentally I do think Finnish is one of the cases where it could work well. The way I see it the difficulty in learning Finnish is primarily learning an entirely new vocabulary, the grammar and sentence structure isn't that hard, and Duolingo could work well to teach you thousands of new words. The problem is they have a very limited amount of exercises, to the point my phone's auto complete can solve half of them.
---
Please don't just link me stuff you've found on Google, I've tried them all. My favourite was Yle Kielikoulu, but that's been shut down.
I once got a "log into phishing training" email which spoofed the company address. No one even saw the email, it instantly hit the spam filter.
Our infra guy then had to argue with them for quite a while to just email from their own domain, and that no, we're weren't going to add their cert to our DNS, and let a third party spoof us (or however that works, idk). Absolutely shocking lack of self awareness.
> This happens with every pump in one way or another to avoid getting air instead of insulin
The tandem doesn't allow you to finish priming before it's used 10u. Even if you know it's fine, and can see drops of insulin coming out immediately, you've got to wait until it reaches 10u first. I took the author's complaint to be more about that.
I've only had my battery die a couple of times, and I use a fresh line every cartridge, so I've only found it mildy annoying. If you're American and often reusing them, I could see it being more grating.