I'm sure most of us have had to deal with issues reported by end users that we ourselves aren't able to reproduce
This video is an extended case study going through my thought process as I tried to track down and fix a mysterious performance regression which impacted a small subset of end users
I look at the impact of acquiring mutex locks across different threads, identifying hot paths by attaching to running processes, using state snapshot comparisons to avoid triggering hot paths unnecessarily, the memory implications of bounded vs unbounded channels, and much more
I updated my NixOS on WSL starter template for NixOS 24.05 and created a fresh walkthrough video.
WSL is how I first got started with NixOS (and now I use it to manage more servers and machines than I can keep track of!) and I'm a big proponent of being able to quickly spin up a simple flake with a relatively flat structure where people can play around with settings to come up with something they feel comfortable applying to a bare metal machine at a later point in time.
Hi friends, I develop and maintain the komorebi tiling window manager and have been posting live coding videos documenting its development for just over a year now.
I'm starting a new mini series on building a visual debugging gui tool to aid development on komorebi and especially to help with understanding some of the more esoteric edge cases and the interactions between the twm, user-defined rules and WinEvents.
I'll be building this from scratch using egui/eframe, so if you're interested in what building a non-trivial real-world immediate-mode gui and integrating with other (Rust, in this case) processes via IPC looks like, you'll probably get something out of this series.
Certainly, no contributors get into projects with the sole purpose to get a financial gain out of them. Open source has never been about money either. But for you as an author, the lack of funds to sustain your ideas and pay for even a small portion of the time you’re spending on them is—I&rsq...
Sharing some numbers on what people can realistically expect with GitHub Sponsors on a moderately popular project without any external / VC / corporate backing.
Yeah this is usually the way to go, I think I just got unlucky that this particular service on nixos-23.11 doesn't have a package override option (but it will have in nixos-24.x releases!)
A few weeks ago I ran nix flake update to get the latest versions of CLI tools that I regularly use from nixos-unstable. atuin is one of those tools which I started using relatively recently and quickly became a huge fan of. I run it on all of my machines, and I can’t overstate how amazing it ...
cross-posted from: https://lemmy.world/post/13113247
> After learning how to add an unstable overlay to nixpkgs, being able to override individual service modules from unstable was something that I still struggled with until fairly recently. Hopefully this helps someone else looking to do common-but-not-very-obvious operation.
A few weeks ago I ran nix flake update to get the latest versions of CLI tools that I regularly use from nixos-unstable. atuin is one of those tools which I started using relatively recently and quickly became a huge fan of. I run it on all of my machines, and I can’t overstate how amazing it ...
After learning how to add an unstable overlay to nixpkgs, being able to override individual service modules from unstable was something that I still struggled with until fairly recently. Hopefully this helps someone else looking to do common-but-not-very-obvious operation.
In this video I discuss the trade-offs of building on top of unstable reverse-engineered private APIs, why I decided against it, and compare to similar software that chose to use them.
A couple of people who aren't particularly interested in the software itself told me that this was an interesting and engaging video on general programming approaches when building applications for closed-source systems, so I thought I'd share it a bit more widely here.
In the previous article we walked through how to set up our very own Nix binary cache. It’s great being able to run attic push system /run/current-system on whichever machine we are currently using, but the the chances are that if you use Nix to manage your system configurations, you have a system c...
Thanks for the kind words :) Sent you a message 🤞
Thank you! Though please keep in mind this part of the README 😅
While Satounki is currently in a functional state, there are no documented steps for deployment and I don't recommend that anyone use this software for anything mission-critical just yet.
Depending on how badly my current job search goes (lol) I'm hoping to have this in an easily deploy-able format for both NixOS and Kubernetes, but it's not too difficult to get up and deployed if you follow the development instructions and provision the credentials in the relevant places 🤞
tl;dr all the same caveats with self-hosted software apply; don't do anything you wouldn't do with a self hosted database or monitoring stack.
Well the actual rules — who gets access to what
The rules themselves are the same public rules in the IAM docs on AWS, GCP etc., while the collections of these public rules (eg. the storage_analytics_ro example in the README) defined at the org level will likely be stored in two ways: 1) in a (presumably private) infra-as-code repo most probably using the Terraform provider or a future Pulumi provider, 2) the data store backing the service which I talk about more below.
"Who received access to what" is something that is tracked in the runtime logs and audit logs, but as this is a temporary elevated access management solution where anyone who is given access to the service can make a request that can be approved or denied, this is not the right place or tool for a general long-lived least-privilege mapping of "this rule => this person/this whole team".
where is that stored and how is it secured, to what standards?
This is largely up to the the team responsible for the implementation and maintenance, just like it would be for a self-hosted monitoring stack like Prom + Grafana or a self-hosted PostgreSQL instance; you can have your data exposed through public IPs, FQDNs and buckets with PostgreSQL or Prom + Grafana, or you can have them completely locked down and only available through a private network, and the same applies with Satounki.
Is there logging, audit, non-repudiation, tamper-proof, time-stamping etc.
Yes, yes, yes, yes and yes, though the degree of confidence in each of these depends to some degree on the competence of the people responsible for the implementation and the maintenance of the service as is the case with all things self-hosted.
If deployed in an organization which doesn't adhere to at least a basic least-privilege permissions approach, there is nothing stopping a bad internal actor with Administrator permissions wherever this is deployed from opening up the database directly and making whatever malicious changes they want.
What sort of sensitive data are you imagining in your reading of the README? It would be useful to understand to update the language appropriately 🙏
Temporary elevated access management as a self-hosted service - GitHub - LGUG2Z/satounki: Temporary elevated access management as a self-hosted service
cross-posted from: https://lemmy.world/post/9143654
> Apologies in advance for sharing two link posts here two days in a row. Unemployment may be driving me a little nuts... 😅 > > I've been working on Satounki since I got laid off last month. It's the culmination of a lot of experience building similar ad-hoc internal tooling at various places throughout my professional career. > > Satounki already includes: > > * AWS support > * GCP support > * Cloudflare support > * Auto-generated Terraform providers from the Rust API > * Auto-generated Typescript client wrapper from the Rust API > * Slack bot for request notifications, approvals and rejections > * CLI for requests, approvals and rejections > * Dashboard for exploring policies, requests and stats > > The scope of this project is pretty big and I'm looking for contributors. > > The majority of the project is written in Rust, including the generated Go and TS code. The stack is pretty simple; Actix, Diesel, SQLite, Tera etc., so if you have experience with writing web apps in Rust it should feel familiar! > > Even if this is a totally new stack to you, this is a great project to develop some familiarity and experience with it, especially if you can help improve the quality of the generated Go and TS code at the same time!
Temporary elevated access management as a self-hosted service - GitHub - LGUG2Z/satounki: Temporary elevated access management as a self-hosted service
cross-posted from: https://lemmy.world/post/9143654
> Apologies in advance for sharing two link posts here two days in a row. Unemployment may be driving me a little nuts... 😅 > > I've been working on Satounki since I got laid off last month. It's the culmination of a lot of experience building similar ad-hoc internal tooling at various places throughout my professional career. > > Satounki already includes: > > * AWS support > * GCP support > * Cloudflare support > * Auto-generated Terraform providers from the Rust API > * Auto-generated Typescript client wrapper from the Rust API > * Slack bot for request notifications, approvals and rejections > * CLI for requests, approvals and rejections > * Dashboard for exploring policies, requests and stats > > The scope of this project is pretty big and I'm looking for contributors. > > The majority of the project is written in Rust, including the generated Go and TS code. The stack is pretty simple; Actix, Diesel, SQLite, Tera etc., so if you have experience with writing web apps in Rust it should feel familiar! > > Even if this is a totally new stack to you, this is a great project to develop some familiarity and experience with it, especially if you can help improve the quality of the generated Go and TS code at the same time!
Temporary elevated access management as a self-hosted service - GitHub - LGUG2Z/satounki: Temporary elevated access management as a self-hosted service
Apologies in advance for sharing two link posts here two days in a row. Unemployment may be driving me a little nuts... 😅
I've been working on Satounki since I got laid off last month. It's the culmination of a lot of experience building similar ad-hoc internal tooling at various places throughout my professional career.
Satounki already includes:
- AWS support
- GCP support
- Cloudflare support
- Auto-generated Terraform providers from the Rust API
- Auto-generated Typescript client wrapper from the Rust API
- Slack bot for request notifications, approvals and rejections
- CLI for requests, approvals and rejections
- Dashboard for exploring policies, requests and stats
The scope of this project is pretty big and I'm looking for contributors.
The majority of the project is written in Rust, including the generated Go and TS code. The stack is pretty simple; Actix, Diesel, SQLite, Tera etc., so if you have experience with writing web apps in Rust it should feel familiar!
Even if this is a totally new stack to you, this is a great project to develop some familiarity and experience with it, especially if you can help improve the quality of the generated Go and TS code at the same time!
Thanks! Turns out I have a lot more time on my hands to be found around the internet since I got laid off last month 😅
This (Windows employing different methods to prevent users from writing programs that programmatically change application focus) has been an ongoing struggle for me for the better part of 3 years.
I finally made what feels like some significant progress this past week.
If you've ever obsessively gone deep down into a hole trying to understand and wrangle weird OS-level behaviors before, you might enjoy this video and feel a vicarious sense of victory :)
This looks cool! It's not packaged on nixpkgs yet so I might package it and then try to selfhost 👀
I wish I had more advice, but I'm in a similar boat, just got laid off earlier this month after being with the same company from Series A in 2018 all the way until today. I'm sending job applications and trying to get interviews, but it's hard to get past the resume screening stage, even with 8+ years of experience.
I've mainly been working in DevOps/SRE/Platform Infrastructure, but I am also an accomplished developer with a pretty thick portfolio of widely used open source projects, though it doesn't seem to matter.
There are so many applicants for every single job now that it feels hopeless, and of course every single opening wants you to waste your time on multiple asinine LeetCode gotcha questions.
If I lived somewhere with a public health system I'd love to take what money I have saved up and open a traditional middle eastern bakery, but I need to do something that will bring health coverage for myself and my family. Who knows, I might just end up working at Trader Joe's. 🤷♀
I got laid off this month and have a lot of time on my hands while I'm looking for new jobs 😅
I tried making a LinkTree but the website UI for editing is so janky and frustrating, and on top of that you have to go Premium for advanced theming, again in the janky UI...
I found this great Hugo theme called Lynx and built out my own links webpage like we did back in 90s on Geocities with Dreamweaver
Some folks on Mastodon and Twitter messaged me asking for a walkthrough because there are a few rough edges that are mostly related to changes between Hugo versions and the docs on the theme, so I made this end-to-end video going from project init to deployment on Cloudflare pages with analytics enabled
It's a pretty fun project and I think it can also be useful as a "portfolio links" page for people that are looking for jobs right now
It's not exactly a traditional RSS feed, but I run a feed of my highlights on all things related to software development, and I'm an experienced DevOps engineer so a lot of my highlights are coloured by that experience.
If you come across a highlight that is interesting you can click to go and read the whole source article or comment. You can check out a HTML version before you decide if you wanna subscribe to the RSS feed.
There are a number of different approaches available for NixOS users to handle secrets. The most popular tend to be git-crypt, agenix and sops-nix. But which one should you use? To hopefully help you in answering this question for yourself, here is an overview of a few common use cases and what I th...
cross-posted from: https://lemmy.world/post/8269080
> Someone on another website asked me whether it makes sense to use agenix or sops-nix to encrypt secrets for NixOS configurations.
>
> I realized that I hadn't seen a good overview article of the different approaches to secret handling in NixOS and when each one is appropriate to use, so I put down all of my knowledge and opinions in this post 🤞
>
There are a number of different approaches available for NixOS users to handle secrets. The most popular tend to be git-crypt, agenix and sops-nix. But which one should you use? To hopefully help you in answering this question for yourself, here is an overview of a few common use cases and what I th...
Someone on another website asked me whether it makes sense to use agenix or sops-nix to encrypt secrets for NixOS configurations.
I realized that I hadn't seen a good overview article of the different approaches to secret handling in NixOS and when each one is appropriate to use, so I put down all of my knowledge and opinions in this post 🤞
In my last post, I shared how to get a working instance of Nitter deployed on NixOS, but requested advice on how to best automatically provision the guest_accounts.json runtime secret file on the target server. A number of folks reached out to me on Mastodon (thanks @vt52@ioc.exchange, @aynish@merve...
With all of the various user and developer hostile changes introduced to Twitter over the past year, the importance of a user-friendly alternative frontend for Twitter is greater than ever. After using public instances of Nitter for a while, I wanted to try hosting my own instance. I thought it woul...
It currently requires some extra steps to get Nitter up and running on NixOS as I found out yesterday. I documented the process for anyone else who might be looking to run their own Nitter instance between now and the trunk branch of Nitter being functional again.
I think it's a stack that really pays off in the long run for solo projects. After a long week of work the last thing I want to do is go tracking down runtime errors (undefined is not a function, my old friend) or messing around with Docker containers and Kubernetes clusters. It also doesn't hurt that once you throw away the costly deployment abstractions, the operating expenses turn out to be a lot cheaper.
The social media landscape from Twitter and Mastodon to Instagram and TikTok has, for better or worse, centralized on sharing text highlights and quotes as images rather than as plain text. Now I can share my highlights easily as images on social media! I like to share my highlights from across the ...
Found some time this past weekend to work on a little "passion feature" that I've been wanting to implement for a while now; sharing the technical write-up for anyone else who is interested in automating headless screenshots with these tools or with others (the knowledge is pretty transferable!)
The whole point is that you can build a working container image and then ship it to a registry (including private registries) so that your other developers/users/etc don’t have to build them and can just run the existing image.
Agreed, we still do this in the areas where we use Docker at day job.
I think the mileage with this approach can vary depending on the languages in use and the velocity of feature iteration (ie. if the company is still tweaking product-market fit, pivoting to a new vertical, etc.).
I've lost count of the number of times where a team decides they need to npm install something with a heavy node-gyp step to build native modules which require yet another obscure system dependency that is not in the base layer. 😅
We all use Linux on our workstations and laptops. That might make it easier.
You are living my dream!
I think this is the key piece; the experience of Docker on Linux (including WSL if it's not hooking into Docker Desktop on Windows) and on macOS is just so wildly difference when it comes to performance, reliability and stability.
Thanks for sharing this! Added to my weekend inspiration/reading pile. 🙏
Highly recommended viewing if you'd like to learn more about the limits of reproducibility in the Docker ecosystem.
Tutorial != advocation. As I said, no attempt to engage in good faith.
I understood your point, and while there are situations where it can be optional, in a context and scale of hundreds of developers, who mostly don't have any real docker knowledge, and who work almost exclusively on macOS, let alone enough to set up and maintain alternatives to Docker Desktop, the only practical option becomes to pay the licensing fees to enable the path of least resistance.
Lot's of (incorrect) assumptions here and generally a very poorly worded post that doesn't make any attempt to engage in good faith. These are the reasons for what I believe is my very first down-vote of a comment on Lemmy.
NixOS on WSL2 is actually my development environment of choice these days! (With my tiling window manager komorebi, of course! 😀)
I believe this is the Docker Desktop license pricing.
On an individual scale and even some smaller startup scales, things are a little bit different (you qualify for the free tier, everyone you work with is able to debug off-the-beaten-path Docker errors, knowledge about fixes is quick and easy to disseminate, etc.), but the context of this article and the thread on Mastodon that spawned it was a "unicorn" company with an engineering org comprised of hundreds of developers.
Hi!
First I'd like to clarify that I'm not "anti-container/Docker". 😅
There is a lot of discussion on this article (with my comments!) going on over at Tildes. I don't wanna copy-paste everything from there, but I'll share the first main response I gave to someone who had very similar feedback to kick-start some discussion on those points here as well:
Some high level points on the "why":
-
Reproducibility: Docker builds are not reproducible, and especially in a company with more than a handful of developers, it's nice not to have to worry about a
docker buildcommand in the on-boarding docs failing inexplicably (from the POV of the regular joe developer) from one day to the next -
Cost: Docker licenses for most companies now cost $9/user/month (minimum of 5 seats required) - this is very steep for something that doesn't guarantee reproducibility and has poor performance to boot (see below)
-
Performance: Docker performance on macOS (and Windows), especially storage mount performance remains poor; this is even more acutely felt when working with languages like Node where the dependencies are file-count heavy. Sure, you could just issue everyone Linux laptops, but these days hiring is hard enough without shooting yourself in the foot by not providing a recent MBP to new devs by default
I think it's also worth drawing a line between containers as a local development tool and containers as a deployment artifact, as the above points don't really apply to the latter.