hansvm

> not every day

Yep

> can take your PTO

You can, but if salaried you usually shouldn't, ignoring any particularly malicious employers and social contracts around the outskirts of the law.

> No obligation to pay hourly employees, tips, etc

Yeah, if you're not salaried you're screwed. PTO might cover a few days, but if you have a month-long trial and need money for rent then my understanding of the law is that serving as a juror will make you homeless unless the courtroom is willing to extend some compassion for your hardship.

If you perform nearly any work at all in a given week you're entitled to your salary, and they can't fire you. They might be able to take away the $15/day stipend from your pay, and there are obvious additional negatives (6 months with limited context and practice of your craft will reduce your performance when you get back too), but that 2-week cap is a lawsuit waiting to happen unless they also forbid you from doing any work while on jury duty.

I'm listening

Of course there is. Raw machine code is the gold standard, and everything else is an attempt to achieve _something_ at the cost of performance, C included, and that's even when considering whole-program optimization and ignoring the overhead introduced by libraries. Other languages with better semantics frequently outperform C (slightly) because the compiler is able to assume more things about the data and instructions being manipulated, generating tighter optimizations.

On their own merits, people choose SMS-based 2FA, "2FA" which lets you into an account without a password, perf-critical CLI tools written in Python, externalizing the cost of hacks to random people who aren't even your own customers, eating an extra 100 calories per day, and a whole host of other problematic behaviors.

Maybe Ada's bad, but programmer preference isn't a strong enough argument. It's just as likely that newer software is buggier and more unsafe or that this otherwise isn't an apples-to-apples comparison.

Thanks for the comment. Lack of seriousness is now appropriately indicated.

It's probably just a higher rate of autonomous vehicles needing stop signs and buses identified at that moment, and cognitive bias causes you to only remember when that happens when you recently performed an update. /s

I suppose I shouldn't be surprised that complaints of rocks where you expect soil invite other Ozarkians. That was something that shocked me about the Midwest in comparison; even with a concerted effort, I couldn't find enough of a rock to fill a slingshot.

Details depend, but the root cause is basically the same every time: your hardware is designed to do something other than what you want it to do. It might be close enough that you want to give it a shot anyway (often works, often doesn't), but solutions can be outside of the realm of what's suitable for a "prod-ready" service.

If you're experiencing NMIs, the solution is simple if you don't care about the consequences; find them and remove them (ideally starting by finding what's generating them and verifying you don't need it). Disable the NMI watchdog, disable the PMU, disable PCIe Error Reporting (probably check dmesg and friends first to ensure your hardware is behaving correctly and fix that if not), disable anything related to NMIs at the BIOS/UEFI/IPMI/BMC layers, register a kernel module to swallow any you missed in your crusade, and patch the do_nmi() implementation with something sane for your use case in your custom kernel (there be dragons here, those NMIs obviously exist for a reason). It's probably easier to start from the ground up adding a minimal set of software for your system to run than to trim it back down, but either option is fine.

Are you experiencing NMIs though? You might want to take a peek at hwlatdetect and check for SMIs or other driver/firmware issues, fixing those as you find them.

It's probably also worth double-checking that you don't have any hard or soft IRQs being scheduled on your "isolated" core, that no RCU housekeeping is happening, etc. Make sure you pre-fault all the memory your software uses, no other core maps memory or changes page tables, power scaling is disabled (at least the deep C-states), you're not running workloads prone to thermal issues (1000W+ in a single chip is a lot of power, and it doesn't take much full-throttle AVX512 to heat it up), you don't have automatic updates of anything (especially not microcode or timekeeping), etc.

Also, generally speaking, your hardware can't actually multiplex most workloads without side effects. Abstractions letting you pretend otherwise are making compromises somewhere. Are devices you don't care about creating interrupts? That's a problem. Are programs you don't care about causing cache flushes? That's a problem. And so on. Strip the system back down to the bare minimum necessary to do whatever it is you want to do.

As to what SystemD is doing in particular? I dunno, probably something with timer updates, microcode updates, configuring thermals and power management some way I don't like, etc. I took the easy route and just installed something sufficiently minimalish and washed my hands of it. We went from major problems to zero problems instantly and never had to worry about DMA latency again.

Yeah, the situation from TFA doesn't make a lot of sense; I was just highlighting that it's not as clear-cut as "costs > 1 FTE => fix it."

