salamander014

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?

If so anyone please lead me to the promise land!

This so much.

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.

This is why core principals matter so much.

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.

So this is a config standard for the infrastructure underneath something like remote vscode / devcontainers?

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.

Thanks for the info.

So, I know very little about this devcontainer spec.

Can I just ask, what value does this spec provide that a simple docker image containing the necessary tools does not already provide?

Why do we need another layer on top? What am I missing?

Historically, C compilers attempted to build the list of all symbols in one pass of the files.

Sometimes, functions may call other functions in the same code file.

This required that functions be declared before they are referenced so C knew it existed.

You can also see this on lines 84-92.

I’ve done this to automate and… err…

“template”

multiline string values back into valid yaml for proper indenting.

Works great, the issue is explaining to anybody why it was necessary, they understand it works but plead for a better way.

It’s one of those clever solutions that seems overcomplicated until you try to replace it and realize it’s actually quite elegant.

Hey this is very cool.

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.

Are you me?

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.

My wife has a 2022 VW.

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.

I’ve suggested that we don’t purchase another VW.

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.

For folks who aren't aware, Ben Eater has a great channel on Youtube also based on the 6502.

Basically, build a computer from literal spare ICs. Every video is nearly a chapter out of a CE / EE encyclopedia. Worth every second watching.

https://eater.net/

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.

Real programmers leave for more pay before somebody asked about backups.

I think people are missing the forest for the trees with this.

In my view, the reason Docker has all the hype is because I can look at a Dockerfile, and know what's up. In seconds. Sometimes in milliseconds.

It's a user experience thing. Yes, Nix is better for 'technical people that spent the time learning the tool', but Dockerfiles rely almost entirely on existing System knowledge.

Yes, Nix is 'better', but the fact is Docker is 'good enough' and also 'stupid simple' to get started.

Also Docker-Compose, I don't know why people hate on YAML. But it takes that same KISS attitude to build complex systems that can also be used as sanity checks for migrating to things like kubernetes.

Being able to spin up a complex full stack app with one command and a compose file that doesn't take any brain cells to read is worth it's weight in gold.

This is like the 'general case tool' vs 'DSL' debate. If it's easy to use, people will use it.

From a quick skim of the PRs, it looks like OP was using CString everywhere, and messing with pointers in unsafe blocks, called from safe blocks of code.

Generally speaking, these 2 things alone are basic errors when coding proper Rust. There were also many minor issues with the PRs that it seems the maintainers attempted to work through with OP.

Unfortunately learning the basics of a language like Rust is hard. Learning how to write correct Rust is even harder (and sometimes impossible without the right background knowledge). Learning how a project expects PRs to be designed and formatted is less technical, but takes dedication and time.

These PRs are riddled with things that are just straight incorrect.

Also, generally you are right about beginners starting with easier projects like this, but as many others in these comments have stated, the general bar is not low. Projects decide how to manage PRs. Nobody is stopping you from creating a terminal emulator in Rust that caters to beginners in Open Source. My guess is that the project would not be as good as Alacritty.

Also, the maintainers of any open source project don't owe you or anyone (including contributors) anything.

The fact is, most people can't write bug free code, that is also maintainable. It's a skill that takes years to hone. Even someone that is smart enough to understand all possible code paths and can prove it is bug free, doesn't automatically mean the code is written in a way that is easy to maintain.

Also, open source goes both ways. Anyone can submit, but maintainers can deny. Their project, their right.

Please remember, the bar has been set this high by successful projects.

One of the reasons Linux became the world's most used OS kernel was because of the high standard Linus maintained for his project. (Not saying I agree with his colorful word choices, but in my opinion most of the time he was 100% right about the PRs.)

That's why he calls himself benevolent dictator for life. The high standards must be maintained for the project to continue to be successful.

Mine uses pandoc and core utils to convert markdown to html and shoves it into an existing page template to create a blog post.

I could add menu / link tracking pretty easily but I don't need it. My script is less than 15 lines long and can convert any number of markdown files into their own pages on my site, ready to serve.

I agree. I like the idea of visualizing previous item in some way, maybe faded instead? Should give the same effect.

That entire industry needs a level of reliability several orders of magnitude more than any other industry. They couldn't redeploy servers even if they wanted to. I'm by no means an expert Space Systems Engineer. But any NASA technicians reading my original comment would probably agree with me in the general case. Space stuff certainly does not fall under the general case, because it's not possible.

Using physical hardware for as long as possible is absolutely the right mindset. For cost, reliability, environmental reasons, and many more.

This post was about an operating system (Software).

People shouldn't be using code that is no longer supported (support it yourself or don't use it, it's dangerous).

And people should be rebuilding their infrastructure from scratch as often as possible. That's the only way to prove you've built something reliable, auditable, and correct.

VMs and containers make that very easy and achievable for even the smallest of teams.

Linux goes to great lengths to support lots of different (and old) hardware. Linus has said many times, if you maintain it, it can stay.

In what use case is non-ephemeral IT infrastructure necessary?

Generally speaking I agree we need to force the rest of the industry into a more ephemeral mindset for infrastructure.

BUT this looks like it is only for ESM, which you need an Ubuntu Advantage subscription for.

If that's the case, then this makes sense. Let Canonical make some more money off those who are willing to pay, big enterprises are slow to do anything.

I've used the Open Weather Map API in the past (https://openweathermap.org/api).

It's free for a reasonable number of requests and has a solid API and a good variety of functionality.

Yours looks well designed! I will give it a shot if I ever need to revisit my local weather script.

Did you chose swift for any reason besides existing knowledge? Python can be compiled down to a binary pretty easily, along with many other languages. Just curious. Cheers.