Eager Eagle @ eager_eagle @lemmy.world

Posts

13

Comments

1,969

Joined

2 yr. ago

Things I already have:

• rebind ctrl-r and up (configurable) to a full screen history search UI
• old history file is not replaced

Things I could find useful once in a while:

• switch filter modes via ctrl-r; search history just from the current session, directory, or globally

Things I don't care about and probably wouldn't use:

• back up and sync encrypted shell history
• log exit code, cwd, hostname, session, command duration, etc
• calculate statistics such as "most used command"
• quick-jump to previous items with Alt-

  <num>

• enter to execute a command, tab to edit

I really don't want:

• the same history across terminals, across sessions, and across machines

Not really a feature:

• store shell history in a sqlite database

Atuin*

I just sync my bash history with dotfiles and use FZF for recalling it. I'm not sold on it.

Also, the same history on different machines would be something I definitely do NOT want. I heavily rely on recent history to re-run commands on different machines with different projects and configurations. Mixing all that would be a mess.

you do have an nginx process with PID 2511847 using the port

get more info with

ps aux | grep 2511847

or kill it, if you need to spawn a new one with the right configuration

find out which process is really binding to 443 if you don't recognize that port as being used

    
sudo ss -unapt | grep 443


  

IMO tensorflow always had a worse API than PyTorch. There's even the legendary issue "I fucking hate tensorflow", now unfortunately censored as spam lol.

Tensorflow died because devs never bothered improving that. While PyTorch always had an increasing number of features and high level capabilities, TF has always felt like a lower level tool that only made sense choosing if you needed to run models for inference in other platforms. PyTorch Lightning on top of it was a great touch for researchers.

I wrote an app in 2016 and maintained it for some 3 years. Every year there would be a number of deprecated things that required code changes and it was a pretty simple app. I only imagine the amount of work more complicated apps demand.

tbh I'm confident I can deliver bugs, slowdowns, and tech debt using any stack 😎

idk, it seems I'll have a similar set of problems I already have with organizing files. If I have health expense documents, is that "health", "me", or "money"? What about travel expense receipts? Or [pick any two categories that may overlap]?

That's why I prefer using tags or labels: they don't force you to make a mutually exclusive choice.

I like the "no more than ten" principle though; when organizing a file tree I try to aim for up to 5 or 6 items in a given directory, as I tend to notice the friction when choosing among more than a handful.

For those already authenticated and wondering how many pulls they use, you can check your usage here:

https://hub.docker.com/usage/pulls

I guess that's only for the rubber or silicone parts, or do your earbuds have a good IP rating to be submerged?

This is such an underutilized and neglected behavior.

The very least a config parser should do is to log a warning.

because of garbage like that I always use the long option names in scripts, even when the short one would be obvious

I like the branch names auch

and the most unrealistic thing is trump apologizing

In most cases the script already installs a pre-compiled binary that can be anything, they wouldn't need to make the script itself malicious if they were bad actors.

I'll die on the hill that curl | bash is fine if you're installing software that self updates - very common for package managers like other comments already illustrated.

If you don't trust the authors, don't install it (duh).

You're already installing a binary from them, the trust on both the authors and the delivery method is already there.

If you don't trust, then don't install their binaries.

does that count as a blow job?