jdsalaro

> This does seem to suggest that there is a very real possibility that they could refuse.

Not at all, on a societal level the US has been increasingly constructed as a huge, intricate, Prisoner's Dilemma where everyone, allegedly, has all to lose and noone, allegedly, has a say in the matter, therefore everyone complies with whatever the system, or media, asks of them.

Everyone thinks they're the victim, everyone thinks civic duty is something the oppressor is responsible for, not them personally, therefore everyone is free to be an oppressor themselves.

This problem will be intensified whenever, as we've seen elsewhere, the military starts being transformed from within and sycophants are put in positions of power.

> With that power, everything is legal.

Although I agree, here I disagree.

In general, the Executive branch, the Intelligence Community, Congress, the Courts, the Populace are all responsible for keeping the President's Office accountable, both officially and extra-officially. Officially, via legal and direct means. Extra-officially, by means of protest, mounting cultural as well as mediatic pressure, etc.

In our, as Trump's actions have greatly affected the international community as well, situation what's most concerning is the initial, slow but eventually complete and absolute breakdown of public discourse.

Truth is irrelevant, poise is impractical, facts are an obstacle, outrage and drama are the new assertive communication. It's all about Me and My Emotions, us versus them.

This has been the case increasingly, for years, on both sides of the political aisle. Everyone compartmentalizes everyone into the sub-groups they are a part of, until everyone is so compartmentalized that they are completely alone because there are no similarities left for any common ground whatsoever. Such is the dystopic portrait of a society in complete disarray.

Under those circumstances, everything is legal, simply because there's noone to enforce the commonly agreed upon Rule of Law.

Are all of your recipes home brewed?

> management is very creative

What you described, I wouldn't accept generally under my definition of creativity.

In order for creativity to be such it must ultimately deliver value; managers "doing their job" in ways which hinder instead of supporting engineers is not creative, it's disruptive.

> The problem is that some methodologies (Scrum, etc.) are heavily abused and transformed into management frameworks, which is the opposite of why they were created in the first place.

At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand.

Any quality work, gain in efficiencies, improvement potential, etc will be hindered by the desire to apply blindly and without creativity any given thought framework.

> He trained for hundreds of hours to fly the capsule manually and the docking process is excruciatingly slow

_COME ON TARS!_

> CFI

They're referring to Control Flow Integrity [1]

[1] https://en.m.wikipedia.org/wiki/Control-flow_integrity

> So that in any directory you can type `<command name>`?

Any tool installed via asdf is available on any directory as long as you are accessing that directory via a shell spawned with a .profilerc or similar which contains your asdf configuration.

> asdf Node installs aren't like Python virtual environments

Correct, neither should they be.

> they're centrally installed and one Node version (and its packages) is shared across all diretories

sure, they are, and that's by design. You're conflating a runtime manager with a package manager. Venvs are _not_ runtime manager, the moment you need another Python version you're done for. asdf.vm is _not_ a package manager, the moment you want package isolation while working on an asdf install is the moment you install yourself pipenv, poetry, pdm or use python venvs for that.

> that want it + global tools.

which is achieved as I've shown below. Still, there was no reason in your usecase to modify or play with globally installed tools besides asdf, through which you can then define global runtime versions and those global versions will hold your global tools, usable wherever.

> pyenv + pip tools

then you'd also need rbenv, nvm, etc.

and pyenv can implode in marvelous ways.

> Why would I want/need this?

always, golang is overly opinionated regarding where modules and binaries are stored. I don't like that and I've blown my local development environment into pieces because of that (looking at you GRPC, yikes)

But also, imagine that you, like me, need to test Python, Java+Kotlin+Gradle and NodeJS+Angular stuff. Do you really want to install _all that_ natively ? Just for a couple of merge reviews, and even if not, do you _really_ want to install all that natively ? The answer is always, IMHO, a resounding and clear no.

> It was a Visual Basic 6 program, so I just took two half days going through every EXE & DLL related to Windows and VB, eventually finding the difference. Tedious but not rocket science. Is it to avoid these cases?

For example, but also much worst, as mentioned in the OP it's to prevent the very real possibility of crippling your OS's language runtimes and also to stay productive.

there's something I don't get, why do you have globally installed tools that asdf can manage at the same time that you have asdf installed?

OP here, although I hoped I took an example that was relatable, it seems it wasn't as relatable as I expected.

> Is it just me that never even wants to get to the problems that asdf attempts to solve?

You aren't alone, the scenario isn't ideal. However, brew's Python installation on MacOS as are Debian's and Ubuntu's are _extremely_ brittle. You are one cask, formulae or apt package away from needing to do a weekend-long spelunking session or a full blown system re-install if you have deadlines.

PyEnv is a pain to set up, and maintain, which is what I used in the years before as well as after Python 2 was deprecated and projects started slowly migrating to newer python versions.

> That example in the article of managing multiple python 2.7 versions sounds like a horror story.

It is a horror story, but is very common.