I mostly agree, but it's more appropriate to weigh contributions against an FTE's output rather than their input. If I have a $10m/yr feature I'm fleshing out now and a few more lined up afterward, it's often not worth the time to properly handle any minor $300k/yr boondoggle. It's only worth comparing to an FTE's fully loaded cost when you're actually able to hire to fix it, and that's trickier since it takes time away from the core team producing those actually valuable features and tends to result in slower progress from large-team overhead even after onboarding. Plus, even if you could hire to fix it, wouldn't you want them to work on those more valuable features first?

That reminds me of one of the easiest big wins I've had in my career. SystemD was causing issues, so I slapped in Gentoo with the real-time kernel patch. Peak latency (practically speaking, the only core metric we cared about -- some control loop doing a bunch of expensive math and interacting with real hardware) went down 5000x.

That specific advice isn't terribly transferable (you might choose to hack up SystemD or some other components instead, maybe even the problem definition itself), but the general idea of measuring and tuning the system running your code is solid.

> good stuff rejected, are you sure that's true

In the academic circles I frequent, it's not true. Any one journal might reject the good stuff, but it doesn't take more than a few applications to find a journal who recognizes it, and the cost of producing the research is so high that with the current career incentives it'd be ridiculous not to continue submitting. That does mean that journal "quality" matters less than you might think, but I don't think anyone's surprised by that notion either.

Errors the other direction are more common. I'll state that as an easily verified fact, but people like fun stories, so here's an example:

One professor I worked with had me write up a bunch of case studies of some math technique, tried to convince me that it was worth a paper, paid somebody else to typeset my work, and told me to compensate him if I wanted my name on the "paper." I didn't really; it was beneath any real mathematician; but there now exists some journal which has a bastardized, plagiarized version of my work with some other unrelated author tacked on available for the world to see [0], and it's worth calling out that nothing about the "paper" is journal-worthy. It's far too easy to find a home for academic slop, and I saw that in every field I spent any serious amount of time in.

[0] https://www.m-hikari.com/ams/ams-2019/ams-9-12-2019/p/jabbar...

Every place I've lived other than CA has had >3x cheaper electricity. If the max break-even period in CA is 20yrs, that's 60yrs in those other places, which is both longer than I practically care about (not that I'm not a fan of non-renewables for other reasons, but we're in a thread talking about costs) and also far beyond the useful life of any of the renewable tech involved, meaning I wouldn't achieve a full 60yrs of benefits in the first place, even if I let the system run for an indefinite period of time.

I know there are other places with high energy costs, but for the majority of the US (both by land area and population count) solar doesn't make economic sense without additional incentives.

And even that analysis assumes that you're forced to use electricity. Many home appliances are vastly more efficient dollar-wise when powered by various petroleum products.

Not all software can be sufficiently insulated from external changes, but almost all software I care about can be. My normal update cadence is every 2-3 years, and that's only because of a quirk in my package manager making it annoying for shiny new tools to coexist with tools requiring old dependencies. The most important software I use hasn't changed in a decade (i.e., those updates were no-ops), save for me updating some configurations and user scripts once in awhile. I imagine that if I were older the 18yr effective-update-cycle would happen naturally as well.

My gut reaction is that the software you're describing relies heavily on external integrations. Is that correct?

There's a sort of mixing of units happening here, and I think it's causing some confusion. Here's an example (greatly simplified) scenario highlighting a flaw in your rationale:

1. Energy at your normal usage costs $1000/yr.

2. You can spend $20k now to have access to equivalent energy output for the next 40 years before it degrades to unusability.

3. Next year, somebody invents a flux capacitor bringing all energy costs for everyone down to $1/yr.

If you don't buy the thing, you spend $1039 over the next 40 years. If you buy the thing you spend $20k, and it's hit its expected lifespan, so you don't recoup any further benefits.

The real world has inflation, wars, more sane invention deltas, and all sorts of complications, but the general idea still holds. If you expect tech to improve quickly enough and are relying on long-term payoffs, it can absolutely be worth delaying your purchase.

If you predict massive improvements in solar/battery/etc tech, the only way it makes sense to invest now is if those improvements aren't massive enough, you expect sufficiently bad changes to the alternatives, etc. I.e., you're playing the odds about some particular view of how the world will progress, and your argument needs to reflect that. It's not inherently true that just because solar pays off now it will in the future.

