chrsig

Sure, and the commenter's PO didn't specify how to get him a webpage. All very reasonable, see?

the "which ones are deployed where" bit is nice. if you're managing a lot of repos and deployments, yeah, that kind of thing can get really messy.

i don't care how it's presented, via webpage or cli tool or whatever -- just saying that when you are working at larger scale, those are very reasonable things to want to see in one spot at a glance.

the need dissipates as you scale down.

> A new product owner came in last year and wanted to "automate everything". They wanted a web page where builds, branches, commits, and more were all on one page that showed exactly which commit was deployed where, by whom, etc etc. They wanted this extravaganza for a 2-person application that was in maintenance with no new features.

you know, this seems very reasonable until that last sentence.

I wouldn't consider my career being in process automation, but I feel like you just described my approach to managing new product development on top of existing machinery while ensuring no breakage of what exists.

Some people have taken the extra time and not gotten it in return, or otherwise been met with negative consequences for helping people.

Bad experiences when trying to be benevolent really take a tole on some people.

Fair enough. Sigh.

I can't help but wonder if the initial blowblack didn't cause some amount of oppositional defiance. or if the FSF just can't operate without him or the inverse. Kind of his life's work.

Not excusing his behavior, just trying to understand it (without putting in enough effort to really understand it, I suppose). I guess I still have to hope that there's some plausible explanation beyond "he's a shitty person".

Maybe there's room for a new foundation for anyone that wanted to pick up the torch. Aside from that, I'm not really sure what there is to do.

Thanks for defending the ND world.

I think the problem is looking at ND as an excuse rather than a reason to change intervention strategies.

Like...yeah, he had a problematic position. He got corrected and someone explained to him the problem and he reversed his position[0].

That's...how people grow.

[0] https://www.engadget.com/2019-09-17-rms-fsf-mit-epstein.html

In a lot of cases, the macos man pages leave a lot to be desired, or don't come up in a google search. I know I'm personally not in the habit of remembering apropros exists, so I can imagine that the first step to manpage discovery being a google search.

And most of the time the docs are interchangable enough. Until they're not. At the raw socket layer, I'd still expect the macos docs to be consulted _eventually_.

Servers have to limit header size as well, since content-length isn't available. Without a bounded header size the client can just send indefinitely.

Also just impossible to read, and url encoding is full of parser alignment issues. I have to imagine that QUERY would support a json request body.

definitely laugh! life's too short, you'll never get out alive :)

Exactly. Gotta be happy you got a response at all!

ok, I found a commit in 2005, coming about because linuxthreads was interfering with the SIGUSR1 signal.

It looks like they wound up making it platform specific, so BSDs and unix like operating systems might still use SIGUSR1.

https://github.com/apache/httpd/commit/395896ae8d19bbea10f82...

y'know...what really is an error, anyway?

No clue what the decision making process was.

There's a bug report for httpd dating back to 2011[0]. The nginx mailling list also has a grumpy person contemporary with that[1].

My guess is someone thought "httpd is a server running somewhere without a monitor attached, why on earth would it get a SIGWINCH!? surely it's available to use for something completely different", not considering users running it in the foreground during development. Nginx probably followed suit for convention, but that's pure speculation on my part.

Also that was before docker really took off (I'm not sure if it was around in 2011 yet; still in it's infancy maybe). Running it in the foreground didn't happen as much yet. People were still using wamp or installing it via apt and restarting via sudo.

[0] https://bz.apache.org/bugzilla/show_bug.cgi?id=50669

[1] https://mailman.nginx.org/pipermail/nginx/2011-August/028640...

My favorite signal surprise was running nginx and/or httpd in the foreground and wondering why on earth it quit whenver i resized the window.

Turns out, they use SIGWINCH (which is sent on WINdow CHange) for graceful shutdown.

It's a silly, silly problem.

i think it is still tracing, it's just a matter of identifying possible roots versus actual roots and constraints that fall out from that.

It took me a bit to hunt down, but it was part of the go 1.4 release in 2014.

the release notes[0] at the time stated

> The implementation of interface values has been modified. In earlier releases, the interface contained a word that was either a pointer or a one-word scalar value, depending on the type of the concrete object stored. This implementation was problematical for the garbage collector, so as of 1.4 interface values always hold a pointer. In running programs, most interface values were pointers anyway, so the effect is minimal, but programs that store integers (for example) in interfaces will see more allocations.

