Not directly related to this, but you can use systemd-creds to store secrets at rest. It can even work with a tpm2 chip or a key file to encrypt the secrets.
And then use these tips for when you want to interactively reference those stored secrets.
I agree that LVM in HP-UX was far ahead of Linux back in the day. To be fair some of those advanced features in HP-UX LVM required an additional license (eg: mirroring required Enterprise Operating Environment). I haven't touched HP-UX in like 10 years however.
That is true, sw licenses were a major nuisance. As they usually are. Not just where to get one, but in time, to keep track of those and secure so that proof of purchase was not lost before deployment and include final delivery. HP product codes and major version change product renaming plague were not exactly my favourite part of work!
Many HP-UX boxen (servers) came with default (interactive) multiuser OS licenses. Product differentiation which HP sales loved had license castrated workstations, which came only two user license.
First time I had no clue about this and were wondering why some odd network management software I was installing a server did not restart properly and was causing head scratching. Then I found that logs stated our license was not valid though it had been confirmed valid in other test install.
A HP support guy I knew and saw later told that I had probably to install optional two-user package and then the software will start. Oh, great that it was. But what the heck that two-user license only prevented only two serial line users simultaneously and only systems console was serial that time and everyone else logged in via network. To be sure I made PM check if we still were within license because of that. He told me later yep, no problem there. Just get it done and we're ready deploy it to site.
Chuckling at the disclaimer 'No AI made by a human.' I doubt many web devs could tell you that because so many use AI now. I was speaking with a web dev this summer and he told me AI made him at least twice as productive. It's an arms race to the bottom imo.
Which begs the question, are people consciously measuring their productivity? If so, how? And did they do it the same way before and after using AI tooling?
Anecdotal, but I don't measure my productivity, because it's immeasurable. I don't want to be reduced to lines of code produced or JIRA tickets completed. We don't even measure velocity, for that matter. Plus when I do end up with a task that involves writing something, my productivity depends entirely on focus, energy levels and motivation.
One of the only studied made so far showed lower actual productivity despite higher self reported productivity. That study was quite limited but I would take self reported productivity with a huge grain of salt.
I tried Github CoPilot for about a year, I may try Claude for a bit sooner or later.
It felt like it got in the way about half the time. The only place I really liked it was for boilerplate SQL code... when I was generating schema migration files, it did pretty good at a few things based on what I was writing. Outside that, I don't feel like it helped me much.
For the Google search results stuff, Gemini, I guess... It's hit or miss... sometimes you'll get a function or few things that look like they should work, but no references to the libraries you need to install/add and even then may contain errors.
I watched a friend who is really good with the vibe coding thing, but it just seemed like a frustrating exercise in feeding it the errors/mistakes and telling it to fix them. It's like having a brilliant 10yo with ADD for a jr developer..
The issue is that you can't give AI a task and let it go off and it actually performs said task in a couple hours and then comes to ask for more... you have to pretty much baby sit it.
Now, I could see a single person potentially managing 2-3 AI sessions across different projects as part of a larger application. Such as a UI component/section along with one or more backend pieces. But then, you're going to need 2-3x the AI resources, network use, etc. Which is something I wouldn't mind experimenting with on someone else's dime.
> he told me AI made him at least twice as productive.
He’s not only lying to you, he’s also lying to himself.
Recent 12-month studies show that less than 2% of AI users saw an increase in work velocity, and those were only the very top-skilled workers. Projection also indicated that of the other 98%, over 90% of them will never work faster with AI than without, no matter how long they work with AI.
TL;DR: the vast majority of people will only ever be slower with AI, not faster.
To drive home how luxurious this was, 1981 was the start of a recession that lead to 10% unemployment, the highest since the end of World War II, and here are people buying a TV that would be $35,000 in today's money.
I hope everyone is reading through and noticing this is for F, M and J visas, which are all education related visas. Not that I love that either, but it doesn't apply to every visitor.
Bolivia also has a reciprocity visa charge of $160 for US citizens. Many years ago we were very close to the Bolivian border but the visa cost for a day trip just didn't make it worth it.
This is great and I believe it. But saying your game would be loaded "after a few minutes" might be true for a small game. I had the Commodore 1541 floppy drive while my friend had the Commodore Datasette. The speed difference between these were huge. The floppy drive was around 300 bytes per second while the tape drive was around 50 bytes per second (3KB/minute). We would literally go outside to play while waiting on the tape drive.
That's why you needed it saved with Turbo. it was at least 10 times faster.. I used to have this cartridge... besides turbo it had some more things, it could grab a hardcopy of memory (ie if you were playing a game.. you could save it... and then load it later, it would be in the same state)
300 Bps is demon speed! I remember using an acoustic coupler to access the early internet at 300 BAUD (i.e. 300 bps), or about 30 char/sec.
Later on, I also remember downloading Linux kernel tarballs, hot off the press, via FTP using 9600 bps modem (if I recall correctly - slow as crap), which I'd kick off before going to bed and hope for the best in the morning. Sometimes I'd make a script to download a few different files at once.
On the theme of slow computing in general, I remember doing embedded software builds on a PDP 11 (Xenix) that would take an hour or so to complete - so you'd go and practice your juggling or somesuch waiting for it to complete.
Still, the big thrill in mid-late 70's had been the switch from batch punched card deck submissions to a mainframe (an hour later comeback to collect the syntax error, or core dump printout) to being ONLINE (woo hoo!) - sitting in front of a terminal and actually interacting with a computer in real time!
That definitely brought back memories. Around '92, being a poor college student I took out a loan from my credit union for about $2,000 to buy a 486 DX2-50. For you younger people, that's about $4,000+ in today's money for a pretty basic computer. I dual booted DOS and Linux on that bad boy.
And then use these tips for when you want to interactively reference those stored secrets.
reply