debatem1

Not meaning to derail an interesting conversation, but I'm curious about your description of your work as "applied probability". Can you say any more about what that involves?

...then it is clearly AI?

It isn't impossible that it's AI, but assuming writing and publishing happen at the same time would also lead you to conclude that Anne Frank wrote from the afterlife.

> Imagine if Siri could genuinely file your taxes

If you trust openclaw to file your taxes we are just on radically different levels of risk tolerance.

Every time I see one of these stories I wonder how many tools I would have to remove from my garage to make it impossible to build a primitive gun in there. With enough ingenuity I'm really not sure there would be anything left.

There is some evidence to suggest that spacex knows how to reenter an object without burning it up.

Possibly, although that article seems quite confused as well (of course they need custom silicon, and of course that doesn't mean anything about what COTS parts they do or don't use). It would be nice if SpaceX would publish more about its compute architecture.

SpaceX supposedly mostly runs non-rad-hard parts, the ostensible reason being because its more cost effective to double or triple up than buy specialty equipment. Do you have a source for this?

How is this different from slushomatics? Sounds exactly like old school fluid couplings.

Anecdotally, a lot more people in the US tow. And pickup trucks are the indisputable king of towing.

There's also the fact that it's a lot harder to take the top off a van than it is to add a top to the bed of a pickup. If I sometimes moved manure and had a van... I'd probably rent a trailer.

The biggest thing I learned from PE was that neither elegant theory nor brute force had a monopoly on successful optimization strategies. It's been something I've carried with me ever since and has over and over again proven its value.

A real gem of a resource.

My politics and his don't line up but I'm not against this. It would be pretty interesting to see the impact on cash usage, and faces on money are pretty archeologically useful-- at least on coins.

Isn't this basically just putting the kid in a tumble drier whenever you hit turbulence? Did they pad the roof and door as well?

I think there's something to what the author says about the shift from mission-driven startups to naked greed, but I don't think I would have put it that way.

Over the last two decades the startup scene has gone from trying to improve nearly everybody's lives at very low cost to consumers (ad-supported services like maps and email) to trying to improve the lives of the upper middle class with debatable impacts on everyone else (gig economy stuff) to something whose most obvious application is destroying jobs (ai).

That's a pretty quick shift from utopian to dystopian rhetoric, and people who bought the line are right to find that jarring.

> Democrats stuffing government bureaucracies with do-nothing jobs for their buddies

Ignoring the partisanship this argument doesn't make sense on its face: government jobs pay extremely poorly. You might say "well what if you hold more than one of them?", but you can't do that: a federal employee can be employed in two different roles, but their pay is capped at 40 hours a week across the federal government.

Anyone keen on that level of grift has vastly better options in the private sector.

> if the shares are truly worth X dollars they should buy them back from me

I always offer companies pushing equity hard to trade for cash at 10% of the highest number they try to get me to value it at. Nobody has ever taken me up on it, even when they really should have.

None of these snippets appear to involve eBPF at all?

If you figure out how to do this I will invest in your fund.

The point of what I spelled out above is that they can jump to the instruction but the kernel will kill the program if they don't go through the function up to that point. That allows you to restrict the arguments to the syscall at the point of call.

"Attacker has ROP and shouldn't be able to make arbitrary syscalls".

Seems mildly useful if you have a really flexible syscall you can't forbid (ioctl, say) but which you only use for a specific narrow purpose.

Seems like an interesting if maybe not practical protection to implement in eBPF for programs that never make a naked syscall.

Step one would be to ensure that every syscall has a wrapper. Place a uprobe at the start of that wrapper which, when hit, sets a per-thread permission bit and a per-thread-per-syscall permission bit in an eBPF map. Place a corresponding uretprobe that clears the per-thread-per-syscall bit. For each syscall place a kprobe which checks the per-thread table to make sure the thread is one which has enabled the feature, and which then checks to make sure the per-thread-per-syscall bit is set for that syscall. If not, sigkill.

Performance would probably suck but it seems like it would protect the syscall entrypoints enough to do some potentially interesting attack surface reduction. The question is really why you would do that there instead of by attaching to, say, the LSM hooks where you have stronger guarantees vis a vis userspace.

I don't think anyone ever doubted that a C program could be memory safe. The problem is knowing without exhaustive work whether yours is one of them.

These aren't bad practices, but I don't think they satisfy that desire either.

I don't know if it was deliberate, but writing code that interfaces with GDB is unpleasant enough that I opted to build our debugger-like tooling in eBPF + pyelftools instead.

Custom forms for concrete pours. Also did a little bit of work making supports for plaster casting.

I was never really able to sell the advantages to artists, but got some good side gig money for landscaping stuff.

(Just to clarify: the business is wound down, but I personally still use the approach in art projects)

I really wanted to love this, but after setting up an older version and spending untold hours debugging it I just can't make myself believe anymore. I am glad to see them move to four cables though-- two + weights was a nice bit of math but not so great as physics.

If you're looking at this, think hard about whether it's possible to cut a router template for what you want to do on a normal sized 2.5D CNC router. It's what I do and is good enough to build a business around.

I wrote a tool a few years ago which automatically generated and inserted type-aware fuzzers for C APIs from DWARF info: https://github.com/intel/fffc

Generating headers and also mutators that you could then modify to meet type constraints was part of that.

Edit: just to add onto the LLM side, I can see this labelling anonymous structs or similar but I'm not sure that's a good idea. What might be interesting would be to try to get an LLM to verbalize/summarize known type constraints for documentation purposes.

Isn't this basically also true of exercise? Running is great for you, but it puts a strain on the cartilage in your joints which will become slower to heal and faster to harm over time. Still, most people would rather have great pulmonary health and a knee replacement by 70 than nice knees and a bad ticker.

Maybe a similar tradeoff here.

Seems like a business opportunity

Intel's main problem is its people. Sorry to say.

The management culture there is insanely siloed and toxic, full of scar tissue from previous periods of political turmoil and a few relentless sociopaths who absolutely will not stop climbing just because it's obviously damaging to the company.

The engineering culture is full of secrets, moats, and the general sense that while making progress might be your job, stopping it is everyone's job. And there are always more of them than there are of you.

Perhaps most fatally, responsibility for decisionmaking is ultimately delegated to the process of decisionmaking rather than the people involved. The resulting proliferation of checkboxes and box checkers have elevated dysfunctions like "the perfect being the enemy of the good" and "none of us is as dumb as all of us" into de facto mottos for large parts of the company.

All of this happens against the backdrop of eroding mind and marketshare, a total lack of real product clarity, and a pervasive culture of bullshit that puffs politically convenient non-accomplishments into events worth of companywide applause while spinning, downplaying, or even hiding bad news of calamitous import.

Intel has vast reserves of talent but without deep (IMO, impossible) cultural changes it will inevitably fail under its own weight.

ASAN doesn't mask bugs-- quite the opposite, it turns silent memory corruptions into crashes.

I'd be pretty interested in working on this kind of critical infrastructure. Any tips or pointers for an experienced SE/SWE on getting into your world?