jdxcode

> I might not need to add anything to .*rc files if rtx is in my path

Generally speaking you'll probably want to use `rtx activate` in your shell rc. However you could use the shims instead if you just wanted to add a directory to PATH instead.

Of course you'd be getting rid of one of the major selling points of rtx by using shims, but it's so much faster than asdf the shims aren't as bad as they are in asdf.

pyenv is really slow. It'll increase the time it takes to run `python` by a ton. For me it makes `python -V` take ~120ms but without pyenv it only takes ~13ms.

I wrote an alternative that has 0 overhead called rtx. https://github.com/jdxcode/rtx

also check out rtx (my project), which does everything asdf does but 20x-200x faster and with better UX https://rtx.pub

I just added `rtx install --all` which installs all plugins and all runtimes. It's in v1.3.0

I knew you wouldn’t be the only one so I made sure that “rtx” was not a popular lisp library. :)

> adding them to the shell as functions

This, like shims, would require “reshimming” anytime a new binary is added by pip/npm. I really want to avoid that as I see juniors (and sometimes experienced devs) get in a bad state fairly often forgetting (or not understanding) reshimming.

I’m also not sure how you deal with subprocesses calling binaries. If they’re only shell functions they only exist to the shell.

> save the extra exec

rtx is already over 100x faster than asdf so this wouldn’t be necessary really. I could load test and optimize for setups with a ton of plugins and stuff if needed. My reason for avoiding shims is entirely UX related, not performance. Though I do think asdf would not have its problems if it didn’t use shims. This really is just because asdf is in bash and rtx is in rust. (I think rtx is already a lot more LOC though, and not as clean).

But in regards to PATH, I think I can get rtx to not screw up anything else that would be modifying PATH (slightly different algo than what’s currently used right now). I can’t guarantee that nothing will screw up rtx, but I can prevent direnv in particular from doing it.

It may be a game of whack-a-mole testing with different tools that modify PATH to get them to not conflict. That’s fine, it’s such a better solution.

I also think if rtx is loaded after other hooks it shouldn’t get messed with. It’s only if it gets called since potentially those tools could remove rtx paths and there isn’t much I could do about that.

I actually had this as the default behavior of `rtx install` but it felt a bit wild for it to just go out and download a bunch of stuff. I feel like it’s nice to have a bit more control over which runtimes are and are not managed by rtx.

That said, I was thinking about this yesterday and that it’s currently painful to have to type out each plugin one by one. I added this ticket for making `plugins install` default to installing all plugins in the local tool-versions: https://github.com/jdxcode/rtx/issues/50

What do you think? Is that discoverable and useful enough? I could go a step further and add a `--plugins` argument to install or something.

I'm on an M1 MacBook Pro 16". The performance issues are well understood by the asdf team and the Github issue with most comments is on the topic: https://github.com/asdf-vm/asdf/issues/290

This was with a half dozen plugins and use_legacy_file disabled. Hardly an edge-case. Though I'll note in other tests it was around 200ms (which is the number I put in the README to be fair). @danfritz in this thread said his can take over 2 seconds!

Out of curiosity, what is the difference between `time node -v` and `time ~/.asdf/installs/nodejs/*/bin/node -v`? I've never seen it not add at least 100ms.

I haven't, thanks for sending. It's interesting that it hooks into the "not found" hook of the shell so you can run things like `node^18 --version`.

I also really like that it has really clean install output.

They nailed the back-end stuff. I would not have come up with such a good, simple plugin design. But yeah, there are several UX issues like this. Part of it is because it’s written in bash, but ones like this I really couldn’t explain.

I’m trying to fix them while also supporting their syntax where I can, muscle memory is strong. So I support “plugins install” and “plugins add” If you notice any aliases that you think should exist, please mention them.

Yeah, the word “current” in the headline is doing some heavy lifting

> I absolutely hate this kind of nitpicking, and am loathe to see it enforced, especially if the org has the bright idea to try to wire this up as a precommit hook.

I find this so strange. I also loathe nitpicking about syntax which is precisely why I think this would be a great tool!

I work in JS now on a large team and one of my least favorite activities is trying to find consensus on which linting rules we should/shouldn’t adopt. It’s such a waste of time!

This is a clear violation of the first amendment, right?

I would assume the biggest roadblock is they actually build physical products

Every time that Chrome updates I have to give it macOS permission to access my location (if I want my location available to any web page at least).

Is there a way to make this permanent anyone is aware of?

iCloud photos aren’t just jpegs in a directory

and decades of lead time since they've been doing cable internet

