The United States is ranked 16th highest in the world for emissions per capita.

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

OAuth (OIDC) still makes a lot of sense in some scenarios. I work at a university and I just used Authlib a few months ago to consume our single sign-on, and let me tell you, that was much easier than using the API would have been.

That may be an issue during onboarding. I've got an account set up already and I'm able to edit my availability schedule from 12:00am to 11:59pm.

This was introduced 03/26/2021. Not sure why it's relevant enough now to be at the top of HN.

I am in love with this trend of replacing old school unix utilities with new rust projects that stay just as fast or faster, but increase the usability or feature set tenfold. rg, fd, exa, bat, and now tuc.

The problem I see is that I don’t see those consolidating anytime soon into a new set of ubiquitous “core” utilities that can be expected to be available everywhere.

I guess it's just up to someone to set up the package on debian that contains all of these

That doesn't solve the "available everywhere" problem. It potentially would make the tools easier to install on Debian-based systems, if you have root access. I'm not sure any new set of tools will ever be available with the ubiquity of coreutils in the next handful of years, if ever.

I agree. If these could be made installable without root, and independent of the current version of glibc, then there is huge potential to replace the older tools. I’d love to use things like fd, but they don’t work on older servers without root and a newer version of glibc

They're already installable without root. Just put them in ~/.local/bin. Most Rust binaries are portable and only dynamically link libc.

Local installation is still not really a practical solution when you work e.g. on customer machines, on machines of another team, or generally if you work on many different machines. You still need to be aware of the standard tools and know how to use them when needed.

I mean, I get it — I used to locally install vim on machines that only had vi, to make my muscle memory be functional when editing files. But it’s not the same as a core tool just being available by default so you don’t have to ever concern yourself with any alternatives.

That’s what I initially tried for fd, but unfortunately glibc is required for it, and probably other utilities as well.

fd has musl version

https://github.com/sharkdp/fd/releases/download/v8.4.0/fd-mu...

What would prevent us from adding those to a docker file?

Docker not being installed on remote

This is why I like that you can "go run" golang programs without installing them. Anywhere golang is installed it will automatically build cache and run the binary for whatever platform you are on.

For example

   go run sigs.k8s.io/kind@latest create cluster

I wonder if something like this exists for rust

Absolute no possible exploit path there at all

Unless you are reviewing the source of everything and compiling it all yourself, then you're executing someone else's binary.

Is it really an exploit when you're explicitly running code that you expressly trust (even if you probably shouldn't necessarily)?

Isn't an exploit explicitly a subversion of trust?

If you shouldn't trust it but you do anyway and someone uses that against you - they exploited your trust.

That is nice, but it still requires installation of golang which is obviously something that can't be guaranteed.

“cargo install” is the Rust equivalent.

There’s moreutils for an older rethink of the same set of utilities. I don’t see why an evenmoreutils wouldn’t eventually become popular enough to take hold? Probably not as quickly as you’d like in today’s world of instant gratification, but we’ll get there, eventually.

moreutils is still nowhere near as ubiquitous as coreutils. For me it's not about gratification. It would be more satisfying to make use of the most modern tools available. It's about making sure stuff works and I find sticking to coreutils is the easiest way to do that most of the time.

Install rustup from https://rustup.rs/

    cargo install broot exa miniserve ripgrep tuc xh xsv zellij

Cargo is the package manager you are looking for.

I use Cargo regularly and rustup it does make it easy to install. That's not the point. I'm not looking for a package manger. I want to be able to write scripts that make use of tools I can pretty much guarantee are already installed.

So we aren't talking past each other, how do you delineate between cargo and a package manager? Does anaconda, pip (pypi) or homebrew also qualify?

Your scripts could have a prolog that installs rustup and calls cargo.

There is also https://github.com/ryankurte/cargo-binstall

Even after 20 years of bashing, my bash skills still suck. So many corner cases!

But if you include this, and call install_utils at the head of your scripts. It should install the tools on demand.

    #!/bin/bash

    RUST_PACKAGE_LIST='rg xsv tuc broot du-dust dutree'
    RUST_UTIL_LIST='rg xsv tuc broot dust dutree'


    function is_cargo {
        cargo > /dev/null
    }


    function is_utils {
        eval "which $RUST_UTIL_LIST" > /dev/null
    }


    function install_utils {
        if ! is_utils ; then
            if ! is_cargo; then
                curl https://sh.rustup.rs -sSf | sh -s -- -y
            fi
            eval "cargo install --locked $RUST_PACKAGE_LIST" > /dev/null
        fi
    }

I don't recommend using this, it is just illustrative.

My primary point is that if I stick to coreutils, I don't have to worry about any of this. I can reasonably expect anything in coreutils to already be installed and available. Your functions seem like they'll work just fine, but either requires build tools to be installed, or the package to support binstall. For me, thinking about all these things and maintaining something like that isn't worth it when I can just use coreutils.

I totally understand. My .vimrc has shrunk from over a hundred lines to 4 lines in the last years. But I really think you are doing yourself a disservice. It is easier than ever (homebrew, nix, cargo, pip) to get nice software everywhere.

