Thanks for the link to https://micro.blog/, it looks intriguing. You don’t mention SSGs + static hosting, but I think they’ve gotten pretty accessible and there are lots to choose from, one can mix and match and even move between hosts without too much trouble, if you own a domain. I think that’s sort of the natural way to approach the simple web.
But… people want to be able to leave comments, and there’s the rub. A comment can be (in my mind anyway) even below the “micro-blog post” threshold, but its context is fixed to a post, or perhaps to other comments. A commenting system pretty much requires identity management of some form, and then moderation… it gets complicated pretty quickly, and user expectations for feature sets have risen quite a bit since the early days of forums. There are several comment systems I’m aware of that are reasonable enough to add to a static blog, but then you have a third party. Or perhaps you can self-host on a little VPS, but then it’s no longer static-simple. Either way, real-time commenting exposes you to some risk, and requires constant moderation effort.
I’m fond of the old-fashioned, anonymity preserving, moderate-before-publish paradigm, but it’s too slow and too much effort for all but the smallest conversation. You can encourage people to publish “comments” about your blog on their own blogs, and thus sidestep moderation, but that’s much less accessible and gets disjointed quickly. Or you can just let a “social network” take care of all that, but then you lose discoverability and control. I wish I knew of a better way.
When I’ve dabbled in having comments I’ve been disappointed in the quality. IMO it’s not worth all the downsides you mention. I’d encourage bloggers to provide an easy-to-find email address, and I’d encourage readers of blogs to consider sending an email even if it’s “hey, I really liked this post!” As a long-time small-fish tech blogger these conversations do happen sometimes and they’re quite fun. Not all our discussions need to double as public performance art à la microblogging. :)
That said, when you do want to comment on something publicly the link-and-comment-in-own-post approach you mention is nice too. As a reader I don’t think it’s too bad to follow the backlinks. It’s gently applying a little structure ad-hoc where it’s needed rather than forcing all conversation into a threaded system to begin with.
A put my email address a few different places, plus I send out a newsletter.
A handful of times each year I get a genuine handwritten email from someone. It’s always a delight and I try to respond with as much effort as they put in to their message.
I wish I got a bit more of those random outreaches.
Smallweb tries to make creating dynamic websites as painless as static ones. No build / deploy step, you just create a folder in you internet folder and it instantly available at https://<folder>.<domain>. To switch between hosts, you can just rsync the an app folder between different smallweb instances, or even the whole smallweb folder.
Thanks for the kind words. I been considering starting a little monthly zine just to surface cool blogging stuff. SSGs alone number in the hundreds at this point. I do mention Jekyll in the post though which is a SSG.
You can have “comments” without too much fuss in your blog if you support WebMentions. Then using something like Bridgy, can help posts on microblogs mentioning your stuff appear on your blog. That is what I do with my blog (even though my third-party WebMention endpoint seems to be down atm).
Not sure recommending Microsoft’s GitHub for hosting is the path to breaking away from the corporations. The platform itself is corporate social media & there are quite a few alternatives that still fit free as in beer & freedom (or at least close to).
I agree with you, I recommended many types of setups there and the criteria was around what are the most common ones that people can find a lot of information about if they search. I recommended many alternatives there that I am not onboard with such as Github and Wordpress. My reasoning was around not pushing what is best for me but what can be an easy path for people. Also, it is fairly easy to move away from Github and carry your stuff with you, it is less than a silo than Wordpress which is a redeeming quality.
But I hear you and I agree. Been considering starting a zine to surface cool blogging stuff away from that mainstream stuff. Do you think that is something worthwhile to do? (just gauging if there is interest from people in this thread)
After my first reply to you I stopped to think about it for five minutes and decided to edit the post to remove the GH link. I left Jekyll as a mention of a good SSG. Added Bear Blog too.
Least bad option is post the link to your blog entry on your Fediverse microblog (e.g. Mastodon) account, then update your blog entry with the URL of that post as accepting comments.
I do like receiving email about posts, and on Gemini, it mostly works for people to just respond in their own blogs. But that’s mainly because Gemini is so small that everyone uses the same aggregators and is likely to see responses; it wouldn’t work for the web. Respond-on-blog and send webping/webmention works, but that introduces a non-static component.
Flicking through the Firefox Privacy Notice it’s all reasonably clear… however doing ctrl-f “sponsored” “ads” “marketing” it does seem like an exercise in “how much can we monetise our users who stick with defaults while placating our power user cohort with opt-outs?”
Reading this article felt like being beaten to death with a large brick which had been meticulously engraved with every acronym ever written. I can only imagine the pain the author must have felt reading the actual full specifications. Kudos to them.
It’s not so popular these days but you can really avoid a lot of strife with a couple of USB hard drives and a bit of routine for rotating them. Doubly so for Apple users where Time Machine is so complete and effective.
Are you suggesting people can just use self-encrypted hard drives as an ADP replacement? That’s not reasonable. ADP is about E2E encrypting data used by most iCloud services, not just files in iCloud Drive. For example, Mail in iCloud mail. Unless your encrypted hard drives also have a suite of software services on top of them that communicate with all your devices, they aren’t a replacement. List of services can be found here: https://support.apple.com/en-us/102651
I assume it’s a mistake that you mention mail? That one fairly obviously has to be handled in cleartext by Apple. I’ve been out of the ecosystem for a few years but doesn’t iPhone sync directly with Macs over USB and LAN for photos, contacts and so on?
But if it sounds like I’m proposing we stop trading off data autonomy at the first whiff of multi-device always-on convenience, then yes that would also be true.
It’s not just “multi-device always-on convenience.” iCloud lets you share a file, send a message, get a reminder, save a bookmark in your browser, store a movie ticket pass, save points on a map, etc. Saying you can replace this with an encrypted hard drive is nuts.
Backing up with iTunes and USB cables is also unnecessarily painful. There is no automated backup. You have to stand there and wait for the passcode prompt to come up every time you want to do a backup, at least on Windows. It is messy and error prone. And if you accidentally hit don’t trust instead of trust even just once by accident, you are in for a world of hurt. Apple has made local backup very painful recently.
Apple has done a great job at making non cloud backups suck which is completely hypocritical given their supposed privacy stance since they own the keys to the cloud backups, so they now own every iOS user’s data (except those using ADP).
I use backup over WiFi. It still requires typing the passphrase (which they have an incentive to keep to push people on iCloud).
I’m using https://imazing.com to do the backups, I don’t remember the hard requirement I had for it but I think it’s because it initiates backups on its own, so the only manual step is the passphrase prompt.
You can customize the initiation conditions like minimum battery, time period.
It’s not the best software ever but works fine as a set it and forget it solution for me.
Time Machine can do encrypted backups to any SMB server and iOS can back up to a Mac (over WiFi) so you can quite easily back up all of your Apple devices without iCloud. The iOS devices periodically sync to the Mac, and the Mac does incremental backups to the SMB server. The Time Machine backups are to an encrypted disk image containing an APFS filesystem on the server, so the server just sees a sparse bundle with a load of files inside for chunks of the disk. You need to back up the encryption key separately if you do this, but it gives you off-site backups.
It’s early days but it’s fun to speculate. The first question will be whether LLM-generated software is not just higher quality on average, but whether its failure modes are no worse than what human programmers do. If an LLM has a 0.00001% chance of hallucinating that an ordinary user should have a button to become an admin, then humans and all their faults might be in business for a while yet.
The other open question is to what degree software developers will atrophy in their problem solving and working knowledge set, affecting their ability to solve problems that their LLMs can’t reason about. This is by no means a given but I’ve read anecdotes about “time wasted” by developers trying futilely to get the right prompt to solve an issue and this suggests to me that it’s already displacing time that could be spent reading structured documentation, etc. If this turns out to be a real phenomenon, old school coders might be in demand even if their specific artifacts are not.
Or TFA may be right and I’ll either get with the times or end up cleaning the burger-flipping machines. We will see.
If this turns out to be a real phenomenon, old school coders might be in demand even if their specific artifacts are not.
My worry is that senior developers will remain in demand (to ride herd on the LLMs), but there will be no need for junior developers. And therefore no pipeline to create senior developers.
A next-gen scripting language; I feel like the current ontology of “Python, Ruby, JS and sometimes Lua” has some good room for improvement from the functional language/Rust/Gleam culture. Something with a strong-ish type system with sum types instead of 1990’s “OO everything”, gradual typing built in from the start, and still keeping an emphasis on fast iteration and smooth development. A compiler built around JIT or incremental recompilation might be nice. Julia and Crystal are steps in the right direction but personally neither really quite makes the leap from “good” to “excellent enough to want to learn and use vs just bashing something out in Python”. Roc might be going in the direction I want?
A language-agnostic program runtime and software build/distribution system that stores programs and libraries as wasm or another openly-specified bytecode, then makes CPU-portable and efficient programs by AoT-compiling them to super-optimized static native code on installation. You know, like Android does with dex. I think this solves a lot of the issues that currently exist with DLL’s. It would let people distribute code as portable binary libraries, build code with portable libraries, not have the runtime overhead calling of dynamic linking, and enable the code inlining and optimizations it disallows. But you could still do things like distribute updated libraries or make plugins for a program (again as bytecode), plop them on an existing computer, and the system would just recompile the programs that need them. The main downside is it’s pretty difficult to always go from bytecode to native code as well as you can go from source code to native code.
A browser scripting environment that enables automatic FFI generation for any language that can target wasm. This kinda exists but has the Slight Issue that any language using it essentially has to be able to talk with JS’s bonkers object model and API assumptions, which usually isn’t worth the effort vs just writing your damn thing in JS.
A web browser that takes a sane subset of HTML and the browser API, and comes with lots of conformance and test suites so other people can make other browsers using the same subset of functionality.
Something nicer than email, intended for resilience and abuse-resistance. (I’m dreaming about it, I don’t know how to do it.)
Something nicer than Discord/Zulip/whatever for chat, built around a peer-to-peer pubsub model from the start but less grotty than XMPP.
Something nicer than IPFS for sharing host-anywhere content-hashed data. And then a crypto identity system built on top of it that lets you do public-key signing and encryption of messages and stuff.
About a million video games.
…yeah, I don’t understand the people who ask “how do you come up with ideas for things to build?”
Reminds me of UNCOL, TenDRA TDF, ANDF, Taos/Taos and even LLVM bitcode. Some more successful than others, some more effective at being actually architecture-neutral than others.
Also ChrysaLisp, which is made by a former Taos engineer. It’s both a reimplementation/imagining of TaoVM, and an entire desktop environment and Lisp dialect, but you could focus just on the VM part.
I’ve (not) been working on this in the background as a long-term project for a while, now, as someone who has zero experience with writing compilers; I call it Rumland (it was initially a pie in the sky idea of an ML-inspired typed scripting language that compiles to Ruby or otherwise interoperates w/ the Ruby ecosystem, then I decided to just do the most minimal, fastest-compiling ML-inspired typed scripting language I could.)
I wanted a scripting language like a mini-Haskell that can do cold builds of at least small scale personal programs (< 100k SLOC), including linking, within tens of milliseconds on a half-decade-old mid-range machine. I wouldn’t mind compiling mid-range programs like ~500k SLOC w/ dozens of transitive dependencies that fast as well, but the main focus is personal programs of < 10k SLOC, then small (but really nice to use and good looking of course) open source projects off less than 100k SLOC.
As soon as I get it compiling a very minimal language of only ADTs, functions, basic effect tracking, imports, and a tiny stdlib, I’ll lock any further changes that don’t maintain that build performance; if I have to give up all the Haskell-inspired niceties I have in mind, I’ll do it. (It’s not a public project, but I may one day make it one.)
I’ve been keeping an eye on Roc as well, and it hits a lot of the same stuff I started this project for; I love that they do their own linking (and I love the recent growth in interest in linker performance in general, e.g. mold, wild).
neither really quite makes the leap from “good” to “excellent enough to want to learn and use vs just bashing something out in Python”.
This is the problem, though. Nothing can make a very compelling case vs. using Python, at least not enough to justify the learning cost. Of the languages you list, you can already use Gleam/Elixir for scripting. There’s also F# - I’ve personally used it as a scripting language for quite a bit. You have always been able to use lisps like Racket or Clojure (via Babashka) for scripting, and there’s a slew of neolangs that try to innovate in this space. But there’s nothing so compelling that would make you want to give up everything you have. Nobody wants to give up the comforts of a familiar language to learn one that is marginally better, and at the end of the day, that’s what all of these “next-gen” improvements are. That’s one of the reasons why I’m looking forward to the upcoming stabilization of cargo-script; Instead of a new language that has all the shiny features of rust that make it comy for me to use, I’d rather just use rust for scripting too, if I can help it.
Yeah, but I’m a language nerd, so if the language is neat then for me the learning cost is potentially negative. :-P And lately a lot of my own scripting-language needs are not “get this big program to work robustly” or even “do a lot of talking with this particular domain-specific library”, but just juggling and automating fairly basic things. It feels kinda wrong to use Elixir or F# for such things, though maybe I should work harder on giving it a go. Jank also looks like it might make me actually want to write clojure, too.
It’s just… It’s not that hard to write a shell-script-like pipeline that’s nicer than Python’s subprocess lib, and I would kick a puppy to the moon for something with the built-in facility to take a bunch of JSON, stuff it into a an in-memory table (or even a persistent one), and let me query it like the database it is instead of rolling my own indices and joins with hashtables checking for the fields I care about. …hell, that alone might be a killer feature to build a language around. There’s lots of annoying REST API’s out there that force you to do this sort of thing to get the information you want.
And lately a lot of my own scripting-language needs are not “get this big program to work robustly” or even “do a lot of talking with this particular domain-specific library”, but just juggling and automating fairly basic things. […]
It’s just… It’s not that hard to write a shell-script-like pipeline that’s nicer than Python’s subprocess lib
And in the parent comment:
A next-gen scripting language; I feel like the current ontology of “Python, Ruby, JS and sometimes Lua” has some good room for improvement from the functional language/Rust/Gleam culture. Something with a strong-ish type system with sum types instead of 1990’s “OO everything”, gradual typing built in from the start, and still keeping an emphasis on fast iteration and smooth development. A compiler built around JIT or incremental recompilation might be nice.
These strike me as requirements for very different languages: the first one is a shell language that revolves around running pipelines of commands while the second is a more traditional scripting language.
But the idea of exposing an SQLite database as a type in a shell language is interesting. I’ve been thinking of a slightly different angle: streaming an SQLite table contents as a way of providing statically-typed pipelines (still very fuzzy admittedly).
I’d say F# fits what you want, especially the last bit. You can use LINQ to query over an array, so you could do basically everything you wrote. The only sticking point would be calling subprocesses, but I’m sure there’s a library that makes it easier, or you could write the boilerplate for that once and put it on nuget.
Hmmm, thanks. I’ve used F# before for medium-sized things and it’s been pleasant but I’ve never tried using it for scripting stuff. Given that u/pyj agrees with you in the sibling comment, I’ll give it a try sometime.
Somewhat in that direction is my Next Generation Shell. Preparing arguments for calling external programs, running external programs (curl to JSON API for example), parsing their output, handling their exit codes properly, small scale data manipulation are the intended use cases.
Small scripts “should not suffer” from language capabilities (no public static void main). If you decide to have main() you get automatic parsing of command line arguments to fit main() definition, of which you can have several because it’s a multimethod.
Ciel looks really cool. I read the docs yesterday and liked almost everything I saw. I feel like I want to start a new project with it, or maybe retrofit one I’ve started but haven’t done much with yet.
There’s also F# - I’ve personally used it as a scripting language for quite a bit
I also tried using F# as a scripting replacement for Python, and had very similar experience and opinion as what you found. It was amazing to me how great it worked with .Net Core across Windows/Mac/Linux.
…yeah, I don’t understand the people who ask “how do you come up with ideas for things to build?”
I don’t ask that exactly, but I do get stuck not having enough ideas about how to implement those ideas.
About a million video games.
This in particular, I have long lists of ideas but any one of them is just discouraging to think about how to produce the intended effect. I have a resolution to do at least one game jam this year, the last two years I’ve struggled after a fairly productive 2022 (when I was between jobs).
On the next-gen scripting language thing… and having chatted with you a bit about some of the past work we’ve both done… one thing I was thinking about the other day on the way back from a flight test campaign was how much the Lua scripting in ArduPilot scares me. It’s an incredibly powerful feature but also seems like it has potential to have unbounded runtime that could cause problems.
A potential solution I scribbled down was to use a more limited VM that is amenable to ahead-of-time verification for bounded execution time and remembered https://ebpf.io/. The pseudo-C code that you use to write most eBPF code is… not great and a long way away from being an easy scripting language, but it seems like a language similar to what you’re describing could be compiled down to something like eBPF and used safely for that kind of scripting.
Ooh, yeah, scripting for high-safety systems sounds like a very interesting and very tricky proposition. Verification would be good, but you’d probably also need a good simulation framework. Do it well and there might be a pretty great market for it though, and Eris knows it’s a market that needs more convenient tools!
With email-like applications the whole problem is the high level “how to do it”. We’d want something that anyone (or a lot of potential senders) could send you an email while preventing spam and abuse. These two contradict each other. I’m hoping a “only friend of my friends” could be a reasonable mdidleground, which is adjacent to what I’m already implementing.
Something nicer than IPFS for sharing host-anywhere content-hashed data. And then a crypto identity system built on top of it that lets you do public-key signing and encryption of messages and stuff.
Something nicer than IPFS for sharing host-anywhere content-hashed data. And then a crypto identity system built on top of it that lets you do public-key signing and encryption of messages and stuff.
You might be interested in Peergos, which does cryptographic identity, signing and encryption on top of a much more efficient ipfs implementation.
I think this solves a lot of the issues that currently exist with DLL’s. It would let people distribute code as portable binary libraries, build code with portable libraries, not have the runtime overhead calling of dynamic linking, and enable the code inlining and optimizations it disallows.
This sounds interesting. What would the ABI look like across langs?
I dunno! Probably a lot like what any ABI looks like, which will be imperfect by necessity. The nice thing about wasm is you can use unmanaged memory with it, mostly unlike JVM or .NET, but then adding managed memory a la the GC proposal is a bit of a mess. So I kinda feel like the ABI is not the special part here and will never be able to be perfect, it just has to be something that does the job pretty well. An AOT compiler/optimizer should hopefully be able to make most of the ABI go away with whole-program opt when the program is turned into native code.
Something nicer than Discord/Zulip/whatever for chat, built around a peer-to-peer pubsub model from the start but less grotty than XMPP.
Not less “grotty” than XMPP, because it’s built on top of XMPP, but I recently found Applesauce, a project that plans to use https://spritely.institute/ and XMPP to build a peer-to-peer pubsub social networking platform like you describe.
Make local builds of some packages for one of our dev teams, meditate upon CI runners, and try out Artifactory alternatives.
Also work on Yet More Symbol Tables for the Garnet compiler. I got my first outside contribution yesterday! (It consisted of my one-year-old niece banging on my laptop keyboard.)
Not a single human being on this planet has ever been able to explain to me how they determined this minimum version. They just copy it from somewhere, it works on their machine, and that’s good enough to move on.
I’ve seen code bases where someone made a mistake a decade ago and everyone just copied the affected snippet and it spread like a virulent disease. I’ve made such mistakes myself and among my biggest programming regrets is that I cut some corners when I wrote examples for an API I developed, and subsequently everyone used it in this flawed way.
Especially if you are among the more experienced programmers in your team, you have a big responsibility to set good examples and to live what you preach, because people will copy you and your mistakes will multiply faster than you realize. It’s a good reality check to be confronted with your own garbage, multiplied thousandfold by diligent junior developers, whenever you deliver sloppy work.
This is also a thing when doing workshops and trainings. Either the example should be completely stupid, just the bare 3-lines proof of concept, or it needs to be a full-blown example. If you skip error checking or something like that, nobody’s going to be doing error checking from that point on.
Not a single human being on this planet has ever been able to explain to me how they determined this minimum version. They just copy it from somewhere, it works on their machine, and that’s good enough to move on.
I’m honestly kind of flabbergasted by that one. At my last cmake shop, we had a super simple rule for determining that minimum version: you started it with a cmake version number that was the same age as the oldest compiler you needed to support. You raised it if you needed cmake features that were newer.
It was easy to articulate, and we all knew how to decide what it should be when we were starting a new project, as long as the oldest compiler we needed to support was clear.
Why do I as the writer of the script need to guess this version number or go through the pain of locating and running an old cmake binary? We should be able to run cmake over the script and it should tell us fully automatically what’s the minimum required version, based on the functionality we use. They know which feature was added in which version.
This whole minimum required version thing is a completely pointless rigmarole. Usually it’s set way too high because someone just randomly picked a number. And if you run into an error because your cmake version is lower, the first thing you do is to just decrease the minimum required version and it usually works anyway. Never in my life have I thought: “Phew, the minimum required version in this CMakeLists.txt saved me, I would have lost a lot of time otherwise.” To the contrary, without exception, it was always a waste of time.
We must be talking past each other, at least a little bit.
We built C++ things that were delivered on Mac, several Linux distributions, Windows, iPhone and Android.
We used cmake to build all of those.
We had a wiki that offered instructions for how to start a new project. It included the instruction that your cmake minimum version, as specified in your CMakeLists.txt, needed to align with your compiler supported version and also included a table detailing just what those numbers were for the compilers we supported across our platforms. There was no guessing or running an old cmake binary. You looked at the table, you specified something that matched, and you ran what you pulled down from our infrastructure.
The minimum required version thing was not at all pointless. To the contrary, it was a canary that let you know, if you were copying and pasting build files, that the ones you were copying might be much older than our current practices and therefore not reflect what we do for new projects. It was just another part of our documentation.
No one ever needed to go find an old cmake binary. Appropriately aged cmake binaries were installed on our systems when when we gave them to developers and they were updated automatically. cmake_minimum_required() was the moral equivalent of telling your C++ compiler which version of the standard you were using, but for cmake files. Naturally, a C++14 compiler behaves differently than a C++21 compiler. Are you as outraged about having a flag describing that in your makefile as you seem to be about having a macro describing your cmake version in your CMakeLists.txt, though?
They know which feature was added in which version.
I’m not very familiar with CMake. Once a feature is added, are its semantics frozen? Otherwise, I think that would interfere with this kind of automated analysis. (But maybe this isn’t a practical concern.)
No, but if the semantics change you need to opt in either with a policy command or a minimum version bump. I think, it’s been a test since this happened for something I care about, you may need to opt out of the new behaviour with a policy if you don’t want the new behaviour. CMake will generate a warning when you do this.
We should be able to run cmake over the script and it should tell us fully automatically what’s the minimum required version, based on the functionality we use
How could the old CMake that my potential users are going to build with know the features added in new cmake? Like, I develop with latest cmake 3.31 but it has to work on whatever crusty old version ships with Debian stable too, or on that once-in-a-moonlight contributor’s computer who runs brew upgrade at best once every two years.
Also, a reason for setting it high could be related to a policy on a specific use case or platform - maybe lowering it would work on your computer but break the shared-libraries-debug-build build on freebsd or msys2
How could the old CMake that my potential users are going to build with know the features added in new cmake?
It doesn’t need to, because you wrote the cmake script to be compatible with the minimum version that is declared in the script. The compatibility query is something the developer would use when writing the cmake script.
Like, I develop with latest cmake 3.31 but it has to work on whatever crusty old version
So you declare the crusty old version as the minimum required, and ideally latest cmake should turn off the new stuff so that you can’t use it by accident, or tell you how you need to adjust the minimum version declaration to enable the feature.
How could the old CMake that my potential users are going to build with know the features added in new cmake?
You develop with a cmake binary that is higher than the minimum required version. This binary knows the entire history of when which feature was added to older cmake versions. Hence, it could calculate and tell you the minimum required version. Currently, the developer just chooses a ‘high enough’ minimum required version, which is often not the real minimum.
This binary knows the entire history of when which feature was added to older cmake versions
I think here the mistake is assuming that a new CMake version is about features, like syntax, etc. Most of cmake’s policies are actually changes in behaviour.
e.g; take https://cmake.org/cmake/help/latest/policy/CMP0177.html or https://cmake.org/cmake/help/latest/policy/CMP0176.html which will be enabled if you set cmake_minimum_required(VERSION 3.31) - how could the build system know that these behaviour are actually required ?
Most likely setting this policy to OLD or NEW is not going to break anything during the build, but it may break what comes after for instance in your deployment scripts.
That is… terrifying. The fact that the mere indication of a minimum version silently changes behaviors under the hood sets off all kinds of alarm bells in my head. This is not good design. Thank you for the clarification.
Is that really much different from /api/v1/foo offering different semantics than /api/v2/foo (to use a web example)? You’re explicitly asking for a different version. Why wouldn’t you expect different behavior? (Would it make more sense if it were called something like “compatibility version” instead of “minimum version”?)
It would be like requiring glibc 2.35 or higher and suddenly fopen has a different function signature or semantics. First of all, nobody expects it and secondly, it would lead to severe breakage in many cases. If you change something, you do it in a backwards-compatible way or you introduce a new name for the functionality. The only reason why cmake gets away with this is because C/C++ developers are accustomed to completely broken build systems anyway, so it doesn’t matter.
It would be like requiring glibc 2.35 or higher and suddenly fopen has a different function signature or semantics.
… functions and stuff change signature and semantics in glibc on a regular basis. There’s a lot of compatibility work (and macros) to make it transparent but as soon as you need to do some complicated things you can hit very, very gnarly bugs because you for some reason ended up linking against symbol foobarn4 that disappeared in newer glibc. That’s also why all the functions you’re linking against aren’t, say, fopen, but fopen@GLIBC_2.17 for instance (woohoo! version numbers!)
random example from the last glibc changelog:
__rseq_size now denotes the size of the active rseq area (20 bytes initially), not the size of struct rseq (32 bytes initially).
^ this kind of change would for instance likely be a cmake policy enabled by setting a new cmake_minimum_required version
… functions and stuff change signature and semantics in glibc on a regular basis […]
but as soon as you need to do some complicated things you can hit very, very gnarly bugs because you for some reason ended up linking against symbol foobarn4 that disappeared in newer glibc
For its public interface, glibc maintains strict backwards compatibility for over two decades. Symbols don’t just disappear. Barring exceptions unbeknownst to me, the only way this can happen is if you are using internal implementation details instead of the public interface. The example you gave (__rseq_size) is such a low-level implementation detail.
That’s also why all the functions you’re linking against aren’t, say, fopen, but fopen@GLIBC_2.17 for instance
Perhaps my example was unclear. Note that you are talking about the ABI, whereas I was referring to the API. The API is strictly backwards compatible. In rare cases, glibc may add functionality like an optional flag that is unsupported on older versions, but it’s not allowed to change semantics. If you want to introduce a breaking change, you need to provide a new function name. For instance, an fopen call you wrote 20 years ago with an older version of glibc still behaves the same way today, regardless of the glibc version in use. The idea that, starting with some arbitrary version, you might begin normalizing paths for functions that previously didn’t (as CMake does in CMP0177), would be completely foreign to glibc.
it starts with a double underscore because those are general libc rules, but for glibc as a project, it’s part of what is exposed to glibc users
For instance, an fopen call you wrote 20 years ago with an older version of glibc still behaves the same way today, regardless of the glibc version in use.
are you really sure it does ? you can guarantee that absolutely nowhere your process runs, someone added an environment variable tunable which would affect your function’s behaviour depending on glibc version ?
Not a single human being on this planet has ever been able to explain to me how they determined this minimum version
I may be the only one, but I genuinely attempt to set that to the earliest one that supports the newest feature I use, according to the CMake docs, and when I use a newer feature I bump that version. However I haven’t been perfect at this, historically.
The minimum version controls breaking changes. If a behaviour in CMake changes, you can explicitly choose in one of two ways:
Set the minimum version to the version that made the change, or explicitly set a policy. After a while, CMake will drop support for the older versions (many years).
This means that I bump the minimum version when one of two things happens:
CMake has a new feature that I depend on (for example, they got Objective-C support around 3.18, which let me delete a load of hacks work arounds).
CMake changes a behaviour and the policy warning tells me it’s something where I don’t want to have to support the old version.
Oh, and a third one: when CMake tells me that it is dropping support for the oldest version.
For a new project, I try to pick the minimum version from the oldest Ubuntu LTS release, because everywhere else makes it trivial to use a new CMake (the latest is usually available and the default to install on Windows, macOS, and FreeBSD a few days after release, for example, OpenBSD is never more than six months old), unless there’s a newer feature that will simplify the code a lot.
Why are 11 people flagging this as spam? Just because it’s about a commercial product? It’s difficult to produce hardware without charging money for it, since it’s, y’know, a physical object that someone has to build. At least the RPi is open-source hardware.
Specifically, the bootloader is proprietary/secret, as in, you cannot build a customized version yourself. I was actually bitten by this: I wanted to PXE-boot a largish initrd (entire root fs, I think it was 600M compressed) but the bootloader had a lower limit of how much it could download. I asked the PI folks to increase the limit but they refused (probably they had their reasons). So it was a no go. And a 16G PI would be a natural fit for running an in-memory OS.
Try iPXE? There’s a build for the pi here : https://github.com/ipxe/pipxe
Then you boot a small (~4MB or so when I’ve used it on x86_64) image via PXE and then use iPXE to pull the rest down via PXE or http(s) (or probably other methods, I’ve not looked beyond those).
Yes, I was thinking of chain booting but decided not to bother (8G was still too tight but might be worth the hassle for 16G). But I didn’t know about the iPXE build for Pi, thanks for the pointer!
It is but the underlying OS is now FOSS. This does not mean that the Pi firmware is FOSS – it isn’t – but it does mean that the code is there to study.
Guessing people parsed “for sale” in the title and flagged it on that basis alone. I wasn’t one of them, but I note that it’s consistent with how Lobsters treats most other product-release links.
I think spam (“for links that promote a commercial service”) is more applicable than off-topic (“for stories that are not about computing”), but I honestly can see both applying. The reason is this has very little technical detail. The article spends about 3/4 of the words talking about the company’s climate change policy and 1/4 talking about the newly released product. Basically only one (smaller) paragraph gets into any technical specifics about what makes this board different from others.
I’m happy to see a new Raspberry Pi model get released, I’m glad the company is considering how to take care of the Earth, but it certainly seems intended simply to sell the new Raspberry Pi, hence promoting a commercial service and I don’t see how it fits this criteria:
“Will this improve the reader’s next program? Will it deepen their understanding of their last program? Will it be more interesting in five or ten years?”
So why haven’t I flagged? As of my writing this comment, my flag would be the balance between positive and neutral votes on the article (+15, 14 flags). This article isn’t so egregious as to make me want to be That Guy and flag it down. Others that feel differently may vote their conscious.
Indeed the selling point of several Pi rivals is that they are open hardware.
The Pi is entirely closed and not very standards-compliant. It uses closed-source firmware based on ThreadX, and has a unique design and startup sequence: the VideoCore GPU is the primary processor and it loads code into the Arm. Thus the Pis can’t even run a normal Arm bootloader without work, and there is nothing resembling UEFI on them.
Some distros, such as openSUSE on Pi, start by softloading Das U-Boot as a more standard bootloader, and then load the OS from this, just to get the hardware into something closer to a more standards-based Arm computer before loading Linux.
The GPU boots the computer, loads the Arm code image from SD or wherever, places is it RAM, initalises the Arm core(s) and sets them running what it put in RAM.
If you want, you are perfectly free to put a UEFI loader in that RAM – but don’t kid yourself: it’s no more in control of the computer than the passenger in the front seat of a self-driving train.
The Picos and RP2040 and RP2350 are thoroughly documented but they don’t go as far as being open source. Last time I looked, the Pico board designs are not published, though the reference designs (for the PCB design guide documentation) are available. Some parts of the chip are published, such as the firmware source and the RISC-V cores, but other parts developed by Raspberry Pi Ltd such as the PIO cores are not published. (And of course most of the big IP blocks such as the ARM cores and USB controller are proprietary to other companies.)
Yeah I guess the original title (“16GB Raspberry Pi on sale now at $120”) could be interpreted as being a sale as in promotion, versus just the release announcement which happens to mention the price in the title. Didn’t even think about the confusing wording when I posted this, I just re-used the original title, but I can see how someone could think it’s off-topic.
IMHO more off-topic than spam, but either way its a product announcement for a minor variant of an existing product, hard for something like that to be on-topic (vs new generations where one often can argue that something fundamental enough has changed that it maybe deserves attention. But even then there are limits)
I haven’t tracked a lot of hardware in this class, but the overall price with the doubled RAM seems noteworthy?
I fondly remember rescuing one of the older models from e-waste and turning it into a more “persistent” alarm clock. I know a colleague that runs a whole rack of Pis for various hobbies. I do figure you’re likely more to get storage I/O bound than RAM bound first, but they still fill an interesting niche for a cheap, “beginner” device.
I do figure you’re likely more to get storage I/O bound than RAM bound first
That may still be true… but these model 5’s are a big improvement in IO throughput compared to previous ones, including first class support for an m.2 nvme daughterboard. It’s a huge step up from the days of doing everything on a microsd card.
Because it’s an ad for a single board computer. In what way is it relevant to lobste.rs? I’d not like it if lobste.rs to be a feed on any kind of ordinary computers.
With “any kind of ordinary computer” I mean that it’s not some world first implementation that is also being discussed.
On top of that the article is not just regarding an ordinary computer it’s also just an ad. There’s nothing setting it apart in content from most other ads out there.
Mods have since improved the title, but two reasons. (1) “X on sale for $Y” is always functionally an ad, even though it’s a plain statement of fact, since its function is to encourage the reader to weigh up buying one - IMO Lobsters don’t need that in their feeds; (2) the article itself has scant technical content to discuss, leading me to the conclusion that the main point of this submission is “hey maybe you want to buy this thing”. To me that’s spam regardless of whether the submitter benefits or not.
Look, I’ve been around since the 1991 green-card-lottery spam on Usenet that coined the term, and what you’re describing is not what “spam” means. This was posted one time by an active member, for informational purposes. You can dislike this sort of post for whatever reason, but use more accurate wording.
The Lobste.rs about page notes how it is defined in this community, which is different from how it was originally used.
For stories, these are: “Off-topic” for stories that are not about computing; … “Spam” for links that promote a commercial service.
In this case, spam simply means this article is by a commercial entity attempting to sell one of its products, with very little technical benefit. Not that people believe the article is trying to sell us pills or a new stock market scheme.
The most interesting part of Gemini isn’t exactly what it can do technically (not a lot) or how suitable it is for displacing modern web use (not very) but that at every step of its development it was designed to be difficult to extend. Solderpunk grasped the fundamental issue—the tech world’s obsession with change, iteration, obsolescence. It’s a radical act to create useful software that isn’t supposed to change. Something that never scales up doesn’t have to scale down.
I don’t know what the answer is yet. Maybe with the benefit of hindsight a more versatile Gemini 2.0 might play a role. What I do know is that a mindset shift is required. Adding and changing things needs to be seen as the cost it is. When Google pushes some ridiculous Bluetooth thing into Chrome then most browser vendors should be shrugging and ignoring it. Users should be asking “Why did you implement this silly feature? We already have perfectly good ways to do Bluetooth.” Sounds improbable to me unfortunately.
(Edit: I have to call out myself for saying “Gemini 2.0” in the same post as criticising iteration. It shows how ingrained this is that I managed to submit it without noticing the hypocrisy.)
Gemini makes the fundamental mistake of assuming the ills of the modern web are due to technical factors (like JavaScript being enabled on web pages) rather than economical/societal (there’s a lot of money to be earned by tracking people online).
I’m not sure that’s so clear-cut. Consider runtime permissions on iOS and Android apps. Together with sandboxing, these technical measures are a fairly successful way for users to manage their privacy and focus, without fixing any of the factors that cause apps to be addictive nuisances in the first place. To take the analogy further, we only got these things by building entirely new consumer operating systems that didn’t have the legacy baggage of desktop OSes where sandboxing is generally absent. I think if a similar “expectations reset” could be achieved for the web then it could be very beneficial on its own, even if the legal environment and issues of political economy are still playing a role.
The web has a very strict sandbox, not much different from what mobile OSs have. Like, a website won’t have access to Web USB without explicit user action.
I think avoiding privacy violations is only marginally affected by improving security, proper privacy has to be forced via laws.
The problem is that all of this isolation is implemented with complex software. A modern OS kernel is ten million lines of code or more. A web browser is even bigger. As I often repeat: isolation is easy, sharing is hard. It’s easy to create a completely isolated environment (just use a separate chip) but OS processes need to share access to hardware, abstractions over that hardware (e.g. filesystems, network protocols) and pure-software communication paths (shared memory, message queues, and so on).
Operating systems often contain bugs that allow you to violate their isolation properties. They are also prone to misconfiguration bugs (for example, it doesn’t matter if filesystem permissions are correctly enforced if you accidentally make all of your confidential files world readable). This is less of an issue in a world of personal computers, where each computer has a single user and they run only trusted apps, as in the early days of home computing. It becomes a problem when an attacker can run arbitrary code in these isolated environments, such as by making you install a malicious app or exploiting a vulnerability in a non-malicious but buggy app.
The problem with the web is the degree to which this is possible. By default, any server that you connect to, including ones that typo squatted or were referred by malicious ads, can run arbitrary code in the sandbox. It’s far easier to escape from a sandbox if you can already run arbitrary code inside it then if you have to first exploit a bug that allows arbitrary code execution.
It’s far easier to escape from a sandbox if you can already run arbitrary code inside it then if you have to first exploit a bug that allows arbitrary code execution.
This is precisely why many of us choose to browse in allowlist mode instead of assuming script execution. A lot of folks try to tease me about it saying the web “just works like this now”, but I don’t see why we should treat it that ways (in the same way you allow access to your locations, & so on). Normalizing allowlisted JavaScript browsing would encourage good <noscript> from site maintainers too.
You are completely right from a technical perspective - I just don’t see how it relates to the “ills of the web”. Of course a smaller surface area can provide better security, but that’s not the core issue (e.g. a company storing your data in plain text and then leaking due to bad practices on their server’s end) - questionable business incentives and not enough responsibility are.
For example, tracking can’t be avoided in a strictly technical way, in my opinion. A program that can communicate with a server (which is often a core part of the very functionality of the program, so you can’t ban it) can trivially do many forms of analytics, but ads are another such example, them being an infinite cat-mouse fight between ad providers/blockers.
HTML wasn’t originally easy to extend, per se. You can only say that if you missed web development ca 2000 to 2010, the browser wars, fighting to get the most ridiculously small thing displayed cross-browser. Unless you count “I invented a new tag no one supports” as “easily extendable”.
It somehow worked, and not only by tech companies with their market leading browser strong-arming the others, some web working groups did useful work.
Unless you count “I invented a new tag no one supports” as “easily extendable”
That is how it mostly worked in the ‘90s. Browsers added new tags as differentiating features. I owned entire booklets of tags listing which browsers they worked with. And they were obsolete within six months as other vendors caught up with supporting any tags that HTML authors enjoyed using.
This kind of incremental evolution worked fairly well, though it left things like img with alt as an attribute rather than the graceful fallback text in between img tags, and object vs embed for the same things. W3C did heroic work to bring some sanity in, but usually software and standards evolution follow this path: explore a load of the design space, see what works, and then standardise around that core.
I guess that’s one way to describe it, but I disagree - if there had been a universal graceful fallback, yeah - but my experience didn’t match that. I’m not saying it was not extensible to some degree, like, compared to a binary protocol where every parser just errors out (not even XHTML 1.0 strict was that bad, as you could ignore the DTD) - but we can still view the same websites as they were published in 1996, so that part still works.
I think you’re right; don’t worry about the fact that “Gemini 2.0” sounds hypocritical, or maybe call it “Gemini bis”, or maybe Pollux (one of the Gemini twins).
As a result, despite a smaller team, we’ve made huge progress with Matrix 2.0, and the results speak for themselves. Anecdotally, I now wince whenever I have to use another messaging system – not because of loyalty to Matrix, but because the experience is going to be worse: WhatsApp has more “Waiting for message, this may take a while” errors (aka Unable To Decrypts or UTDs) than Matrix does, takes longer to launch and sync and has no threads; iMessage’s multidevice support can literally take hours to sync up; Signal just feels clunky and my message history is fragmented all over the place. It feels so good to be in that place, at last.
I’m currently attempting to leave a room in my Matrix account on my self-hosted Conduit instance, in element-desktop. When I clicked the leave room menu item, the client threw up a loading spinner for a while, then said there was an unexpected error leaving the room, and now I have no idea whether my user has in fact left the room.
I’m not sure if the problem here is Conduit, or something about how I’m hosting it, or something with element-desktop; in any case, it’s not the first time I’ve run into weird issues when trying to join or leave a room. Maybe I should try running a synapse instance again (the reason I stopped that and went to Conduit a while ago is because I thought the improved performance of a lightweight Rust homeserver might help with some joining/leaving issues). I could go back to my account hosted on matrix.org, but it sort of defeats the purpose of a federated protocol if I can’t run my own node and have it work reasonably well.
Anyway, I wish I could say that my Matrix experience felt less clunky than Signal, but that is unfortunately not currently the case. I really wish I could say it felt less clunky than Discord because Discord is what everyone I know uses to communicate and what they need to not be using, but that is certainly not the case now.
Also I just checked https://github.com/element-hq/element-meta/discussions/1681 and am disappointed to see that support for multiple matrix accounts in Element is still not ready to go. This is a feature with a huge amount of demand, that demand has been constant for many years, it’s something I personally have wanted for many years, and I really do not see why it is so difficult to implement.
FWIW I was experiencing a similar issue with a synapse homeserver run by a buddy. The room got stuck, not showing me any events since Sep 2023 and I was getting a 500 popup every time I tried to leave.
That’s just one bug of course but I ended up deleting my account and reverting to IRC because there is a more fundamental flaw in Matrix for public use - (1) the entire network is TOFU and it’s easy to get an anonymous account; (2) rooms display images and shared files by default. The kinds of things I’ve seen in benign programming rooms before the mods woke up to delete them… good grief. Hardcore gifs. Zip files suggesting they contain extremely illegal content (whether they do or not), one click away from your homeserver caching it. There is only so much you much abuse you can pack into an IRC connection (especially with anti-flooding protection) and that’s a feature.
There’s been a coordinated attack on Matrix over the last year by folk(s) posting illegal content to try to wreck public rooms and get outcomes like this. In retrospect clients should probably default to hiding images by default from folks you don’t know/trust; on the plus side we’ve managed to expand the antiabuse team in the last month or so, which should help combat in future.
When I clicked the leave room menu item, the client threw up a loading spinner for a while, then said there was an unexpected error leaving the room, and now I have no idea whether my user has in fact left the room.
That sound like a problem with the server. If the leave is successful, it gets echoed down sync and only then takes effect; so if you appear to still be in the room, you are likely still in the room. Writing state events (the key/value data stored per room) is still painfully slow in Matrix, although we’re working right now on speeding it up in state res v3 (mentioned in the OP).
the reason I stopped that and went to Conduit a while ago is because I thought the improved performance of a lightweight Rust homeserver might help with some joining/leaving issues)
Conduit has empirically taken a slightly fast & loose approach to implementing Matrix - so while it uses less resources than Synapse, it definitely comes with a beta label. Meanwhile, Synapse is certainly slow at joins/leaves still, but is boring mature and stable (and is using less resources over time, especially as hot paths get rewritten in Rust).
Anyway, I wish I could say that my Matrix experience felt less clunky than Signal, but that is unfortunately not currently the case.
Fair point on joins/leaves. The performance here does seem to be a bit of a blind spot for the team (perhaps because powerusers tend to keep with a single set of rooms which doesn’t change that often, or perhaps normalised deviance to the bad perf). I’ve personally tried to push join perf loads over the years - e.g. with https://matrix.org/blog/2022/10/18/testing-faster-remote-room-joins - but it’s ended up stuck in a weird place where the hard bits (non-atomic joins) got implemented, but the actual benefits still haven’t been fully realised due to other non-perf customer-funded features taking priority.
I really wish I could say it felt less clunky than Discord because Discord is what everyone I know uses to communicate and what they need to not be using, but that is certainly not the case now.
Yup. Element X is targetting WA/iMessage/Signal first, and Discord/Slack later. (Element Web/Desktop itself hasn’t really had the Element X rework yet).
The Element team has ended up prioritising stuff that customers offer to fund, and, frustratingly, almost none of them have explicitly asked for multiaccount on web (on the basis that you can open multiple tabs instead). On Mobile, Element X has been built with multiaccount in mind (and there’s actually a unreleased build of Element X Android which uses it), but getting parity with the old app has taken priority there.
I agree that it’s a very desirable feature, especially on mobile, and can’t wait to finally have it.
(posting with my Element CEO hat on, in this instance)
am disappointed to see that support for multiple matrix accounts in Element is still not ready to go. This is a feature with a huge amount of demand, that demand has been constant for many years, it’s something I personally have wanted for many years, and I really do not see why it is so difficult to implement.
This is indeed incredibly frustrating. I was surprised six years ago when it wasn’t a thing, and while I’m no longer surprised now I’m obviously still disappointed. Federation is both great in some respects, and also not a substitute for multiple account support.
I think the difficulty is that they (the Element folks) just don’t want to do it. Apparently the VoIP stuff was more important, despite literally none of my users asking for it and some of them being at least a bit confused about why it was now possible to bump a button and call someone by accident in a chat program.
An implementation of Slack style threads (already a horrendous idea) that you can’t turn off, and which doesn’t work especially well, was also apparently more important.
as per https://lobste.rs/s/oswvfj/matrix_holiday_special_2024#c_h3llef, the Element folk very much do want to do it. But we want the existing features to be improved first, plus we can only work on it (given we’re operating in hand-to-mouth mode) if a customer funds it.
FWIW, I understand the situation with customers and funding. It’s a tough spot to be in. I’m also, despite the constant stream of issues over the last few years and a (my) user community that has increasingly vocal contempt for the software as a result, still bullish on the platform – because I am not sure what else exists that has the same level of openness.
On the other hand, it’s really hard to stand up for the software. These blog posts talk about how the software is competitive with features and stability and performance of other platforms, and it feels like you’re living in a different universe. I think the stabilisation work on the encryption has been incredibly critical, because it was dire before, and it now appears to finally be mostly fine in terms of issues people actually hit, which is a big improvement!
But I don’t know what’s going on with Element web:
The threads stuff is a total UX disaster, and needs to be something people can disable on a per-room basis. It’s a constant source of confusion, and every time someone new gets onboarded and tries to use it, someone else has to point out “oh, gosh, sorry, we don’t use the threads here, please just send regular messages.”
For some reason, you’ve elected to take the topic out of the title bar, so it’s now hidden in some panel. We have used the topic for years to communicate information relevant to the room, except now it’s completely invisible to users. Essentially undiscoverable.
For some reason, the hashed colour scheme for users has changed at least once in the last year, and is jarring to users each time because they get used to the colours that individual nicknames have hashed to in the past.
Online/offline presence status became catastrophic in the last year or two; some interaction between the Element client and Synapse meant that our homeservers were spinning at 100% CPU all the time. It’s not clear if this now works again or not, because experimenting with turning it back on is obviously incredibly disruptive, and we don’t control the version of every client that connects.
This is just the stuff I can think of in a few minutes right now. I field a constant stream of support issues like these. I encourage people to log issues, and we do sometimes, but it doesn’t feel like they result in improvements. Then we read congratulatory blog posts like this and it’s hard not to feel like we’re being gaslighted. I appreciate the Matrix ecosystem, and again, I understand what a struggle it is to work with limited resources – but I wanted to try and let you know that I’m barely hanging on here as a supporter and it’s not easy.
I’m also, despite the constant stream of issues over the last few years and a (my) user community that has increasingly vocal contempt for the software as a result, still bullish on the platform
Well, thanks for sticking with it, i guess.
But I don’t know what’s going on with Element web:
Basically, the web team has been understaffed over the last year - the vast majority of effort has been going into the Element X project on mobile, which in turn focuses more on personal messenger (iMessage/WA/Signal) use cases rather than team collaboration (Discord/Slack). The issues you describe here are all ones on the team
collaboration side of the house - and ones which online communities hit rather than enterprisey deployments. Good news is that the expectation is to improve Element Web over the next year (hopefully funded by zendis.de), so we should make some progress.
In terms of presence, i vaguely remember there being a nasty performance regression in presence at some point in the last year or so in synapse (although can’t find the PR now). However, presence has never been fully optimised and we don’t run it on our own servers, which explains why it is less than reliable.
Then we read congratulatory blog posts like this and it’s hard not to feel like we’re being gaslighted.
I’m not trying to gaslight anyone, ftr - the difference is simply that Element X is something to be proud of (imo), even if Element Web clearly needs love. And the congratulatory blog post here is in part reflecting the fact that we’re (almost) in position to fix Element Web too.
The issues you describe here are all ones on the team collaboration side of the house - and ones which online communities hit rather than enterprisey deployments.
We’re not a massive company, but we’re definitely an enterprise deployment, FWIW.
However, presence has never been fully optimised and we don’t run it on our own servers, which explains why it is less than reliable.
Is it not something that your enterprise customers demand?
Element X is something to be proud
I mean… kind of? I agree that it has recently, especially with sliding sync making it into Synapse, become tenable as an extremely basic messenger. It’s basic though, and lacks polish; e.g.,
every time I rotate my phone from portrait to landscape to view a wide message, the program crashes immediately
if I am having an ongoing DM conversation with someone, I am frequently tapping on a push notification to get back to the DM from some other context; after I’ve done this about ten times, I find that to get back to the list of channels I have to press the “back” button at least ten times, because each time I do, I end up in the DM over and over again, rather than just once
markdown (really, HTML) support is extremely incomplete (e.g., headers, colours, tables, etc, just don’t seem to work), and worse, where it does at least do something, what it is often inconsistent with Element; in some cases it is not possible to produce a HTML message that will correctly render in both Element and Element X
the “low priority” room feature from Element is not present, despite being very valuable for making a distinction between things you do and don’t care about at a glance; this is arguably even more important on a phone, where the ~10 large rooms (e.g., the synapse admin room!) that I have marked “low priority” routinely show up at the top of my Element X room list and drown out the things I actually care about
FWIW, even if the focus is only on “personal messenger” features, I would encourage you to add Telegram to the list of applications you’re looking at. The service is obviously dubious, but the clients are stellar: their mobile applications are feature rich, high performing, and essentially glitch free as far as I can tell. If Element X felt like the Telegram desktop application, I think there would be a lot less griping, at least with respect to the personal messenger use case.
Good news is that the expectation is to improve Element Web over the next year (hopefully funded by zendis.de), so we should make some progress.
I hope so, and I wish you luck! I think that would help a lot.
We’re not a massive company, but we’re definitely an enterprise deployment, FWIW.
Ooh, interesting. One of the constant battles we have on defining the direction for Element is the extent to which “community features” (i.e. stuff which folks used to IRC or other FOSS community collaboration tools are used to - e.g. topic must be visible in the titlebar at all times; colour hashing changed) apply to workplace deployments who (in theory) pay the bills. Can you give me an idea of roughly how large your deployment is, and what the split is between developers and non-developers, and what demographic the feedback is coming from?
Is [working presence] not something that your enterprise customers demand?
Nope, “Bob was last seen 30m ago” as a requirement comes up very infrequently. Folks seem to find that read receipts are at least as good as presence info.
[Element X] is basic though, and lacks polish
Hmmm. The first two bugs are EX Android specific. The Android app /is/ a little less polished than the iOS one currently; i personally daily drive EX iOS and that’s what the commentary in the blog post is based on; it really is a nice app. Luckily the polish required on EX Android is all cosmetic, and all the heavy lifting is provided by matrix-rust-sdk which is shared with EX iOS. Guess we need to find a way to dial up polish on Android.
markdown (really, HTML) support is extremely incomplet
This is a feature, for now. commonmark doesn’t have colours/tables. headers should work, although the larger font sizes get crimped down.
It should be consistent with Element Web though; if not, that’s a bug (again, i wonder if something’s gone wrong specifically on Android).
the “low priority” room feature from Element is not present, despite being very valuable for making a distinction between things you do and don’t care about at a glance
Kate has become my editor of choice these days, which I use with the Rust and Go LSPs. Very broadly speaking it’s an equivalent to VS Code except Qt instead of Electron and a real preferences UI. It’s fast and effective and I don’t have to use questionable forks to avoid telemetry or anything else MS want to promote.
Clementine Music Player is a lovely music player for desktop. It’s inspired by Amarok and has just the right level of features for me with library management, fixing tags, ad-hoc queuing and so on.
What is currently done by the Debian Rust Team is to manually patch the dependency specifications, to relax them. This is very labour-intensive, and there is little automation supporting either decisionmaking or actually applying the resulting changes.
Two years later, this is hilarious to read. For two years, they shipped a version of bcachefs-tools that simply didn’t work at all. Why? Well, they were shipping bindgen 0.66, which had a severe miscompilation bug that made bcachefs-tools simply not work. bcachefs-tools specified a minimum of 0.69, the version that fixed the bug, but the Debian maintainers patched it to allow 0.66. They shipped that broken version for two years in testing, and then decided to simply drop the package, because it was “too hard” to maintain.
It doesn’t necessarily apply to this scenario, but in general terms if someone said “I’m trying to maintain a stable distribution here; your software is neat but the dependency sprawl caused by your language choice is more or less YOLO so I’m just not going to ship it” then I think that would be a defensible position.
The only thing that’s YOLO is Debian’s choice to randomly patch stuff that they don’t understand. This isn’t just an issue with Rust, they’ve shipped horribly broken C stuff too!
So-called dependency sprawl is a red herring. Two different C programs can depend on two different versions of a C library. It’s a thing that happens. And Debian either packages two versions of the library or they break things. It’s been a problem for decades at this point. Rust just took a sledgehammer to the issue and made it impossible to ignore that Debian’s practices don’t really work all that well.
I think it would be a defensible position if they found a better way to deal with breakage such as the above. A number of places use a similar strategy.
It’s been a frequent issue with Debian that they would stick with horribly broken packages in the name of policy, e.g. it has driven a lot of Rubyists away from using apt. (Won’t got into details, but Debian Ruby was broken between 1.9 and 2.x for a long stretch to the point where no one was willing to assist someone using it)
I love fish…except that it doesn’t have ctrl-O (execute line then select the next command from history) and I don’t know what the workaround is. I switched anyway, but every time I have to do something repeatedly that takes more than one command, I feel like I must be missing something. (Am I?) I have ctrl-R, blah, ctrl-O ctrl-O ctrl-O in my fingers from years of bash/zsh.
In bash/zsh, after you find a command in history with c-R, you can go up and down in history with c-P and c-N, and you can execute a command and immediately select the following command with c-O. So if you have a sequence of commands to repeat, you c-R back to the first one, then repeatedly do c-O to execute the sequence. (This is assuming emacs keybindings.)
Fuzzy history search in fish doesn’t seem to be related to the chronological history list. It just pulls out a single command with no context.
So I’m hoping that now c-R is incremental in fish that it can do the bash/zsh thing, but I haven’t looked at the beta yet.
I’m glad I’m not alone in this! It’s extremely rare to see someone mentioning this feature.
In zsh it’s also possible to select multiple completion candidates with Ctrl+o. I miss it even more than executing multiple history lines. There is an open issue about this, but it’s pretty much dead. https://github.com/fish-shell/fish-shell/issues/1898
I wonder what would happen if GitHub projects had two types of star - one for the code/implementation, one for documentation. I’m not sure what fraction of developers are working for dopamine but steering that effort could be interesting.
Foreign code may rely on futures code being fully lazy
IMO this is a problem in the foreign code. As a frequent writer of async code I would never make that assumption. You indicated your desire to work towards some goal the moment you called the function. Maybe it’s cancellable, maybe it’s not, but your side effects are locked in.
I’m not familiar enough with the tracing ecosystem to understand why their specific example is not following their expectations but to me this isn’t a problem with futures in general.
Make all your code fully lazy.
What does that even mean? What if your future has to capture some shared state via Arc? Does that have to be a Weak now until it’s polled the first time, and potentially fallible if it can’t acquire the necessary prerequisites?
Simpler idea: if you don’t want a function to happen, don’t call the function.
Someone linked me to their codeberg repo the other day and I was amazed how slick it was. If the forgefed protocol ever really gets off the ground (cross-instance pull requests!) I think forgejo becomes unstoppable. I get that email-based patch workflows are already federated but I just haven’t got around to learning it and PRs are pretty intuitive.
I did some poking around and honestly, Forgejo looks like everything I’d want out of a forge these days. I’m a bit surprised to see it even includes CI. A lot of smaller companies should probably be using this instead of Gitlab.
Have the Forgejo developers shown any interest in supporting self-hosted CI runners on Windows and macOS? Or is that specifically out of scope for them because those platforms are proprietary?
I believe there isn’t an active movement for using anything outside of their fork of act, however their docs state
It is possible to use other runners instead of Forgejo runner. As long as they can connect to a Forgejo instance using the same protocol, they will be given tasks to run.
So, technically speaking, someone could write a runner that runs on any platform that can connect and respond to the protocol (and what happens after that seems to be up to the runner itself).
I may be mistaken, but I think they just don’t provide pre-built binaries for those OSes. But you should be able to build forgejo-runner on your own for them.
The proportion of software engineers who have the living knowledge base of how to use PRs seems far greater than those possessing the knowledge of how to effectively use git send-email. Maybe it’s true that git send-email is much less work once you know it (I don’t know, never tried, only project I know of that uses it is the Linux kernel) but any “less work” analysis will have to account for the work of training others how to use it, amortized over the number of patches they send. And for open source projects seeking contributors, removing friction to initial contributions is everything.
I really don’t think PRs are more work. I just git push myorigin, and it prints a URL. I click it and, if it’s a simple case, just click Create PR (if it’s a complicated case you have to write a cover letter, just like you do with email). It takes longer to figure out what email address to send to for git send-email than those two clicks.
The real benefit of forge PRs comes after the initial send. I can force push to update the PR instead of having to resend emails, as often as I want, without spamming people. Countless times I noticed a mistake after the fact and quickly fixed it without having to bother anyone.
All review comments on the PR are linked in one convenient place and with a rich UI where you can expand code context without having to cross-reference a code editor manually. It’s almost impossible to review complex email patches without manually digging up context (and visualizing how the patch applies mentally, unless you manually apply it for real so you can use Git tooling!). I find that this encourages “lazy” email reviews that only consider the immediate code context because it’s too much work to pull up more, which often waste everyone’s time because the comments turn out to be invalid when considered with more code context. Meanwhile, a forge PR can be reviewed entirely in the forge, pulling up as much code context as you need on demand with a couple clicks. Comments are tied to the code context, such that you can see all comments from different people on one piece of the code together, instead of having to walk through separate email subthreads. Other PRs can be linked directly and commit IDs are clickable. Reviewers can suggest code changes that can be applied directly with one click.
Review and commenting occurs in parallel in one place, without having to break the conversation into discrete “versions” that are re-sent as unique PRs (and often end up with duplicated discussions as new people join who missed the context). That means I can be working on discussing changes A and B while I’ve already fixed C as C’ and someone is already reviewing C’, and D is already considered good and need not be re-sent to anyone if nobody has any comments on it. The UI automatically hides obsolete comments after that particular part of the code is updated (but you can still click to read them). There is an explicit concept of “resolved” conversations so you can keep track of every review change without having to do it manually in a text file or something (or worse, in your head, and then forget a few days later if you have to set the PR aside for a bit).
It’s easy to enumerate at a glance open PRs for a project, and there is a consistent notion of “closed/merged”, unlike email where there’s no programmatic way of doing that that doesn’t involve parsing human language with heuristics. And anyone joining in from elsewhere can just do it, without worrying about being subscribed to the ML or CCed in advance, or else they don’t have context in their inbox and have to cross-reference an ML archive or manually import messages.
And actually merging the PR is way easier too, just one button click for a whole series of commits vs. using something like b4 (which isn’t even part of Git itself) to download the mbox and apply it, or doing it manually via bespoke email client workflows message by message (and then if your email client doesn’t preserve whitespace properly, you’re in trouble). Plus a PR is explicit about the base commit, while bare patches aren’t, and then you have to either guess, ask, or ask for a rebase when they don’t apply (and Git can’t do useful automatic conflict resolution without a base commit, git am just gives up, unlike a rebase where you get conflict markers etc.).
And then there’s the manual email editing, and the endless nested quotes. That’s just a poor workaround for lack of rich, fine-grained threading and grouping with context! It creates visual clutter and slows everything down, because if I’m reading an email thread in sequence now I have to skip over all the quotes which I just read, and if I’m looking at a leaf message far down it was probably trimmed too much and I’ll have to look at the parents for context anyway. Clearly if you have a data structure which is a set of messages and replies to specific code context points, grouped by author/review, the efficient way to manage it is like that, not flattening it out to emails with duplicate context to make it fit a medium that cannot efficiently represent that data structure. Consider that a review implies commenting on multiple pieces of code, and while there is value to grouping them together, the comments usually stand alone. But nobody does email review like that, one comment per email. They get grouped together in one reply, and then replies to that splinter off, but the email metadata does not tell you which part of the email, which review comment, the reply is a reply to. And on the other hand, when the review is of multiple commits which are related, email has no way of grouping those together, because you can only reply to individual patches. I can fit a dozen comments and replies in one screen in a forge including the original code, while with email I can only fit one message, which might or might not have arbitrary context which may or may not be what I need depending on what the authors did while trimming quotes. And I can scroll up and down through the discussion seamlessly, while with email I have to jump from message to message (or at best get a GMail type view which is just a heuristic and may not get the threading/context right). Email is just not, at all, the right data structure to do complex code reviews with.
There’s endless other reason to use a forge depending on what you’re doing. For example, if your project involves artwork at all, forges can display and even diff images for you, while email clients just see a huge blob of base64 (because email flows also can’t integrate with attachments, which are actually the native mechanism email has for sending files). And that’s if your change even made it to the inbox and wasn’t dropped for being too large. Some projects have multi-megabyte resources and that simply can’t work with email, while Git handles it fine, especially if it’s an efficiently delta-able binary format (or there’s git LFS, which might kind of work with email if you send the changes to the LFS blob store and only email the identifiers, but I don’t know if anyone does that and why would you do that instead of using a forge with LFS integration?). Same with better integration with CI and code quality bots (which can suggest changes or fixes, and again those can be applied without the author having to re-send the entire PR, including going through several attempts at fixing a CI problem without spamming every human in the conversation).
What may be interesting is a bridge that converts pull requests from forgefed to email, so I don’t have to ever interact with the hosting website.
There are already several solutions along these lines. You can provide email interfaces for a forge flow, because it’s easy to go from rich structured content to plain text, and degrade gracefully when replies can’t be parsed back into rich content. The converse is nearly impossible.
Honestly, my intuition is that PRs provide at least a several-fold improvement in overhead over email flow. And for small changes overhead dominates the overall time spent on the whole change. The PR flow is also much friendlier to newcomers (just ask people).
Sure, with a forge you have to create an account upfront, but that is amortized among projects using the same forge or compatible login providers (quite common these days). And quite frankly, I waste more time dealing with the overhead of a single complex email code submission and review than it takes to create a forge account from scratch, with manual email/password login (if it’s OAuth then it’s just two clicks and it beats even simple email code review overhead).
Source: I regularly contribute to both large forge flow projects (Mesa) and the only large notable email flow project (Linux) and I very, very much prefer the forge flow. Even for simple changes like this one which had no review comments and didn’t need any of the post-send PR flow features I just mentioned, the email flow gives me significantly more anxiety and mental overhead, and that’s using b4 prep/b4 send which is already a huge improvement over git send-email.
You’re allowed to feel that way. I absolutely loathe the PR review UIs I’ve had to use, and I think that the foregefed protocol is a good opportunity to allow me to ignore them completely.
The way activitypub, (and by extension forgefed), works is already extremely analogous to email. There are already projects that serve activitypub via imap. Fully bridging to email seems quite doable, and I won’t be forced to conform to your preferred workflow.
IMHO a major failing of the email based workflow is that it doesn’t preserve enough commit metadata. Including the parent commit ID would help figuring out conflicts as well as avoiding missing dependencies. If the exact commit could be transferred via email it would also help future merges and updates as Git would understand that the commit that you sent as a patch is the same as the one applied by the maintainer. Right now that information is lost and when merging upstream back into your branch it can become a huge pain to resolve all of these false conflicts.
It’s also really hard to send a follow-up v2 patch that shows up in the same thread as the original. I’m a huge email fan in general, but git send-email doesn’t actually benefit from the main advantage of email flows because it doesn’t let you send using your existing mail client you already know how to use! As a result, I mess this up like 50% of the time.
I just do git push origin HEAD:refs/for/main -o topic="branch-name" and let the magic of the AGit workflow do its thing (most recent example here). I do need an account on the forge, but if I plan to contribute to things hosted there, that’s a very small price to pay.
Other than that: I just clone the upstream repo, do my thing, and git push away. I get reviews in email, and can push my updates the same way, with a simple git push. It’s bliss, I very, very rarely have to interact with the hosting website. And even in the rare cases I do: it has an API, so I can do all my interactions through Emacs, after the initial registration.
Merging PRs is similarly doable without interacting with the site, and doesn’t even require anything but git itself.
They’ve made PRs super easy, honestly. When you push to a fork the server sends back a URL to create a PR and you just fill in the title and description like you would write in an email. If there’s only one commit, those are filled in for you. That’s less work than mailing around patches for me at least.
It’s even better when you discover the AGit workflow: you don’t even need to fork. Clone the upstream repo, branch off, do your thing, and you’re a single git push away from a PR.
No fork, no email, just git clone, git checkout -b, and git push.
I like Forgejo and I think Codeberg is doing really good work there.
On the subject of email-based workflows… as a contributor, I like to be notified if my PR ends up having conflicts with the mainline so that I can fix them, for example. As a maintainer, I like being able to see all open PRs. I like suggestions in code reviews that contributors can just accept in one click. The list goes on. I’m not against creating PRs by email, but I really wouldn’t want to be a part of a process where git send-email to a mailing list is the only available tool.
It’s not that hard to write tooling that makes opening a PR as easy as git send-mail.
The fundamental issue is that git send-mail works with email addresses, whereas PRs work with accounts on a git forge. Email addresses are in some sense more decentralized internet IDs than accounts on a git forge are; but both have serious issues.
You don’t even need to write any tooling, because it already exists. It’s called git. As long as you have an account on any Forgejo instance, you can just git push using the AGit workflow.
No need to visit the web UI, no need for a fork. Just clone the original repo, then git push your branch, and a wild PR appears.
My ideal Forge would be one that would offer all forms of workflow at once. You can use ForgeFed, you can send email to create “PR” and for internal developers/core team you can use stacked diffs.
I’ll reserve judgement but I’m not confident this is going to be a great experience for everyone. Spammers, griefers, LLMs, all able to spring up from any domain straight into your issues and PRs, with no central account management to control abuse… It’s a tough gig.
Good comparison for this would be mastodon replies. In theory anyone could spin up an instance and spam you. In practice your instance moderators do a good job on spam detection and defederating malicious instances, so this isn’t a problem
This is one of the better criticisms of bsky/atproto I’ve read. So glad to read a good one. Just two comments:
DMs were added out of protocol for exactly the reason the author suspects: users were clamoring for this functionality, and doing it right will take a while. So they’ve alluded to plans to bring them back into the protocol, but for now, most people are okay with trusting Bluesky and being able to do what they want to do. It’s effectively a non-regression from the point of “I’m migrating from Twitter.”
it seems unlikely that downplaying the role of domains is something Bluesky as an organization will be motivated to do since selling domains is currently a Bluesky business strategy.
It seems like this integration has disappeared, as far as I can tell. They didn’t say anything about it publicly that I saw.
Personally I am baffled by this mindset. How can a company that has every incentive to data mine everything that touches their servers be any better than a random dude without any such incentive. Granted the dude might be a creep, but I think these people get found out pretty quick… the simile of “many eyes make all bugs shallow” can be applied here. People smell a rat quite quickly on the internet.
I think both are reasonable. Some people prefer to only need to trust one party, instead of needing to re-figure out trust every time they message someone on a different server.
I personally just never put anything that I wouldn’t mind others reading into something that’s not E2E encrypted. I wouldn’t put something into a bsky DM that I would be upset with the team reading anyway.
I do think the risk is smaller than a lot of people make it out to be, but the odds of my fedi admin knowing and caring enough about me to snoop on my messages is significantly higher than that of a Twitter sysadmin.
I am actually exploring a user encrypted storage option for the ActivityPub service I develop.
Theoretically vanilla ActivityPub should support everything out of the box, but I don’t know for sure if the HTTP-Signatures that the protocol uses for inter-instance authorization would work when the private keys are not stored on the server itself but only on the client.
Because a lot of people are on fedi instances operated by their friends, or (if they aren’t already friends) users and admins on small-medium instances will inevitably get to know each other. There’s a lot more motivation to snoop on people you know, because by and large you don’t care about the private lives of complete strangers (and, frankly, it’s much more likely to cause me problems if someone I know snoops on my messages compared to some twitter sysadmin I’ve never met).
Obviously you’d hope nobody’s going around snooping on their friends’ posts, but people you thought you liked turn out to be shitty sometimes.
I guess the snooping that large companies are incentivized to do has a more diffuse impact, like everyone buying slightly more useless junk, with less risk of acute harms as long as you stay within certain bounds.
I generally agree with you, but I think the idea is weighing the difference between a corporate entity which nominally has certain legal compliance obligations and may offer a degree of transparency versus a completely random individual human answerable and transparent to nobody. Neither is inherently trustworthy, but they are certainly untrustworthy in different ways for different reasons.
Companies are very careful with private data beyond what the TOS permits for good reasons. Individuals are always problematic even with the best intentions. You lurking at private data in a company is a firing offense. You doing that out of power on a mastodon server is something that would not be spotted let alone be something that’s particularly problematic for you.
20 years ago I had an email address managed by an acquaintance of an acquaintance and eventually we figured out that they had a bash script running looking for keywords. Was definitely a lesson for me.
Google knowing what’s in my e-mail affects me far less than people I know and deal with regularly knowing what’s in my e-mail, simply because I don’t personally know Google and they don’t know me, and have no direct personal or emotional involvement in me. Likewise, if I’m on a mastodon server run by someone I know, them knowing what I’m DMing about is creepier by default. Imagine if you texted a friend about relationship troubles. Would you prefer someone else you know having access to that or an impartial, unrelated entity like Google?
This is, of course, assuming E2EE is not an option, which is true for both alternatives in consideration.
In a non-E2EE situation, I trust a company (or any other organisation) much more for this kind of problem than a random, unspecified, sometimes unknowable person on an instance I haven’t chosen (the administrator of the personal instance of the person I’m talking to ‘in private’).
But the thing is that on the Fediverse you can join an instance that has a well known community and sysops. And, with the risk of repeating the same trite thing as everyone else: you can always host your own. :P
I can’t choose the admin of the instance of my recipient, and they can’t do either for mine, so I think that point is moot?
(And I’ll reply what everyone else may have replied to you before: not everyone can host their own, it’s a common fallacy but not everybody has the technical knowledge, free time or purchasing power to rent a server to do so.)
How can a company that has every incentive to data mine everything that touches their servers be any better than a random dude without any such incentive.
Why do you think the company has this incentive but the random dude doesn’t?
Granted the dude might be a creep, but I think these people get found out pretty quick… the simile of “many eyes make all bugs shallow” can be applied here. People smell a rat quite quickly on the internet.
Why does “trust and ditch if they turn out to be a creep” policy apply to a random dude and not a company?
Because selling data on users is how companies with free services usually get money. The dude doesn’t because probably there’s no market for not mass sourced data, but I might be wrong.
Why does “trust and ditch if they turn out to be a creep” policy apply to a random dude and not a company?
It does, of course, but currently there’s only one Bluesky, so there’s nowhere else to go if you ditch them.
Well, I think that you could replace “DM” with “emails” in that context, and still get a clear picture of how much people care about that, in general.
As super techno-geeks living in the future /s, it would be nice to offer something more private to the world, rather than repeat the same mistakes. I understand Bluesky may have been pressed by time/resources to ship DMs. I can only hope that they will improve on this first version.
I definitely think adding DMs was a mistake. They weren’t ready to do it right, and really there’s no reason to do it at all. We have dozens of chat protocols already we didn’t need another half baked one.
I’m very interested in the novel stuff atproto is doing for the social space. The bolt on, less interesting.
Funnily enough the GNU social people were saying exactly the same thing when Mastodon was adding DMs. The lack of proper security against admins (plus footguns where @-ing someone you were talking about added them as a recipient) made it a pretty compromised thing. To this day I think we’d be better off using different tools for broadcast and for private chat.
Would you care to elaborate or at least link to why laundering copyrighted code through a series of weights to enable unlicensed commercial use does not stand up to even cursory analysis as a moral issue?
My original comment having been removed, the claim I made (for context) was not that there were no moral issues but that the quality of discussion and discourse around them is low as to be beneath engagement and indeed instead is deserving of mockery and annoyance pour encourager les autres.
You pose a reasonable and (fairly) serious question, so I’ll attempt to engage in good faith.
I did not claim that “laundering” of copyrighted code through a series of weights is not a moral issue. Though I disagree with the framing, out of intellectual honesty I’ll provide a straightforward argument that such an act is a moral one: “laundering” of code involves reproduction of code, reproduction of code theoretically invokes moral rights of the other, ergo this is a moral issue (though that’s not a particularly good argument imho because I’m being lazy and cute with the use of “moral”).
Copyright–and indeed, all intellectual property law writ large–has always been about property rights and governments choosing winners or losers, and that’s an economic issue disguised as a moral one. For some strange reason, growing economies and progressing sectors (to my knowledge) always tend to play fast-and-loose with such things–see the “theft” of the IP of the industrial revolution from Britain by the Americans and of literature in the 19th century, the “theft” of the Western IP by Chinese and other countries in the 20th (and early 21st; Shanzai I think is the term of art but I may be wrong)–until they get far enough along in their own innovations to attempt to clamp down and pull the ladder up after themselves. It seems to me to be less of a moral stance and more a pragmatic, economic one.
I personally reject the idea of intellectual property as anything other than retarding progress and advancement, because it is predicated on the principle that you must artificially limit and gatekeep the spread of ideas. Perhaps the one thing we have that is truly post-scarcity and with zero reproduction cost is an idea, and copyright and patent and IP laws are there to screw that up to benefit a small handful of rentiers.
Even setting aside my own disdain for the concept, there’s still the matter of “what exactly is laundering”? Is it a moral rights violation if I rewrite your algorithm in, say, C instead of Fortran (the authors of Numerical Recipes may hold that it is)? What if I make your code use a stack instead of a queue to change the search behavior? Okay, what if my friend reads your code, and then describes to me what it does at an algorithmic level, and I reimplement it with my own flourishes? Indeed, at what point is a standard education in computer science not to be said to be “laundering” the ideas of our predecessors? It would seem to me that there are much more accepted and direct forms of laundering than jiggery-pokery in the latent space of a transformer, and so I again am unconvinced that this is worth my outrage.
Setting even that aside, when people tend to talk about morality, it can be helpful to look at different moral frameworks for evaluating things. From both a consequentialist and utilitarian standpoint, it seems clear to me that having more people writing and using more code is an absolute win (one could argue that fear of copied code would result in less code written would result in less global good, but the sheer number of for-fun reinventions of text editors and programming languages suggests that this isn’t a realistic outcome). From a Kantian standpoint, you could argue that having your code passively trained on is something you cannot consent to and thus it fails as moral–but unlike Kant’s argument against theft (e.g., an act of theft is impossible if given consent, ergo theft is mutually exclusive with consent, ergo theft is immoral under his reasoning) it’s not clear to me that you couldn’t in some cases permit training (again, contrast with theft which by construction cannot be consented to) and indeed the act of posting your code where others can see it is in effect consenting to its consumption. From a broader deontological standpoint, you pick your values and duties and I pick mine and we’ll yell past one another until we get our doctorates in moral philosophy. (What Rawls, Nietsche, or others would say is left as an exercise to the reader.)
Thanks for the interesting response. For the record, yes, it’s a pity that my out-of-context reply puts words in your mouth but I was making a good-faith attempt to pull the discussion back to specifics so I appreciate you taking it that way.
I take your broader point that one’s view on copyright plays a major factor here. I’m not a copyright maximalist but I do think it’s important on a short timeframe - I’ve always liked the 7 years proposal pushed by some political organisations. It’s clear that if one doesn’t believe in intellectual property in general then it’s going to be difficult to take seriously any moral concerns about breach of copyright through use of LLMs.
However, this discussion is not taking place in a hypothetical environment where abolishing copyright is a possibility. The AI situation is unfolding in a reality where copyright law exists. It’s generally popular and propped up by democracies, and not really at any short-term risk. Therefore we should consider the effects of the AI in this reality.
It’s fair to say that “laundering” is too woolly. There is always borrowing and and inspiration. Even so, there are several ways that this situation is offensive. When you look at the output of an LLM you have no idea of the sources and no idea how directly it’s been copied. In the arts consumers can generally distinguish between what is inspiration, following a genre, sampling, or what amounts to plagiarism, with plagiarism being something that you can actually sue people over. This works because the arts are effectively entirely open source - what you see or hear is what you get. With the right prompt an LLM might reproduce code exactly how it is in another software project without meeting the licence conditions. You wouldn’t know, computer goes brrr. There are no humans in the loop and if the outcome goes into proprietary software then those who profit from this automated pivot from inspiration to plagiarism will not easily be held accountable.
In the context of a world with copyright, it is also repugnant to trample on the modest requirements stipulated by open source developers. They don’t ask for much, especially the permissive licence crowd - they just want to be credited. Denied. Then there’s the GPL crowd, who make their code available (generally) for free with the explicit goal of ensuring users of that code have the right to modify it. Denied. It is callous and sad to disregard even the limited requests of these altruistic people, particularly if the justification for the increased productivity is ultimately “profits” which they have explicitly given up by making their work publicly available.
In this context I think it is splitting hairs to argue about what is training or whether changing one data structure to another is a material difference. A human with the honest intent to uphold copyright and licences will not be looking at MIT code or GPL code in any detail at all unless they plan to comply with the condition. The human who takes heavy inspiration from an MIT or GPL module then rewrites some of it and says “this is mine now” is scummy. Outsourcing it to a software program doesn’t make it any less scummy, so don’t be surprised if that software program becomes the target of ire.
In the context of a world with copyright, it is also repugnant to trample on the modest requirements stipulated by open source developers. They don’t ask for much, especially the permissive licence crowd - they just want to be credited. Denied. Then there’s the GPL crowd, who make their code available (generally) for free with the explicit goal of ensuring users of that code have the right to modify it. Denied. It is callous and sad to disregard even the limited requests of these altruistic people, particularly if the justification for the increased productivity is ultimately “profits” which they have explicitly given up by making their work publicly available.
I think this characterizes my take reasonably. If we’re going to have copyright, and copyright licenses, the only two decent forms of behavior I see wrt software are “respect the license” and “don’t copy/use it” unless you’re in a situation where some kind of file format lock-in coerces you into using it anyway.
I find it anti-social (“callous and sad” is a good way to put that, and I might borrow it in the future!) to accept an altrustic offer and then disregard these terms, and I think people who trained LLMs on freely offered software in a way such that they later emit portions of that software without crediting the author fail that basic test and are behaving in an anti-social way.
Well put. It’s worth keeping in mind that not only are these LLM purveyors violating the copyrights of the countless people whose work is used as training data, they are (for the most part) then also turning around and renting access to the resulting model. Even in the case of so-called “open-weight” LLMs like LLaMa, they’ve discarded the licenses of the input data (if any) and stamped their own terms of service on the freely available wad of model weights. It’s a perfect example of the way modern copyright law is interpreted to the benefit of large corporations while offering only harm and restrictions to individual people. Paying OpenAI and their ilk to use LLMs is a tacit endorsement of their exploitative methods, even if one thinks that in an ideal world copyright laws shouldn’t exist or should be strongly curtailed.
Thanks for the link to https://micro.blog/, it looks intriguing. You don’t mention SSGs + static hosting, but I think they’ve gotten pretty accessible and there are lots to choose from, one can mix and match and even move between hosts without too much trouble, if you own a domain. I think that’s sort of the natural way to approach the simple web.
But… people want to be able to leave comments, and there’s the rub. A comment can be (in my mind anyway) even below the “micro-blog post” threshold, but its context is fixed to a post, or perhaps to other comments. A commenting system pretty much requires identity management of some form, and then moderation… it gets complicated pretty quickly, and user expectations for feature sets have risen quite a bit since the early days of forums. There are several comment systems I’m aware of that are reasonable enough to add to a static blog, but then you have a third party. Or perhaps you can self-host on a little VPS, but then it’s no longer static-simple. Either way, real-time commenting exposes you to some risk, and requires constant moderation effort.
I’m fond of the old-fashioned, anonymity preserving, moderate-before-publish paradigm, but it’s too slow and too much effort for all but the smallest conversation. You can encourage people to publish “comments” about your blog on their own blogs, and thus sidestep moderation, but that’s much less accessible and gets disjointed quickly. Or you can just let a “social network” take care of all that, but then you lose discoverability and control. I wish I knew of a better way.
When I’ve dabbled in having comments I’ve been disappointed in the quality. IMO it’s not worth all the downsides you mention. I’d encourage bloggers to provide an easy-to-find email address, and I’d encourage readers of blogs to consider sending an email even if it’s “hey, I really liked this post!” As a long-time small-fish tech blogger these conversations do happen sometimes and they’re quite fun. Not all our discussions need to double as public performance art à la microblogging. :)
That said, when you do want to comment on something publicly the link-and-comment-in-own-post approach you mention is nice too. As a reader I don’t think it’s too bad to follow the backlinks. It’s gently applying a little structure ad-hoc where it’s needed rather than forcing all conversation into a threaded system to begin with.
A put my email address a few different places, plus I send out a newsletter.
A handful of times each year I get a genuine handwritten email from someone. It’s always a delight and I try to respond with as much effort as they put in to their message.
I wish I got a bit more of those random outreaches.
I feel like you might be interested in smallweb: https://www.smallweb.run/
Smallweb tries to make creating dynamic websites as painless as static ones. No build / deploy step, you just create a folder in you internet folder and it instantly available at
https://<folder>.<domain>. To switch between hosts, you can just rsync the an app folder between different smallweb instances, or even the whole smallweb folder.There is a live demo available at https://demo.smallweb.live
Check out: https://bearblog.dev/ too
Easy enough even on a static site e.g.: https://discourse.gohugo.io/t/static-comments-script-for-hugo-in-php/51924/2
Editted the post to include Bear Blog <3 thanks for reminding me of it.
Thanks for the kind words. I been considering starting a little monthly zine just to surface cool blogging stuff. SSGs alone number in the hundreds at this point. I do mention Jekyll in the post though which is a SSG.
You can have “comments” without too much fuss in your blog if you support WebMentions. Then using something like Bridgy, can help posts on microblogs mentioning your stuff appear on your blog. That is what I do with my blog (even though my third-party WebMention endpoint seems to be down atm).
Not sure recommending Microsoft’s GitHub for hosting is the path to breaking away from the corporations. The platform itself is corporate social media & there are quite a few alternatives that still fit free as in beer & freedom (or at least close to).
I agree with you, I recommended many types of setups there and the criteria was around what are the most common ones that people can find a lot of information about if they search. I recommended many alternatives there that I am not onboard with such as Github and Wordpress. My reasoning was around not pushing what is best for me but what can be an easy path for people. Also, it is fairly easy to move away from Github and carry your stuff with you, it is less than a silo than Wordpress which is a redeeming quality.
But I hear you and I agree. Been considering starting a zine to surface cool blogging stuff away from that mainstream stuff. Do you think that is something worthwhile to do? (just gauging if there is interest from people in this thread)
After my first reply to you I stopped to think about it for five minutes and decided to edit the post to remove the GH link. I left Jekyll as a mention of a good SSG. Added Bear Blog too.
Least bad option is post the link to your blog entry on your Fediverse microblog (e.g. Mastodon) account, then update your blog entry with the URL of that post as accepting comments.
I do like receiving email about posts, and on Gemini, it mostly works for people to just respond in their own blogs. But that’s mainly because Gemini is so small that everyone uses the same aggregators and is likely to see responses; it wouldn’t work for the web. Respond-on-blog and send webping/webmention works, but that introduces a non-static component.
Flicking through the Firefox Privacy Notice it’s all reasonably clear… however doing ctrl-f “sponsored” “ads” “marketing” it does seem like an exercise in “how much can we monetise our users who stick with defaults while placating our power user cohort with opt-outs?”
Reading this article felt like being beaten to death with a large brick which had been meticulously engraved with every acronym ever written. I can only imagine the pain the author must have felt reading the actual full specifications. Kudos to them.
That line from Mickens’ The Night Watch popped into my head unbidden
It’s not so popular these days but you can really avoid a lot of strife with a couple of USB hard drives and a bit of routine for rotating them. Doubly so for Apple users where Time Machine is so complete and effective.
Are you suggesting people can just use self-encrypted hard drives as an ADP replacement? That’s not reasonable. ADP is about E2E encrypting data used by most iCloud services, not just files in iCloud Drive. For example, Mail in iCloud mail. Unless your encrypted hard drives also have a suite of software services on top of them that communicate with all your devices, they aren’t a replacement. List of services can be found here: https://support.apple.com/en-us/102651
I assume it’s a mistake that you mention mail? That one fairly obviously has to be handled in cleartext by Apple. I’ve been out of the ecosystem for a few years but doesn’t iPhone sync directly with Macs over USB and LAN for photos, contacts and so on?
But if it sounds like I’m proposing we stop trading off data autonomy at the first whiff of multi-device always-on convenience, then yes that would also be true.
Yes, sorry, I meant Messages and not Mail.
It’s not just “multi-device always-on convenience.” iCloud lets you share a file, send a message, get a reminder, save a bookmark in your browser, store a movie ticket pass, save points on a map, etc. Saying you can replace this with an encrypted hard drive is nuts.
Backing up with iTunes and USB cables is also unnecessarily painful. There is no automated backup. You have to stand there and wait for the passcode prompt to come up every time you want to do a backup, at least on Windows. It is messy and error prone. And if you accidentally hit don’t trust instead of trust even just once by accident, you are in for a world of hurt. Apple has made local backup very painful recently.
Apple has done a great job at making non cloud backups suck which is completely hypocritical given their supposed privacy stance since they own the keys to the cloud backups, so they now own every iOS user’s data (except those using ADP).
I use backup over WiFi. It still requires typing the passphrase (which they have an incentive to keep to push people on iCloud).
I’m using https://imazing.com to do the backups, I don’t remember the hard requirement I had for it but I think it’s because it initiates backups on its own, so the only manual step is the passphrase prompt.
You can customize the initiation conditions like minimum battery, time period. It’s not the best software ever but works fine as a set it and forget it solution for me.
Time Machine can do encrypted backups to any SMB server and iOS can back up to a Mac (over WiFi) so you can quite easily back up all of your Apple devices without iCloud. The iOS devices periodically sync to the Mac, and the Mac does incremental backups to the SMB server. The Time Machine backups are to an encrypted disk image containing an APFS filesystem on the server, so the server just sees a sparse bundle with a load of files inside for chunks of the disk. You need to back up the encryption key separately if you do this, but it gives you off-site backups.
Or simply encrypting yourself before uploading into the cloud?
It’s early days but it’s fun to speculate. The first question will be whether LLM-generated software is not just higher quality on average, but whether its failure modes are no worse than what human programmers do. If an LLM has a 0.00001% chance of hallucinating that an ordinary user should have a button to become an admin, then humans and all their faults might be in business for a while yet.
The other open question is to what degree software developers will atrophy in their problem solving and working knowledge set, affecting their ability to solve problems that their LLMs can’t reason about. This is by no means a given but I’ve read anecdotes about “time wasted” by developers trying futilely to get the right prompt to solve an issue and this suggests to me that it’s already displacing time that could be spent reading structured documentation, etc. If this turns out to be a real phenomenon, old school coders might be in demand even if their specific artifacts are not.
Or TFA may be right and I’ll either get with the times or end up cleaning the burger-flipping machines. We will see.
My worry is that senior developers will remain in demand (to ride herd on the LLMs), but there will be no need for junior developers. And therefore no pipeline to create senior developers.
A next-gen scripting language; I feel like the current ontology of “Python, Ruby, JS and sometimes Lua” has some good room for improvement from the functional language/Rust/Gleam culture. Something with a strong-ish type system with sum types instead of 1990’s “OO everything”, gradual typing built in from the start, and still keeping an emphasis on fast iteration and smooth development. A compiler built around JIT or incremental recompilation might be nice. Julia and Crystal are steps in the right direction but personally neither really quite makes the leap from “good” to “excellent enough to want to learn and use vs just bashing something out in Python”. Roc might be going in the direction I want?
A language-agnostic program runtime and software build/distribution system that stores programs and libraries as wasm or another openly-specified bytecode, then makes CPU-portable and efficient programs by AoT-compiling them to super-optimized static native code on installation. You know, like Android does with dex. I think this solves a lot of the issues that currently exist with DLL’s. It would let people distribute code as portable binary libraries, build code with portable libraries, not have the runtime overhead calling of dynamic linking, and enable the code inlining and optimizations it disallows. But you could still do things like distribute updated libraries or make plugins for a program (again as bytecode), plop them on an existing computer, and the system would just recompile the programs that need them. The main downside is it’s pretty difficult to always go from bytecode to native code as well as you can go from source code to native code.
A browser scripting environment that enables automatic FFI generation for any language that can target wasm. This kinda exists but has the Slight Issue that any language using it essentially has to be able to talk with JS’s bonkers object model and API assumptions, which usually isn’t worth the effort vs just writing your damn thing in JS.
A web browser that takes a sane subset of HTML and the browser API, and comes with lots of conformance and test suites so other people can make other browsers using the same subset of functionality.
Something nicer than email, intended for resilience and abuse-resistance. (I’m dreaming about it, I don’t know how to do it.)
Something nicer than Discord/Zulip/whatever for chat, built around a peer-to-peer pubsub model from the start but less grotty than XMPP.
Something nicer than IPFS for sharing host-anywhere content-hashed data. And then a crypto identity system built on top of it that lets you do public-key signing and encryption of messages and stuff.
About a million video games.
…yeah, I don’t understand the people who ask “how do you come up with ideas for things to build?”
Reminds me of UNCOL, TenDRA TDF, ANDF, Taos/Taos and even LLVM bitcode. Some more successful than others, some more effective at being actually architecture-neutral than others.
Also ChrysaLisp, which is made by a former Taos engineer. It’s both a reimplementation/imagining of TaoVM, and an entire desktop environment and Lisp dialect, but you could focus just on the VM part.
Oooh, thanks! Sounds like there’s lots of prior art to learn the mistakes of then. :D
I’ve (not) been working on this in the background as a long-term project for a while, now, as someone who has zero experience with writing compilers; I call it Rumland (it was initially a pie in the sky idea of an ML-inspired typed scripting language that compiles to Ruby or otherwise interoperates w/ the Ruby ecosystem, then I decided to just do the most minimal, fastest-compiling ML-inspired typed scripting language I could.)
I wanted a scripting language like a mini-Haskell that can do cold builds of at least small scale personal programs (< 100k SLOC), including linking, within tens of milliseconds on a half-decade-old mid-range machine. I wouldn’t mind compiling mid-range programs like ~500k SLOC w/ dozens of transitive dependencies that fast as well, but the main focus is personal programs of < 10k SLOC, then small (but really nice to use and good looking of course) open source projects off less than 100k SLOC.
As soon as I get it compiling a very minimal language of only ADTs, functions, basic effect tracking, imports, and a tiny stdlib, I’ll lock any further changes that don’t maintain that build performance; if I have to give up all the Haskell-inspired niceties I have in mind, I’ll do it. (It’s not a public project, but I may one day make it one.)
I’ve been keeping an eye on Roc as well, and it hits a lot of the same stuff I started this project for; I love that they do their own linking (and I love the recent growth in interest in linker performance in general, e.g. mold, wild).
This is the problem, though. Nothing can make a very compelling case vs. using Python, at least not enough to justify the learning cost. Of the languages you list, you can already use Gleam/Elixir for scripting. There’s also F# - I’ve personally used it as a scripting language for quite a bit. You have always been able to use lisps like Racket or Clojure (via Babashka) for scripting, and there’s a slew of neolangs that try to innovate in this space. But there’s nothing so compelling that would make you want to give up everything you have. Nobody wants to give up the comforts of a familiar language to learn one that is marginally better, and at the end of the day, that’s what all of these “next-gen” improvements are. That’s one of the reasons why I’m looking forward to the upcoming stabilization of
cargo-script; Instead of a new language that has all the shiny features of rust that make it comy for me to use, I’d rather just use rust for scripting too, if I can help it.Yeah, but I’m a language nerd, so if the language is neat then for me the learning cost is potentially negative. :-P And lately a lot of my own scripting-language needs are not “get this big program to work robustly” or even “do a lot of talking with this particular domain-specific library”, but just juggling and automating fairly basic things. It feels kinda wrong to use Elixir or F# for such things, though maybe I should work harder on giving it a go. Jank also looks like it might make me actually want to write clojure, too.
It’s just… It’s not that hard to write a shell-script-like pipeline that’s nicer than Python’s
subprocesslib, and I would kick a puppy to the moon for something with the built-in facility to take a bunch of JSON, stuff it into a an in-memory table (or even a persistent one), and let me query it like the database it is instead of rolling my own indices and joins with hashtables checking for the fields I care about. …hell, that alone might be a killer feature to build a language around. There’s lots of annoying REST API’s out there that force you to do this sort of thing to get the information you want.And in the parent comment:
These strike me as requirements for very different languages: the first one is a shell language that revolves around running pipelines of commands while the second is a more traditional scripting language.
But the idea of exposing an SQLite database as a type in a shell language is interesting. I’ve been thinking of a slightly different angle: streaming an SQLite table contents as a way of providing statically-typed pipelines (still very fuzzy admittedly).
I’d say F# fits what you want, especially the last bit. You can use LINQ to query over an array, so you could do basically everything you wrote. The only sticking point would be calling subprocesses, but I’m sure there’s a library that makes it easier, or you could write the boilerplate for that once and put it on nuget.
Hmmm, thanks. I’ve used F# before for medium-sized things and it’s been pleasant but I’ve never tried using it for scripting stuff. Given that u/pyj agrees with you in the sibling comment, I’ll give it a try sometime.
Have you played with kdb+/q at all?
Never heard of it, I’ll have to check it out! Thanks.
DuckDB is great for that.
Somewhat in that direction is my Next Generation Shell. Preparing arguments for calling external programs, running external programs (curl to JSON API for example), parsing their output, handling their exit codes properly, small scale data manipulation are the intended use cases.
Small scripts “should not suffer” from language capabilities (no public static void main). If you decide to have main() you get automatic parsing of command line arguments to fit main() definition, of which you can have several because it’s a multimethod.
https://github.com/ngs-lang/ngs
https://github.com/ngs-lang/ngs/wiki/Use-Cases
Hope this helps
and also Common Lisp, specially with http://ciel-lang.org/ which can be seen as Babashka-like (without the platform limitations):
it’s still alhpa, we are refining it and adding more features.
Ciel looks really cool. I read the docs yesterday and liked almost everything I saw. I feel like I want to start a new project with it, or maybe retrofit one I’ve started but haven’t done much with yet.
I also tried using F# as a scripting replacement for Python, and had very similar experience and opinion as what you found. It was amazing to me how great it worked with .Net Core across Windows/Mac/Linux.
I don’t ask that exactly, but I do get stuck not having enough ideas about how to implement those ideas.
This in particular, I have long lists of ideas but any one of them is just discouraging to think about how to produce the intended effect. I have a resolution to do at least one game jam this year, the last two years I’ve struggled after a fairly productive 2022 (when I was between jobs).
Hmmm, do we need «What software you’d try implementing, but would want to discuss implementation design first» threads?
On the next-gen scripting language thing… and having chatted with you a bit about some of the past work we’ve both done… one thing I was thinking about the other day on the way back from a flight test campaign was how much the Lua scripting in ArduPilot scares me. It’s an incredibly powerful feature but also seems like it has potential to have unbounded runtime that could cause problems.
A potential solution I scribbled down was to use a more limited VM that is amenable to ahead-of-time verification for bounded execution time and remembered https://ebpf.io/. The pseudo-C code that you use to write most eBPF code is… not great and a long way away from being an easy scripting language, but it seems like a language similar to what you’re describing could be compiled down to something like eBPF and used safely for that kind of scripting.
Ooh, yeah, scripting for high-safety systems sounds like a very interesting and very tricky proposition. Verification would be good, but you’d probably also need a good simulation framework. Do it well and there might be a pretty great market for it though, and Eris knows it’s a market that needs more convenient tools!
It’s relatively easy to take https://github.com/n0-computer/iroh nowadays, and either built-in https://www.iroh.computer/proto/iroh-blobs , or just something custom with
baofor incremental hash verification. Depending on what you want it to do exactly, could be a little spin on top of the minimal demo app they have: https://github.com/n0-computer/sendmeThese are two things I could try to incorporate into https://github.com/dpc/rostra
With email-like applications the whole problem is the high level “how to do it”. We’d want something that anyone (or a lot of potential senders) could send you an email while preventing spam and abuse. These two contradict each other. I’m hoping a “only friend of my friends” could be a reasonable mdidleground, which is adjacent to what I’m already implementing.
Sounds rather like Veilid
You might be interested in Peergos, which does cryptographic identity, signing and encryption on top of a much more efficient ipfs implementation.
https://book.peergos.org
This sounds interesting. What would the ABI look like across langs?
I dunno! Probably a lot like what any ABI looks like, which will be imperfect by necessity. The nice thing about wasm is you can use unmanaged memory with it, mostly unlike JVM or .NET, but then adding managed memory a la the GC proposal is a bit of a mess. So I kinda feel like the ABI is not the special part here and will never be able to be perfect, it just has to be something that does the job pretty well. An AOT compiler/optimizer should hopefully be able to make most of the ABI go away with whole-program opt when the program is turned into native code.
Not less “grotty” than XMPP, because it’s built on top of XMPP, but I recently found Applesauce, a project that plans to use https://spritely.institute/ and XMPP to build a peer-to-peer pubsub social networking platform like you describe.
Your link is broken. Here’s the right one: https://spritely.institute
Thank you for catching my mistake!
rakudo (perl6) is pretty cool.
Make local builds of some packages for one of our dev teams, meditate upon CI runners, and try out Artifactory alternatives.
Also work on Yet More Symbol Tables for the Garnet compiler. I got my first outside contribution yesterday! (It consisted of my one-year-old niece banging on my laptop keyboard.)
Anything standing out re: artifactory alternatives?
Not yet, maybe ask again next week.
This happens everywhere. My favorite example is:
Not a single human being on this planet has ever been able to explain to me how they determined this minimum version. They just copy it from somewhere, it works on their machine, and that’s good enough to move on.
I’ve seen code bases where someone made a mistake a decade ago and everyone just copied the affected snippet and it spread like a virulent disease. I’ve made such mistakes myself and among my biggest programming regrets is that I cut some corners when I wrote examples for an API I developed, and subsequently everyone used it in this flawed way.
Especially if you are among the more experienced programmers in your team, you have a big responsibility to set good examples and to live what you preach, because people will copy you and your mistakes will multiply faster than you realize. It’s a good reality check to be confronted with your own garbage, multiplied thousandfold by diligent junior developers, whenever you deliver sloppy work.
This is also a thing when doing workshops and trainings. Either the example should be completely stupid, just the bare 3-lines proof of concept, or it needs to be a full-blown example. If you skip error checking or something like that, nobody’s going to be doing error checking from that point on.
Not to mention when you write example code for web services. One time I made a typo in the example code and saw that typo proliferate so far.
I’m honestly kind of flabbergasted by that one. At my last cmake shop, we had a super simple rule for determining that minimum version: you started it with a cmake version number that was the same age as the oldest compiler you needed to support. You raised it if you needed cmake features that were newer.
It was easy to articulate, and we all knew how to decide what it should be when we were starting a new project, as long as the oldest compiler we needed to support was clear.
Why do I as the writer of the script need to guess this version number or go through the pain of locating and running an old
cmakebinary? We should be able to runcmakeover the script and it should tell us fully automatically what’s the minimum required version, based on the functionality we use. They know which feature was added in which version.This whole minimum required version thing is a completely pointless rigmarole. Usually it’s set way too high because someone just randomly picked a number. And if you run into an error because your
cmakeversion is lower, the first thing you do is to just decrease the minimum required version and it usually works anyway. Never in my life have I thought: “Phew, the minimum required version in thisCMakeLists.txtsaved me, I would have lost a lot of time otherwise.” To the contrary, without exception, it was always a waste of time.We must be talking past each other, at least a little bit.
We built C++ things that were delivered on Mac, several Linux distributions, Windows, iPhone and Android.
We used cmake to build all of those.
We had a wiki that offered instructions for how to start a new project. It included the instruction that your cmake minimum version, as specified in your CMakeLists.txt, needed to align with your compiler supported version and also included a table detailing just what those numbers were for the compilers we supported across our platforms. There was no guessing or running an old cmake binary. You looked at the table, you specified something that matched, and you ran what you pulled down from our infrastructure.
The minimum required version thing was not at all pointless. To the contrary, it was a canary that let you know, if you were copying and pasting build files, that the ones you were copying might be much older than our current practices and therefore not reflect what we do for new projects. It was just another part of our documentation.
No one ever needed to go find an old cmake binary. Appropriately aged cmake binaries were installed on our systems when when we gave them to developers and they were updated automatically.
cmake_minimum_required()was the moral equivalent of telling your C++ compiler which version of the standard you were using, but for cmake files. Naturally, a C++14 compiler behaves differently than a C++21 compiler. Are you as outraged about having a flag describing that in your makefile as you seem to be about having a macro describing your cmake version in your CMakeLists.txt, though?I’m not very familiar with CMake. Once a feature is added, are its semantics frozen? Otherwise, I think that would interfere with this kind of automated analysis. (But maybe this isn’t a practical concern.)
No, but if the semantics change you need to opt in either with a policy command or a minimum version bump. I think, it’s been a test since this happened for something I care about, you may need to opt out of the new behaviour with a policy if you don’t want the new behaviour. CMake will generate a warning when you do this.
How could the old CMake that my potential users are going to build with know the features added in new cmake? Like, I develop with latest cmake 3.31 but it has to work on whatever crusty old version ships with Debian stable too, or on that once-in-a-moonlight contributor’s computer who runs brew upgrade at best once every two years. Also, a reason for setting it high could be related to a policy on a specific use case or platform - maybe lowering it would work on your computer but break the shared-libraries-debug-build build on freebsd or msys2
It doesn’t need to, because you wrote the cmake script to be compatible with the minimum version that is declared in the script. The compatibility query is something the developer would use when writing the cmake script.
So you declare the crusty old version as the minimum required, and ideally latest cmake should turn off the new stuff so that you can’t use it by accident, or tell you how you need to adjust the minimum version declaration to enable the feature.
but OP is complaining about that exactly - they’re saying that a minimum version should not be declared at all and that CMake could magically infer it
You develop with a
cmakebinary that is higher than the minimum required version. This binary knows the entire history of when which feature was added to oldercmakeversions. Hence, it could calculate and tell you the minimum required version. Currently, the developer just chooses a ‘high enough’ minimum required version, which is often not the real minimum.I think here the mistake is assuming that a new CMake version is about features, like syntax, etc. Most of cmake’s policies are actually changes in behaviour.
e.g; take https://cmake.org/cmake/help/latest/policy/CMP0177.html or https://cmake.org/cmake/help/latest/policy/CMP0176.html which will be enabled if you set cmake_minimum_required(VERSION 3.31) - how could the build system know that these behaviour are actually required ? Most likely setting this policy to OLD or NEW is not going to break anything during the build, but it may break what comes after for instance in your deployment scripts.
That is… terrifying. The fact that the mere indication of a minimum version silently changes behaviors under the hood sets off all kinds of alarm bells in my head. This is not good design. Thank you for the clarification.
Is that really much different from
/api/v1/foooffering different semantics than/api/v2/foo(to use a web example)? You’re explicitly asking for a different version. Why wouldn’t you expect different behavior? (Would it make more sense if it were called something like “compatibility version” instead of “minimum version”?)It would be like requiring
glibc2.35 or higher and suddenlyfopenhas a different function signature or semantics. First of all, nobody expects it and secondly, it would lead to severe breakage in many cases. If you change something, you do it in a backwards-compatible way or you introduce a new name for the functionality. The only reason whycmakegets away with this is because C/C++ developers are accustomed to completely broken build systems anyway, so it doesn’t matter.… functions and stuff change signature and semantics in glibc on a regular basis. There’s a lot of compatibility work (and macros) to make it transparent but as soon as you need to do some complicated things you can hit very, very gnarly bugs because you for some reason ended up linking against symbol foobarn4 that disappeared in newer glibc. That’s also why all the functions you’re linking against aren’t, say, fopen, but fopen@GLIBC_2.17 for instance (woohoo! version numbers!)
random example from the last glibc changelog:
^ this kind of change would for instance likely be a cmake policy enabled by setting a new cmake_minimum_required version
For its public interface,
glibcmaintains strict backwards compatibility for over two decades. Symbols don’t just disappear. Barring exceptions unbeknownst to me, the only way this can happen is if you are using internal implementation details instead of the public interface. The example you gave (__rseq_size) is such a low-level implementation detail.Perhaps my example was unclear. Note that you are talking about the ABI, whereas I was referring to the API. The API is strictly backwards compatible. In rare cases,
glibcmay add functionality like an optional flag that is unsupported on older versions, but it’s not allowed to change semantics. If you want to introduce a breaking change, you need to provide a new function name. For instance, anfopencall you wrote 20 years ago with an older version ofglibcstill behaves the same way today, regardless of theglibcversion in use. The idea that, starting with some arbitrary version, you might begin normalizing paths for functions that previously didn’t (as CMake does in CMP0177), would be completely foreign toglibc.is part of the public interface of glibc, documented here: https://www.gnu.org/software/libc/manual/html_node/Restartable-Sequences.html
it starts with a double underscore because those are general libc rules, but for glibc as a project, it’s part of what is exposed to glibc users
are you really sure it does ? you can guarantee that absolutely nowhere your process runs, someone added an environment variable tunable which would affect your function’s behaviour depending on glibc version ?
I may be the only one, but I genuinely attempt to set that to the earliest one that supports the newest feature I use, according to the CMake docs, and when I use a newer feature I bump that version. However I haven’t been perfect at this, historically.
The minimum version controls breaking changes. If a behaviour in CMake changes, you can explicitly choose in one of two ways:
Set the minimum version to the version that made the change, or explicitly set a policy. After a while, CMake will drop support for the older versions (many years).
This means that I bump the minimum version when one of two things happens:
Oh, and a third one: when CMake tells me that it is dropping support for the oldest version.
For a new project, I try to pick the minimum version from the oldest Ubuntu LTS release, because everywhere else makes it trivial to use a new CMake (the latest is usually available and the default to install on Windows, macOS, and FreeBSD a few days after release, for example, OpenBSD is never more than six months old), unless there’s a newer feature that will simplify the code a lot.
I realise it’s not the key point of your comment, but if anyone was wondering, this page has quite a useful discussion about what minimum version of CMake you might want to choose: https://cliutils.gitlab.io/modern-cmake/chapters/intro/dodonot.html
Personally I always use the CMake version installed on my development machine (usually the latest). There is a pretty good article about it here: https://alexreinking.com/blog/how-to-use-cmake-without-the-agonizing-pain-part-1.html
It looks like
3.15specifically most likely comes from the cliutils ‘modern cmake’ book, it should probably be bumped.Why are 11 people flagging this as spam? Just because it’s about a commercial product? It’s difficult to produce hardware without charging money for it, since it’s, y’know, a physical object that someone has to build. At least the RPi is open-source hardware.
Neither the hardware nor the firmware are open source, and large chunks of it (principally the GPU) are proprietary secrets.
Specifically, the bootloader is proprietary/secret, as in, you cannot build a customized version yourself. I was actually bitten by this: I wanted to PXE-boot a largish initrd (entire root fs, I think it was 600M compressed) but the bootloader had a lower limit of how much it could download. I asked the PI folks to increase the limit but they refused (probably they had their reasons). So it was a no go. And a 16G PI would be a natural fit for running an in-memory OS.
Try iPXE? There’s a build for the pi here : https://github.com/ipxe/pipxe Then you boot a small (~4MB or so when I’ve used it on x86_64) image via PXE and then use iPXE to pull the rest down via PXE or http(s) (or probably other methods, I’ve not looked beyond those).
Yes, I was thinking of chain booting but decided not to bother (8G was still too tight but might be worth the hassle for 16G). But I didn’t know about the iPXE build for Pi, thanks for the pointer!
It is but the underlying OS is now FOSS. This does not mean that the Pi firmware is FOSS – it isn’t – but it does mean that the code is there to study.
I wrote about it:
https://www.theregister.com/2023/11/28/microsoft_opens_sources_threadx/
Guessing people parsed “for sale” in the title and flagged it on that basis alone. I wasn’t one of them, but I note that it’s consistent with how Lobsters treats most other product-release links.
This isn’t supposed to be a place to promote products. But we’re aggravatingly inconsistent about that policy; see https://lobste.rs/s/bed56d/mecha_comet_modular_linux_handheld for a recent example.
Caveat: I haven’t flagged this article.
I think spam (“for links that promote a commercial service”) is more applicable than off-topic (“for stories that are not about computing”), but I honestly can see both applying. The reason is this has very little technical detail. The article spends about 3/4 of the words talking about the company’s climate change policy and 1/4 talking about the newly released product. Basically only one (smaller) paragraph gets into any technical specifics about what makes this board different from others.
I’m happy to see a new Raspberry Pi model get released, I’m glad the company is considering how to take care of the Earth, but it certainly seems intended simply to sell the new Raspberry Pi, hence promoting a commercial service and I don’t see how it fits this criteria:
So why haven’t I flagged? As of my writing this comment, my flag would be the balance between positive and neutral votes on the article (+15, 14 flags). This article isn’t so egregious as to make me want to be That Guy and flag it down. Others that feel differently may vote their conscious.
Jeff Geerling did a very in depth review and benchmark of this, which probably would have been the better link to post: https://www.jeffgeerling.com/blog/2025/who-would-buy-raspberry-pi-120
No it is not, and never was.
Indeed the selling point of several Pi rivals is that they are open hardware.
The Pi is entirely closed and not very standards-compliant. It uses closed-source firmware based on ThreadX, and has a unique design and startup sequence: the VideoCore GPU is the primary processor and it loads code into the Arm. Thus the Pis can’t even run a normal Arm bootloader without work, and there is nothing resembling UEFI on them.
Some distros, such as openSUSE on Pi, start by softloading Das U-Boot as a more standard bootloader, and then load the OS from this, just to get the hardware into something closer to a more standards-based Arm computer before loading Linux.
Is it still true for Pi >= 4? https://developer.arm.com/documentation/102677/0100/Set-up-the-Raspberry-Pi explains how to run UEFI on the Pi 4.
Yes.
AIUI the simplified boot process is this:
The GPU boots the computer, loads the Arm code image from SD or wherever, places is it RAM, initalises the Arm core(s) and sets them running what it put in RAM.
If you want, you are perfectly free to put a UEFI loader in that RAM – but don’t kid yourself: it’s no more in control of the computer than the passenger in the front seat of a self-driving train.
Apologies for that … must’ve been a false memory implanted by the aliens.
In fairness, it’s a widespread belief that I’ve seen a lot in other places.
The Pi Pico is FOSS, I believe, but it’s not a general-purpose computer.
The Picos and RP2040 and RP2350 are thoroughly documented but they don’t go as far as being open source. Last time I looked, the Pico board designs are not published, though the reference designs (for the PCB design guide documentation) are available. Some parts of the chip are published, such as the firmware source and the RISC-V cores, but other parts developed by Raspberry Pi Ltd such as the PIO cores are not published. (And of course most of the big IP blocks such as the ARM cores and USB controller are proprietary to other companies.)
Yeah I guess the original title (“16GB Raspberry Pi on sale now at $120”) could be interpreted as being a sale as in promotion, versus just the release announcement which happens to mention the price in the title. Didn’t even think about the confusing wording when I posted this, I just re-used the original title, but I can see how someone could think it’s off-topic.
IMHO more off-topic than spam, but either way its a product announcement for a minor variant of an existing product, hard for something like that to be on-topic (vs new generations where one often can argue that something fundamental enough has changed that it maybe deserves attention. But even then there are limits)
I haven’t tracked a lot of hardware in this class, but the overall price with the doubled RAM seems noteworthy?
I fondly remember rescuing one of the older models from e-waste and turning it into a more “persistent” alarm clock. I know a colleague that runs a whole rack of Pis for various hobbies. I do figure you’re likely more to get storage I/O bound than RAM bound first, but they still fill an interesting niche for a cheap, “beginner” device.
That may still be true… but these model 5’s are a big improvement in IO throughput compared to previous ones, including first class support for an m.2 nvme daughterboard. It’s a huge step up from the days of doing everything on a microsd card.
Because it’s an ad for a single board computer. In what way is it relevant to lobste.rs? I’d not like it if lobste.rs to be a feed on any kind of ordinary computers.
With “any kind of ordinary computer” I mean that it’s not some world first implementation that is also being discussed.
On top of that the article is not just regarding an ordinary computer it’s also just an ad. There’s nothing setting it apart in content from most other ads out there.
Mods have since improved the title, but two reasons. (1) “X on sale for $Y” is always functionally an ad, even though it’s a plain statement of fact, since its function is to encourage the reader to weigh up buying one - IMO Lobsters don’t need that in their feeds; (2) the article itself has scant technical content to discuss, leading me to the conclusion that the main point of this submission is “hey maybe you want to buy this thing”. To me that’s spam regardless of whether the submitter benefits or not.
Look, I’ve been around since the 1991 green-card-lottery spam on Usenet that coined the term, and what you’re describing is not what “spam” means. This was posted one time by an active member, for informational purposes. You can dislike this sort of post for whatever reason, but use more accurate wording.
The Lobste.rs about page notes how it is defined in this community, which is different from how it was originally used.
In this case, spam simply means this article is by a commercial entity attempting to sell one of its products, with very little technical benefit. Not that people believe the article is trying to sell us pills or a new stock market scheme.
The most interesting part of Gemini isn’t exactly what it can do technically (not a lot) or how suitable it is for displacing modern web use (not very) but that at every step of its development it was designed to be difficult to extend. Solderpunk grasped the fundamental issue—the tech world’s obsession with change, iteration, obsolescence. It’s a radical act to create useful software that isn’t supposed to change. Something that never scales up doesn’t have to scale down.
I don’t know what the answer is yet. Maybe with the benefit of hindsight a more versatile Gemini 2.0 might play a role. What I do know is that a mindset shift is required. Adding and changing things needs to be seen as the cost it is. When Google pushes some ridiculous Bluetooth thing into Chrome then most browser vendors should be shrugging and ignoring it. Users should be asking “Why did you implement this silly feature? We already have perfectly good ways to do Bluetooth.” Sounds improbable to me unfortunately.
(Edit: I have to call out myself for saying “Gemini 2.0” in the same post as criticising iteration. It shows how ingrained this is that I managed to submit it without noticing the hypocrisy.)
Gemini makes the fundamental mistake of assuming the ills of the modern web are due to technical factors (like JavaScript being enabled on web pages) rather than economical/societal (there’s a lot of money to be earned by tracking people online).
I’m not sure that’s so clear-cut. Consider runtime permissions on iOS and Android apps. Together with sandboxing, these technical measures are a fairly successful way for users to manage their privacy and focus, without fixing any of the factors that cause apps to be addictive nuisances in the first place. To take the analogy further, we only got these things by building entirely new consumer operating systems that didn’t have the legacy baggage of desktop OSes where sandboxing is generally absent. I think if a similar “expectations reset” could be achieved for the web then it could be very beneficial on its own, even if the legal environment and issues of political economy are still playing a role.
The web has a very strict sandbox, not much different from what mobile OSs have. Like, a website won’t have access to Web USB without explicit user action.
I think avoiding privacy violations is only marginally affected by improving security, proper privacy has to be forced via laws.
The problem is that all of this isolation is implemented with complex software. A modern OS kernel is ten million lines of code or more. A web browser is even bigger. As I often repeat: isolation is easy, sharing is hard. It’s easy to create a completely isolated environment (just use a separate chip) but OS processes need to share access to hardware, abstractions over that hardware (e.g. filesystems, network protocols) and pure-software communication paths (shared memory, message queues, and so on).
Operating systems often contain bugs that allow you to violate their isolation properties. They are also prone to misconfiguration bugs (for example, it doesn’t matter if filesystem permissions are correctly enforced if you accidentally make all of your confidential files world readable). This is less of an issue in a world of personal computers, where each computer has a single user and they run only trusted apps, as in the early days of home computing. It becomes a problem when an attacker can run arbitrary code in these isolated environments, such as by making you install a malicious app or exploiting a vulnerability in a non-malicious but buggy app.
The problem with the web is the degree to which this is possible. By default, any server that you connect to, including ones that typo squatted or were referred by malicious ads, can run arbitrary code in the sandbox. It’s far easier to escape from a sandbox if you can already run arbitrary code inside it then if you have to first exploit a bug that allows arbitrary code execution.
This is precisely why many of us choose to browse in allowlist mode instead of assuming script execution. A lot of folks try to tease me about it saying the web “just works like this now”, but I don’t see why we should treat it that ways (in the same way you allow access to your locations, & so on). Normalizing allowlisted JavaScript browsing would encourage good
<noscript>from site maintainers too.You are completely right from a technical perspective - I just don’t see how it relates to the “ills of the web”. Of course a smaller surface area can provide better security, but that’s not the core issue (e.g. a company storing your data in plain text and then leaking due to bad practices on their server’s end) - questionable business incentives and not enough responsibility are.
For example, tracking can’t be avoided in a strictly technical way, in my opinion. A program that can communicate with a server (which is often a core part of the very functionality of the program, so you can’t ban it) can trivially do many forms of analytics, but ads are another such example, them being an infinite cat-mouse fight between ad providers/blockers.
Not sure I like the analogy.
HTML wasn’t originally easy to extend, per se. You can only say that if you missed web development ca 2000 to 2010, the browser wars, fighting to get the most ridiculously small thing displayed cross-browser. Unless you count “I invented a new tag no one supports” as “easily extendable”.
It somehow worked, and not only by tech companies with their market leading browser strong-arming the others, some web working groups did useful work.
That is how it mostly worked in the ‘90s. Browsers added new tags as differentiating features. I owned entire booklets of tags listing which browsers they worked with. And they were obsolete within six months as other vendors caught up with supporting any tags that HTML authors enjoyed using.
This kind of incremental evolution worked fairly well, though it left things like img with alt as an attribute rather than the graceful fallback text in between img tags, and object vs embed for the same things. W3C did heroic work to bring some sanity in, but usually software and standards evolution follow this path: explore a load of the design space, see what works, and then standardise around that core.
I guess that’s one way to describe it, but I disagree - if there had been a universal graceful fallback, yeah - but my experience didn’t match that. I’m not saying it was not extensible to some degree, like, compared to a binary protocol where every parser just errors out (not even XHTML 1.0 strict was that bad, as you could ignore the DTD) - but we can still view the same websites as they were published in 1996, so that part still works.
But then it has to actually be useful. Creating something good enough that it can be unchanging is hard, and probably requires iteration!
I think you’re right; don’t worry about the fact that “Gemini 2.0” sounds hypocritical, or maybe call it “Gemini bis”, or maybe Pollux (one of the Gemini twins).
I’m currently attempting to leave a room in my Matrix account on my self-hosted Conduit instance, in element-desktop. When I clicked the leave room menu item, the client threw up a loading spinner for a while, then said there was an unexpected error leaving the room, and now I have no idea whether my user has in fact left the room.
I’m not sure if the problem here is Conduit, or something about how I’m hosting it, or something with element-desktop; in any case, it’s not the first time I’ve run into weird issues when trying to join or leave a room. Maybe I should try running a synapse instance again (the reason I stopped that and went to Conduit a while ago is because I thought the improved performance of a lightweight Rust homeserver might help with some joining/leaving issues). I could go back to my account hosted on matrix.org, but it sort of defeats the purpose of a federated protocol if I can’t run my own node and have it work reasonably well.
Anyway, I wish I could say that my Matrix experience felt less clunky than Signal, but that is unfortunately not currently the case. I really wish I could say it felt less clunky than Discord because Discord is what everyone I know uses to communicate and what they need to not be using, but that is certainly not the case now.
Also I just checked https://github.com/element-hq/element-meta/discussions/1681 and am disappointed to see that support for multiple matrix accounts in Element is still not ready to go. This is a feature with a huge amount of demand, that demand has been constant for many years, it’s something I personally have wanted for many years, and I really do not see why it is so difficult to implement.
FWIW I was experiencing a similar issue with a synapse homeserver run by a buddy. The room got stuck, not showing me any events since Sep 2023 and I was getting a 500 popup every time I tried to leave.
That’s just one bug of course but I ended up deleting my account and reverting to IRC because there is a more fundamental flaw in Matrix for public use - (1) the entire network is TOFU and it’s easy to get an anonymous account; (2) rooms display images and shared files by default. The kinds of things I’ve seen in benign programming rooms before the mods woke up to delete them… good grief. Hardcore gifs. Zip files suggesting they contain extremely illegal content (whether they do or not), one click away from your homeserver caching it. There is only so much you much abuse you can pack into an IRC connection (especially with anti-flooding protection) and that’s a feature.
There’s been a coordinated attack on Matrix over the last year by folk(s) posting illegal content to try to wreck public rooms and get outcomes like this. In retrospect clients should probably default to hiding images by default from folks you don’t know/trust; on the plus side we’ve managed to expand the antiabuse team in the last month or so, which should help combat in future.
That sound like a problem with the server. If the leave is successful, it gets echoed down sync and only then takes effect; so if you appear to still be in the room, you are likely still in the room. Writing state events (the key/value data stored per room) is still painfully slow in Matrix, although we’re working right now on speeding it up in state res v3 (mentioned in the OP).
Conduit has empirically taken a slightly fast & loose approach to implementing Matrix - so while it uses less resources than Synapse, it definitely comes with a beta label. Meanwhile, Synapse is certainly slow at joins/leaves still, but is boring mature and stable (and is using less resources over time, especially as hot paths get rewritten in Rust).
Fair point on joins/leaves. The performance here does seem to be a bit of a blind spot for the team (perhaps because powerusers tend to keep with a single set of rooms which doesn’t change that often, or perhaps normalised deviance to the bad perf). I’ve personally tried to push join perf loads over the years - e.g. with https://matrix.org/blog/2022/10/18/testing-faster-remote-room-joins - but it’s ended up stuck in a weird place where the hard bits (non-atomic joins) got implemented, but the actual benefits still haven’t been fully realised due to other non-perf customer-funded features taking priority.
Yup. Element X is targetting WA/iMessage/Signal first, and Discord/Slack later. (Element Web/Desktop itself hasn’t really had the Element X rework yet).
The Element team has ended up prioritising stuff that customers offer to fund, and, frustratingly, almost none of them have explicitly asked for multiaccount on web (on the basis that you can open multiple tabs instead). On Mobile, Element X has been built with multiaccount in mind (and there’s actually a unreleased build of Element X Android which uses it), but getting parity with the old app has taken priority there.
I agree that it’s a very desirable feature, especially on mobile, and can’t wait to finally have it.
(posting with my Element CEO hat on, in this instance)
This is indeed incredibly frustrating. I was surprised six years ago when it wasn’t a thing, and while I’m no longer surprised now I’m obviously still disappointed. Federation is both great in some respects, and also not a substitute for multiple account support.
I think the difficulty is that they (the Element folks) just don’t want to do it. Apparently the VoIP stuff was more important, despite literally none of my users asking for it and some of them being at least a bit confused about why it was now possible to bump a button and call someone by accident in a chat program.
An implementation of Slack style threads (already a horrendous idea) that you can’t turn off, and which doesn’t work especially well, was also apparently more important.
as per https://lobste.rs/s/oswvfj/matrix_holiday_special_2024#c_h3llef, the Element folk very much do want to do it. But we want the existing features to be improved first, plus we can only work on it (given we’re operating in hand-to-mouth mode) if a customer funds it.
FWIW, I understand the situation with customers and funding. It’s a tough spot to be in. I’m also, despite the constant stream of issues over the last few years and a (my) user community that has increasingly vocal contempt for the software as a result, still bullish on the platform – because I am not sure what else exists that has the same level of openness.
On the other hand, it’s really hard to stand up for the software. These blog posts talk about how the software is competitive with features and stability and performance of other platforms, and it feels like you’re living in a different universe. I think the stabilisation work on the encryption has been incredibly critical, because it was dire before, and it now appears to finally be mostly fine in terms of issues people actually hit, which is a big improvement!
But I don’t know what’s going on with Element web:
This is just the stuff I can think of in a few minutes right now. I field a constant stream of support issues like these. I encourage people to log issues, and we do sometimes, but it doesn’t feel like they result in improvements. Then we read congratulatory blog posts like this and it’s hard not to feel like we’re being gaslighted. I appreciate the Matrix ecosystem, and again, I understand what a struggle it is to work with limited resources – but I wanted to try and let you know that I’m barely hanging on here as a supporter and it’s not easy.
Well, thanks for sticking with it, i guess.
Basically, the web team has been understaffed over the last year - the vast majority of effort has been going into the Element X project on mobile, which in turn focuses more on personal messenger (iMessage/WA/Signal) use cases rather than team collaboration (Discord/Slack). The issues you describe here are all ones on the team collaboration side of the house - and ones which online communities hit rather than enterprisey deployments. Good news is that the expectation is to improve Element Web over the next year (hopefully funded by zendis.de), so we should make some progress.
In terms of presence, i vaguely remember there being a nasty performance regression in presence at some point in the last year or so in synapse (although can’t find the PR now). However, presence has never been fully optimised and we don’t run it on our own servers, which explains why it is less than reliable.
I’m not trying to gaslight anyone, ftr - the difference is simply that Element X is something to be proud of (imo), even if Element Web clearly needs love. And the congratulatory blog post here is in part reflecting the fact that we’re (almost) in position to fix Element Web too.
We’re not a massive company, but we’re definitely an enterprise deployment, FWIW.
Is it not something that your enterprise customers demand?
I mean… kind of? I agree that it has recently, especially with sliding sync making it into Synapse, become tenable as an extremely basic messenger. It’s basic though, and lacks polish; e.g.,
FWIW, even if the focus is only on “personal messenger” features, I would encourage you to add Telegram to the list of applications you’re looking at. The service is obviously dubious, but the clients are stellar: their mobile applications are feature rich, high performing, and essentially glitch free as far as I can tell. If Element X felt like the Telegram desktop application, I think there would be a lot less griping, at least with respect to the personal messenger use case.
I hope so, and I wish you luck! I think that would help a lot.
Ooh, interesting. One of the constant battles we have on defining the direction for Element is the extent to which “community features” (i.e. stuff which folks used to IRC or other FOSS community collaboration tools are used to - e.g. topic must be visible in the titlebar at all times; colour hashing changed) apply to workplace deployments who (in theory) pay the bills. Can you give me an idea of roughly how large your deployment is, and what the split is between developers and non-developers, and what demographic the feedback is coming from?
Nope, “Bob was last seen 30m ago” as a requirement comes up very infrequently. Folks seem to find that read receipts are at least as good as presence info.
Hmmm. The first two bugs are EX Android specific. The Android app /is/ a little less polished than the iOS one currently; i personally daily drive EX iOS and that’s what the commentary in the blog post is based on; it really is a nice app. Luckily the polish required on EX Android is all cosmetic, and all the heavy lifting is provided by matrix-rust-sdk which is shared with EX iOS. Guess we need to find a way to dial up polish on Android.
This is a feature, for now. commonmark doesn’t have colours/tables. headers should work, although the larger font sizes get crimped down.
It should be consistent with Element Web though; if not, that’s a bug (again, i wonder if something’s gone wrong specifically on Android).
Amen to that. Please upvote https://github.com/element-hq/element-x-ios/issues/2478 to try to get this or an equivalent solution back on the radar.
We do, and agreed that the clients are stellar, and it’s the target which we’re chasing on Element X.
thanks, and thanks for the balanced feedback.
I think the priorities are set to a large degree by paying customers. The big ones want an alternative to ms teams so video is important
If you stop running your own hs, don’t go to matrix.org. Pick any other large hs.
Kate has become my editor of choice these days, which I use with the Rust and Go LSPs. Very broadly speaking it’s an equivalent to VS Code except Qt instead of Electron and a real preferences UI. It’s fast and effective and I don’t have to use questionable forks to avoid telemetry or anything else MS want to promote.
Clementine Music Player is a lovely music player for desktop. It’s inspired by Amarok and has just the right level of features for me with library management, fixing tags, ad-hoc queuing and so on.
Kate, what a blast from the past!
I am passively looking for a good python development environment mostly for debugging, especially remotely if possible.
I tried vscode but it duplicates my environments and has problems with collaboration (besides the evil corp shenanigans).
Also tried spyder but crashes one out of two times when debugging.
My scenario is mostly numerical computing where python is just syntactic sugar on top of C or Fortran libraries. E.g. numpy, scipy, tensorflow, cvxpy.
I have not used Kate since the early 2000s. Is it a good fit for this?
Thank you!
P.S. – my stable setup for a decade now is vim+ssh+tmux+ipython, debugging sucks everything else is super-duper
Two years later, this is hilarious to read. For two years, they shipped a version of bcachefs-tools that simply didn’t work at all. Why? Well, they were shipping bindgen 0.66, which had a severe miscompilation bug that made bcachefs-tools simply not work. bcachefs-tools specified a minimum of 0.69, the version that fixed the bug, but the Debian maintainers patched it to allow 0.66. They shipped that broken version for two years in testing, and then decided to simply drop the package, because it was “too hard” to maintain.
It doesn’t necessarily apply to this scenario, but in general terms if someone said “I’m trying to maintain a stable distribution here; your software is neat but the dependency sprawl caused by your language choice is more or less YOLO so I’m just not going to ship it” then I think that would be a defensible position.
The only thing that’s YOLO is Debian’s choice to randomly patch stuff that they don’t understand. This isn’t just an issue with Rust, they’ve shipped horribly broken C stuff too!
So-called dependency sprawl is a red herring. Two different C programs can depend on two different versions of a C library. It’s a thing that happens. And Debian either packages two versions of the library or they break things. It’s been a problem for decades at this point. Rust just took a sledgehammer to the issue and made it impossible to ignore that Debian’s practices don’t really work all that well.
I think it would be a defensible position if they found a better way to deal with breakage such as the above. A number of places use a similar strategy.
It’s been a frequent issue with Debian that they would stick with horribly broken packages in the name of policy, e.g. it has driven a lot of Rubyists away from using apt. (Won’t got into details, but Debian Ruby was broken between 1.9 and 2.x for a long stretch to the point where no one was willing to assist someone using it)
Context: https://jonathancarter.org/2024/08/29/orphaning-bcachefs-tools-in-debian/
I love fish…except that it doesn’t have ctrl-O (execute line then select the next command from history) and I don’t know what the workaround is. I switched anyway, but every time I have to do something repeatedly that takes more than one command, I feel like I must be missing something. (Am I?) I have ctrl-R, blah, ctrl-O ctrl-O ctrl-O in my fingers from years of bash/zsh.
Wow, TIL. Thank you.
Using Unix for > 25 years now. Never heard of C-O before. Thanks!!
Execute which line? The current input? The once the executed comand terminate, what do you mean by select? Putting it in the promot input?
Why is this practical? Why do you want to runa command and then the one you have executed before?
Either way, sounds like something you can implement in 3 ton 5 lines of code.
I’ve never seen this before. Is this like !! ?
In bash/zsh, after you find a command in history with c-R, you can go up and down in history with c-P and c-N, and you can execute a command and immediately select the following command with c-O. So if you have a sequence of commands to repeat, you c-R back to the first one, then repeatedly do c-O to execute the sequence. (This is assuming emacs keybindings.)
Fuzzy history search in fish doesn’t seem to be related to the chronological history list. It just pulls out a single command with no context.
So I’m hoping that now c-R is incremental in fish that it can do the bash/zsh thing, but I haven’t looked at the beta yet.
…I really need to read more documentation. What a time saver I never heard of.
cross posting to say: I am one of today’s lucky 10000..
Ooooooh. Neat, yeah I can see the appeal.
I’m glad I’m not alone in this! It’s extremely rare to see someone mentioning this feature.
In zsh it’s also possible to select multiple completion candidates with Ctrl+o. I miss it even more than executing multiple history lines. There is an open issue about this, but it’s pretty much dead. https://github.com/fish-shell/fish-shell/issues/1898
I wonder what would happen if GitHub projects had two types of star - one for the code/implementation, one for documentation. I’m not sure what fraction of developers are working for dopamine but steering that effort could be interesting.
Twice as many stars to sell with bots.
IMO this is a problem in the foreign code. As a frequent writer of async code I would never make that assumption. You indicated your desire to work towards some goal the moment you called the function. Maybe it’s cancellable, maybe it’s not, but your side effects are locked in.
I’m not familiar enough with the tracing ecosystem to understand why their specific example is not following their expectations but to me this isn’t a problem with futures in general.
What does that even mean? What if your future has to capture some shared state via Arc? Does that have to be a Weak now until it’s polled the first time, and potentially fallible if it can’t acquire the necessary prerequisites?
Simpler idea: if you don’t want a function to happen, don’t call the function.
Someone linked me to their codeberg repo the other day and I was amazed how slick it was. If the forgefed protocol ever really gets off the ground (cross-instance pull requests!) I think forgejo becomes unstoppable. I get that email-based patch workflows are already federated but I just haven’t got around to learning it and PRs are pretty intuitive.
I did some poking around and honestly, Forgejo looks like everything I’d want out of a forge these days. I’m a bit surprised to see it even includes CI. A lot of smaller companies should probably be using this instead of Gitlab.
Have the Forgejo developers shown any interest in supporting self-hosted CI runners on Windows and macOS? Or is that specifically out of scope for them because those platforms are proprietary?
I believe there isn’t an active movement for using anything outside of their fork of
act, however their docs stateSo, technically speaking, someone could write a runner that runs on any platform that can connect and respond to the protocol (and what happens after that seems to be up to the runner itself).
I may be mistaken, but I think they just don’t provide pre-built binaries for those OSes. But you should be able to build
forgejo-runneron your own for them.Hah maybe I should have a crack at it. I really don’t like the act/GitHub Actions based runners, though.
I had another look and the runner seems to build fine for/on Windows.
PRs are so much work compared to
git send-email --to list@project.com, or piping the current email togit am.What may be interesting is a bridge that converts pull requests from forgefed to email, so I don’t have to ever interact with the hosting website.
The proportion of software engineers who have the living knowledge base of how to use PRs seems far greater than those possessing the knowledge of how to effectively use
git send-email. Maybe it’s true thatgit send-emailis much less work once you know it (I don’t know, never tried, only project I know of that uses it is the Linux kernel) but any “less work” analysis will have to account for the work of training others how to use it, amortized over the number of patches they send. And for open source projects seeking contributors, removing friction to initial contributions is everything.I really don’t think PRs are more work. I just
git push myorigin, and it prints a URL. I click it and, if it’s a simple case, just click Create PR (if it’s a complicated case you have to write a cover letter, just like you do with email). It takes longer to figure out what email address to send to forgit send-emailthan those two clicks.The real benefit of forge PRs comes after the initial send. I can force push to update the PR instead of having to resend emails, as often as I want, without spamming people. Countless times I noticed a mistake after the fact and quickly fixed it without having to bother anyone.
All review comments on the PR are linked in one convenient place and with a rich UI where you can expand code context without having to cross-reference a code editor manually. It’s almost impossible to review complex email patches without manually digging up context (and visualizing how the patch applies mentally, unless you manually apply it for real so you can use Git tooling!). I find that this encourages “lazy” email reviews that only consider the immediate code context because it’s too much work to pull up more, which often waste everyone’s time because the comments turn out to be invalid when considered with more code context. Meanwhile, a forge PR can be reviewed entirely in the forge, pulling up as much code context as you need on demand with a couple clicks. Comments are tied to the code context, such that you can see all comments from different people on one piece of the code together, instead of having to walk through separate email subthreads. Other PRs can be linked directly and commit IDs are clickable. Reviewers can suggest code changes that can be applied directly with one click.
Review and commenting occurs in parallel in one place, without having to break the conversation into discrete “versions” that are re-sent as unique PRs (and often end up with duplicated discussions as new people join who missed the context). That means I can be working on discussing changes A and B while I’ve already fixed C as C’ and someone is already reviewing C’, and D is already considered good and need not be re-sent to anyone if nobody has any comments on it. The UI automatically hides obsolete comments after that particular part of the code is updated (but you can still click to read them). There is an explicit concept of “resolved” conversations so you can keep track of every review change without having to do it manually in a text file or something (or worse, in your head, and then forget a few days later if you have to set the PR aside for a bit).
It’s easy to enumerate at a glance open PRs for a project, and there is a consistent notion of “closed/merged”, unlike email where there’s no programmatic way of doing that that doesn’t involve parsing human language with heuristics. And anyone joining in from elsewhere can just do it, without worrying about being subscribed to the ML or CCed in advance, or else they don’t have context in their inbox and have to cross-reference an ML archive or manually import messages.
And actually merging the PR is way easier too, just one button click for a whole series of commits vs. using something like b4 (which isn’t even part of Git itself) to download the mbox and apply it, or doing it manually via bespoke email client workflows message by message (and then if your email client doesn’t preserve whitespace properly, you’re in trouble). Plus a PR is explicit about the base commit, while bare patches aren’t, and then you have to either guess, ask, or ask for a rebase when they don’t apply (and Git can’t do useful automatic conflict resolution without a base commit,
git amjust gives up, unlike a rebase where you get conflict markers etc.).And then there’s the manual email editing, and the endless nested quotes. That’s just a poor workaround for lack of rich, fine-grained threading and grouping with context! It creates visual clutter and slows everything down, because if I’m reading an email thread in sequence now I have to skip over all the quotes which I just read, and if I’m looking at a leaf message far down it was probably trimmed too much and I’ll have to look at the parents for context anyway. Clearly if you have a data structure which is a set of messages and replies to specific code context points, grouped by author/review, the efficient way to manage it is like that, not flattening it out to emails with duplicate context to make it fit a medium that cannot efficiently represent that data structure. Consider that a review implies commenting on multiple pieces of code, and while there is value to grouping them together, the comments usually stand alone. But nobody does email review like that, one comment per email. They get grouped together in one reply, and then replies to that splinter off, but the email metadata does not tell you which part of the email, which review comment, the reply is a reply to. And on the other hand, when the review is of multiple commits which are related, email has no way of grouping those together, because you can only reply to individual patches. I can fit a dozen comments and replies in one screen in a forge including the original code, while with email I can only fit one message, which might or might not have arbitrary context which may or may not be what I need depending on what the authors did while trimming quotes. And I can scroll up and down through the discussion seamlessly, while with email I have to jump from message to message (or at best get a GMail type view which is just a heuristic and may not get the threading/context right). Email is just not, at all, the right data structure to do complex code reviews with.
There’s endless other reason to use a forge depending on what you’re doing. For example, if your project involves artwork at all, forges can display and even diff images for you, while email clients just see a huge blob of base64 (because email flows also can’t integrate with attachments, which are actually the native mechanism email has for sending files). And that’s if your change even made it to the inbox and wasn’t dropped for being too large. Some projects have multi-megabyte resources and that simply can’t work with email, while Git handles it fine, especially if it’s an efficiently delta-able binary format (or there’s git LFS, which might kind of work with email if you send the changes to the LFS blob store and only email the identifiers, but I don’t know if anyone does that and why would you do that instead of using a forge with LFS integration?). Same with better integration with CI and code quality bots (which can suggest changes or fixes, and again those can be applied without the author having to re-send the entire PR, including going through several attempts at fixing a CI problem without spamming every human in the conversation).
There are already several solutions along these lines. You can provide email interfaces for a forge flow, because it’s easy to go from rich structured content to plain text, and degrade gracefully when replies can’t be parsed back into rich content. The converse is nearly impossible.
Honestly, my intuition is that PRs provide at least a several-fold improvement in overhead over email flow. And for small changes overhead dominates the overall time spent on the whole change. The PR flow is also much friendlier to newcomers (just ask people).
Sure, with a forge you have to create an account upfront, but that is amortized among projects using the same forge or compatible login providers (quite common these days). And quite frankly, I waste more time dealing with the overhead of a single complex email code submission and review than it takes to create a forge account from scratch, with manual email/password login (if it’s OAuth then it’s just two clicks and it beats even simple email code review overhead).
Source: I regularly contribute to both large forge flow projects (Mesa) and the only large notable email flow project (Linux) and I very, very much prefer the forge flow. Even for simple changes like this one which had no review comments and didn’t need any of the post-send PR flow features I just mentioned, the email flow gives me significantly more anxiety and mental overhead, and that’s using
b4 prep/b4 sendwhich is already a huge improvement overgit send-email.You’re allowed to feel that way. I absolutely loathe the PR review UIs I’ve had to use, and I think that the foregefed protocol is a good opportunity to allow me to ignore them completely.
The way activitypub, (and by extension forgefed), works is already extremely analogous to email. There are already projects that serve activitypub via imap. Fully bridging to email seems quite doable, and I won’t be forced to conform to your preferred workflow.
IMHO a major failing of the email based workflow is that it doesn’t preserve enough commit metadata. Including the parent commit ID would help figuring out conflicts as well as avoiding missing dependencies. If the exact commit could be transferred via email it would also help future merges and updates as Git would understand that the commit that you sent as a patch is the same as the one applied by the maintainer. Right now that information is lost and when merging upstream back into your branch it can become a huge pain to resolve all of these false conflicts.
It’s also really hard to send a follow-up v2 patch that shows up in the same thread as the original. I’m a huge email fan in general, but
git send-emaildoesn’t actually benefit from the main advantage of email flows because it doesn’t let you send using your existing mail client you already know how to use! As a result, I mess this up like 50% of the time.git has a way to attach this and it’s suggested eg. for kernel patches: https://people.kernel.org/monsieuricon/all-patches-must-include-base-commit-info
Agreed on other points.
I just do
git push origin HEAD:refs/for/main -o topic="branch-name"and let the magic of the AGit workflow do its thing (most recent example here). I do need an account on the forge, but if I plan to contribute to things hosted there, that’s a very small price to pay.Other than that: I just clone the upstream repo, do my thing, and
git pushaway. I get reviews in email, and can push my updates the same way, with a simplegit push. It’s bliss, I very, very rarely have to interact with the hosting website. And even in the rare cases I do: it has an API, so I can do all my interactions through Emacs, after the initial registration.Merging PRs is similarly doable without interacting with the site, and doesn’t even require anything but git itself.
Forgejo + AGit is <3.
They’ve made PRs super easy, honestly. When you push to a fork the server sends back a URL to create a PR and you just fill in the title and description like you would write in an email. If there’s only one commit, those are filled in for you. That’s less work than mailing around patches for me at least.
It’s even better when you discover the AGit workflow: you don’t even need to fork. Clone the upstream repo, branch off, do your thing, and you’re a single
git pushaway from a PR.No fork, no email, just
git clone,git checkout -b, andgit push.That’s how gerrit (which I mostly use for work) does it, and I find the GitHub PR flow so confusing and crufty in comparison.
I like Forgejo and I think Codeberg is doing really good work there.
On the subject of email-based workflows… as a contributor, I like to be notified if my PR ends up having conflicts with the mainline so that I can fix them, for example. As a maintainer, I like being able to see all open PRs. I like suggestions in code reviews that contributors can just accept in one click. The list goes on. I’m not against creating PRs by email, but I really wouldn’t want to be a part of a process where
git send-emailto a mailing list is the only available tool.It’s not that hard to write tooling that makes opening a PR as easy as
git send-mail.The fundamental issue is that
git send-mailworks with email addresses, whereas PRs work with accounts on a git forge. Email addresses are in some sense more decentralized internet IDs than accounts on a git forge are; but both have serious issues.You don’t even need to write any tooling, because it already exists. It’s called
git. As long as you have an account on any Forgejo instance, you can justgit pushusing the AGit workflow.No need to visit the web UI, no need for a fork. Just clone the original repo, then git push your branch, and a wild PR appears.
My ideal Forge would be one that would offer all forms of workflow at once. You can use ForgeFed, you can send email to create “PR” and for internal developers/core team you can use stacked diffs.
I’ll reserve judgement but I’m not confident this is going to be a great experience for everyone. Spammers, griefers, LLMs, all able to spring up from any domain straight into your issues and PRs, with no central account management to control abuse… It’s a tough gig.
Good comparison for this would be mastodon replies. In theory anyone could spin up an instance and spam you. In practice your instance moderators do a good job on spam detection and defederating malicious instances, so this isn’t a problem
This is one of the better criticisms of bsky/atproto I’ve read. So glad to read a good one. Just two comments:
DMs were added out of protocol for exactly the reason the author suspects: users were clamoring for this functionality, and doing it right will take a while. So they’ve alluded to plans to bring them back into the protocol, but for now, most people are okay with trusting Bluesky and being able to do what they want to do. It’s effectively a non-regression from the point of “I’m migrating from Twitter.”
It seems like this integration has disappeared, as far as I can tell. They didn’t say anything about it publicly that I saw.
Trusting Bluesky for DMs privacy wise definitely beats whatever the DM situation is on Mastodon where you have to trust random admins you do not know.
Personally I am baffled by this mindset. How can a company that has every incentive to data mine everything that touches their servers be any better than a random dude without any such incentive. Granted the dude might be a creep, but I think these people get found out pretty quick… the simile of “many eyes make all bugs shallow” can be applied here. People smell a rat quite quickly on the internet.
I think both are reasonable. Some people prefer to only need to trust one party, instead of needing to re-figure out trust every time they message someone on a different server.
I personally just never put anything that I wouldn’t mind others reading into something that’s not E2E encrypted. I wouldn’t put something into a bsky DM that I would be upset with the team reading anyway.
I do think the risk is smaller than a lot of people make it out to be, but the odds of my fedi admin knowing and caring enough about me to snoop on my messages is significantly higher than that of a Twitter sysadmin.
I am actually exploring a user encrypted storage option for the ActivityPub service I develop.
Theoretically vanilla ActivityPub should support everything out of the box, but I don’t know for sure if the HTTP-Signatures that the protocol uses for inter-instance authorization would work when the private keys are not stored on the server itself but only on the client.
Why would you think that?
Because a lot of people are on fedi instances operated by their friends, or (if they aren’t already friends) users and admins on small-medium instances will inevitably get to know each other. There’s a lot more motivation to snoop on people you know, because by and large you don’t care about the private lives of complete strangers (and, frankly, it’s much more likely to cause me problems if someone I know snoops on my messages compared to some twitter sysadmin I’ve never met).
Obviously you’d hope nobody’s going around snooping on their friends’ posts, but people you thought you liked turn out to be shitty sometimes.
OK that makes sense.
I guess the snooping that large companies are incentivized to do has a more diffuse impact, like everyone buying slightly more useless junk, with less risk of acute harms as long as you stay within certain bounds.
Bluesky and Mastodon have enough public data. There is little incentive to go after private data. It’s high risk, low reward.
It’s worth saying that Elon Musk can read any DM ever sent on X.
Can he? I thought Twitter DMs were E2E except group chats and media.
As usual, Elon lied about a feature: https://9to5mac.com/2023/05/11/twitter-encrypted-dms-3/
How is it I keep needing to lower my expectations?
I generally agree with you, but I think the idea is weighing the difference between a corporate entity which nominally has certain legal compliance obligations and may offer a degree of transparency versus a completely random individual human answerable and transparent to nobody. Neither is inherently trustworthy, but they are certainly untrustworthy in different ways for different reasons.
Companies are very careful with private data beyond what the TOS permits for good reasons. Individuals are always problematic even with the best intentions. You lurking at private data in a company is a firing offense. You doing that out of power on a mastodon server is something that would not be spotted let alone be something that’s particularly problematic for you.
20 years ago I had an email address managed by an acquaintance of an acquaintance and eventually we figured out that they had a bash script running looking for keywords. Was definitely a lesson for me.
Google knowing what’s in my e-mail affects me far less than people I know and deal with regularly knowing what’s in my e-mail, simply because I don’t personally know Google and they don’t know me, and have no direct personal or emotional involvement in me. Likewise, if I’m on a mastodon server run by someone I know, them knowing what I’m DMing about is creepier by default. Imagine if you texted a friend about relationship troubles. Would you prefer someone else you know having access to that or an impartial, unrelated entity like Google?
This is, of course, assuming E2EE is not an option, which is true for both alternatives in consideration.
In a non-E2EE situation, I trust a company (or any other organisation) much more for this kind of problem than a random, unspecified, sometimes unknowable person on an instance I haven’t chosen (the administrator of the personal instance of the person I’m talking to ‘in private’).
By what mechanism are Bluesky admins specified, knowable or subject to your choice?
But the thing is that on the Fediverse you can join an instance that has a well known community and sysops. And, with the risk of repeating the same trite thing as everyone else: you can always host your own. :P
I can’t choose the admin of the instance of my recipient, and they can’t do either for mine, so I think that point is moot?
(And I’ll reply what everyone else may have replied to you before: not everyone can host their own, it’s a common fallacy but not everybody has the technical knowledge, free time or purchasing power to rent a server to do so.)
OTOH all the admins are (supposed to be) trusted by at least one person in the conversation, so they’re not random completely untrusted people.
Why do you think the company has this incentive but the random dude doesn’t?
Why does “trust and ditch if they turn out to be a creep” policy apply to a random dude and not a company?
Because selling data on users is how companies with free services usually get money. The dude doesn’t because probably there’s no market for not mass sourced data, but I might be wrong.
It does, of course, but currently there’s only one Bluesky, so there’s nowhere else to go if you ditch them.
Well, I think that you could replace “DM” with “emails” in that context, and still get a clear picture of how much people care about that, in general.
As super techno-geeks living in the future /s, it would be nice to offer something more private to the world, rather than repeat the same mistakes. I understand Bluesky may have been pressed by time/resources to ship DMs. I can only hope that they will improve on this first version.
I definitely think adding DMs was a mistake. They weren’t ready to do it right, and really there’s no reason to do it at all. We have dozens of chat protocols already we didn’t need another half baked one.
I’m very interested in the novel stuff atproto is doing for the social space. The bolt on, less interesting.
Funnily enough the GNU social people were saying exactly the same thing when Mastodon was adding DMs. The lack of proper security against admins (plus footguns where @-ing someone you were talking about added them as a recipient) made it a pretty compromised thing. To this day I think we’d be better off using different tools for broadcast and for private chat.
Yoy could even pick one and integrate it in your mastodon, bsky, whoever UI same as the DMs, but using a battle tested protocol instead of NiH
I had my first lunch today organized through bsky dm, so yes it’s very nice to have this feature in there.
I feel that this underestimates the amount of people who don’t want to get into it for moral reasons, despite their curiosity.
Agreed, it’s hard to keep a blind eye to all of the external issues this type of tooling causes.
Would you care to elaborate or at least link to why laundering copyrighted code through a series of weights to enable unlicensed commercial use does not stand up to even cursory analysis as a moral issue?
My original comment having been removed, the claim I made (for context) was not that there were no moral issues but that the quality of discussion and discourse around them is low as to be beneath engagement and indeed instead is deserving of mockery and annoyance pour encourager les autres.
You pose a reasonable and (fairly) serious question, so I’ll attempt to engage in good faith.
I did not claim that “laundering” of copyrighted code through a series of weights is not a moral issue. Though I disagree with the framing, out of intellectual honesty I’ll provide a straightforward argument that such an act is a moral one: “laundering” of code involves reproduction of code, reproduction of code theoretically invokes moral rights of the other, ergo this is a moral issue (though that’s not a particularly good argument imho because I’m being lazy and cute with the use of “moral”).
Copyright–and indeed, all intellectual property law writ large–has always been about property rights and governments choosing winners or losers, and that’s an economic issue disguised as a moral one. For some strange reason, growing economies and progressing sectors (to my knowledge) always tend to play fast-and-loose with such things–see the “theft” of the IP of the industrial revolution from Britain by the Americans and of literature in the 19th century, the “theft” of the Western IP by Chinese and other countries in the 20th (and early 21st; Shanzai I think is the term of art but I may be wrong)–until they get far enough along in their own innovations to attempt to clamp down and pull the ladder up after themselves. It seems to me to be less of a moral stance and more a pragmatic, economic one.
I personally reject the idea of intellectual property as anything other than retarding progress and advancement, because it is predicated on the principle that you must artificially limit and gatekeep the spread of ideas. Perhaps the one thing we have that is truly post-scarcity and with zero reproduction cost is an idea, and copyright and patent and IP laws are there to screw that up to benefit a small handful of rentiers.
Even setting aside my own disdain for the concept, there’s still the matter of “what exactly is laundering”? Is it a moral rights violation if I rewrite your algorithm in, say, C instead of Fortran (the authors of Numerical Recipes may hold that it is)? What if I make your code use a stack instead of a queue to change the search behavior? Okay, what if my friend reads your code, and then describes to me what it does at an algorithmic level, and I reimplement it with my own flourishes? Indeed, at what point is a standard education in computer science not to be said to be “laundering” the ideas of our predecessors? It would seem to me that there are much more accepted and direct forms of laundering than jiggery-pokery in the latent space of a transformer, and so I again am unconvinced that this is worth my outrage.
Setting even that aside, when people tend to talk about morality, it can be helpful to look at different moral frameworks for evaluating things. From both a consequentialist and utilitarian standpoint, it seems clear to me that having more people writing and using more code is an absolute win (one could argue that fear of copied code would result in less code written would result in less global good, but the sheer number of for-fun reinventions of text editors and programming languages suggests that this isn’t a realistic outcome). From a Kantian standpoint, you could argue that having your code passively trained on is something you cannot consent to and thus it fails as moral–but unlike Kant’s argument against theft (e.g., an act of theft is impossible if given consent, ergo theft is mutually exclusive with consent, ergo theft is immoral under his reasoning) it’s not clear to me that you couldn’t in some cases permit training (again, contrast with theft which by construction cannot be consented to) and indeed the act of posting your code where others can see it is in effect consenting to its consumption. From a broader deontological standpoint, you pick your values and duties and I pick mine and we’ll yell past one another until we get our doctorates in moral philosophy. (What Rawls, Nietsche, or others would say is left as an exercise to the reader.)
That clear anything up?
Thanks for the interesting response. For the record, yes, it’s a pity that my out-of-context reply puts words in your mouth but I was making a good-faith attempt to pull the discussion back to specifics so I appreciate you taking it that way.
I take your broader point that one’s view on copyright plays a major factor here. I’m not a copyright maximalist but I do think it’s important on a short timeframe - I’ve always liked the 7 years proposal pushed by some political organisations. It’s clear that if one doesn’t believe in intellectual property in general then it’s going to be difficult to take seriously any moral concerns about breach of copyright through use of LLMs.
However, this discussion is not taking place in a hypothetical environment where abolishing copyright is a possibility. The AI situation is unfolding in a reality where copyright law exists. It’s generally popular and propped up by democracies, and not really at any short-term risk. Therefore we should consider the effects of the AI in this reality.
It’s fair to say that “laundering” is too woolly. There is always borrowing and and inspiration. Even so, there are several ways that this situation is offensive. When you look at the output of an LLM you have no idea of the sources and no idea how directly it’s been copied. In the arts consumers can generally distinguish between what is inspiration, following a genre, sampling, or what amounts to plagiarism, with plagiarism being something that you can actually sue people over. This works because the arts are effectively entirely open source - what you see or hear is what you get. With the right prompt an LLM might reproduce code exactly how it is in another software project without meeting the licence conditions. You wouldn’t know, computer goes brrr. There are no humans in the loop and if the outcome goes into proprietary software then those who profit from this automated pivot from inspiration to plagiarism will not easily be held accountable.
In the context of a world with copyright, it is also repugnant to trample on the modest requirements stipulated by open source developers. They don’t ask for much, especially the permissive licence crowd - they just want to be credited. Denied. Then there’s the GPL crowd, who make their code available (generally) for free with the explicit goal of ensuring users of that code have the right to modify it. Denied. It is callous and sad to disregard even the limited requests of these altruistic people, particularly if the justification for the increased productivity is ultimately “profits” which they have explicitly given up by making their work publicly available.
In this context I think it is splitting hairs to argue about what is training or whether changing one data structure to another is a material difference. A human with the honest intent to uphold copyright and licences will not be looking at MIT code or GPL code in any detail at all unless they plan to comply with the condition. The human who takes heavy inspiration from an MIT or GPL module then rewrites some of it and says “this is mine now” is scummy. Outsourcing it to a software program doesn’t make it any less scummy, so don’t be surprised if that software program becomes the target of ire.
I think this characterizes my take reasonably. If we’re going to have copyright, and copyright licenses, the only two decent forms of behavior I see wrt software are “respect the license” and “don’t copy/use it” unless you’re in a situation where some kind of file format lock-in coerces you into using it anyway.
I find it anti-social (“callous and sad” is a good way to put that, and I might borrow it in the future!) to accept an altrustic offer and then disregard these terms, and I think people who trained LLMs on freely offered software in a way such that they later emit portions of that software without crediting the author fail that basic test and are behaving in an anti-social way.
Well put. It’s worth keeping in mind that not only are these LLM purveyors violating the copyrights of the countless people whose work is used as training data, they are (for the most part) then also turning around and renting access to the resulting model. Even in the case of so-called “open-weight” LLMs like LLaMa, they’ve discarded the licenses of the input data (if any) and stamped their own terms of service on the freely available wad of model weights. It’s a perfect example of the way modern copyright law is interpreted to the benefit of large corporations while offering only harm and restrictions to individual people. Paying OpenAI and their ilk to use LLMs is a tacit endorsement of their exploitative methods, even if one thinks that in an ideal world copyright laws shouldn’t exist or should be strongly curtailed.