Well not all injection vulns deserve this level of scrutiny.

I'm not familiar with that vuln, but I don't see how it could be the "same mistake". My guess is there simply wasn't support for parameterization or there was a non-obvious concatenation problem when building the query string—but please correct me if I'm wrong.

This instance is novel because the parameterization protection was removed in favor of concatenation and that the vuln is so obvious a first-year CS student wouldn't struggle to identify it.

I get so busy I rip out query builders to SQL concat strings all the time. /s

That’s like going 120mph and telling the cop you were just “distracted”.

You’re correct that we often make mistakes when we’re busy, but this isn’t that. This is OWASP #1 and the most plain example of it.

This is not a “mistake” that engineers make, this is unethical to allow this to go into production. He even has a stackoverflow answer where he explains this exact problem: https://stackoverflow.com/questions/11554015/syntax-sql-wher...

If you think I’m wrong, then what could an engineer be responsible for? Literally nothing ever?

Of course they can change hands outside the ledger. We could create paper wallets and exchange them on the street and the blockchain isn't going to know that happened. A tumbler is just a more complex version of that.

Imagine this scenario: You have 10 BTC of illegal funds you'd like to launder. I, and 3 of my friends each have 5 BTC and they're all wanting to do the same.

I transfer some money into a new wallet from 2 of my friends and give it to you. Your money goes to me and 1 of my other friends.

This way the blockchain has no link between your source funds and the money that you received.

This is a simple example. If you split the money into random amounts and do this a few times with new wallets each time it can easily become untraceable.

A well written Tumbler wouldn’t connect any of your money to your own wallets, it’s not hard to think how an algorithm would do this. Just keep an internal ledger and make sure the money doesn’t come back to the source.

Ross probably could’ve even made his own tumbler. Giving out his money to anyone that sends him some would be a naive way to think about it.

In terms of amount, I don’t think it would be hard with all the illicit activity on bitcoin to launder even this amount of money, but it’s not like he would need all of it right away.

Anyways, this is in response to “isn’t this a public ledger?” To which the answer is, “not if you make part of the ledger private—outside the blockchain—it isn’t.”

I don’t understand either. It says private.sh can’t see your query but the “search provider” can, so that’s the other end.

What the heck is a search provider though?

EDIT: looks like it’s “gigablast”. I don’t understand why I just wouldn’t use that search engine directly?

While it doesn’t make sense how a mistake like this could happen, I also don’t think this could be intentional either. I don’t see why anyone would throw their reputation into the gutter like that.

Imagine trying to explain this to a future employer.

tumblers exist

I used https://github.com/nekobato/deno-xml-parser which worked fine for my use-case. It's 1 TS file with no dependencies.

Note that it’s unclear which regions this could be because this was only a string found when deconstructing the release.

> If you so much as have a single @ts-ignore or "any" in your code base, then all bets are off on correct behavior.

I've been writing a ton of TS since 2016 and in most of those projects we've had liberal use of 'any' or even incorrect types (!). It's still far better than vanilla JS. The argument that "it doesn't work all the time therefore it's worse" makes no sense to me.

Ultimately the issues you're talking about make logical sense academically, but nobody has ever raised them as problems in the real world that I've ever encountered.

Full typing makes my job easy, but a little bit of typing is still better (in most cases) than no typing at all. There is an argument to be made about simplicity for small codebases, but those aren't the ones I'm talking about.

I've been on teams building web applications for 14 years and not once have I seen someone simply rip out a query builder like this in production code and replace it with a non-parameterized string—let alone someone with 20+ years of experience.

Accidents and SQL injections happen, usually because of non-obvious query-building but this is a different level.

Yes, and I'd argue this was beyond a simple "mistake", it's borderline negligence for anyone but a very junior engineer: https://archive.vn/oxbck

EDIT: that link isn't working, but here is a screenshot: https://imgur.com/4lyElZI

The major flaw in your argument is that you can't do #2 with rent control in the picture. From the economist[0]:

> Rent controls are a textbook example of a well-intentioned policy that does not work. They deter the supply of good-quality rental housing. With rents capped, building new homes becomes less profitable. Even maintaining existing properties is discouraged because landlords see no return for their investment. Renters stay put in crumbling properties because controls often reset when tenants change. Who occupies housing ends up bearing little relation to who can make best use of it (ie, workers well-suited to local job opportunities). The mismatch reduces economy-wide productivity. The longer a tenant stays put, the bigger the disparity between the market rent and his payments, sharpening the incentive not to move.

[0] https://www.economist.com/leaders/2019/09/19/rent-control-wi...