Have you tried running them with Nix? I believe you can use most things from it without root, but I'm not sure.

I suppose I shouldn't have said only Debian. But having tools easily installable is still quite different from being able to reasonably assume they are already installed.

I wonder how well Rust project get along with Debian packaging tools.

"Modern" dev environments are often tied to their own package manager. JS has Npm, Rust has Cargo, etc... These have their own dependency managers, version systems, etc... and they don't always get along with the way Linux package managers work.

IIRC, you don't even need Cargo to do Rust, so it should be possible to compile Rust projects like you compile C projects and essentially mirroring crates.io but with .deb packages but it looks like a lot of work.

Debian packages individual cargo packages/crates as their own Debian packages, and also applications that then depend on them.

https://packages.debian.org/stable/rust/

https://crates.io/crates/cargo-deb exists but I don’t know if Debian uses it or something else.

coreutils-ng? It would be nice to have a bunch of these in one package.

It's easy to fall in love with someone who is young, hip and all that. When it comes done to work on my loved UNIX systems though, I still prefer to stay with the old-school tools given by coreutils et. al. They are a quasi-standard, I can rely on them and I always know what to expect. Better yet, I will find them on every system and can reduce my mental load to learn and internalize something new. Sure, they're not perfect, but these advantages trump the disadvantages, and it's all worked out pretty well for decades. Here, I don't have to chase the next bride.

And yet, bash eventually replaced bourne shell (by having an sh-compatibility mode), and vim has replaced vi.

If you get anywhere in the neighborhood of a proper superset of the old application, we do occasionally retire the old ones.

I can say exactly the opposite and I have the collection of shell scripts to prove it -- the newish tools work better for me when doing a ton of scripting tasks.

So maybe don't project about "hip" or "young" because it does your otherwise decent argument a disservice.

>It's easy to fall in love with someone who is young, hip and all that

>Here, I don't have to chase the next bride.

Who hurt you? :)

I use rg, exa, bat, and zellij as my "rust replaced old stuff". Zellij isn't yet as polished as I'd like it, but it's way more intuitive than tmux.

Oh god, is tmux considered “old stuff” now? I barely finished replacing my screens.

I actually started with screen, but I only used it for daemonising some foreground processes, I work in Zellij daily.

It happens to all of us. Did you know Interstellar came out eight years ago?

The names of these utilities are bad. I have literally no idea what any of them do. The same could be said for standard unix utilities, true, but they have 50+ years (in some cases) of brain bake in, and have the advantage of names that have _some_ relation to their function (ls : list files :: exa : “extract the list of files from a dirent?”)

At some point you have to accept that if you want to know something, you have to learn it. At one point, you didn't know grep, awk, sed, etc... And then you learned them.

Or you can just stick with the old tools if you prefer not learning a new thing - that's a perfectly valid option.

Does it really matter though? You can just alias them over the originals or something close-by.

Yes, you can do that. But that exasperates the system portability problem. The real solution is for some distro to, gasp, decide that POSIX compatibility can be done with utilities in /opt/posix (or something) and do widespread replacement by default. But that’ll never happen…

In your scripts you can use "/usr/bin/env cat" to get whichever version of cat is first in your PATH. NixOS abuses this to an almost silly level :)

Usually you have to install tmux on a remote machine anyway, so Zellij seems like a good one of these to try.

OpenBSD ships tmux in the base system. I would be very pleased if more systems did this.

You can say that again. After using rg for a few years now, I can't imagine not having this tool, that I use weekly, if not daily

Same here with `exa` and `bat`

Don't forget syntax highlighting shortcomings. Sublime, VS Code, Syntect, Pygments, and other highlighting engines all get most languages right. Emacs and vim both do weak and incomplete jobs identifying tokens. It makes nice color schemes look bland because they skew toward only a few colors. At least neovim is working on treesitting which should improve this ability.

Right, I've noticed this while trying to update my vimrc for web development. Syntax highlighting is just not as nice as in vscode.

It looks like port 63333 is a common forwarding port for Postgresql. https://github.com/search?q=port+63333+database&type=Code

Location: Ypsilanti, MI

Remote: Yes, only

Technologies: Golang, C++, Ruby, Linux

Résumé: https://shreve.io/resume.pdf

Email: jacob@shreve.io

I'm a soon-to-be CS BSE looking for a junior software engineering role starting in May. I spent 6 years as a Rails developer, but went to school to help me pivot to systems programming. I want a job that will help me grow my security and distributed systems knowledge.

When you explain what Net Neutrality is, an overwhelming majority of people supported it, including republicans. This isn't just a tech-literate liberal issue.

https://www.washingtonpost.com/news/the-switch/wp/2017/12/12...

A majority of people support Democrat's economic policies...even though Republicans hold a majority of the seats at both the state and federal level. It seems like people aren't necessarily voting for the party that represent's their positions--or, more likely, there are wedge issues that cause them to vote another way.

https://www.washingtonpost.com/news/monkey-cage/wp/2016/05/2...