asdjlkadsjklads

We used NixOps for a while. Small company (<100, >20), with lots of client deployments on prod and various pre-prod environments as well. NixOps worked well enough, and i never heard complaints about it. Though i wasn't in the trenches with it personally.

Our problem was hiring for it. Ultimately we ended up moving away from NixOps and into more Kube/AWS solutions to provide this basic orchestration. Unlike a lot of Kube talk, it isn't entirely overkill for us - but NixOps worked just fine, and is probably better for us. We just didn't have Ops with enough knowledge in Nix to properly exploit Nix to easily achieve our goals. Nothing was easy.

With Kube/AWS though a lot of hiring decisions were dead easy and bringing people on who knew it was dead simple. As much as i'd prefer to be on Nix, reducing decision fatigue is at least nice.

In this case i'd say yes. It's a DB purposefully written for learning, with good references and documentation.

However if it was just another DB.. especially one competing in an area no one really feels deficient, prob not.

Okay i wasn't interested in the `less` usage in the GP comment because i use tmux to stop and view logs as they're passing by. However automatically opening in my CLI editor? That sounds sexy as hell!

Couldn't agree more. The only reason i'd call myself employable as a developer is because i've taken on many self-projects and reinvented many wheels, which resulted in lots of sharp corners and hard lessons learned.

It's a definite time sink to learn these lessons, but it's of real value to me personally.

Losing, but still buying in.

Agreed, but only one party there is supposed to be working in your interest.

It's why i'm pro-big-government, but also very heavy handed about what i want to see with government transparency and power dynamics.

heh, makes me want to go to a code camp now. I've got ~7 years professional(?), ~11 years hobby, experience at two medium sized companies. Spent my years reinventing a ton of things, and know a fair amount of oddities on how to get things done. Combine that with a passion for idiomatic, standards, maintainable code and .. i think i'd be a decent hire.

