Tohsig

I suspect you're right that those concepts are now more widespread because of LLMs, but they didn't originate with LLMs. The word "Grok" came from Heinlein in the 60s and using it as "to understand" goes back to at least the 80s. Talking about the "shape of a problem" goes back decades. Ditto for "loosely held", though it's not about uncertainty; it's about being open to ideas and/or evidence that may conflict with your strongest opinions and beliefs.

Now, I'll grant that those concepts weren't common outside of techy circles. Just clarifying that the LLMs are amplifying them, not synthesizing.

https://en.wikipedia.org/wiki/Grok

https://wiki.c2.com/?ChadwickBoggs

No, they're supporting Gruber's statement that the woman filming was putting herself in very real danger by filming the shooting and then continuing to film for several minutes after.

  Location: Maryland, USA Remote
  Remote: Yes
  Willing to relocate: No
  Technologies: Typescript, Vue, Node.js, Go, Postgres, Linux
  Résumé/CV: https://standardresume.co/r/ecareytech
  LinkedIn: https://www.linkedin.com/in/ecareytech/
  Email: ecareytech@gmail.com

My background is heavy in web development, computer networking, and devops. For the past decade I've worked across the entire web stack building network monitoring software (NMS) for large, distributed networks. I'm particularly experienced in building performant, large-scale browser based GUIs in Vue.js for data heavy applications.

I've built my career around organizing complex and/or abstract product requirements into structured, modular applications. Whether working as an IC or leading a team, that approach allows me to create pragmatic solutions in the near term that can be fully iterated on and improved for the long term.

Currently looking for a remote role with a thoughtful, high-performing team that shares a love of the web!

Fixing my formatting in case this proves useful to anyone:

  machine {server} # e.g. gitlab.com
  login {username}
  password {read_only_api_key} # Must be actual key and not an ENV var

Fun idea! I'll echo the comments about bringing in the text all at once, or at least line by line. The characters are definitely printing out at your 60 chars/second target; it's just significantly slower than I think a lot of people read.

Some additional common parts you might consider adding:

- Rear wheel hub (cassette compatibility) and front wheel hub

- Bottom bracket (crankset compatibility)

- Axles (quick release and threaded)

- Star nut (what the top cap is generally bolted to)

And some minutia you may want to add:

- Many rear derailleurs nowadays come with a simple on/off clutch that adds extra rotational resistance to the cage arm. That helps keep it from pivoting during rougher riding and in turn helps limit "chain slap" against the frame.

- The handlebar stem is one of the most, if not the most, critical components on a bike in terms of safety. You tighten the top cap just enough to pull all of the headset components flush against each other, but the stem bolts are what actually lock the handlebars to the fork. Just something I always emphasize because I've seen too many people try to wrench the top bolt within an inch of its life, barely tighten the stem bolts, and then almost hurt themselves when their bars rotate and/or twist while riding.

Definitely not just you. At my previous job we had a need to fetch private Go modules from Gitlab and, later, a self-hosted instance of Forgejo. CTO and I spent a full day or so doing trial and error to get a clean solution. If I recall correctly, we ultimately resorted to each developer adding `GOPRIVATE={module_namespace}` to their environment and adding the following to their `.netrc`:

``` machine {server} # e.g. gitlab.com login {username} password {read_only_api_key} # Must be actual key and not an ENV var ```

Worked consistently, but not a solution we were thrilled with.

I suspect it's too early to make predictions about which languages are going to become dominant moving forward, but in my experience robust type systems do seem to improve the accuracy of responses that I get from the various LLMs. I've been writing JS/TS for over a little over a decade now and am regularly impressed with what the best of the current crop of models can turn out. I'm not just seeing decent TS code but also decent explanations as to why the model went one direction vs. another. I'm sure that's at least partially thanks to the sheer quantity of JS/TS code that's out there.

I contrast that with the responses I get back from the LLMs for Elixir. I'm currently learning Elixir/Phoenix/Ash for a personal project. Absolutely loving that environment, but I'm seeing a much lower level of accuracy from the models. Basic questions about Elixir syntax and best practices are usually fine, but with anything more complex the responses are often more of a hinderance.

Phoenix, Ash, and Elixir itself are so well documented that the inaccurate LLM responses aren't slowing me down overall, but I'm very curious about whether the underlying issue has more to do with Elixir itself or just the amount of sample code that's in the wild.

I'll add on to this that per-user channels could work well in teams where everyone is comfortable sharing, but could be absolutely paralyzing in other situations.

My personal preference is to have some kind of "Off-Topic" or "Open Discussion" channel that is communal. I'll then make a point of consistently posting half-developed ideas to that channel. Especially the ideas that I know are going to morph as the team discusses them. I find that helps do two things:

- Helps create a culture of collaboration rather than one of "whatever the lead dev says goes".

- Provides Cover For/Reduces Pressure On anyone that is less comfortable putting their thoughts out there for discussion.

As the parent comment said, the fundamental idea in the post isn't bad, but the mechanism may need tweaking for a given team.

Appreciate you pointing that out. HTTP/1.1 may be relatively long in tooth, but this particular vulnerability seems straightforward to mitigate to me. Especially at the CDN level.

Following through the links referenced in the article, this appears to be the actual underlying research: https://portswigger.net/research/http-desync-attacks-request...

Fully agree. It's the same reason why you wouldn't put a repo on Github and then mirror that repo to Github. At a minimum any good mirror would be on a different provider, and ideally (if we get real picky) on a completely different cloud service.

Technically true, but only if we consider dev checkouts as "backups". In the majority of cases they probably are, but that's not guaranteed. The local repo copy could be in a wildly different state than the primary origin, a shallow clone, etc... While the odds of that mattering are very low, they're not zero. I personally prefer to have a dedicated mirror as a failsafe.