syhol

The radio caroline of git hosting

The word "open" has lost all meaning

> What exactly do you want?

1. I want it to be easy for developers to publish their own packages. 2. I want it to be easy for users to install these developer-published packages.

> Are you saying they're not "professional"?

I regret using the word professional, I was replying to the claim GP made:

> Packaging it for a distro is someone else's job

Well I (as a developer) want to publish my own software without waiting and hoping someone else will do it for me.

> Somebody has to do the work.

Yes, I (the developer) want to do the work. The whole point of the article is that its painful to do today. I'm interested in how we make the packaging work easier so the developers can do it.

> [...] So third parties

the whole 3rd/1st party question is whether a developer can publish their own package. In most cases they technically can (taps, PRs, flathub, Debian registries, so on) but run into lots of issues along the way.

This isn't a good dichotomy though. Either "Build it from source" or "Wait for a professional 3rd party to package it for you".

The idea that your OS distro needs to explicitly support and package every software you could ever want to use seems crazy to me.

Both users and authors want the same thing: low-effort, high-quality distribution of software.

Personally I put my support behind flatpak for GUI, mise for CLI/TUI, but it's not a perfect solution and I occasionally bail out to homebrew/linuxbrew.

OLED screens are famous for having great contrast, especially deep blacks. The website is in the style of a 90's geocities website with garish colours and some absolute black #000000 backgrounds.

Most people would have seen those websites on shitty low contrast CRT monitors, so seeing them again today with a modern OLED is a very different experience.

Or get the best of both worlds, use a monorepo with microservices.

I'm very excited by this idea. I feel like email/chat is ripe for reinvention.

I don't agree with "Domain control as a fallback", as the author said "a domain is not owned, it is rented" and I want to normalise the idea that if you lose your private key, you need to start again. I hate that we keep giving so much authority to domains, it's such a big weakness. The author even left the key rotation chain out of the initial implementation.

I still think root/signer keys or sigchains are decent options.

Looks very good and I'm excited to try it out properly. It's a shame about the name considering a lot of self-hosters will be using BentoPDF. But thats one of two hard things in Computer Science.

It's an exciting time for binface. The anti-reform vote may be strong enough that we end up with an MP from Sigma IX. Wild.

It's just a choice of stability https://vanillaos.org/blog/article/2023-01-31/point-vs-rolli...

We love/help/replace you

To UK oldies it probably reminds them of the sitcom Open All Hours with Ronnie Barker.

> So far

Someone's optimistic

Great topic and message. But the AI-generated writing really gets under my skin. It's not painful. Not unclear. Just really annoying.

- Thunderbolt 3 is a superset of USB 3.1

- USB4 is built on Thunderbolt 3's protocol, implementing a subset of its mandatory features

- Thunderbolt 4 is a strict profile of USB4 (all optional features made mandatory)

- USB4 v2 introduced 80 Gbps signaling

- Thunderbolt 5 is a strict profile of USB4 v2 (again, optional features made mandatory)

https://pi.dev/ seems popular, whats not open source about opencode? The repo has an MIT License.

> Many popular tools are much more complex to install

I'm curious which dev tools you're using aren't installable with standard mise backends. 99% of dev tools I use don't require a plugin.

> (more painful than, say, an asdf plugin)

You can still use asdf plugins, I could use mise to install an asdf plugin right now with one line `mise use asdf:raimon49/asdf-hurl`. The mise registry is just a convenient list of aliases, even if it doesn't accept new asdf plugins, you don't need it to.

As Larry Wall said "make easy things easy and hard things possible"

There is a good chunk of overlap but mise predominately pulls from github releases artifacts/assets and pixi uses conda packages. While mise can use conda packages, the mise-conda backend is still experimental. I don't think github releases or conda packages are better than the other, they both have tradeoffs.

Pixi is very python focused, it's both a tool manager and a library dependency manager (see uv/pip). Mise considered library dependency an anti-goal for a long time, while I don't see that on the website anymore I haven't seen any movement to go into that space.

You start with the cleanest most minimal config you can get away with, but over the years you keep adding small additions and tweaks until it becomes a massive behemoth that only you will ever understand the reasoning behind.

Like deno sandbox https://deno.com/deploy/sandbox

Do these scripts need to be productionised? I prefer working in an environment where efficient sharing of knowledge and solutions is encouraged, rather than framed as a burden of responsibility.

Given the choice between starting with an almost-working script or starting from scratch, I’ll take the former, it might save a few hours.

My colleagues and I don’t do this 100% of the time, but I never regret it and always appreciate it when others do.

My gut reaction is to rush to the comments to shill my favourite task runner ( mise tasks[1], now with shell aliases[2]!) but pushing past that, the core idea of writing scripts in a file rather than a shell prompt is a great nugget of wisdom. But I disagree with this bit:

"I want to be clear here, I am not advocating writing “proper” scripts, just capturing your interactive, ad-hoc command to a persistent file."

What's the difference? Why not version control it, share it with colleagues. Imagine writing a unit test to test a new feature then deleting it when done, what a waste. Ok it's not exactly the same because you aren't using these scripts to catch regressions, but all of that useful learning and context can be reused.

I don't think the language you use for scripting is too important as long as the runtime is pinned and easily available on all engineers machines, perhaps using a toolchain manager like... mise[3].

[1] https://mise.jdx.dev/tasks/ [2] https://mise.jdx.dev/shell-aliases.html [3] https://mise.jdx.dev/dev-tools/

My main problem with matrix is that it feels sluggish. I'm told the experience can be improved by running your own homeserver so I'll be trying that sometime this year.

Mise started out using the same plugins as asdf, mostly focused on adding performance and usability improvements. Over time it added more features and security.

Most tools are now directly fetched from github releases without the need for random shell scripts (which is what asdf plugins are).

It also grew to be a task runner and environment manager. At first you might think this is scope creep but they're both opt in and very elegant additions. I don't want to ramble but let's just say they've solved real problems I've had.

I'm a fan of it, and I can't think of a reason why I would use asdf over mise. Its real competition is nix (+devbox/devenv/flox), devcontainers, and pixi.

Learn x in y is always my goto: https://learnxinyminutes.com/lua/

Frontend churn has chilled out so much over the last few years. The default webapp stack today has been the same for 5 years now, next.js (9yo) react (12yo) tailwind (8yo) postgres (36yo). I'm not endorsing this stack, it just seems to be the norm now.

Compare that to what we had in the late 00's and early 10's we went through prototype -> mootools -> jquery -> backbone -> angularjs -> ember -> react, all in about 6 years. Thats a new recommended framework every year. If you want to complain about fads and churn, hop on over to AI development, they have plenty.

have you tried lazyjj? I was thinking about giving it a go.

I've been fighting the git CLI for over a decade and I've recently picked up lazygit so I can relate to this post. A good TUI has made git a joy to use and when I did try to pick up jj last year it seems like too much learning for too little gain.

I think git will be "good enough" version control for many years to come.

HOCON is so overlooked but an almost ideal config language in my eyes. The only element I'm not 100% on is unquoted string values (the norway problem but not quite as bad since there isn't no/yes booleans), but even thats not too bad.

A passkey import/export standard is in the works. Once I know I can backup everything in a keepass database I'll be much happier.