Also, if you have useful nice shelves that make your fridge aka postgres run better, why shouldn't we work on putting that on servers to make all fridges run better? Also, having a comparable and shared admin experience is a big deal in a team.
Like sure, if you need to quibble about red or yellow prompts, eh. But if there is a good log colorizer or analyzer that makes an expert better at handling the system, or some aliases that make a system easier to manage - I want this deployed for _all_ admins on _all_ relevant systems.
And sure, all code running on a server is a security topic. But then let's figure out a way to run your favorite tools through the software security pipeline and then deploy it to systems. Sure, I dislike installing the latest js-based npm fad on a database for a minor advantage, but if there is some well-aged tool from the postgres space... I'd probably rather work to have it.
> I want this deployed for _all_ admins on _all_ relevant systems.
Another user above mentioned that his most important config is mapping j to gj. That would drive me nuts. When lines are so long that they wrap, I want j to go to the next line, not the next however-wide-the-terminal-is. On the off chance that I ever want that, I have gj right there at my literal fingertips.
You're never going to find a config that everybody is happy with. If that were the case, then there would be no need of config at all.
I was rather referring to things like: Aliases to access important log files. Aliases to supply security credentials to important commands. Coloring logs so relevant details are highlighted.
If your biggest problem running a system is the line-next semantic, you're in a much better place than I am. No one on the team has ever raised that.
Besides that, I just spent way too much time figuring out this is an encrypted OpenTofu state. It just looked way too much like a terraform state but not entirely. Tells ya what I spend a lot of time with at work.
This is probably another interesting situation in which you cannot read the state, but you can observe changes and growth by observing the ciphertext. It's probably fine, but remains interesting.
We have post-its with file names on a wall in the office. You take one down if you edit the file, and put it back up when you're done. Easy.
Though I wish I was entirely kidding. ~12 years ago or so we did that if one of two parallel development teams had to modify a message of the network protocol to avoid incompatibilities and merge problems.
Mind you, these were SVN merges. I can't even verbalize my feelings about SVN merges but by a mixture of laughing and groaning in pain, like if you stubbed your toe in a painful, but entirely funny way.
What is this eternal meme about merges in svn being harder than in other tools? Git used literally the same merge algorithm, even if that has changed a bit since then, and merge conflicts are not something a tool can't just magically make disappear. If you want concurrent edits (the c in cvs), conflicts come in the same package. Various algortihms can supply their own dose of magic, but they're more similar than different (minus a few special cases such as rerere in git).
My interpretation within that company: You know this new idea of "If it's painful, do it more"? People in that company didn't do that in the SVN days or earlier, because merges were painful. Thus, merges filled a sprint if they had to be done. This made sense if you came from CSV or nothing, tbh.
Git in turn made branches easier, causing merges to be more prevalent and developers overall learned to merge more, merge more often.
Keeping it when tech can't keep up is genuinely a good hack for any kind of engineering. Physical lock out tag out on industrial machines for instance. Passing paper notes/wooden blocks in air traffic control towers to see who's responsible for what even if computers go down.
This was also a plot point used much before The Martian; in the 2000 Val Kilmer film Red Planet- stranded astronauts make their way to the spot where Pathfinder's 'Sojourner' rover rests, in order to pull it's radio and use it to communicate an SOS with the orbiting station.
It's been a long time since I've seen that (widely panned as not-very-good) movie, but I feel I remember a line about the little rover using an 'off the shelf computer modem' - this is actually true, the little rover communicated back to the Pathfinder base station with a straight up off-the-shelf RS232 9600bps wireless transparent modem link. [0] [1] I remember that detail as it showed that, even though the movie itself was... uhhh... interesting, science-wise, it clearly had someone in an advisory role that knew something about real JPL hardware on Mars at the time.
They do, if you type something like `stop`, it's equivalent to typing `/stop` in the in-game chat. In my scripts I set stdin to a named pipe, to be able to send commands later.
This is something I've started to notice as I've talked with artists on tour.
Like, I'm a hobby metal musician, and I do have a certain dream of being on stage with a band. Even if it's just a dive bar with 20 people. Gotta be realistic. And I have 15 - 20 years available for that, or even more if you look at Grave Digger or - rest in peace old chap - Ozzy. But I'm not certain if I have the passion to be a touring musician even if that happened (which most likely wont). Like what these people take on is entirely insane.
Brittney Slayes from Unleash the Archers had tours during which she worked full-time remote. 8 full hours of work, out of the hotel, soundcheck, gig, meet and greet, back into the bus, sleep, back to work. And from what I've heard they've also done that with a kid on top. That is just nuts.
And even without that, big tours are hell from what I've heard. The first one or two tours are an absolute test for bands because it's all a huge rush of adrenaline, excitement, nonsense, strange locations all at once without a second to breathe.
If you hear that, a 9-5ish tech job isn't that bad.
creating an account just to respond to you, because i just got to the end of a 8 ish year journey playing with a local band and the reason i stopped has a lot to do with this unpacking. we never toured, and i would have loved to do exactly one, but i realized that i am not crazy about music in the sense of the article. even weekend gigs mean many hours of driving and spending most of your time with the band, who are cool guys but not nearly as cool as your SO.
don't get me wrong, i LOVE playing live, and i hope you find a way to do so, because it really is great, but going to that next level really does take being a little nuts. stories about people shedding on their instrument for 8 hours, and then going out and jamming for 6 more hours until 4 am, every day. music is really important to my life, but when push comes to shove i don't care about it that much!
This area of security always feels a bit weird because ideally, you should think about your assumptions being subverted.
For example, our development teams are using modern, stable libraries in current versions, have systems like Sonar and Snyk around, blocking pipelines for many of them, images are scanned before deployment.
I can assume this layer to be well-secured to the best of their ability. It is most likely difficult to find an exploit here.
But once I step a layer downwards, I have to ask myself: Alright, what happens IF a container gets popped and an attacker can run code in there? Some data will be exfiltrated and accessible, sure, but this application server should not be able to access more than the data it needs to access to function. The data of a different application should stay inaccessible.
As a physical example - a guest in a hotel room should only have access to their own fuse box at most, not the fuse box of their neighbours. A normal person (aka not a youtuber with big eye brows) wouldn't mess with it anyway, but even if they start messing around, they should not be able to mess with their neighbour.
And this continues: What if the database is not configured correctly to isolate access? We have, for example, isolated certain critical application databases into separate database clusters - lateral movement within a database cluster requires some configuration errors, but lateral movement onto a different database cluster requires a lot more effort. And we could even further. Currently we have one production cluster, but we could isolate that into multiple production clusters which share zero trust between them. An even bigger hurdle putting up boundaries an attacker has to overcome.
I'd say, pure SQL gives you a higher performance ceiling and a lower performance and security floor. It's one of these features / design decisions that require diligence and discipline to use well. Which usually does not scale well beyond small team sizes.
Personally, from the database-ops side, I know how to read quite a few ORMs by now and what queries they result in. I'd rather point out a missing annotation in some Spring Data Repository or suggest a better access pattern (because I've seen a lot of those, and how those are fixed) than dig through what you describe.
The best is when you use an orm in standard ways throughout your project and can drop down to raw sql for edge things and performance critical sections… mmmmm. :chefs kiss:
Having run servers on OpenVPN, IPSec and Wireguard.. Wireguard is very mundane software.
I still get the chills at the deep and arcane configuration litanies you have to dictate over calls to get a tunnel configured. And sometimes, if you had to integrate different implementations of IPSec with each other, it just wouldn't work and eventually you'd figure out that one or two parameters on one side are just wrong.
And if you don't want to manage IPTables/nftables manually to firewall the traffic from the VPN (which is ugly, I agree), ufw or firewalld introduced forwarding rule management (route, and policies) recently.
Yes, the initial setup and troubleshooting of IPSec can be a nightmare. I've spent hours on bridges with people getting it up and running properly.
Wireguard is a damn simple breath of fresh air. There's so little to configure and go wrong. The mental model took a little bit of time click for me (every endpoint is a peer, it's not client/server) but after that it was a breeze.
Like sure, if you need to quibble about red or yellow prompts, eh. But if there is a good log colorizer or analyzer that makes an expert better at handling the system, or some aliases that make a system easier to manage - I want this deployed for _all_ admins on _all_ relevant systems.
And sure, all code running on a server is a security topic. But then let's figure out a way to run your favorite tools through the software security pipeline and then deploy it to systems. Sure, I dislike installing the latest js-based npm fad on a database for a minor advantage, but if there is some well-aged tool from the postgres space... I'd probably rather work to have it.
reply