There are several US states where, by law, retailers are not allowed to give preferential treatment to credit card paying customers over cash paying ones. Which means, in those states, retailers will be required to always round transactions to the cash paying customer's benefit, where in other states the retailer is allowed to round to the nearest 5 cents. This is going to cost large retailers millions.
Interestingly many of them had already put the work into updating the cash register software to allow for this due to the penny shortages during covid.
Let those large retailers put pressure on their suppliers. Prices haven't exactly been stable recently. I really don't think it matters, but if it did (as you claim) then surely some downward pressure is a good thing.
Unfortunately I think this is much easier said than done. No single store is going to want to make this change, because it'll make their prices look higher than the competitors'. It'd require legislation, (and even that'd likely be state-by-state legislation).
It also means a company wouldn't be able to advertise a single price for a product nationwide, since sales tax rates vary by state (and many times even within a state).
Also worth noting that Canada also doesn't include sales taxes.
In fish, I have an abbreviation that automatically expands double dots into ../ so that you can just spam double dots and visually see how far you're going.
# Modified from
# https://github.com/fish-shell/fish-shell/issues/1891#issuecomment-451961517
function append-slash-to-double-dot -d 'expand .. to ../'
# Get commandline up to cursor
set -l cmd (commandline --cut-at-cursor)
# Match last line
switch $cmd[-1]
case '*.'
commandline --insert './'
case '*'
commandline --insert '.'
end
end
I used to do this, but unary kind of sucks after 3; So maybe others might like this better before their fingers get trained:
..() { # Usage: .. [N=1] -> cd up N levels
local d="" i
for ((i = 0; i < ${1:-"1"}; i++))
d="$d/.." # Build up a string & do 1 cd to preserve dirstack
[[ -z $d ]] || cd ./$d
}
Of course, what I actually have been doing since the early 90s is realize that a single "." with no-args is normally illegal and people "cd" soooo much more often than sourcing script definitions. So, I hijack that to save one "." in the first 3 cases and then take a number for the general case.
# dash allows non-AlphaNumeric alias but not function names; POSIX is silent.
cd1 () { if [ $# -eq 0 ]; then cd ..; else command . "$@"; fi; } # nice "cd .."
alias .=cd1
cdu() { # Usage: cdu [N=2] -> cd up N levels
local i=0 d="" # "." already does 1 level
while [ $i -lt ${1:-"2"} ]; do d=$d/..; i=$((i+1)); done
[ -z "$d" ] || cd ./$d; }
alias ..=cdu
alias ...='cd ../../..' # so, "."=1up, ".."=2up, "..."=3up, ".. N"=Nup
and as per the comment this even works in lowly dash, but needs a slight workaround. bash can just do a .() and ..() shell function as with the zsh.
Good point, when working with keybindings, you'll inevitably end up overriding built-ins. I see it as a trade-off, between something I don't know of (and wouldn't use) and something I find useful. Works for me :)
absolutely. From back in the day, the annoying one was GNU screen, which took over ctrl-a by default. Overrode that to be ctrl-^, which in bash is transpose, make "zx be "xz", which was rare enough to okay with losing.
Does zsh support this out-of-the-box? Because I definitely never had to setup any of these kinds of aliases but have been using this shorthand dot notation for years.
Assuming I understand your workflow, one difference is that unregistry works with already-built images. They aren't built on the remote host, just pushed there. This means you can be confident that the image on your server is exactly the same as the one you tested locally, and also will typically be much faster (assuming well-structured Dockerfiles with small layers, etc).
It is fine if you are just working by yourself on non-prod things and you’re happy with that.
But if you are working with others on things that matter, then you’ll find you want your images to have been published from a central, documented location, where it is verified what tests they passed, the version of the CI pipeline, the environment itself, and what revision they were built on. And the image will be tagged with this information, and your coworkers and you will know exactly where to look to get this info when needed.
This is incompatible with pushing an image from your local dev environment.
With that sort of setup you'd run `docker pussh` from your build server, not your local machine (really though you'd probably want a non-ephemeral registry, so wouldn't use unregistry at all).
Other than "it's convenient and my use case is low-stakes enough for me to not care", I can't think of any reason why one would want to build images on their production servers.
Totally valid approach if that works for you, the docker context feature is indeed nice.
But if we're talking about hosts that run production-like workloads, using them to perform potentially cpu-/io-intensive build processes might be undesirable. A dedicated build host and context can help mitigate this, but then you again face the challenge of transferring the built images to the production machine, that's where the unregistry approach should help.
Taking a photo of my handwritten notes and passing it to ChatGPT works 95% of the time. Once in a while it gets a character or two wrong, but for the most part its magic for me.
Yeah but it's XML not pydantic which means it doesn't play well with failovers to other providers. It would be tolerable if Anthropic didn't have such abysmal API uptime but at this point no way will I use them for my SaaS.
reply