They are a great team! You will defacto also use Caido if you add it to your stack

I found that Mise handles all my needs for development and it is scoped so it doesn't try to update Python and break all my virtual env when I install something new /shrug

Why would you even use python without uv anymore, and have a system python binary and virtual envs linked to it?

> Why would you even use python without uv anymore

Probably wouldn't:

https://mise.jdx.dev/mise-cookbook/python.html#mise-uv

> have a system python binary and virtual envs linked to it

I'm not sure if you're saying avoid using system python?

In my experience so far, you never want to develop complex software locked to system versions of runtimes. Too often you need a bleeding edge feature, or conversely need to postpone updating due to needing an old version for some reason.

Old Mise user too.

Now that PNPM supports managing runtimes [0], I found that most of Mise's offerings are actually built into package managers. Maybe I will have it graduates from my machine when I have time.

[0]: https://pnpm.io/cli/runtime

That's the beauty of asdf and then mise; they leverage existing solutions where possible, and unify how to get versioned runtimes for projects. Rust? rustup with mise, ruby? Precompiled when possible, otherwise ruby-build. Etc.

I'm not sure if I trust or want pnpm to support bundling rust for binary plugins, or various sundry toolchains.

But use what works for you.

> I'm not sure if you're saying avoid using system python?

That's what I'm saying, yes. System python should be treated as a REPL for interactive shell scripting and otherwise ignored entirely.

Python might be just one of the languages required by the dev stack not the only language. Mise is the right tool for the job.

True, but Python is the one with an env management system (virtual environments) which is the most prone to breakage for projects that depend on system Python.

Uv is far superior to both Mise and Homebrew for Python work, and I find that it removes the vast majority of pain preventing me from using Homebrew by default for most things, and Mise only occasionally for specific dev envs. Mise is a great tool though!

Last time I checked, Mise is still a one-man show. That’s way too risky for a critical party of my supply chain for my taste.

this makes no sense to me, the reason i don't give anyone else the commit bit is only to _protect_ the supply chain. you should want as few people with that access as possible.

I think the concern is more if something happens to you or stop development for any reason, then the project is dead or would fork in a few separate directions

The bus factor makes no sense to you?

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

do you have any kind of succession plan in place in case you get incapacitated for one reason or another? anyone you trust enough for that?

Yes I have a friend that can access my GitHub if I were to die and he would be in charge of deciding who would lead the project

So is sudo... And that's not "too risky" for the entire industry.

That's not to say bus factor is irrelevant (I personally think about it a lot when choosing software projects), but truthfully the bus factor here especially doesn't matter much, as mise is an easy tool to replace (with asdf, for example) if something goes wrong with it eventually.

I highly recommend trying it out. I resisted using it for some time, but it solved some pain points I had with NodeJS, Ruby, and Python regarding installation.

> So is sudo... And that's not "too risky" for the entire industry.

Sure it is, and that's why I'm looking forward to systemd's Run0 -- but for now, there's just no way around the sudo package. That's different for Mise, though, because there are a lot of ways to work productively without it. I'm not fond of consciously adding supply chain vulnerabilities to our stack when I don't have real pain to do so.

   > Sure it is, and that's why I'm looking forward to systemd's Run0 -- but for now, there's just no way around the sudo package.

Regarding Run0, I'd prefer to not rely so much on Polkit authentication after crazy vulnerabilities such as PwnKit (a pkexec vuln, but a good reminder that moving the security boundary won't magically solve issues).

   > I'm not fond of consciously adding supply chain vulnerabilities to our stack when I don't have real pain to do so.

I SUPER agree with you on that, btw. It's just likely that mise solves a problem which is much bigger for me than it is for you. Honestly, I'd prefer if I could manage everything with my distro packages, but, for a multitude of reasons, they're rarely enough for development tooling with multiple versions and environments.

I split my usage. Homebrew for OS things mise for the various tooling.

The only problem some things still have a dependency on requiring python and others on the system. The problem being that they’re there, mise works just fine.

You can use mise for install homebrew items btw so if you get a new computer you just drop the config.toml inside the mise and install.

This is all you have to add to the config file:

[bootstrap.packages]

"brew:git" = "latest"

"brew-cask:ghostty" = "latest"

Homebrew does this as well, I keep my packages synced with a Brewfile in chezmoi. Obv this only works for brewed packages though.

I've found `mise` more useful solely because it also handles things like tasks and daemons.

Yeah, the combination with mise is what make this great.

I also started using Mise for global CLI tools instead of brew and it’s working really well

Eg: mise use -g gcloud instead of brew install xxx

It can even do that for npm packages! Like mise use -g npm:xxx

re: npm, if you upgrade your global node version, you will lose that installation, right?

no, in fact you don’t even need node or npm to install npm packages with mise. (You likely will need it to execute them though)

Mise is really sloppily vibe coded these days

What broke and affected you?

my split: brew for casks, mise for tools

mise also can manage brew

I am in this space. The reality is that the margins for a Bug Bounty Hunting platform are not good, triage is very expensive specially with all the AI slop that gets submitted now. You can hide it for a long time with VC money, but they need to diversify their product line to continue growing and compete against the AI pentest compagnies (which themselves will also diversify as AI pentest becomes a feature and not the whole product).

I agree. They have quality data to build an effective AI pentest product that is good enough, and they already have a good offering to bundle that into and satisfy enterprise demand.

Up and coming AI pentest companies need to have an exceptional product to get a chance to stand on their own and penetrate the enterprise market, otherwise their best scenario is an acquisition to get bundled into an established platform.

I am guessing Ghosty will become closer to Warp.

The post itself says that the effort is independent of ghostty. Their first work will utilize libghostty, and they'll contribute upstream.

In other words, this probably won't directly involve changes to ghostty.

You sure about that? Visa/Mastercars certainly are selling at least aggregated data if not more.

AWS runs a lot of ARM server and they are pushed heavily since they are cheaper and faster. And with Apple running ARM it is just easier to fully transition now.

If someone from the EFF is reading this, could we get a French translation of that article so I can send it to my MP and share around to friends and family. We need a mass movement on that to block it.

The linked CCLA article is available in French [0].

[0]: https://ccla.org/fr/intimite/coalition-to-mps-scrap-unpreced...

Great terminal, annoying that everytime it updates I have to go back to the settings to disable new AI features or layout changes.

Respectfully I think your argument defeats itself. If you can only speak to your users once every 10-12 months it means your process doesn't scale by definition. Good analytics (not useless vanity metrics) should allow you to spot a problem days after it was launched not wait 3 quarters for a user to air their grievances.

Microsoft has a horde of developers that fit the entire breadth of gh usage. They could fix issues prior to a release if they wished to without opt-out client side telemetry.

You're describing a different problem.

Bug fixing absolutely gets taken care of immediately, and our customers are very active in telling us about them through these strange new feedback mechanisms known as "e-mail" and "a telephone."

But we don't spy on people to fix bugs.

Nothing that the big tech "telemetry" is doing is about bug fixes. In the article we're all talking about the spying that Microsoft proposes isn't to fix bugs. Re-read what it wrote. It's all for things that may not appear for weeks, months, or years.

And to think that a trillion-dollar company like Microsoft can't figure out how, or doesn't have the money available to scale real customer feedback is just sticking your head in the sand and making excuses.

Microsoft doesn't need people to apologize for its failure.

That is just poor analytics IMO, if you have a good harness you can definitely tell if a feature is not well designed. You have to optimize for things like number of clicks to perform an operation not time spent in app.