SourceHut Blog

It is why we decided [2] to exclude floats as map key in bare [1]. Go follows the standard. However, this creates an issue [3]. Indeed, NaN can map to an infinite number of values. These values cannot be accessed. +0 and -0 designates a unique key. JavaScript normalizes -0 to 0, and NaNs are normalized to a canonical NaN. This makes possible to use NaN as a key in a map. Other implementations could rely on binary comparison. This is a lot of pain to deal with. It is better to avoid float comparison or to restrict floats in some way. [1] https://baremessages.org [2] https://lists.sr.ht/~sircmpwn/public-inbox/%3CCAFFTG-a-Vci%2BkS_d_%3Du… [3] https://github.com/golang/go/issues/20660

I have round the D forum to be quite pleasant, although I don't really use it: https://forum.dlang.org/ But my favorite remains mailing lists with a web interface, like on sourcehut: https://lists.sr.ht/~sircmpwn/public-inbox. It's hard to beat it in terms of lightweightness

Nice move. Any will/energy to self-host instead of using sr.ht? https://man.sr.ht/packages.md lists Alpine Linux and Arch Linux as best distributions for Sourcehut, there's also Debian though the maintainer wants help https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C20210622200102.f36q6mod… , and NixOS, but the services part still needs more PR reviews: https://github.com/NixOS/nixpkgs/pull/133984 (full disclosure, I'm the author of this PR)

Yes, SourceHut mailing lists have public archives. Some examples from our official mailing lists: https://lists.sr.ht/~sircmpwn/sr.ht-dev https://lists.sr.ht/~sircmpwn/sr.ht-discuss https://lists.sr.ht/~sircmpwn/sr.ht-announce https://lists.sr.ht/~sircmpwn/sr.ht-ops Additionally, unlike GitHub, these discussions have been forwarded to all list subscribers, any of whom could trivially turn them into another public archive, independently of sourcehut. Such an archive is also available to list admins in one click for both export and import, in a standard file format. With DKIM and PGP signatures and such, you can even preserve the authenticity of these messages across arbitrary sources.

> https://lists.sr.ht/~sircmpwn/sr.ht-dev That's a multi-purpose mailing list, where I had to read for a couple of minutes to assume belongs to the whole project sr.ht instead of a specific repo (I trusted your response to mean this was an actual 1:1 replacement and that I missed it), and I had to go into one of the patches and find a link to an issue in the tracker, and from there I had to go to the main page of that issue's project, and from there I see there's an ad-hoc association between the tracker and the actual repo by a link in the description which I assume you added because you noticed that it's useful to associate issue trackers and repos. And that's just for finding one of the repos that mailing list covers. In the end, I still have to come up with custom filters to use to get only the patch requests for the specific repo I'm interested in, and assume everybody follows every single non-obvious instruction to the letter to make it all work. The whole experience feels like a grabbing a bunch of general purpose tools and trying to get them to work for the project's purpose as well as possible, because there is no solution that solves the problem in obvious ways that doesn't require learning and carefully following a bunch of ceremony without failure. Except in this case, there are such solutions, and I'd have to be a sadist to try to get coworkers to learn and follow every single convention to the letter when they have problems just working well with git in the…

Yes, and if you're able to use HTML tables then you should. HackerNews implements a particularly spartan flavour of MarkDown, so the 'ASCII art' approach is the only one available here. This is similar to how pre-wrapped text often looks terrible on mobile. This is an issue with plaintext email, for instance. [0] [0] https://lists.sr.ht/~sircmpwn/public-inbox/%3C87wo85l3c5.fsf%40codesec…

This[1] discussion from a month ago seems much less definitive. [1]: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3Cjwvfs5o9e0f.fsf-monnier…

Mailing lists don't have to suck or be unsearchable. See sourcehut: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/<000001d97d57$caca69b0$…

There was a discussion on sourcehut about making this change to their TOS, not sure what happened with it though https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CC32T7UNXIK7O.3QD7A1EJDI…

