Reminds me of a hang in the Settings UI that was because it would get stuck on an RPC call to some service.
Why was the service holding things up? Because it was waiting on acquiring a lock held by one of its other threads.
What was that other thread doing? It was deadlocked because it tried to recursively acquire an exclusive srwlock (exactly what the docs say will happen if you try).
Why was it even trying to reacquire said lock? Ultimately because of a buffer overrun that ended up overwriting some important structures.
>Else trade secrets can easily be hired away from competition
Misappropriating trade secrets is already a crime in several states and federally.
>you are paid highly for the specific reason that you are long term investment for that company.
Sounds like the company then should make staying long term an attractive proposition. I mean I understand, but "investment" usually implies some amount of risk.
Yes, Rust supports annotating your types with a `#[repr(...)]` attribute to control how it gets laid out in memory. There's a "C" repr that gives you representations interoperable with C.
What's stopping those input methods from having a special scroll gesture that is optimal for their input medium? But sure, have an accessibility override for giant scrollbars.
I thinks that of all things, eye trackers and voice controllers have the easiest time sending whatever scrolling commands, without a need to fiddle with scrollbars.
This sorta meshes with how I tend to think of cash. I essentially consider withdrawn cash as already "spent" the moment it leaves my account. So when I do get around to spending that cash (especially on something frivolous) there's less of a hangup over it.
Same—though I didn't used to do that back when 1) I had a whole lot less money, and 2) I used cash way more often.
Now, if I have cash, it's almost always because I intend to spend it, usually for some purpose or activity or over some time period. It's not going back in the bank. Any left over or if plans change, I'll just spend it on whatever. It's "already spent". If it leaves the bank account, it's gone.
>The second most recent was when Windows Store local repository become broken. Any attempt at resolving the issue failed using Windows provided tools. Yet again had to reinstall the OS and all applications.
oh man, I had my Windows install get into a weird state where trying to open 'Updates & Security' would just crash the Settings app altogether. Eventually I submitted a feedback hub report for it with a dump and tttrace (though that was a journey in and of itself) and in the meanwhile I actually managed to get updates installed via the PSWindowsUpdate powershell module. Alas, that still didn't fix the crashing Settings app. I had a friend at MS promote my feedback hub item to a bug who relayed the reason being that my copy of MusUpdatehandlers.dll was corrupt somehow. Ok, I guess I can try using sfc and dism to hopefully repair that. A couple rounds of that and all I learnt was I actually had a few more update related DLLs that were also corrupted. The real kicker being the copy in the store was also corrupted??
2022-05-25 16:40:41, Info CSI 00000226 [SR] Could not reproject corrupted file \??\C:\WINDOWS\System32\\updatepolicy.dll; source file in store is also corrupted
Anyways, I was too stubborn to just reinstall and got it fixed by grabbing an install.wim from an ISO that matched my install and telling dism to use that. The really dumb thing was i first tried to do the repair in offline mode pointing it at the install.wim for sources but turns out that's just not supported.
Instead you get some opaque failure message and it only mentions the fact that wasn't supported in a single line buried in the huge log file.
>Could they have purchased the hardware instead? Probably
Uh, from the article:
>We use many off-the-shelf development boards and even provide support for a number of these boards in Hubris. These are great for many use-cases, but less great when we are trying to model specific circuits or subsystems of our product designs. Second, we have numerous examples of custom boards that were built simply because we could find no useful OTS (off-the-shelf) alternative.
Yes but here the author mixes tool-making and product de-risking. I was talking about tool-making which seemed to be the unique part of the article. Everyone designing hardware products designs some hardware.
You can almost always make tools and test equipment with general-purpose hardware. There are companies that design hardware intended to be used like that. People tend to (understandably) try to drag problems into domains where they are comfortable solving them. In this case they tended to draw solutions from hardware but a software team probably would have solved them a different way.
>By creating a standard, and allowing multiple implementations, someone creating a new OS or a new CPU architecture can create their own implementation of the language without having to wait for anyone else to deign to create the port.
Why does that require multiple implementations? There's nothing stopping said party from adding support for their OS/arch to rustc directly today. There are multiple examples of this already: fuchsia, Sony PSP, Nintendo Switch, etc [1]. Now if you want support in rustc itself out-of-the-box this does require LLVM support your target as well. But even then, again nothing stopping you from adding LLVM support too. The avr-rust project for instance maintained an LLVM/rustc fork for a while before those patches were upstreamed.
Off the top of my head? Maybe you want to target a small system with a native compiler, so users of those systems don't have to cross-compile, but the standard implementation is just too big to run on those systems? (e.g. tcc)
Or maybe you don't want your work to be redistributed under the original project's license, and would prefer to have a copyleft/permissive/proprietary licensed version instead, which can still call itself a "real" implementation. (e.g. mono or gcj/openjdk. Or gcc, originally.)
Why was the service holding things up? Because it was waiting on acquiring a lock held by one of its other threads.
What was that other thread doing? It was deadlocked because it tried to recursively acquire an exclusive srwlock (exactly what the docs say will happen if you try).
Why was it even trying to reacquire said lock? Ultimately because of a buffer overrun that ended up overwriting some important structures.