Cool page, it lists a bunch of compelling arguments. It's always good to see more and more people realising these things and start insisting on actual ownership.
Meanwhile, did you know defectivebydesign.org has been around for 20 years now? Makes me feel old.
> The ignore file lives in your machine’s home directory in ~/.config/git/ignore. Whatever filenames are added to this file are ignored globally at a machine-level.
The wording here is slightly wrong: ~/.config/git/ignore will ignore files per-user on the machine, not "at a machine level". And it's not "your machine's home directory", it's your user's home directory on that machine. Any other users on the same machine will not see this. Git calls this "global", as in "global for the user".
Git config does also have a --system option which modifies the system-level config file, /etc/gitignore. You could probably ignore stuff at the system/machine level (hint: you don't want to), with this. I'd do something like:
Note however that user config will override this, so any user who has a core.excludesFile setting will not also look at your system level excludes file. Which is a pretty big caveat.
Well hi there chatgpt! I wonder if the person who couldn't be bothered writing this article actually had a point they wanted to make? I don't know because I stopped reading as soon as I recognised your fingerprint.
I second GP's sentiment. That debugger was amazing. I've never seen anything that can touch it to this day.
Tell you more: you could also just run code to do things like change variables in the immediate window while execution was paused, so e.g that example where you want to re-run some loop: first you drag the PC arrow back to above the loop as GP already described, then in the immediate window you can just run things like e.g:
someVariable="initial value"
To reset vars back to their initial values, or clean out buggy data, or whatever.
then you can just step through the code or resume execution.
I used to use it a LOT for handling edge cases on long-running, one-off things: run the code until it hits an error, fix the error by doing some stuff in the immediate window, resume the loop without re-processing the 100K items you've already processed.
The destruction of VB with no upgrade path (the advice was to "just" rewrite your perfectly-functional 100KLOC codebase) is what pushed me away from MS, first to delphi and then to FOSS. But that VB6 debugger was IMO probably the best thing MS has ever done.
Yes, yes, this is all very clever and funny and whatnot. I chuckled. Well done you.
...But has it occurred to you that by putting this online and publicising it, you're effectively daring this lunatic with nuclear codes to actually go through with his threats? I for one am relieved every time he "chickens out".
yep! and ffplay will detect your situation and run on the framebuffer if that seems appropriate. I'm sure there's arguments to explicitly tell it to do that, but I've never used them :)
This is exactly right - you can get a framebuffer on just about anything, including pretty much any video card made since about 1990, and also more fun things like the little i2c display that your toaster has. No need to restrict relatively simple software like fbi/fim to running on less hardware by using drm.
I used to play videos with the framebuffer just fine and read PDF's with fbpdf2, among watching TV with fbtv and the like. I didn't miss nearly anything, as most games under SDL1/2 can render into FB with
export SDL_VIDEODRIVER=fbcon
or
export SDL_VIDEODRIVER=kmsdrm
And tons of games too, such as Supertux2, Crispy Doom, SDLQuake, FreeCiv-SDL...
another fun one if you're in an exotic situation and don't have a framebuffer (or if you just want to have some fun by making your games to look worse):
Meanwhile, did you know defectivebydesign.org has been around for 20 years now? Makes me feel old.