Lwerewolf

Re: $1k/day on tokens - you can also build a local rig, nothing "fancy". There was a recent thread here re: the utility of local models, even on not-so-fancy hardware. Agents were a big part of it - you just set a task and it's done at some point, while you sleep or you're off to somewhere or working on something else entirely or reading a book or whatever. Turn off notifications to avoid context switches.

Check it: https://news.ycombinator.com/item?id=46838946

On that note, I could also comfortably fit a couple of chat windows (skype) on a 17'' CRT (1024x768) back in those days. It's not just the "browser-based resource hog" bit that sucks - non-touch UIs have generally become way less space-efficient.

FoundationDB's approach - look up their testing framework.

I've worked in a company that, for all intents and purposes, had the same thing - single thread & multi process everything (i.e. process per core), asserts in prod (like why tf would you not), absurdly detailed in-memory ring buffer binary logs & good tooling to access them plus normal logs (journalctl), telemetry, graphing, etc.

So basically - it's about making your software debuggable and resilient in the first place. These two kind of go hand-in-hand, and absolutely don't have to cost you performance. They might even add performance, actually :P

Re: "yes men" - critical thinking always helps. I kind of treat their responses like a random written down shower thought - malicious without scrutiny. Same with anything that you haven't gone over properly, really.

The advantages that you listed make them worth it.

This kind of works for me, GPT 5.2:

Base style & tone - Efficient

Characteristics - Defaults (they must've appeared recently, haven't played with them)

Custom instructions: "Be as brief and direct as possible. No warmth, no conversational tone. Use the least amount of words, don't explain unless asked.'

I basically tried to emulate the... old... "robot" tone, this works almost too well sometimes.

Same with doing things in RAM as well. Sequential writes and cache-friendly reads, which b-trees tend to achieve for any definition of cache. Some compaction/GC/whatever step at some point. Nothing's fundamentally changed, right?

Google "K-series Cam lobe pitting".

Anyways, nice engines, but you don't need something to be exceptionally reliable to keep it in production for 25 years.

I'm pretty sure that most cases of x86 reordering issues are a matter of the compiler reordering things, which isn't (afaik) solved with just "volatile". Caveat - haven't dealt with this for at least over a year (multicore sync without using OS primitives in general).

Would you mind linking some articles or hinting towards techniques used to "coerce" the choosing of ray sample directions so that noise is minimized even in very "specular" scenes? Sorry for the lack of proper terminology on my end, I've been out of the loop for a very long time, but I assume that's where the majority of the tricks are - I suppose the rest is mostly intersection check accelerations (i.e. BVH).

I always move the taskbar to the right on any remotely wide setup that I have - including my 21:9 main. Had it at the top on my sp3. On my current portable (spectre 13.5) it's at the bottom, since I kind of have to use win11 due to the heterogeneous cpu arrangement (how "hard" could it be to port the scheduler to win10... yeah yeah we know), and while it annoys me when I dock it at work, the system (win11 pro, with MS account) absolutely does suck in a lot of other respects.

Right click latency in explorer is annoying.

Opening the settings "app" after first boot takes several seconds because who the hell knows - I personally blame it on moving everything to some thousand layers JS framework since I like being grumpy about that. This is a core part of the OS, FFS. Fairly certain that they have the talent to pull it off properly.

Search has been fine for me.

Language switching almost always breaks during updates - "ghost keyboard layouts" and such. Has been the case for a few years now.

General "we'll shove down whatever we feel like on you" BS.

Just let us pay for "ultimate" (a.k.a. end-user enterprise) and be rid of all the BS.

Getting WSA back (yes, I have the community version) and expanding on connected standby or however they call it now would've been neat, especially on a convertible, but it is what it is, I guess. WSL2 is also quite the improvement. Lots of other small little things like the task manager (not using procexp too often nowadays).

Stress hormones. Read up on cortisol's effects. XCM - cross country marathon (MTB race). 2700mD+ - 2.7km of vertical gain. A reduction of inflammation is a general effect of anti-inflammatory drugs, which tend to make you feel better. There's a LOT more than that (i.e. say, all the things that fall under the umbrella of "runner's high"), but the TL:DR is that significant physical activity / energy expenditure, combined with a lack of proper rest & nutrition leads to long-term undesirable effects that can definitely be masked and/or disregarded.

Be careful with that feeling and don't underfuel, or at least keep it at "sane" levels. I feel pretty amazing and full after 62km/2700mD+ XCMs as well, as an extreme example... which is at least partially due to the immune system (and resp. inflammation/etc) being suppressed. Long, light/moderate efforts without adequate food intake and rest can lead to the same thing.

Aren't most UAC bypasses relying on the fact that UAC by default isn't "full sudo"mode - i.e. it allows certain things without prompting?

I guess you meant to say "only the people working on the software coupled to the tooling will use it". It's not just FDB & Amazon that are using something like this, and it is a ridiculously powerful type of tool for debugging distributed systems.

Brake torque is far higher than engine torque and can be applied at speeds where tire traction is far greater - at least at the front. The rear makes far more sense for this application - assuming a performance RWD or AWD vehicle, the rear driveshafts already handle most of the acceleration load, and max rear braking load is practically severely limited by the load transfer to the front.

Formula student cars and other open-wheelers have far greater packaging flexibility as well. A quick search doesn't bring up a whole lot of encouraging discussions on FSAE and related places re: inboard brakes, please share if you've seen such.