To be fair, CA is one of the only places that's true, largely due to PG&E fuckups paired with a legislature keen to grant them unlimited money to kick back to shareholders.

Incentives drive outcomes, do they not? It's too easy to become a billionaire as a charlatan and too hard as somebody able to make a difference. Rather than granting Zuck nearly unlimited power and politely asking him to use it wisely if he doesn't overly mind the inconvenience, why not create a world where monsters can't have that much power in the first place?

Man, I wish I had access to heavily compacted, organic-poor, heavy-clay soil. It's the 80% rock that makes even basic tasks a day-long chore.

That's not a great comparison. People absolutely do learn by watching, especially when they do so actively.

Your counter-examples have the property that most of the things you need to learn are absent from the media being watched, leading to an observation which is "obviously" true, but they ignore the impact of media on a journey properly incorporating other pieces of information. To compare to the mental models being discussed, you'd have to actually consider effects you're writing off as negligible, and when it comes to something like a world model which we've only learned by observation and which doesn't have a lot of additional specialized knowledge those effects might be much more impactful.

I didn't have a lot of choice. I was pretty broke and also couldn't afford to skip 2 months of work or school. Nowadays I'm a bit more careful with my time.

To their credit, the 24hr hold would actually serve an important, legitimate purpose if the same malware weren't going to be on the PlayStore anyway. I was expecting to disagree with their public statements more than I actually did on this topic.

This still isn't a good idea. It's not going to materially improve security for anyone, so all the negatives (beaten to death here and elsewhere) are still top-of-mind.

Does it take 10 minutes to choose? Back when I was commuting, I had different kit depending on the temperature, and it wasn't exactly hard.

>50F: Summer gear, and not much of it. I run hot, and there's no need to make it worse.

>20F: Add a thick sweatshirt and gloves

>0F: Add wool socks, long pants and a wool underlayer, a windproof outer shell, glasses, a hat, a thicker windproof layer over my gloves, and sometimes a scarf depending on how short I'd cut my beard.

>-20F: Similar, but with some extra layers over my core, and the scarf is mandatory.

>-40: Similar, more layers.

<-40: I know my limits. I've nearly gotten in serious trouble before when it's too cold out and I didn't plan for extra wind and a cold pocket near the river or having to walk because of a poorly maintained road or whatever. My gear wasn't especially high-tech, and I just called work and emailed my professors to let them know I wasn't going to make it.

Wind would have me reaching for wind breaking and insulation at higher temperatures.

It wasn't a 10-minute process by any means though. I'd pull out my phone in the wee hours of morning, see that it was X temperature on the homescreen, and plan accordingly. If he's just selecting between a few jerseys that should be even easier, right?

It........depends.

I make things faster all the time by leveraging various CPU caches, sometimes even disk or networked disks. As a general principle though, memory lookups are substantially slower than CPU (and that has indeed changed over time; a decade or three ago they were close to equal), and even cache lookups are fairly comparatively slow, especially when you consider whole-program optimization.

That isn't to say that you can't speed things up with caches, but that you have to be replacing a lot of computations for even very small caches to be practically better (and even very small caches aren't helpful if the whole-program workload is such that you'll have to pull those caches from main RAM each time you use them).

To your paper in particular, their technique still assumes reasonably small caches which you constantly access (so that you never have to reach out to main RAM), even when it was written, and part of what makes it faster is that it's nowhere near as accurate as 1ULP.

Logarithms are interesting because especially across their entire domain they can take 40-120 cycles to compute, more if you're not very careful with the implementation. Modern computers have fairly fast floating-point division and fused multiply-add, so something I often do nowadays is represent them as a ratio of two quadratics (usually rescaling the other math around the problem to avoid the leading coefficient on one of those quadratics) to achieve bounded error in my domain of interest. It's much faster than a LUT (especially when embedded in a larger computation and not easily otherwise parallelizable) and much faster than full-precision solutions. It's also pretty trivially vectorizable in case your problem is amenable to small batches. Other characteristics of your problem might cause you to favor other solutions.