Yesterday, while reading about Hare, I discovered the problem this blog post alludes to (Hare's own module code just assumes if the hash for two modules was identical, they're the same module) and I reported it to Hare's developer list. https://lists.sr.ht/~sircmpwn/hare-dev/%3C20220503143516.19e61ad8%40to… I was sort of expecting Drew to... fix it? I mean, what you'd hope for is an updated blog post with a mea culpa in it, but I'm not setting my expectations so high. Fixing the bug seems like a pretty basic place to start though.

https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/27721 SourceHut does this since it exclusively uses mailing lists.

I tried a couple pages from SourceHut, which famously prides itself on its fast performance. The projects page (dynamic, changes with user activity on the site) https://sr.ht/projects: 100 A patch page https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/23162: 99 A source page https://git.sr.ht/~sircmpwn/pages.sr.ht/tree/master/item/server.go: 100 SourceHut often "feels" a bit slower in that the browser does a full navigation whenever you click, but the absolute time is definitely low and I applaud them from building such a fast (and accessible!) experience.

On my computer, I use aerc[1] with an extra patch to sign outgoing emails by default. I try to never check emails on my phone, but I do have an emergency mailbox which I use FairMail[3] to get notifications for. [1] https://aerc-mail.org/ [2] https://lists.sr.ht/~sircmpwn/aerc/patches/14523/ [3] https://email.faircode.eu/

This is exactly how I would have done it, just using my editor of choice (kakoune) instead. I also wrote on Drew's mailing list in case anyone is interested: https://lists.sr.ht/~sircmpwn/public-inbox/%3CCAKW6382rV5iW28YfyK%2BUs…