The major "sudden" failure mode of pretty much all those systems has so far been the (brushed!!!) electric motor eating through its commutator (with the brushes still relatively intact) and stopping relatively suddenly - at that point, you'd better not ignore the lights on the dash, as it means there's only what's left in the hydraulic pressure accumulator in terms of assistance - afterwards there's almost nothing. The backup hydraulic lines have never really been an issue with this setup - the backup lines are two and directly go to resp. the front left and right calipers, and the only time they see pressure and fluid movement is during the brake bleeding procedure. The rest of the hydraulic circuits are somewhat safer as cars with such systems can absolutely detect and isolate a "misbehaving" circuit - i.e. if a flex hose is punctured, the rest of the system will work.

I wonder how strong the driveshafts would have to be to handle all the braking torque transmitted through them. Dissipating the heat would also be an interesting problem. Also reduced clearance and/or increased drivetrain complexity and a million other things.

There are good reasons why people haven't moved away from old school rotors, pads & calipers right at the wheel hub, for basically any application.

Not too different from, say, any of Toyota's hybrids (and the TLC100 / GS430 / others using "electronic brakeforce distribution")? Same with almost every EV out there, same with MB's SBC, etc. I really don't see why this counts as a big leap - all I see is the removal of the backup direct hydraulic lines, which doesn't exactly sit well with me.

-Rim brakes means ever so slightly bent rim = SOL.

-There are some decent internal cable routing setups. The newest fad (through-headset), though...

-Comfort has a ton of variables, of which tyre volume/pressure/type/details(inserts/etc) are a major part of, but not the be-all-end-all. Grips, handlebars, saddles, pedals, crank length, etc, etc, etc, etc...

The Prius and other HSD cars (i.e anything with a power-split device of the Toyota variety - input-split PSD) are some of, if not flat out the most reliable and simple ICE cars. Permanent atkinson-cycle engine, no turbos because there's no exhaust gas pressure to drive them in the first place (and if there was, it'd be an inefficiency to be rooted out), bulletproof starter/generator especially since the ls600h (double-sided cooling of IGBTs >> no usual IGBT packaging degradation-related failure modes - this was NOT the setup on the 3rd gen prius), still a very efficient power transfer from the engine to the wheels (a big percent is still transferred mechanically), etc, etc.

Adding a bigger battery to those isn't a whole lot of increased complexity. The only issue is making a PHEV that has the same performance characteristics in both EV and hybrid mode - not that it hasn't been done. Specifically on HSD cars, the two electric motors combined, or even just MG2 (the "motor") have way more power than you'd assume - they actually function as an AC-AC converter, converting a significant portion of the engine's output power from mechanical to electric and back to mechanical again. It's essentially the way the eCVT works. Therefore, with a battery (and buck-boost converter) that can support such a load, they can propel the car alone way more than adequately - with a speed limit to protect the "generator" from too high RPM, due to the way the HSD works.

Anyways, it absolutely can be done and it absolutely can be way simpler. If it's a case of a typical modern ICE with a big battery and a motor thrown in somewhere that makes it "hybrid"-ish - i.e. all the ICE complexity + the EV "complexity" (minus the classic starter/alternator) - yeah, no thanks.

IMO: Good examples - the Chrysler Pacifica PHEV. Bad examples - C63 AMG (the PHEV version).

1.8l engines were always an option.

Sounds like the typical case of people not looking at the core work required in order for the very expensive individual items like tailored nutrition, top-end (and even customized) parts, per-race-specific optimized chains and what not to make any sense whatsoever.

If your times are, say, 20% or more above the absolute top times for a given course, you've got a long way to go by improving yourself - on just about any bike whatsoever. The super expensive parts make low single digit differences.

Good LCDs (i.e. native 8-bit IPS) have been available for a very long time. No-compromise gaming IPS's (120hz+, backlight strobing) - for more than 7 years. Decent 60hz ones (and even 76hz - 2209WA with overdrive) - for far, far longer. Yes, there's still the IPS glow, A-TW polarizer-equipped panels are almost impossible to look up in the first place. Yes, the black level is still pretty bad, unless you have a stacked matrix reference Sony or something. Yes, cheap 16-bit-with-bad-dithering TN less-than-sRGB-gamut LCDs are not great, but so were the el cheapo shadow mask CRTs.

Regarding what others earn - I've already asked the ones that I know, and on average it's 20-30% more (mobile dev & security... advisor, you could say).

About the concern of not having a more senior person around - true. I was (and still am, as a good measure) scared of that bit, what I pretty much did was dig in everything that I could find on the subject before development of my part (and the ones that I'm linked to - not writing a software driver ;) spinned up. That pretty much meant scouring the books (windows internals, Oney's WDM, MS's WDF one, except for the UMDF part), MSDN/linked "whitepapers" (let's say that there are some holes), any sample code that I could find, and most helpfully, NTDEV discussions/linux drivers docs and guides (yes, it is very relevant :)/osdev wiki&forums... and whatever else I've stumbled upon that seemed even remotely connected. As a consequence, I had a slight burnout during my part-time period (school&work) - I'm nowhere near as exhausted now (8/day) as I was during that period (3-4/day) :)

The other defense mechanism against being alone is that documents and code reviews are common in the company, and I'm steadily documenting / teaching others (who have significant linux drivers experience) the concepts of windows drivers, so it's not entirely without scrunity. Perhaps the biggest issue there is converting people from the "windows sucks/linux rules" mindset (well, it's not so bad, but there are some cases in which I feel it approaches that set in stone mentality).

Also, a mindset of "making the thing work somehow" for kernel programming (driver or otherwise) doesn't strike me as proper ;)