> I'm now experimenting with `age`, which touts itself as "simple, modern, and secure encryption". If needed, I will use `minisign` for signatures.
I have also switched from GPG to age.
When I wanted to start signing my open-source software releases because of recent supply-chain attacks, I first thought of Minisign, too.
I tried it for binaries and even found a few third-party Git integrations (https://codeberg.org/SkyFox42/git-minisign, https://github.com/sug0/git-signify), then discovered that Git and GitHub supported signing with SSH keys (https://stackoverflow.com/questions/72844616).
GitHub supports it in the sense that it will indicate a commit or tag is signed.
I have adopted this approach: I sign tags with `git tag -s foo` and binaries with `ssh-keygen -Y sign`, and I have put the public key and usage instructions on my site (https://dbohdan.com/pubkeys).
Cool concept.
I like the lowercase q a lot.
The misaligned dot (tittle) on the lowercase i and j bugs me.
It feels off to have it at different heights.
I'd try making the i taller to match the j.
VB6 is as stretch, but I'd love to see Microsoft Visual Basic 1.0 for MS-DOS open-sourced.
It is the only DOS version of Visual Basic.
What is remarkable about VB for DOS is that it's a complete text-mode RAD IDE [1] for TUIs.
There is no TUI builder that I know of like it.
It is obscure and barely discussed by retrocomputing enthusiasts.
Your best resource outside of early-1990s books and magazines is a 2020 blog post [2] that demonstrates building a "Hello, world!" project with screenshots.
Add me to the VB for DOS fan club! I was a user in the mid to late 90s. TurboVision was beyond me at the time (I didn't really know Pascal well at all, and I wasn't good enough at C++), but VB for DOS was just the ticket (mostly) - the language was not terrible, and the form designer was super easy to use. Much easier than me attempting to recreate a nice text UI in C. I wrote a few programs in it.
I do recall the 640 KB barrier being a limitation. I've forgotten the exact details, but, as I recall, the docs implied it shouldn't generally be an issue - but in practice it was. And it'd always be a problem at the most annoying time.
(But it could just have been some large model thing that experienced real mode fiends would instinctively know to avoid? Coming from a 68000 background, for DOS stuff I'd used Borland's huge model or a DOS extender of some kind, to avoid the segmentation one way or another. Maybe that was the problem.)
Despite the occasional problems I had, I always generally liked it, and felt the UIs I created with it looked really rather nice.
That's wild that it passed me by. I've never seen that before. I used the Windows version from 1.0, but all my main development was still in TUI apps like Borland until about 1995.
Funny that the DOS version came out after the Windows one.
It amuses me that I'm sat here at my desktop right now using the exact same interface in Visual Studio 34 years later to build a WinForms app.
Google of 3 words Vermont Views, software still picks up several links
Borland Turbo Pascal and Borland Delphi where also (similar) products from around that time. These products where popular at the time. ( The development system provide include some kind of windows system for the application )
It doesn't sound like this is what redwall_hp meant; it sounds like what they meant was that pixels are the wrong level of abstraction.
If so, I agree: the web is about marked-up text.
When you break it down to the very basics, what you get is a teletype, not raster.
I'd say that is more like a terminal than a browser. Regardless, what I really mean is some data is needed for the pixels (or whatever abstraction you want above that). You don't need data for anything other than the current viewport and whatever is likely needed next. No less, no more. No over or under fetching. This would be much better imo.
curl -sSL https://example.com/install.sh | vipe | sh
This will open the output of the curl command in your editor and let you review and modify it before passing it on to the shell.
If it seems shady, clear the text.
vet looks safer.
(Edit: It has the diff feature and defaults to not running the script.
However, it also doesn't display a new script for review by default.)
The advantage of vipe is that you probably have moreutils available in your system's package repositories or already installed.
What it comes down to is that people want a one-liner.
Telling them they shouldn't use a one-liner doesn't work.
Therefore, it is better to provide a safer one-liner.
This assumes that securing `curl | sh` separately from the binaries and packages the script downloads makes sense.
I think it does.
Theoretically, someone can compromise your site http://example.com with the installation script https://example.com/install.sh but not your binary downloads on GitHub.
Reviewing the script lets the user notice that, for example, the download is not coming from the project's GitHub organization.
Same but less instead of cat so my fingers stay in the keyboard.
Vet, vite, etc are kind of like kitchen single-taskers like avocado slicer-scoopers. Surely some people get great value out of them but a table-knife works just fine for me and useful in many task flows.
I'd get more value out of a cross-platform copy-paster so I'm not skip-stepping in my mind between pbpaste and xclip.
I’m honestly not familiar with pbcopy, but I imagine you could make a relatively consistent wrapper in python if a simple alias does not work. Are you able to give some example shell code of what you’d like to be consistent?
I have also switched from GPG to age. When I wanted to start signing my open-source software releases because of recent supply-chain attacks, I first thought of Minisign, too. I tried it for binaries and even found a few third-party Git integrations (https://codeberg.org/SkyFox42/git-minisign, https://github.com/sug0/git-signify), then discovered that Git and GitHub supported signing with SSH keys (https://stackoverflow.com/questions/72844616). GitHub supports it in the sense that it will indicate a commit or tag is signed. I have adopted this approach: I sign tags with `git tag -s foo` and binaries with `ssh-keygen -Y sign`, and I have put the public key and usage instructions on my site (https://dbohdan.com/pubkeys).
gpg-agent was valuable to me because it let me use `pass` in scripts while maintaining encryption at rest. This prevented me from switching to `passage`. After surveying my options (https://github.com/dbohdan/pago/blob/6aa312e83113498a64abd9a...), I ended up forking pash (https://github.com/dylanaraps/pash) and developing the fork into an age-based password manager with its own agent. The developer of seniorpw has a nice feature comparison of `pass`-like password managers based on age (https://gitlab.com/retirement-home/seniorpw/-/blob/f1584cf42...).
I can say I am happy with the switch. If you use GPG for encrypting files, I can recommend it.