(Primary experience through the years in: Rust (current), Go, Python, JavaScript(Node/etc).

Yet. I don't think i'd pass a single interview. I really need to learn the fundamentals i need for those interviews. Feels like a liability at this point.

I'm writing a git-like, so i'm curious your thoughts on this. What would undo, do exactly?

Eg would it make a new commit, reverting the previous? Would it undo the last commit, dropping it from history? Would it undo the last commit, putting the contents into staging/unchecked?

My git-like is for structured data and is very very different from git. Conceptually though, it's similar in that it's a hash tree of content addresses. So it'll conceptually suffer the same problems, if i wanted it to.

My plan, due to the nature of the project, is to for the most part avoid conflicts and be more forgiving in the primary flows. This makes sense (imo) because the nature of the application is about data retention moreso than it is strictly VCS. It just has VCS fundamentals to reach into, should they be needed.

But as i dive into the primary user flow - it feels like there are always a few cases that seem primary. Undo is a great example - making a new commit (revert), undoing the last and dropping it (hard reset), and undoing the last into staging all seem like primary UXs.

A lot of Git feels like the primary UX. I struggle to think of single concepts, like your undo example, where a simple path will be right to the user 90% of the time.

Thoughts?

What's going to be in 5.11?

PASETO looks interesting, thank you!

Since my primary concern is external client APIs communicating with ours securely, but also in a way that's not too-foreign. I imagine JWT would fit the bill of being widely known, but PASETO sounds really interesting too - having less things to get wrong sounds amazing. My concern with PASETO is that client APIs are huge slow customers, so i'm hesitant to choose anything that's not super mainstream.

I'll research PASETO more, but i feel like my decision would come down to fitting to what the customer can use - less change is more, in that case. Ie, JWT.

> first off: the whole idea of using oauth in your systems is to externalize authentication. its main usecase is if you have several services which share the same users... usually microservices, but everything else which supports oauth works as well, obviously

We don't want to externalize it. For clarity _(because i think i implied internal API->API)_, our primary concern right now is a client API interfacing with our API. We want to choose some implementation that clients would expect, and easily reason about.

There may be a future where those clients have to authenticate to multiple APIs / microservices of ours, but currently it is one API setup for this explicit purpose.

> but to come back to my initial point: if you do not want to externalize your authentication, then do not use oauth! almost all frameworks already have tools available you can use to authenticate with api tokens.

Yea, not using Oauth was my thought was well. My concern however, was trying to pick something clients would expect. I don't want it to feel custom, arbitrary, hodgepodge.

Our very early impression / plan is to use a token renewal, and a shortlived token, similar to oauth. However this loose, and custom, and i don't want clients feeling like we're making things up. Hell, i don't want to make things up.

My current thought is that I need to research JWT more, as it may fit what we need, and be more standardized.

edit: And PASETO

Interesting article. On this note, recently as part of small group of people we needed to implement API -> API authentication. Unfortunately, we don't have anyone who has solely implemented this before, so we took to searching to try and pick something resembling industry standards. Of course Oauth 2 got brought up, however the spec and articles on it seem bizarrely out of sync with out needs. Notably on two points:

1. It seems any piece of content talking about Oauth 2 is referring to 3rd party, external authentication. Ie i want a client API to talk to my API but with an identity managed by a third party entirely. This is not our use case, but seems to be the primary focus for Oauth 2 articles.

2. The rest of the spec _feels_ very loose for our use case. There's loose definitions _(it feels like)_ on some basic patterns of tokens and renewal tokens, but it all seems so wildly flexible that we're almost lost on what to actually write, what technologies to use to generate tokens, etc.

Any tips for narrowing the field, to implement the right thing, in the right way? This article struck a chord with me.

> What if, instead of bowing to corporate greed which cares not a bit for our country or our people, we actually invested in our own population and trained them to do the jobs H1-B workers currently do.

Wishful thinking under the current administration.

> Think of special pronouns as names. All the etiquette we have surrounding names apply equally to pronouns.

I'm bad with names, too.

Sometimes i consider myself lucky that i don't know anyone seeking special pronouns - because i imagine i would repeatedly use what i visually see, not what they request.

These days i seek to find a gender neutral word i can get into the habit of using (it, or they, or something similar), for fear of mis-nouning someone. Though, i also have the fear that if i use something neutral, when someone requested a specific non-neutral pronoun, i may be negatively impacted.

As someone "on the spectrum" social norms are already difficult. All of this talk just makes me nervous.

This feels pedantic and totally besides the point.

The author was describing "gets all users" as in, gets all users that Apple can get. What's next, would you point out how people in the 3rd world wouldn't be buying Apple/Google phones either?

The point was, when Apple has all of the market share they can expect to get, will they turn around and flip tracking on and etc.

Please don't deviate topics for solely pedantic reasons. I generally love pedantic distinctions, but this i think added little to no value.

Yea, this whole discussion feels weird to me. Different use cases. I love Rust (and dislike Py lol), but from everything i hear a highly dynamic frontend (like Py) has little downsides to authors of ML/etc. All of the hotpaths are in other already because Python is so slow.

The only downside i've seen is sometimes the programmer will want more safety. In such a scenario Rust for the "frontend" would be very useful.

So we have two concerns, frontend and backend. For the backend Rust would perfectly acceptable, but i'm not sure it is fixing a safety issue/etc in other (C/etc) languages - aka, perhaps little value in the backend. For the frontend it only has value in some areas.

Regardless, i love Rust and would totally welcome any tooling to keep me in Rust. However i'm not an ML person hah.

Cool! I wanted to do similar things, neat idea. These days i'm wanting to try something similar but with a nice UI - i'm so tired of the Terminal, but it's hard to get away because editors like Kakoune and Vim are just so powerful.

My wish is that you or I (if i ever have the time) will implement something like this onto XiEditor. Ie, implement this as a feature to a lower level editor backend, so that you get the frontends "for free".

It drives me nuts that there's so much work done for the frontend side of things, but the backend of editors are being reinvented repeatedly for little gain.

I hope Xi can make a performant, hackable backend to plug into solid frontends.

> If the price was the only problem, you'd still expect to see people playing draft regularly, at least in the interim, especially since there are free drafts you can play. But there's more wrong with this game than just how they priced it.

Fwiw, price _was_ my only problem and i still stopped playing. Why? Because it felt the game's intentions differed from mine. It felt like the game was trying to be Magic, where as i just wanted to play a card-dota game - not invest in some market, continually buying packs, etc.

In addition to this, the drama and complaints surrounding the market also made me feel like the game was doomed for failure. And the type of game it was made me not want to play it if it died (unlike a single player game, where i'd happily play regardless of other people).

Just my 2c / context.

Interesting! On that note, is there a service like this to request drawings not from photos? Maybe with early sketch phases to suss out the specifics before committing to the final iteration?

I've got some work i've been wanting to commission, but i'm not sure on where best to find an artist

/shrug, language matters to me. I like knowing what code i can interface with. Generally speaking, written in Go is a boon to me (as a Go dev obv), written in Python/Node/Ruby is a negative with runtime requirements for me.

I love new editors, but i have to ask every time - what is this one doing new?

I'd kill for new editors trying new and interesting methods of text (or code) navigation and editing, but so often i don't feel like i see... anything, new. The only one i can recall offhand is Kakoune, which is basically Vim-like but changes the verb order a bit. It's a nice attempt, i like it.

Yet with things like Atom, Xi, Xray, i don't get what they're doing special?

I totally get that focusing on easy plugins could be a major selling point. I'm not disputing that or ignoring it. I'm merely trying to.. well, i guess understand, why so many new editors pop up but don't try anything new. They just try.. speed, generally.

Am i alone here? I want more Kakounes of the world.