Anyone have ideas about what to do when using cgroup weights rather than max?
I'm currently in the process of removing cpu.max from our clusters, to allow applications to better utilize the available cpu time which currently is just being wasted. We will use cpu weights to make sure that cpu time is fairly allocated during contention, and to not oversubscribe the hosts, but I'm sure that among the thousands of applications that are running on those clusters today, many will be relying on cpu.max to size threadpools etc.
On the one hand, we do want applications to use the available cpu time, but at the same time they need to not kill themselves by running out of memory.
This was pre-Anthropic but the fact that Bun automatically loads .env files if they're present almost disqualifies it from most tasks https://github.com/oven-sh/bun/issues/23967
It makes it hard to take them too seriously with such a design choice - a footgun really. It's so easy to accidentally load secrets via environment variables, with no way to disable this anti-feature.
Best case is they throw their endless amount of paper at it without touching it. At least something useful comes out of this AI crap then. One can dream.
Deno is solid. Or just use nodejs, it got many of the features deno/bun originally shipped with. No matter how you slice it, node is still the defacto server side JS runtime.
> It's worse to assume something is completely broken and anyone who has had a good experience with it to be an ignorant.
About the same, regardless, truth usually sits somewhere in the middle :)
> I know the tradeoffs
No harm no foul then, "it's been flawless for me" certainly gave me a different impression, but I guess as long as we all find the tools that work for us.
I thought that was a typo or the forum software removed something, but no - it's a pointer to an empty string literal. If I understand how that works, this creates a null byte (in the read-only memory section of the compiled output?) and points to it. Before this line it checks if p is NULL.
I wonder what is the advantage of doing this? Maybe to make sure that p is an actual pointer, so later code can just make that assumption.
That makes sense, with that "guard" at the top, the rest of the function can return the pointer anywhere. And I imagine the compiler will ensure the empty string literal is created only once. Good to know!
it would be better to make p a const char* though, so that the code is not casting away the constness of the string literal (which can invoke undefined behaviour, though in practice string literals are going to be in a read-only area of memory anyway).
Something from the PR description that I had to look up to understand: "WTF" is "WebKit Template Framework".
I had to take a moment to find out why all primitives in chrome were in the WTF namespace.
WTF is just kinda funny. Seen it used in loggers too log.wtf("this should never happen")
That comment put my brain into an infinite loop for a while...
Anyone have ideas about what to do when using cgroup weights rather than max?
I'm currently in the process of removing cpu.max from our clusters, to allow applications to better utilize the available cpu time which currently is just being wasted. We will use cpu weights to make sure that cpu time is fairly allocated during contention, and to not oversubscribe the hosts, but I'm sure that among the thousands of applications that are running on those clusters today, many will be relying on cpu.max to size threadpools etc.
On the one hand, we do want applications to use the available cpu time, but at the same time they need to not kill themselves by running out of memory.
I had high hopes for Bun, but looks like it has gone down the shitter after they went all in on vibecoding.
This was pre-Anthropic but the fact that Bun automatically loads .env files if they're present almost disqualifies it from most tasks https://github.com/oven-sh/bun/issues/23967
It makes it hard to take them too seriously with such a design choice - a footgun really. It's so easy to accidentally load secrets via environment variables, with no way to disable this anti-feature.
Damn. That one is absolutely horrific.
What a find.
Any specific links to problems? I was planning to start a new project on it :(
Anthropic acquisition, what do you expect as outcome?
Best case is they throw their endless amount of paper at it without touching it. At least something useful comes out of this AI crap then. One can dream.
Deno is solid. Or just use nodejs, it got many of the features deno/bun originally shipped with. No matter how you slice it, node is still the defacto server side JS runtime.
I still have high praises since one of my clients use it in production.
I personally use it's tooling part which is screamingly fast.
it's been flawless for me
That's maybe more worrisome, everything has tradeoffs, if you don't know them yet, search for them :)
It's worse to assume something is completely broken and anyone who has had a good experience with it to be an ignorant.
I know the tradeoffs. For me it's way better than Node. Especially given the campaign targeting Node devs.
https://socket.dev/blog/attackers-hunting-high-impact-nodejs...
> It's worse to assume something is completely broken and anyone who has had a good experience with it to be an ignorant.
About the same, regardless, truth usually sits somewhere in the middle :)
> I know the tradeoffs
No harm no foul then, "it's been flawless for me" certainly gave me a different impression, but I guess as long as we all find the tools that work for us.
Well I certainly didn't say "it's flawless" :)
I feel like https://github.com/oven-sh/WebKit/commit/35315978baee84ed1bd... is the more interesting commit tbh
> p = (char*)"";
yikes
I thought that was a typo or the forum software removed something, but no - it's a pointer to an empty string literal. If I understand how that works, this creates a null byte (in the read-only memory section of the compiled output?) and points to it. Before this line it checks if p is NULL.
I wonder what is the advantage of doing this? Maybe to make sure that p is an actual pointer, so later code can just make that assumption.
Yeah, it simplifies later code, and is safer in the face of future changes.
Or put another way, it tightens the API/contract of that chunk of code to always return a valid string.
That makes sense, with that "guard" at the top, the rest of the function can return the pointer anywhere. And I imagine the compiler will ensure the empty string literal is created only once. Good to know!
it would be better to make p a const char* though, so that the code is not casting away the constness of the string literal (which can invoke undefined behaviour, though in practice string literals are going to be in a read-only area of memory anyway).
Haha, did I just hear someone whisper GOMAXPROCS?