@rsc wrote in some detail[0] about it the initial layout on his blog.

I couldn't find a detailed explanation about how the optimization interacted w/ the gc, but my understanding is that it couldn't discern between pointer and integer values

[0] https://go.dev/doc/go1.4#runtime [1] https://research.swtch.com/interfaces

It was a bit of a bummer when go switched from the conservative gc to a precise gc. One of the implications was that they needed to change how interface types were represented.

They had a nice little optimization for word-sized values to store in-place rather than as a pointer out to a value. With the precise gc, they had to make the change to only storing pointers, leading to allocating small values.

I don't know if they've done work to (or perhaps better put: had success) regain the performance hit from the extra allocation & gc load.

On the flip side, my experience is that they've made the pretty unobtrusive with regards to latency and pauses. Or perhaps I'm just not stressing it as much as I had in the past.

Random anecdote on gc tuning: I was once dealing with a go process that sped up (higher throughput, lower latency) by an alarming amount limiting the max processors. This was many years ago, and I wouldn't be able to say what version of go. It was after you no longer had to set GOMAXPROCS, but probably not very long after.

Performance tuning is crazy sometimes.

It's definitely cool, and and accomplishment. I think it's a bit strange to compare it to "no cgo overhead" though

I say that because it's an interpreter rather than a jit, and doesn't have nearly as many person hours put into it as v8.

I can see the argument that if you just need to evaluate a quick expression or maybe some user supplied script or something, it could be very handy, but I have a hard time believing that the cgo overhead is a factor when using cgo to invoke v8 compared to the parse/jit overhead that v8 will do.

This is all armchair speculation of course. I use go regularly, but have no taste for javascript, so I have no dogs in that race. Definitely cool that there's an interpreter focused on correctness though.

"new" is subjective -- I'll catch up with the times eventually, I'm sure :)

but yeah, I've had to write said script due to needing to compile in proprietary modules.

It's just a bit of CI glue, pretty straightforward and quick build -- thanking to it being written in C rather than C++.

You know, for most projects, I'd think that'd be pretty...bad. Given that nginx only recently got dynamic module support, I'm curious how many people are out there having grown to build it from source, letting them switch upstreams a bit more easily. perhaps. maybe.

Learning any language more or less starts with learning a subset of it.

Asking a new hire to "learn awk" vs "learn perl" have two very different time investments attached to them.

Tasking someone with "learning a subset of perl" begets the question "what subset?", and a very exhausting conversation with someone(s) routinely asking "so?" follows. After spending a large amount of time re-litigating which subsets of perl features we want that awk already supplies.

awk is also a much smaller language than perl, so it's generally less effort to teach, learn, and read.

...who let's a cat in their data center!? and where did the mouse go!?

Flesh?

I mean, I wish that didn't need to be said, but after the whole submarine-controlled-by-an-xbox-going-to-the-titantic thing, who am I to say what bucket of bolts people might jump into entirely on their own accord

> Rule 8: Controlling for a causal descendant (partially) controls for the ancestor

perhaps this is a quaint or wildly off base question, but an honest one, please forgive any ignorance:

Isn't this essentiallydefining the partial derivative? Should one arrive at the calculus definition of a partial derivative by following this?

"reasonable" is doing a lot of heavy lifting in that post. I haven't examined the input/outputs -- just calling it out as an inherently subjective thing that warrants some further definition.

You know, after watching enough stargate, I'm fairly convinced we probably shouldn't do that.

> I've personally witnessed a case where a team member went out of his way to propose a rewrite of an important feature and reached out to a couple of senior members to do a system design review and provide feedback. They initially told him the design was good as is and required no feedback and change, but once the project was about to be deployed they suddenly became very opinionated and critical of each and every tiny detail, including on the need to rewrite the component.

I think I've probably been on both sides of this coin. It takes some experience to recognize, and I don't think it's entirely on the individuals.

I think it comes about when the people being asked "if it's fine" probably have a completely separate set of day to day concerns than the people doing the asking. They probably have not enough context on why, or the impacts. And they probably don't have the time or support to ask for more time to give a real answer.

It's on management for not asking for more analysis or aligning needs or overextending the staff.

The term 'ownership' has also done a disservice. 'Stewardship' would be better.