I've wanted to do this for a while. Thanks for detailing your setup! I hope one day I find the time to try it.
I've also always yearned for more usability from just the command line.
There's no tui spotify client, is there? Maybe I should break out my mp3 collection again... I'm trying to think of what else I'd really need to not need a GUI machine for my day to day. Maybe email?
Lynx and other tui browsers are not usable on today's web. Maybe there's a subculture to find somewhere that also appreciates reader-mode / lack of javascript?
The number of times I’ve had to defend someone else’s customers let alone my own is exhausting.
And that dynamic is only allowed within close circles.
I’ve found once “the decision” is made, the bigger the subsequent meeting, protests are often swept under the rug.
On most occasions the worst part is that folks intentionally withhold information to get their way. And thats real hard to compete against without making an ass out of yourself, or losing the trust of others.
I’ve also always wanted this, but what I’ve realized after noodling on it a while is I’d really just prefer a way to use git, and push markdown documents to the Notes System.
I dont want a different system handling edits reviews and merges.
I just want CD to send my docs from git to a system that can properly host / give me the Doc-related features I need.
Sorry if I'm being thick, but why not just cache the response?
If you are guessing at the data anyway, what's the difference?
Why set up an entire speculative execution engine / runtime snapshot rollback framework when it sounds like adding heuristic decision caching would solve this problem?
Hey cool project! I had the same need, and solved it a very different way.
I set up a wireguard server on a publicly accessible VPS.
The neat part about using "lscr.io/linuxserver/wireguard:latest"
is that it allows my to codify the number of clients I need. This includes both endpoints and source devices.
The second thing I did, was separate out the "networking" bits from the "userspace" bits, meaning it doesn't matter what port the service is running on. The client can hit it.
Taking that one step further, I just combined the above with haproxy and set my application ports there. This means I can hit haproxy on "someport" inside the VPN and it'll forward to whatever service I've got configured on that "client" that haproxy can see on it's LAN.
Works great, currently running a simple web page off the whole thing, where you connect to VPS and it tunnels the actual HTTP connection into kubernetes in my house.
I was thinking about writing this all up one day, but there's some cleanup to be done. Oh well.
> punish the grumpy ones in favor of the people-pleasers, that this crap happens
This isn’t exclusive to technology, but I see this all the time at my large organization. As a grump, I have to pick which shitstorm to care about and spend my time chipping away at, which ends up being really draining.
To help with this, we began focusing a team of great folks with shared values, leaning in on modern operations/SRE best practices.
We started to have some real success with SDLC for our operations workflows.
That’s when management changed our teams direction. Good times.
For the first bit, all I can think is a compose file. Also podman can run k8s configs locally, which I personally hope all of that eventually washes into the same thing. It feels like we already have the tools to make this a "solved" problem, is what I'm trying to say. I just include an additional .env that the compose file pulls in so it's not committed to git.
For the second point, ok this makes a little bit more sense, I've heard of Codespaces or OpenShift Dev Spaces but I guess I still question the value of additional complexity on top of the container (a simple dockerfile in my mind) your vscode instance's terminal is running in.
I did something similar with Kubernetes, work has some OSE clusters that will generate DNS for you, it works great and the devs love using it. It’s a little bespoke but its simple and gets a lot of attention.
Plus since the namespaces preexist the workloads, we spin them up for the entire branch lifetime (times out after n days). Makes everyones jobs a lot easier.
Anything that helps shift lifecycle requirements and testing left has huge impact on DX.
I’ve been working on the same thing for a few months now.
Not only is it more customizable / less complicated than helm / other solutions, but GNU gettext is almost 30?! years old at this point, and environment variables are probably realistically double that age. They aint going anywhere anytime soon.
Plus I feel that more complex logic removes value from the configs we are building, and so am not interested in many other tools.
If the door is not closed and you shift into drive, you also get a very loud annoying beep and visuals.
Not only that, the brakes engage and the car LOCKS ITSELF IN PARK AND DOES NOT LET YOU DRIVE EVEN THOUGH THE SHIFTER IS IN ‘D’!!!
I pray the door sensor doesnt fail while driving on the highway, or theres never a situation that arises where the car needs to be driven regardless of the door being open.
On top of that, the door locks /trunk locks act very strange while the engine is running /driver door is open. Still dont have that figured out.
Use the service resource in Kubernetes to order a load balancer in different clouds. You need different tags, they function and are configured differently, and you still need to learn how it works in your cloud.
Contrast this with the contract* K8 tries to sell you, which is "describe the intent and we'll figure it out for you" and you'll realize the cloud providers bunged up this whole thing.
That's not to say K8 is perfect, but if you think for even a second that wiring up resources outside your kubernetes cluster will be lower-friction, kubernetes is falling short of it's goals.
It's more about what happens once there is an issue. I agree if something works and remains unchanged it will probably stay reliable, the issue is once you introduce a change, even nowadays you can possibly break something that isn't easy to undo (or troubleshoot without taking services down).
For low traffic stuff, might seem OK, but no redundancy for a service that users pay for seems irresponsible, however Gitea might just be for them to track internal stuff, so maybe a little less so.
If it went viral, yes. I agree most of the time I feel like the world is run by evil folks twiddling their fingers in secret.
This is not one of those times. I agree there's a chance there are better word choices or feedback for some commands, but overall once you 'learn the language' it really is a lean, mean, well designed piece of software.
Folks that complain about the UI/UX don't realize it wasn't designed for less technical folks. It was designed for the folks who needed it.
It's success must at least partially prove that the UI/UX is not 1/10. Any real engineer will tell you, there are times where they wish they could do something better but the requirements and constraints left them making tough decisions, and that doesn't mean they aren't proud of their work.
It's success is also partially due to the fact that it is lean and mean, which allows it to be applicable to nearly all software projects of any flavor. So I don't understand why folks argue it could have been done better. If it was 'better', in my view it wouldn't have been successful. The success was driven by it's succinct design and Linus' take it or leave it attitude.
Technically accurate studio monitors don't sound as pleasing to the ear as good well tuned speakers. But they are exceptional at the job they were designed for. This is like that.
I try to subscribe to the idea that if you cannot adequately describe your commit in a small number of characters (~50 is plenty I feel), your commit is likely too complicated. One size does not fit all, and if a workflow ain't broken there's usually no need to fix it. However most workflows are imperfect, there is almost always room for improvement.
But in the general case I find that if commits are not themselves concise and simple changes, they often should be broken up so that the moving pieces can be better tracked when looking back at the history.
I've also always yearned for more usability from just the command line.
There's no tui spotify client, is there? Maybe I should break out my mp3 collection again... I'm trying to think of what else I'd really need to not need a GUI machine for my day to day. Maybe email?
Lynx and other tui browsers are not usable on today's web. Maybe there's a subculture to find somewhere that also appreciates reader-mode / lack of javascript?
If so anyone please lead me to the promise land!