I think this is FUD. Haven't GLP-1s been around for 20+ year? The recent surge in popularity was due to new formulas that could be injected once per week instead of daily.
The most noticeable jump has been at 10mg but i started noticing it from the beginning of 2.5 to 5 to 7.5 over a 6 month period but something about 10 just hit different but only on my 2nd month of it now. Less anxiety about things i was hit by before and mood improved overall
Yeah I'm just confused why someone would go from a completely deterministic dependency management system back to a dice-rolling one especially when LLM's now exist where all the top tier ones are excellent at the Nix language
Because I myself am never going to anything else ever again, unless it's a derivative of the same idea, because it's the only one that makes sense
After troubleshooting a couple issues with the GitHub Actions Linux admin team, and their decision to not address either issue, I'm highly skeptical of investing more in GitHub Actions:
- Ubuntu useradd command causes 30s+ hang [1]
- Ubuntu: sudo -u some-user unexpectedly ends up with environment variables for the runner [2]
They told you why it takes so long no? the runners come by default with loads of programming languages installed like Rust, Haskell, Node, Python, .Net etc so it sets all that up per user add.
I would also question why your adding users on an ephemeral runner.
> I would also question why your adding users on an ephemeral runner.
We use runners for things that aren't quite "CI for software source code" that does some "weird" stuff.
For instance, we require that new developer system setup be automated - so we have a set of scripts to do that, and a CI runner that runs on those scripts.
Fair enough if you've some development environment automation and you want the CI to run it as well so CI is consistent with local development.
Don't know exactly what your doing but others(myself included) are using Mise or Nix on a per project basis to automate the development environment setup and that works well on GitHub Actions.
But I don't think useradd taking 30's on GitHub Actions is a bug or something they need to fix, they've explained why. Unsure about the sudo issues, did not read it carefully.
> Fair enough if you've some development environment automation and you want the CI to run it as well so CI is consistent with local development.
Oh we don't even run it in applications' CI, the environment automation is an entirely separate CI workflow. The intention isn't consistency between dev/CI, the environment automation CI effectively just serves to ensure that the automations actually run without error, and adds some explicit responsibility for anyone who's adding a new dependency.
> But I don't think useradd taking 30's on GitHub Actions is a bug or something they need to fix, they've explained why. Unsure about the sudo issues, did not read it carefully.
Yeah, agreed. Tangential, our dev setup CI is fairly slow, which tends to be fine - it runs a couple orders of magnitude less frequently than our app CI.
> That said, the framing feels a bit too poetic for engineering.
I wholeheartedly disagree but I tend to believe that's going to be highly dependent on what type of developer a person is. One who leans towards the craftsmanship side or one who leans towards the deliverables side. It will also be impacted by the type of development they are exposed to. Are they in an environment where they can even have a "lump of clay" moment or is all their time spent on systems that are too old/archaic/complex/whatever to ever really absorb the essence of the problem the code is addressing?
The OP's quote is exactly how I feel about software. I often don't know exactly what I'm going to build. I start with a general idea and it morphs towards excellence by the iteration. My idea changes, and is sharpened, as it repeatedly runs into reality. And by that I mean, it's sharpened as I write and refactor the code.
I personally don't have the same ability to do that with code review because the amount of time I spend reviewing/absorbing the solution isn't sufficient to really get to know the problem space or the code.
Level 12 is a software consulting and custom development agency. We have mid and senior level positions. Our job descriptions are written by developers for developers. No HR fluff here, we want you to know what you are really getting into:
- We have a commitment to transparency and offer a "no surprises experience" throughout the interview and hiring process. We value candor...as evidenced by the length of our job description. :)
- Our CEO prefers the title CED, Chief Executive Developer. Engineering and operational concerns don't take a back seat when potential sales come to the front door.
- You will be working remote with a team that is all working remote and has been for years. Let's make the best use of our time by not commuting.
- We practice and preach sound development practices. You are likely to learn and grow as a developer while working here.
- You are committed to automated testing of all the software you write (our apps typically have 92%+ test coverage).
- We have a no-drama office policy. We value and cultivate enjoyable working relationships among team members. No jerks allowed!
- We emphasize work/life balance and adopt policies that make sure our people don't get burnt out. For instance, our PTO/Vacation policies are designed so that you actually use them.
- If you apply, we guarantee that we will give you a response, whether "yay" or "nay". No black holes here!
NOTE: our intent to hire is currently tentative but should be resolved one way or the other in the next couple weeks. So, if you are interested, read the job description but, for now, don't go through the entire application process unless you really want to. Just email me (the CEO) with a clean dad joke, or your take on Kirk vs Picard, and reference your interest: randy.syring@level12.io. I'll follow-up in a couple weeks when I know for sure if we are going to be taking applications.
I mean you must care a little bit right? Why publish it and share it here otherwise? :) Maybe you're looking for people to just review and learn from the code, rather than use it in their projects?
> From license terms you can see that any independent developer and small teams could use it without any issues
Right, until they cannot, and that choice won't be made from their own agency, and most people will try to avoid ending up there, hence not using the project in the first place.
Not saying "it's doomed to have zero users", but you'll probably find it slightly strange when people seemingly would have perfect use for your project, yet find other options anyways.
> And yes I do not want it to be "free stuff" for big corporations. I just do not know any existing license that can define such terms.
Guess BSL would fit you, but yeah, if you want any sort of restrictions, what you want is something else than Free and Open Source Software, and that's fine of course, just be aware it'll be a hard sell to developers used to FOSS. Again, a fine choice to be making and understandable.
I don't really get the idea that LLMs lower the level of familiarity one needs to have with a language.
A standup comedian from Australia should not assume that the audience in the Himalayas is laughing because the LLM the comedian used 20 minutes before was really good at translating the comedian's routine.
But I suppose it is normal for developers to assume that a compiler translated their Haskell into x86_64 instructions perfectly, then turned around and did the same for three different flavors of Arm instructions. So why shouldn't an LLM turn piles of oral descriptions into perfectly architected Nim?
For some reason I don't feel the same urgency to double-check the details of the Arm instructions as I feel about inspecting the Nim or Haskell or whatever the LLM generated.
I've been using VS Code for many years and I try pretty hard to be a security aware dev.
I checkout all code projects into ~/projects. I don't recall ever seeing a trust/restricted dialogue box. But, I'm guessing, at some point in the distant past, I whitelisted that folder and everything under it.
I've only just now, reading through this thread, realized how problematic that is. :o/
I recently tried to help my mom reset her Apple account password on a modern Mac. Absolutely and utterly shite process at almost every step. I couldn't believe it. Even had a screen show up completely blank that was obviously supposed to have something there but I have no idea what.
Finder is garbage from a power user UX perspective.
And the extra hoops to jump through to manage windows instead of applications is super annoying IMO.
I think Apple is slowly enshitifying it's UX advantages.
reply