I'm trying nix instead of Homebrew on my mac. It worked great until I decided to give rust a shot. I think my solution is to just do rust development on my Arch machine and stick with nix. That said, if I run into additional issues, I will probably just go back to Homebrew.
from the top of my head: various hacks to make apps available to spotlight, packages/apps behind their equivalents in brew to the point where I use nix to orchestrate brew for
too many things, starting envs and build switch is too slow for my taste despite caching etc, nix the language is unfriendly and hard to debug, the stack traces are useless, etc
Yes, I've gone through every style of dotfile management. Stow, bare git repo, custom script, and now nix with home-manager. Using Nix is definitely the best solution so far, largely because not only does it manage the configurations, but also installs the programs you need.
The one thing that makes me hesitate with nix is that it only really supports Linux and Darwin; of the BSDs only FreeBSD has any support (somewhat suboptimal still), and AIUI Windows is also unsupported.
disagree, it is a good keyboard but the thumb cluster is not ergonomic. There is better, especially if you are up to build one yourself with a kit. Otherwise the voyager is already an improvement over the moonlander.
I really like the idea! At some point I put up a miniflux instance and it has surprisingly been a breath of fresh air for my content consumption. What miniflux and my setup lacks is a way to retrieve stuff I read and this OpenOrb might fit the use case... I will try it out!
sometimes I stumble
into stuff I’m sure I’ve already read something about in an article but if I didn’t bookmarked or made a note of it it’s very hard to find again (miniflux flushes content after a certain age)
You can set the age to arbitrary points in the past, if storage isn't a concern. I've actually found miniflux's search feature fairly solid for dredging up old stuff I've read!
Ah, I see, thanks for the explanation! I'm asking because I'm working on a similar project, which allows to both search and save blog posts permanently.
Speaking for me personally, I've always felt "search my history" should be implemented in the browser, not as an external tool. "Search and save blog posts" seems like a subset of the real problem.
I don't understand why Github does not invest more into Dependabot. Everyone need something like this, and Github is positioned to offer the best sca tool there is. And yet... stuff like grouping has only been recently added.
I've been dumbfounded that GH hasn't invested in the space. There's tons of obvious surface area still available for automation.
A one-off project of mine tries to improve supply-chain license management for projects [1]. I got bit once by an MIT licensed project that accidentally took a GPL dependency a couple versions later. That was a pain to notice without analyzing transitive dependencies. Never again.
GitHub has the advantage of a low barrier to entry for their tools. A lot of their features are inferior to special-purpose tools, but they can expect high usage because a lot of users shrug and live with it.
Would you like to spell them out? It's not exactly clear if you're thinking of the same ideas as other people, a conspiracy to take over the world, or something in between.
Last time I tried (which is >2y ago, so things might have improved), dependabot seemed like an afterthought for GitHub.
For example, at some point GitHub introduced a change that prevented CI builds triggered by forks from accessing secrets in CI variables. This made sense from a security perspective (although I would have a preferred a hard failure instead of variables silently being set to empty), but it also applied to all Dependabot PRs, which I have to assume wasn't intended behaviour. It really seemed like different teams at GitHub weren't talking to each other. An issue was opened about this and got quite heated, but wasn't really resolved (except for some ugly workarounds) before it was locked for becoming too uncivil.
Your read on the situation is spot on, and no, it doesn't look like it's been "fixed" (mostly because "fixing it would re-introduce the same potential vulnerability).
I think it would be possible to fix it properly and without security risk by allowing pipeline authors to allowlist dependabot and/or specific forks for accessing secrets.
I just want to be able to browse the dependencies of my repo with a web UI. Show me a tree of dependencies in my repo, filter for ones that are outdated, expand them to show what would be in a dependabot PR (the keen description it generates that contains all the release info and links to changelogs and whatnot). Then let me open a PR (or tell dependabot to do so) with the click of a button, or ignore it with another.
The current workflow where dependabot just spams an endless stream of PRs is not optimal. I don't need any new features from dependabot, I just want a better UI.
Fastmail is a smaller company, focused on email and calendars, but it does it well and you’re unlikely to be subject to random algorithm nukes and having to sit through the nonexistent Google support channels.
The more folk that get out of Gmail the better. Google has too much power there, and controls your entire online life by controlling your email. I’ve seen so many folks have their online lives nuked when Google didn’t like something for no real reason, then refusing to help fix it.
Fastmail does also have contacts within their portfolio and you can manage own (static) websites with their service. They do really have a great feature set.
They're the developers of JMAP (with great features for now and in future), they do have Masked Mails built-in and much more.
I’ll probably use something dumber for the next machine, and keep nix for servers and local vms.
reply