What, again?
HN user
mathfailure
I don't know any scenario where I'd need any of that, but I love such things regardless.
About git.kontain.me - what if I'd like to setup my own copy of such a service and would like it to work with a non-public git repo, how to pass credentials? Since you support only cloning over https (btw, why not over ssh as well?) - one could use an URL of format user:pass@host:port/path/to/repo, would that work?
You can't reasonably get a job at a US firm while being physically located somewhere else and on the other side of an uncertain and greatly attenuated greencard application process. That's just not how this works.
For IT jobs - why can't you?
Yes.
...or is it?
Cloudflare is cancer. And the tumor is now too big.
I do. I care. And there are dozens of us.
Lots of infected programs provide value. It has nothing to do with being or not being infected.
If a project was vibecoded in a weekend - there are less chances that it will still be maintained in a, say, year or two.
Nice to have this as an extra option, but being a linux user I value openness of code. I am pretty content with opensnitch + opensnitch-ui.
Scotty doesn't know...
Works fine for me. Configure your shell.
But how do we know the readme isn't also vibecoded?
That's not a dichotomy.
That's probably a security feature.
tl;dw
No, there are no such news yet, only hearsay.
What stops them from selling it to an affiliated entity for 1 eurocent and thus evade the ban?
Looks believable that they are indeed the devs behind the project, but it's weird to post stuff like that to... reddit? They have a site for the project, why not post there?
One can start working on creation of a teleportation device. Doesn't mean we have it.
https://asahilinux.org/docs/platform/feature-support/m3/
What do you see as progress here? Nothing is supported, everything is "to be announced" (i.e. unsupported).
They did. Just not explicitly.
Not if if you APPEND the dot path to the PATH env: the system traverses the dirs specified in the PATH env from left to right and stops at first match. Your system's sed binary is in the dir that's to the left of your '.' dir.
if you end up in a directory that's not under your control, and you do a "ls", it might execute "./ls" instead of /usr/bin/ls,
Not if if you APPEND the dot path to the PATH env: the system traverses the dirs specified in the PATH env from left to right and stops at first match. Your system's ls binary is in the dir that's to the left of your '.' dir.
No, in fact he is correct: system scripts won't pick up your overrides configured via your shell's rc scripts.
Because it's useless extra typing. People try to narrow commands down to two fucking chars and you suggest to type the whole goddamn path!
Kinda makes no sense to me: so you don't use '--' as a prefix, you use it in the middle of an alias, so you first have to autocomplete, say, 'gi' not to 'git' but to 'git--progress'. What does that alias do? Doesn't it call git with some args? If so - why not just alias it to git?
I prefer giving scripts numbers instead of names
Something like "[number"
It contains 100s of short scripts
So you call scripts like [1 [2 [3 [4 ... and remember what each one of them does? If yes - that's nuts, I'd visit a doctor.
People tend to want some separation between what's theirs and what's others. Other programs/scripts quite often put something into ~/.local/bin, so it's not yours actually, it's theirs.
Ah, I see you're a man of culture as well!
I like to follow my own convention where I name files with shell scripts with an extension: .sh for POSIX-compatible scripts, .bash for scripts with bashisms or .zsh for scripts with zshisms.
If I ever wanted to achieve what you initially wanted to achieve - I could use something like
alias -s sh=sh
alias -s bash=bash
alias -s zsh=zsh
Just like I do bind .txt and .conf to 'less', .pdf to 'qpdf', .json to 'ijq', video formats to 'mpv' and so on.
One rarely actually needs to shadow binaries. Some cases could indeed be covered by introducing an alias that binds the binary's name to call a different copy of that binary.
You use shadowing to fix issues where you install some software that expects you to have a sane and ~recent version of some tool like git, but you don't as your system provides that binary and unfortunately it is either not sane (not GENERALLY sane [while it could be sane for system scripts]) or not recent enough. In that case the program's function would simply fail if it would call the system's binary and you shadow the binary with your version to fix that.
adding your script directory in front of the PATH
That's a poor advice for the scripts you call relatively frequently. Instead, (as a general approach, we aren't discussing some particular script) don't use shadowing for scripts: just pick a non-conflicting script name and append the script's dir to $PATH.
No, don't do that as a precaution. As others have already answered correctly - it's too late to worry about such things if a malicious agent has write access to your ${HOME} dir.