Out of curiosity, do you have an example of what it looks like? (I checked several patches on https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches but couldn't find anything with line-by-line discussion.)

The Debian experience with this is that browsers have terrible client cert UX and are actively making that worse. https://lists.sr.ht/~sircmpwn/public-inbox/%3Cf7599ba5de4864a28293a53a…

I don't have a reply for most of your comment, but with respect to this part: >If that is the situation, where does SourceHut stand? The site makes little sense to me. The URL is sourcehut.org, but there is no statement about it being a non-profit, or any discussion about a board that manages it. There is a pricing page, but no contact us page. I don't know where it is based, and I can't find a reference on Crunchbase to get any idea of who owns the company. I own SourceHut as a sole proprietor, you can reach me at [email protected] with private questions or ~sircmpwn/[email protected] with public questions. Archives here: https://lists.sr.ht/~sircmpwn/public-inbox The business is operated transparently, here's the latest quarterly financial report: https://sourcehut.org/blog/2019-10-21-sourcehut-q3-2019-financial-repo…

Also from sircmpwn, there is a mailing list called free-writers-club [0] with quite a few introductory posts and blog links... post yours, everyone! Hello and welcome! This mailing list is for authors of technical blogs and other publications to support each other's work. Feel free to post questions, drafts for review, and so on. [0]: https://lists.sr.ht/~sircmpwn/free-writers-club

This is just your greed for $10m speaking. The cost is vastly, vastly less than that. source: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/<BVRVZEWYB30Q.3HGIC803L…

Is it possible to reconsider the decision on status codes for unauthorized access to private repositories: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C20190407161316.mb644ldm… ? It's actually a drawback.

Not sure about that figure but there's https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CBVRVZEWYB30Q.3HGIC803LD… Looks like their monthly expenses were around $1,200 going in to Q2.

For completeness, here is the reply from one of the KDE developers: https://lists.sr.ht/~sircmpwn/public-inbox/%3CCAGeFrHA7FyqR24VkOgYO7tf… (It doesn't appear in the thread because it's been forwarded) EDIT: and here is a blog post about EGLStreams from another KDE developer (2016): https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-or-not/ Here is a follow-up blog post from the same author (2017): https://blog.martin-graesslin.com/blog/2017/10/plasmawayland-and-nvidi… Here are some (technical) discussions on wayland-devel about EGLStreams (2016): https://lists.freedesktop.org/archives/wayland-devel/2016-March/thread… Here are some recent IRC logs from #wayland, also discussing EGLStreams: https://dri.freedesktop.org/~cbrill/dri-log/?channel=wayland&highl…

Source: https://lists.sr.ht/~sircmpwn/sr.ht-announce/%3C20190206223744.GA10775…

Thanks, I also found this information in the site: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C20180718225440.GA4503%4… It seems a fresh revenue model after so much the-user-is-the-product models. Here's is to your success!

You mention: > lists.sr.ht finally modernizes mailing lists What's new that lists.sr.ht brings to the table? I only had a quick browse of https://lists.sr.ht/~sircmpwn/sr.ht-dev, but as far as I could tell it looked like a pretty normal list of topic lines (like a typical web forum), and the e-mail conversations themselves are just the messages concatenated into one long page (e.g. https://lists.sr.ht/~emersion/mrsh-dev/%3C20180916165820.14491-1-sir%4… Is there something interesting and new about the way these mailing lists work that I'm not seeing?

SourceHut just feels refreshingly snappy! Even the homepage has a few links that you can click around, to explore some of the features for yourself: https://sourcehut.org/ "Hosted git repositories": https://git.sr.ht/~sircmpwn/scdoc "Powerful continuous integration": https://builds.sr.ht/~sircmpwn/job/97412 "Mailing lists & code review tools": https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/14726 "Focused ticket tracking": https://todo.sr.ht/~sircmpwn/todo.sr.ht "Markdown- and git-driven wikis": https://man.sr.ht/ I'm not sure what the adoption will be like in the long term (the design might be too minimalist/niche for some), but it's nice to see such variety and focus on usability and meaningful minimalism. It feels like my install of Gitea and Drone CI, but taken a step further on getting things done and not much more. Probably a pretty stark contrast from what my personal GitLab and GitLab CI instance used to run like (the UI there was great IMO, just slow). It's nice that we have solutions like that, especially those that can be self-hosted, or just hosted versions for people who don't want to admin their own instances. For now, self-hosted Gitea and Drone CI are good enough for me.

That may be, but the fact remains that nVidia is pushing an interface that no other Linux drivers currently support, for reasons that really only benefit them. The Linux kernel team has never been particularly supportive of middleware layers designed to promote common drivers between Linux and other operating systems, and for good reason—it impedes the development of optimized, native Linux drivers. The only way I see nVidia succeeding here is if they clearly demonstrate that EGLStreams is a technically superior alternative to GBM, not just for their own hardware but in general, and also contribute the changes needed to support EGLStreams for all the other graphics drivers currently using GBM so that applications don't need to deal with both systems. As long as the EGLStreams code path can only be exercised in combination with the proprietary nVidia drivers it will remain a second-class citizen and projects would be well-advised to avoid it. (Drew DeVault goes into more detail[1] in his objection to the inclusion of EGLStreams support in KWin, which I agree with 100%.) Or they could just acknowledge that this is a Linux driver, not a Windows driver, and implement the standard Linux GBM interfaces like everyone else even if that means less shared code. [1] https://lists.sr.ht/~sircmpwn/public-inbox/%3C20190220154143.GA31283%4…

This is really exciting! I particularly like the lightness of the web-pages and the non-necessity of javascript. The support for the BSDs in the build system (FreeBSD at the moment, OpenBSD and NetBSD planned[0]) is also nice — as a Linux person I've far too often ignored the other Unixes and POSIX / general Unix compatibility. I hate being THAT guy, but would you consider trying[1] to re-license the AGPL-3.0 bits to AGPL-3.0-or-later, unless sticking with just v3 was deliberate (in which case fair enough)? My rationale: i) License-incompatibility is a curse that fragments the copyleft world. ii) Worrying about AGPL-3.0-only being incompatible with AGPL-4.0, in ten years time, if/when the latter comes out, will be too late, as (hopefully) sr.ht will have had hundreds or thousands of contributors, many uncontactable, by then. iii) Having AGPL-3.0-or-later instead of just AGPL-3.0 is unlikely to put off any contributors. iv) (This is subjective and might not hold for you:) I trust the FSF not to do something sufficiently crazy with its next iteration of licenses (if such exist), that I would prefer my code not to be compatible with such licenses. [0] https://lists.sr.ht/~sircmpwn/sr.ht-announce/%3C20180802214500.GA5332%… [1] This obviously also depends on the other contributors, so you might not want to bother with the effort.