xxs

26 ms·

511.
by xxs 2y ago
>Apple, which makes sense considering their stance on security. How does it help? A lot of cert would expire prematurely and the folks will learn to accept expired cert as a norm.
512.
by xxs 2y ago
>drop of blood... so cool, if there was some startup to give you a full health info with that. Imagine - with your login attempt it comes a proper analysis if you are fit for purpose.
513.
by xxs 2y ago
It's a very similar situation with concurrent programming. Knowing which instruction does a CAS, or the exact memory semantics of a particular load/store/etc., doesn't do much on its right own.
514.
by xxs 2y ago
the scheduler has been an issue for windows for quite some time... along with the built-in anti-virus (and ads).
515.
by xxs 2y ago
Two beers fine for an old joke!
516.
by xxs 2y ago
> the one was application initialisation ...and then you want to parallelize as much as possible to allow for fast boot times which helps the development process immensely. One of the things I've learned is that optimizing for devel
517.
by xxs 2y ago
b-trees are just 'better' binary trees as they have lower amounts of indirections (nodes)
518.
by xxs 2y ago
Sync is easy. Concurrency is hard. Partly b/c as humans we can't multitask. CPU reordering instructions (and speculative execution) should be not be hard to understand. It tries to do as much work as it could before it has to stal
519.
by xxs 2y ago
of course, no lock. I have written quite the fair share of lock free code (back then when it was new), and generally enjoy writing it (to this day). Yet, for most folks it's just too hard to reason/understand/maintain it. Jus
520.
by xxs 2y ago
spin locks prevent forward grantees, e.g. when the thread is scheduled out (or serves an interrupt), no other thread can make progress. Lock free allows progress - there is no exclusivity. Of course if working on the kernel and controlling
521.
by xxs 2y ago
of course, there is very rarely any a naked CAS
522.
by xxs 2y ago
start with few attempts w/o pause, just busy CAS, then CAS + pause, then yield (and backoff/sleep with random duration)
523.
by xxs 2y ago
Indeed, b/c locks need to have their CAS.
524.
by xxs 2y ago
Lots of code is 'lock free' and uses the same pattern (more or less). Attempt the change optimistically, if it fails spin it, if it keeps failing (Massive Contention), back off.
525.
by xxs 2y ago
if YieldProcessor() actually did switch it'd be awfully expensive, like mentioned "rep; nop", is not just a "nop". OTOH, the usual way to lock via a busy loop/spin, does require some attempts then backoff with
526.
by xxs 2y ago
mutexes are far from the most 'complicated'. There are really not that many way to implement them (efficiently). In most cases there are best avoided, esp. on the read paths.
527.
by xxs 2y ago
> Use your favorite library for point+polygon intersection to decide if you're in a national park it's like 50ish lines of code in C, just iterating over the points (with the polygon represented by arrays of points). The algor
528.
by xxs 2y ago
> ever been to North Europe No need for personal snark comments. Not everybody lives in the US. The worst part moving there was surviving the lack of sun light during the winter but that was many years back.
529.
by xxs 2y ago
>On top of that, the commenter is completely ignorant of the rise of saltwater batteries which don't even use lithium. I'd not call the rise, yet. The Na ones' energy density (and specific energy) is even lower than Li bas
530.
by xxs 2y ago
Talk about North Europe winters - all the forever gray (and snow)
531.
by xxs 2y ago
>how damaging it is mining for rare metals to make those batteries. Even thought I'd agree mass EV would not be carried by the current grid, or that charging density and time is not satisfactory (in most of Europe)... LiFePO4 doesn&
532.
by xxs 2y ago
> Are they storing all of their images in RAM? That part would not matter regardless. RAM is powered at all times, kept being refreshed too. Unless, of course you mean, they'd have to keep buying new machines to store more pictures.
533.
by xxs 2y ago
Hmm - that's quite nice/reassuring, although not my experience. Benchmarking, OTOH, is notoriously hard, esp. the microbenchmark type. The old: lies, damn lies, statistics, (micro)benchmarks.
534.
by xxs 2y ago
>It's much easier to learn good habits than to unlearn bad ones. How do you know they are 'good habits'. I have seen countless years of bad practices lauded internally as amazing/the etalon weight when it comes to cod
535.
by xxs 2y ago
just pointing that even in 6S, it'd be over 5A at the lower end of charge (I'd assume 3V to be the cut off). I have not checked the schematics but I'd expect a PWM controlled resistive heater and Joule counting, i.e. constant
536.
by xxs 2y ago
This (phosphor bronze springs) is, actually, pretty nice. 10A still should require either crimping or soldering, though. The flashlights draw significantly less current.
537.
by xxs 2y ago
So you are saying tool maintenance (well any maintenance) is important?
538.
by xxs 2y ago
While I do agree - you can (or should be able to) get any knife to shave. They may lack edge retention or proper geometry but slicing/cutting/chopping is doable with pretty much any knife, as long as you can sharpen them. I'd
539.
by xxs 2y ago
>Easily replaceable commodity batteries with spring terminals are massively superior to packs. Spring terminals would be sub optimal drawing 10A off them as they are made of steel - high resistance. Developing any oxidation would make ma
540.
by xxs 2y ago
Out of curiosity - why not offer tool battery adapters, e.g. DeWalt/Makita/Milwaukee/Bosch (depending which color you bleed). Those are ubiquitous 18v - have fast charging, and drawing 100W is fine even for the 1P types, e.g

More ›