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.
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.
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.
> 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).
Butter them up and then cut them off, they’ll be too fat to do anything about it.
> 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.
What are you on about? Government work is a wonderful career opportunity for the non-HN crowd. These are often people of at best average intelligence and near zero ambition who want a cushy career that you can't be fired from unless you punch a supervisor (and even then it's tough).
There are wonderful people in government, I've worked with them. But there are a ton of people along for the ride and it's absolutely insane to argue the opposite given hundreds of thousands of government employees on cruise control. Plenty of folks would (and do) love a GS-scale gig that requires nearly no work and provides terrific bennies. They were never going to work for FAANG or another high-payer anyway.
And many of the people "in on the grift" are constituents, not donors.
The pay, job per job, is significantly lower across the public sector. You take a massive pay-cut. I don't know what lied to you and told you it's "cushy", but it's definitely not.
Also, you can absolutely be fired for performance. In fact, across the public sector probationary periods are typically longer than in the private sector. Meaning, it's actually easier for you to get fired.
These are the types of things people just sort of... make up... and then other people run with it because they like how it sounds and it reaffirms their ideology.
Interesting past tense. Why did you leave and does it involve getting paid more?
I've worked in government and it's just like the private sector. You have people that are there check in, make money, and go home, and you have people that care about their work. And I don't think there are any significant ratio differences between public and private in regards to that.
So? You're one of millions, and many people are ideologically opposed to the public sector. Obviously, I cannot trust you, so I won't.
What I've said isn't up for debate, it's just true. If you find yourself disagreeing, please feel free to look up salaries and probationary periods. You will see you are incorrect. From there, you can decide whether to change your mind or continue to believe in lies.
> But there are a ton of people along for the ride
For someone who claims to be not in the startup hustle world of Hacker News, you also don't understand that people "along for a stable ride" is how 98% of the world views employment.
> 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.
Correct no eBPF-code is directly involved.
As post explores eBPF-based tools for understanding user-space connection with container-runtime and enrichment of event once received from kernel-space.
The snippets are taken from cilium/tetragon, aquasecurity/tracee and crictl as mentioned in the post.
The post doesn't covers these projects in depth, instead act as a quick reference to the parts, where connection with CRI is being made and used for enrichment.
I understand there are more better ways to do the thing.
P.S: Post is a collection of my memories, when I was implementing the functionality. So just wanted to share, in hope that, maybe it will help others as well. Thanks !
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.
The point of pinsyscall is that they have to jump to the single entry point for that syscall, rather than any of the ~200+ syscall instructions littering the address space. ALSR makes finding an entry point difficult, but that's easier if you only need to find any syscall instruction, rather than the specific one for the syscall you're invoking. The rationale is explained here: https://undeadly.org/cgi?action=article;sid=20230222064027
I’ve already expressed my opinion on this particular mitigation elsewhere and I’m pretty sure you’ve read it so I won’t go into it again here. I was more interested in the scheme that the other comment was constructing.
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.
A real gem of a resource.