HN user
Or maybe you pipe into xargs and pray your filenames don’t have spaces:
find . -name '*.log' | xargs rm
No need for prayer:
find . -name '*.log' -print0 | xargs --null rm
In my case, I am a very senior member of my team so 25-50% of each day is spent helping and/or teaching teammates. In situations like that, it is useful to be deeply familiar with the tools that your teammates are using so you can tell them exactly what to do.
For example, if I'm teaching a new hire to set up their vscode it is not very helpful to tell them "now you need to activate the python venv". It is much more helpful to be able to tell them "Now we're going to activate the python venv. To do that, open your command palette and search for 'select python interpreter'".
In my personal life, I still exclusively use emacs (which I have scripted to auto-detect venvs) but I put up with using vscode at work to be a greater utility to my team.
They're referring to the partnership between GrapheneOS and Motorola: https://motorolanews.com/motorola-three-new-b2b-solutions-at...
It's at the end on the conclusion slide @24:40:
My area has a net-metering plan available, so you can send any surplus out to the grid to offset energy pulled from the grid, essentially treating the grid like a large battery. That can extend the 8 hours into full 24-hour coverage with enough panels.
With enough solar panels it is!
Not necessarily. I was spending ~$150/month on vultr's kubernetes hosting. I spent $5k building out a pretty awesome 1U server and I put it in a colo that costs me $50/month. Next year I will break even financially and everything after that is saving money. I also am getting so much more out of this server than I was getting on vultr because I over-spec'd the machine. In addition to running more on my cluster, I spin up large virtual machines for development, experiments, and for offloading distributed builds. No shade to vultr, but owning my hardware instead of renting was absolutely the way to go. Unfortunately today the ram alone would cost over $5k, so the math has changed.
It has. For example, PirateFi back in 2025: https://www.bitdefender.com/en-us/blog/hotforsecurity/pirate...
The FBI were seeking victims for ~8 "games" earlier this year: https://forms.fbi.gov/victims/Steam_Malware/view
FWIW I'm one of those people. I have an old rotting pixelbook that I installed Linux on back-in-the-day thanks to Mr. Chromebox. It was a huge improvement over chromeos but I'd never buy a chromebook to install Linux on it again because there was too many small annoyances like needing to fix the keymap every time I did a clean install (the caps lock key was bound to super and I vaguely recall some craziness around the higher function keys), and sound didn't work.
Was there? I see 14 comments, of which only 3 have any value at all which are: fanf finding an irrelevant bug, oliverpool explaining the use of LetsEncrypt staging, and hexadecimal suggesting setting up expiration alerts.
The rest is:
- People bitching about systemd and replies to their bitching totaling 7 posts (literally half the comments)
- conversational detritus like "well written blog post" and the whiteboard commentDo you honestly think stackghost doesn't know what the "D" stood for? They were making a point, not seeking information. My answer directly responded to the point they were making.
That's more of a historical artifact. The BSDs started as just "BSD": a set of patches for AT&T Unix that were _distributed_ by Berkeley. Eventually the patches became complete enough to be an entire operating system. _Then_ the various BSDs that we know today (FreeBSD, OpenBSD, NetBSD, DragonflyBSD) all forked and became completely independent operating systems. For decades, FreeBSD's kernel and userland has been developed independently from the OpenBSD kernel and userland which is developed independently from NetBSD's kernel and userland, etc. You could not take an OpenBSD program and run it on FreeBSD. Even recompilation from source isn't necessarily enough since the BSDs support different syscalls.
They are completely independent operating systems with a distant shared history.
Whereas on Linux, the distros are taking a common Linux kernel source, and combining it with their choice of common userlands like GNU. Debian has the same kernel and GNU userland that Arch and Fedora use. You could take a program compiled for Debian and run it on Arch, which is common these days due to Docker where you're pulling another distro's userland and running it on your distro's kernel. That is how Linux distros are "distros" whereas the BSDs are independent operating systems.
I think the author was suggesting "wait a week" as a one-time wait for fixes to be written and patches distributed for these specific prematurely-disclosed vulnerabilities, not an on-going suggestion for delaying all updates. But otherwise I agree with you.
"I really wish I was eating in an airport" - literally no one ever.
Airports are expensive, loud, and uncomfortable.
In that situation, the multiplexing wouldn't be handled in the terminal. You'd use something like tmux or screen. Seems irrelevant to the discussion about terminals.
tab-complete, history
Those would be handled by your shell, not your terminal, right?
multiplexing
If you have a good window manager, then there is no reason to have a bespoke multiplexing implementation in your terminal. I can stack my terminals and _any other window I want_ with tabs and switch between them using the same hotkeys/interface that I use for my whole system, rather than each app implementing their own tabs.
Perhaps as a web client for the remote desktop on the BMC chips?
I was able to reproduce it using that script in my PS1 when `GIT_PS1_SHOWUNTRACKEDFILES=1` which triggers a call to `git ls-files`. Without that, it seems to be just calling `git rev-parse` which does not execute fsmonitor.
I was also able to reproduce it with `GIT_PS1_SHOWDIRTYSTATE=1` which invokes `git diff`.
As far as I am aware, this has been brought to the attention of the git maintainers years ago: https://github.com/justinsteven/advisories/blob/main/2022_gi...
any competently set up shell PS1 will tell you that
I certainly hope your shell is not running `git` commands automatically for you. If so, that is a RCE vulnerability since you could extract a tarball/zip that you don't expect to be a git repository but it contains a `.git` folder with a `fsmonitor` configured to execute a malicious script: https://github.com/califio/publications/blob/main/MADBugs/vi...
Oh neat, thanks! I (clearly) did not know that command.
If you don't run checkout on file paths, how do you undo changes to specific files that you haven't committed yet? Like you've edited but not committed <foo>, <bar>, and <baz>. You realize your edits to <bar> are a mistake. I'd just run `git checkout <bar>` to revert those changes, what do you do?
It is also really useful when you realize you want <bar> to be the version from a commit two weeks ago. I guess you could always switch to the branch 2 weeks ago, copy the file to /tmp/, switch back, and copy the file into place, but `git checkout c23a99b -- <bar>` is so quick and easy. Or does this example not fall under the "dont run checkout on a path" since it is taking a treeish first before the path?
< glances around at all the people telling me to never use `jj edit` >
ooo that will be a nice improvement. So many times I've run `jj status`, then saw a file I wanted gitignored, so I'll edit my gitignore, but the file has already been added to the repo so I have to `mv <file> /tmp/ && jj status && mv /tmp/<file> .` to get the file out of the repo.
Ah, thanks! That's a command I haven't learned yet, so I'll have to check it out. I learned jj from the tutorial that was posted and I don't think it covered `jj commit` at all.
That avoids the problem for the specific workflow of checking out an old revision (and it was what I was describing with checking out a new branch off the old commit and adding a blank commit to that branch), but another way this design bites me: At work I am constantly jumping around numerous repos because I might be working on repo <foo> but then someone on my team will ask for help with repo <bar>. So I'll turn on screen sharing, open up repo <bar> and I'll type out psuedo-code into <bar> as I'm explaining things to them.
So if the last thing I did on <bar> was finish some work by making a new commit, then writing some changes, and then giving it a commit message with `jj desc`, then I am now polluting that commit with the unrelated explanatory psuedo-code. So when switching to a repo I'm not actively working in, I need to defensively remember to check the current `jj status` before typing in any files to make sure I am on an empty commit. With git, I can jump around repos and make explanatory edits willy-nilly, confident that my changes are distinct from real meaningful commits.
I guess one way to describe it is: we want to make it easy to make good commits and hard to make bad commits. jj seems to be prioritizing the former to the detriment of the latter. My personality prioritizes rigorous safety / lack of surprises.
Yeah, that's a very real possibility. On the bright side, jj is git-compatible so at least the two camps can live together in harmony.
I'm giving jj a try but one aspect of it I dislike is edits to files are automatically committed, so you need to defensively create empty new commits for your changes. As in, want to browse the repo from a commit 2 weeks ago? Well if you just checkout that commit and then edit a file, you've automatically changed that commit in your repo and rebased everything after it on top of your new changes. So instead you create a new branch off of the old commit and add an empty commit to that branch so any file changes don't end up rewriting the past 2 weeks of history. git is much nicer in that I can do whatever I want to the files and it won't change the repo until _I tell it to_.
Induction is also faster to boil water, easier to clean since it's just flat glass, and safer since an induction stove without a pot/pan stays room temperature (in fact, they usually can detect if a pot/pan is present and automatically turn themselves off)
Induction is also particularly nice for certain types of cooking because many induction stoves can be set to a specific temperature instead of just to a power level.
As an alternative, you could get a stand-alone USB-C power meter which can be used with any cable. That way, when the cable breaks, you don't have to buy a new power meter. Here is an example of one such product (though I've never used this model): https://www.amazon.com/Adapter-Voltage-Current-Extension-Con...
These two statements aren't mutually exclusive. The link is looking at the analog signal through an oscilloscope. The person you replied to is pointing out that after decoding and applying error correction, you can still end up with the same digital signal output. So the eye diagram charts are useful for detecting the quality of the cable, but as long as the quality is past a certain threshold, it does not matter.