I sent out screens to ~15-25% of resumes (a higher rate for new grads, lower for seniors, not wanting to unnecessarily rule them out just because they didn't have positive evidence of potential success and didn't know how to write a resume, only ruling them out of there was positive evidence they'd be unsuccessful). That amounted to ~100 per position filled. Around half of those completed the take-home. Some of the rest should have self-selected out and didn't, which is something I'd like to improve if I run a take-home again.

You're right the time commitment wasn't equal. Early on I spent much more time than the candidates designing and analyzing the test. Afterward, their 20 minutes would usually take me <5min (often <1min for obvious failures and obvious passes, the average brought up due to time analyzing edge cases).

I did read every submission though. It wasn't wasted time for candidates.

Cheating is possible in the abstract, but I found a tight correlation between interview and take-home performance. For whatever reason, candidates didn't seem to cheat much.

The AI point is worth diving into a little. This was a year ago, so SOTA was worse, but I didn't find it terribly hard to write questions AI couldn't solve, whose answers you couldn't search for, and which good candidates could solve. The test was a few of those questions and a few which were easier to cheat, and almost nobody had good scores on just the cheatable section.

I don't think that moat will exist indefinitely, but today's AI just isn't very good at a lot of incredibly basic tasks unless the operator has enough outside knowledge to guide it in the right direction (and if a candidate did that I mostly wouldn't care because, by definition, they had the knowledge I was looking for). I use AI a lot, it's great at a lot of things, some even quite complicated, but it was weaknesses, and those are pretty easy to exploit.

> examples

One such question (obviously tailored to the role I'm hiring for) is asking whether SoA or AoS inputs will yield a faster dot-product implementation and whether the answer changes for small vs large inputs, also asking why that would be the case.

I typically offer a test with a small number of such questions since each one individually is noisy, but overall the take-home has good signal.

> why not test that directly?

The big thing is that you don't have enough time to probe everything about a candidate, especially if you're being respectful of their time and not burning too much of yours. Your goal is to maximize information gain with respect to the things you care about while minimizing any negative feelings the candidate has about your company.

I could be wrong, but vibe coding feels like another skill which is more efficient to probe indirectly. In your example, I would care about the prompt/session, mostly wouldn't care about the resulting code, and still don't think I would have enough information to judge whether they were any good. There are things I would want to test beyond the vibe coding itself.

In particular, one thing I think is important is being able to reason about code and deeply understand the tradeoffs being made. Even if vibe coding is your job and you're usually able to go straight from Claude to prod, it's detrimental (for the roles I'm looking at) to not be able to easily spot memory leaks, counter-productive OO abstractions, a lack of productive OO abstractions, a host of concurrency issues LLMs are kind of just bad at right now, and so on. My opinion is that the understanding needed to use LLMs effectively (for the code I work on) is much more expensive to develop than any prompt engineering, so I'd rather test those other things directly.

It's been a year since I've actively given out take-homes for hiring, but I'm not sure I agree that everyone will use AI. I designed half the questions to be impossible for current-gen AI to answer without the candidate actually knowing what's going on [0], and only ~1% of candidates who responded did poorly on that half and not the other half (and, if we're worried about LLMs being better than I think, not all that many candidates passed most questions either).

[0] The most reliable strategy I've found for that is choosing questions where the wrong answer is the right answer for some much more common question. Actually spending a few seconds and solving the problem easily lets a human pass, but an LLM with insufficient weights or training data (all of them) doesn't stand a chance.

The last time I was hiring I gave out a take-home test, and I thought it was the opposite of an imposition on candidates' time. I'd be curious to hear your thoughts:

- It was designed to be fast to complete (20min max -- not a huge imposition if being hired is likely, obviously very expensive if you're taking one for every job posting).

- I only gave them out after a resume screen. If you had a 0% chance then I didn't waste your time. If you had enough other proof of abilities then I skipped the take-home.

- Candidates were told that it was designed to be fast and that if they couldn't complete it quickly they were unlikely to be successful interviewing either. They still had the option to spend a lot of time if they thought my assessment of the situation was wrong, but part of the point was to allow candidates to gauge their own abilities and not waste their time interviewing without a chance of being hired.

- I did a lot of work behind the scenes calibrating and re-writing the questions individually and as a whole so that the test score correlated very well with interview performance (most interviews administered by not-me, removing a form of bias that's easy to creep in there).

It's been a non-issue for us at tvScientific. Once or twice a year you settle in for a mass refactor, and when that's done you move on with your day.

Packages do fall behind. We only use a couple, so it's pretty easy to point to an internal fork while we wait for upstream to update or to accept our updates. That'd probably be a pain point if you were using a lot of them.