You can run each project on its own subdomain on a shared domain. Example: app1.mysite.com app2.mysite.com. This can save you tens of dollars a year and save you some headaches. Probably not optimal for SEO, but for random projects it's pretty good.
I've used asdf for years, but recently switched to https://github.com/jdx/mise
It's a drop-in replacement for asdf, but I prefer some of the nice features it has to offer.
No disrespect to mise but this what’s so frustrating about the industry. Just as one starts getting popular, some people move on to something “better”.
The main issue most people have with asdf is that it’s annoyingly slow. Not unusably so, but just enough that it’s irritating.
I identified [0] the source for much of it (sub-shells and pipes) and began a PR [1], but became bogged down with BATS testing, and then found mise / rtx, so kind of lost interest. Sorry. You can always implement these if you’d like.
It's normal to build new stuff based on the experience we got from what came before. If you like asdf, use asdf, there's nothing wrong with using it, and there's nothing wrong with wanting something "better" (depending on what "better" means for the user)
asdf hasn't just started getting popular. It's been popular for a long time already. IIRC I started using it ~8 years ago (~2016). asdf has been around since 2014. I believe Mise (rtx) has been around for a couple of years already too.
Mise/rtx doesn't cut it for us. It's approach is shell-based, so if your programs launch sub-processes, mise won't be applied. So for example Node scripts running in version 18 might npm run a process, which gets launched with the system node.js version.
Where-as asdf creates shims that go into the PATH. That way any processes launching processes using normal env rules have asdf applied.
Mise looks well built & is very fast. But it's jaw dropping to me that it's coverage is so drastically lower than asdf.
mise borrows the plugins from asdf, which also makes it non-cross platform. Interesting discussion on this topic on their GitHub: https://github.com/jdx/mise/discussions/66
Solutions considered include adopting the vfox plugin system or transpiling all asdf plugins to ShellJs.
I made some progress on windows last week! I'm working on making it so vfox plugins can be used as the "default" backend instead of asdf which will be a prerequisite for windows support. Step 1 is being able to run vfox plugins inside of rust which I got pretty far on: https://github.com/jdx/vfox.rs
It'll be a long road ahead and I could certainly use some help if anyone out there is interested in moving it forward. That said, vfox is a really great project and they are targeting windows specifically. Windows will probably always be second in the mise ecosystem (because I don't use it) but my hope is I can get at least a baseline of support which would help teams that have occasional windows contributors.
I still prefer asdf. It does the job just fine. Direnv has its own stdlib, which sometimes I find useful, and make is something I have to install anyway.
I was only vaguely aware of rtx, but after discussing this post at length with people online they've made me aware of the rebranding and the general capabilities of mise.
It sure is great, it is! However, like you, I tend to prefer minimalistic and predictable tools.
That's why I decided to add the small comment in the discussion section of the post, to be fair but also kind of clear that bloating the runtime manager that was supposed to help manage the bloated runtimes and package managers isn't a great idea.
Having said that, if the scope of mise stabilizes and it doesn't turn into a kitchen-sink kind of project, it sure seems sweet!
Mise’s #1 objective is to be a really great tool manager, just like ASDF, but way faster and smarter.
However, it turns out that a tool that needs to be extremely CWD-aware also makes a great .env tool and task runner. I was also a little skeptical, but it’s actually super super useful. Especially because it’s easy to convince team members to install it for the tools, they get the rest for free with easy syntax.
You pretty much nailed it here. Env vars and tasks were kind of a happy accident—I implemented both inside of a day. (different days of course) Just because I realized I had all the building blocks to make them possible already, just needed to arrange them in a different way and they just appeared.
In the future though I see tasks as being the headline for mise over tools. That's a ways out, certainly more than a year, but the thing about tasks is they don't suffer from the drawbacks that both PATH and shims have for putting your tools in the right place. In my personal use of mise I don't actually like using `mise activate` whatsoever. The problem is just that I can't yet do everything with tasks easily enough. Tasks need to get to a point where they're so easy you won't want to bother with having tools in your shell.
Though who knows. I may be off my rocker on that one. I certainly get things wrong as much, if not more, than I get them right.
Mise does a lot of things and I don't buy into the unix philosophy so you may not like it (which is totally fine btw, my goal is not at all for everyone to love it).
That said, I think if you thought about _why_ you like minimalistic and predictable tools you may find that mise solves the underlying reasons for that. My whole thing is about augmenting your environment and not replacing it. This is generally where I contrast mise with tools like nix and docker but I thought it was worth calling out.
I think people like mise because they can use it for just setting some env vars, installing a few npm packages globally, having an easy way to synchronize tool versions between local dev and CI/CD. You can use it for any one of those things and it slots right in wherever you are—whether that's inside VSCode, ssh'ed into a remote machine, in a github action, or inside a docker container in a k8s fleet.
Yeah mise is capable of a lot of different things, but the important thing is that it doesn't force you to change anything _else_ about your setup.
I recently started using https://github.com/prefix-dev/pixi for Python projects. I really love it so far, but this tool looks a bit more mature, which makes sense considering pixi is relatively new.
For as much improvement as there has been with what can be distributed via PyPI, there are still some domains that have gnarlier dependencies than wheels happily handle alone, and you either need to reach for the system package manager (and loose the ability to really control the dependency environment from that mismatch), or take advantage of the Conda ecosystem.
My org does a lot of work combining machine learning with oceanographic and climate modeling, which are both domains that have deep dependency chains that don't always mesh well, especially as our researchers mix in R and other languages as the same time, and the Conda ecosystem helps us a ton with that, but there are issues that `conda` and `mamba` don't help us out with.
Pixi takes a swing at some of what the Conda ecosystem hasn't been great at (at least without a lot of manual custom ceremony) that Cargo, Poetry, Pipenv, PDM, and other dependency and workflow management tools have demonstrated can be done such as lock files, cross platform dependency management, task running, and defining multiple related environments.
I know this is over a week old, just coming back to say I moved off Poetry in favor of PDM. The main reason is because of PDM's built in scripting/tasks management. I have to install a plugin to get this with Poetry, and it's clumsy even then.
The other 2 reasons are more subjective. The first being I've had less issues installing packages with PDM. It's been a while and I don't remember which specific packages Poetry struggled to install, but my takeaway was just that I don't run into those problems with PDM the way I did with Poetry.
The other larger/more consequential reason is the maintainers of Poetry. There have been a number of GitHub issues replies laying out plans for things they will/won't do with Poetry, and it didn't inspire confidence in me. I want to do things the "Python way," not the "Poetry way," and PDM adheres more closely to the direction the Python project is moving. I don't want surprises later down the road when a tool (Poetry) is doing a bunch of custom stuff that eventually may not be compatible with the ecosystem at large.
All that being said, I had a lot of good things to say about Poetry while I was using it, and I do understand why people make it their package/project manager. Just wasn't the right fit for me.
My experience with Poetry has been mixed the last couple of times I've tried it, it attempts to do way to many things but often failed to do them properly. Determining dependencies and proper packaging and upload to PyPI are the ones which come to mind.
asdf.vm together with pipenv is my go-to for Python environment management.
As for Poetry, it is constantly improving and has gotten very popular. It should not be dismissed, especially for larger projects since its dependency management is so much better than pipenv. This is a good primer: https://diegoquintanav.github.io/poetry-primer.html
pyenv + pip tools is all one needs. Supposedly uv is gunning to be a drop in for both. I think there’s a good chance uv pulls it off and becomes defacto for this use case.
I think it’s fair to see appeal in poetry, but ultimately the maintainers have created a culture that feels a bit too non-collaborative to outside ideas or use cases beyond what they more narrowly envisage. That said, my perspective may just be tainted by multiple poor experiences interacting with the maintainers.
I can’t speak to rbenv or npm, but IMO it’s better of use well known and canonical tools for each rather than a more unknown mega tool that wraps or replaces these.
pyenv isn’t perfect, and isn’t what I’d use for prod images, but for dev setup it’s relatively bulletproof and less issue-prone than any alternative I’ve seen.
> We were made aware that a single user of the AI platform was purportedly provided an image that did not adhere to the built-in parameters set by the developers.
I laughed at this. What a non-apology with no accountability.
That's the quote that stuck out to me, too. It's like they're insinuating that the person is lying (while elsewhere admitting they don't have evidence either way). I mean, I don't want to backseat-quarterback here, but would it have been so hard to say something like, "We have decided to take our website offline while we investigate a report that our website generated an inappropriate image of a user"?
Whereas for practical security, having some common substring in all your passwords that you don't type but insert through some global hotkey would be just fine as a mitigation against eavesdrop attacks.
Yes, that's also obscurity, but obscurity is actually good - it only got a (deservedly) bad reputation from when it gets used as a substitute (but I fail to see how using a nonstandard keyboard layout would even count as obscurity in the context of an audio attack, as the clear text reference would surely go through the same layout?)
Brilliant suggestion. Have a TRNG or a CSPRNG (if too poor for a TRNG) choose the next layout at random for you, ideally with every keystroke. Good luck cracking that!
Some places use touchscreen keypads for PIN entry exactly for this reason: to allow randomization, e.g. for opening a locked door, or for authorizing a transaction.
I’m sure it depends on the application to some extent. I can type my pin in without looking at all, so I can cover it up while doing it. If I had to hunt and peck, it’d easier for an onlooker to observe my slower motions I think.
But if I used the same machine often enough to produce wear specific to me, this randomization would be really useful.
I use a randomized PIN pad on my phone, and I've gotten quite used to it. I can enter my PIN almost as fast as I could on an unscrambled pad; it's definitely not hunting and pecking.
Could be done by using a device with a display - e.g. an "ereader" - to present a random keyboard layout. But, good luck being efficient typing on that. At that point, better use a different input model.
Or, use techniques such as those in the article, such as random keypresses played during the actual ones.
...wait, are you telling me Konami shuffling the touch input for e-Amusement PINs[0] was a good idea!?
[0] Okay... deep breath
Konami is a pachinko manufacturer with a side hustle making rhythm games for Japanese arcades. They have an online service that all their games connect to called e-Amusement. You can log into it using an e-Amusement Pass card, and your card is locked to a PIN number you have to set up when you first use it. Cabinets with touchscreens give you a touch keypad, except all the digits are shuffled around, which is a total pain in the ass and you have to do this for every credit.
Indeed. Let me add that how your fingers come into contact with the keys is probably just as important. I recommend a cryptographically rolling choice of dustballs, crumbs, and boogers.
Because the real data stream would still be there, just mixed with some noise. It feels harder to analyze whether the noise sufficiently obscures the real keystrokes than it does to ensure the actual keystrokes reveal no information.