Have you tried to install and maintain Java, Kotlin and Graddle installations for a given project although your machine is not primarily a Java, Kotlin, Graddle box? That is a real nightmare, not so much with asdf.vm.

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.

this makes me itchy, pulling the whole internet without looking into your development machine sounds like a very bad idea. It's the equivalent of an IDE's "do you trust this project" but on steroids.

> A dockerfile solves that, my system is a carbon copy of the prod environment.

Yeah, that can definitely not be beat, if at all probably only due to comfort.

> Not tried pipenv

I've been meaning to put a tutorial out there with my workflow since forever, if I had it I'd point you to it.

I recommend you give it a try if you get the chance, you might like it.

just curious, have you tried using asdf.vm with pipenv ? I've never needed anything else and have yet to have any problems.

A couple of moons ago I used Poetry, but gave up on it because it was so heavy and unfortunately would bug out often.

> I recently started using https://github.com/prefix-dev/pixi for Python projects

Why is it based on the Conda ecosystem? Do you happen to know?

I assume it's for portability, but that sounds heavy.

it certainly looks interesting! I'm still not sure if "It’s npx for everything else" is good marketing :P

> can activate project tooling upon cd’ing into a project folder

this probably can be replicated with zsh hooks: https://zsh.sourceforge.io/Doc/Release/Functions.html#Hook-F...

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!

The definition of "Agile Approach" is refreshingly succinct: https://www.dau.edu/glossary/agile-approach :)

> release locks

Joke's on y'all, our "release lock" in first semester introduction to programming for team assignments was the name of our ZIP file and whoever cc-blasted every member of the team with "team07_assignment03_v07.zip" called dibs on it :)

It goes without saying, that "it works on my machine was out mantra". Those were the days!

Disregard the comment you're replying to, they're either misinformed or deliberately inaccurate in their assessment.

The backdoor consisted of a combination of publicly visible code and binary blob test files available in the project's repository as well as obfuscated build scripts which were contained only in the released tarballs, tucked away, which, nevertheless, were also publicly accessible, decompressable and auditable[1]

[1] https://gynvael.coldwind.pl/?lang=en&id=782

> Just take the L for FOSS instead of trying a UNO reverse card

No, you're either wrong or malicious, likely both.

> But open sourceness in no way contributed to this being found, it was not in the source code.

Of course it did.

Please point me to Window's or MacOS' "easily" decompressable, distributable, and interpretable tarballs containing dependencies which are signed, independently downloaded, verified, decompressed, tested, benchmarked, built and integrated according to somewhat predictable customs following somewhat standardized and well-known procedures by a community of several hundred competing projects ( Debian, Ubuntu, Fedora, Arch, Red hat )

Yes, I figured that isn't the case for Windows nor MacOS.

> If something like this happened in windows, it could be found in the same way, and the culprit could be identified and charged with crimes.

They won't be charged with crimes, because sometimes it's even possibly deliberate and none of us can reliably check:

https://www.wired.com/story/nsa-windows-10-vulnerability-dis...

Sometimes it's not, and we find out by sheer luck and the odds, due to lack of source availability, are not not in our favor:

https://arstechnica.com/information-technology/2017/11/macos...

> Just because you don't get paid for it doesn't mean it's not an incredibly valuable part of your contribution to the good of your neighbors. Keep up the excellent work, everyone.

Precisely, I truly do not understand how these people witness a potentially catastrophic event of such proportions and instead of asking "dear God, I wonder how many backdoors there are in the Windows operating system that we don't know and will never find out about!?! Thankfully Linux and its ecosystem can be somewhat audited!". Instead they go full blown "please make it go away, if it's visible by us it means it's terrible and dangerous! FOSS is insecure!"

I've said it once[1] and I'll say it again: FOSS delivered both on its pitfalls and its strengths.

Moreover, and I'll never get tired of repeating this:

Although this might be indeed a FOSS-exclusive or FOSS-adjacent kind of risk that ultimately materialized, as some would like to call it, it’s nevertheless also an issue where checks and balances that are only intrinsically possible in FOSS worked as expected and needed. Yes, there was an element of luck in the discovery of CVE-20240-3094, but it is undeniable source code availability and other FOSS customs tipped the scale in the community’s favor.

[1] https://jdsalaro.com/note/xz-liblzma-linux-backdoor-foss-pit...

> This event should be a wake-up call to businesses everywhere

This ought to be not only a wake-up call for businesses, but also to hobbyists and members of the public in general; our code, our projects and our social "code-generating systems" must be hardened or face rampant abuse and ultimately be weaponised against us.

In a way, these issues which FOSS is facing and are becoming apparent are no different to those democracy been submitted since time immemorial.

I agree, thanks for raising this.

The detachment from reality I see in some HN readers is really mind boggling sometimes.

> Why the fox?

Perhaps because Firefox, and the Mozilla foundation as a whole, are one of the few projects not trying to milk you for data nor money? Might be a good enough reason in my book.