I really appreciate how this post leads with all the trade-offs of using a fringe mobile operating system. It provides a metal checklist of what I could or could not do with out if I chose to switch.
I think it misses the largest trade-off, which is that it's not just mobile payments which you lose, but also banking apps. This is especially crucial since in the UK to log on to mobile banking usually requires using the app for 2FA, which you then cannot do.
Heavily depends on your bank/banking app. All the ones I tried worked on Waydroid without any fiddling: ING, mBank, Revolut, and a few more.
Some of the bank apps print a warning, that your device might be insecure, but 2FA for gov services works nonetheless and I use it everyday.
I read on a forum that sometimes you have to reach out to your bank to allow installation on a compatibility layer like Waydroid, but it seems like they are obligated to comply with your request (at least in the EU/Poland).
It does indeed. Last I checked Monzo worked for me but HSBC didn't, which is one of the larger banks in the country. None of my building societys worked either.
In the UK they are not obligated to comply with that request.
Is this a banking policy at the national level? Can you write a letter to your representative about this? This seems like a horrible access issue along with exposing all citizens to US big tech. Last time I lived in the UK cash & plastic still worked for basically everything…
It’s quite the journey going down this path. I’m a decade in & the only things left I don’t have real replacement for is Voice (JMP is great, but I just don’t need a US phone number often enough to justify the cost) & YouTube (Peertube doesn’t have anywhere enough steam, & Nebula has some of the greatest hits, but lack the ubiquity). Now if you could get businesses off a GSuite & users off GMail… as private conversations require both sides to be off Google to truly work. …That & many worry about unGoogling without unMicrosofting too.
Now if you could get businesses off a GSuite & users off GMail…
Proton has faced criticism for larping a bit with privacy, but it's still a real improvement over Google. They're obviously positioning themselves as a GSuite replacement, what with the recent release of Proton Meet which I hear works pretty well.
I have mixed feelings about Proton (I left them as my primary account several years ago), but even scattering your data across different platforms helps user to not have a single, all-knowing entity. I would welcome it—even if it’s just one step in the right direction (same with my feelings about Signal).
yeah, I don't think they're as trustworthy as they're depicted, especially once you get into VPN area where they appear to be NordVPN-in-a-trenchcoat and I think they did let govt access their users data (IIRC it was a bit more complicated, but I'm more wary since then)
Am I getting this wrong or they could have just used a calculator instead of an LLM?
What I am trying to say is that this feels hardly as a new phenomenon.
It seems alike moving from physical dictionary to digital one when studying a new language, or from sifting trough books in a library instead of using a search engine and wikipedia.
The process went from labor intensive to more immediate.
Are we really that worst off after these technological innovations?
as I mentioned in my other comment, they also tested reading comprehension and found the same affects, "Experiment 3: Convergent evidence from reading comprehension"
I'm not sure this test is actually testing anything...useful? Like if you did s/AI/calculator/, such that
the opening directions said that I should try to use the calculator
the final 3 questions did not have access to the calculator
I might be inclined to also skip? This is a pretty short problem set that some people might not really care for, and by time the assistant is removed you're already mostly done. It's not clear to me that you can take much of note from this. (To be entirely frank, there have also just been better—and more concerning—studies done on the effect on thinking, in a much more intricate way.)
I agree that it's unclear how well this result generalizes and that the authors try to inflate the importance of the study. As always! Also, this study is still in review, which is worth noting. I think there is a conclusion to be made that the result supports, though.
One argument that I have heard from AI proponents is that because they are spending less time and effort writing code, they can now spend that time and effort on architecture / planning / reviewing etc. I think this study shows quite clearly that mental effort is not quantitive in that sense, and that reduced effort in one area of solving a problem rather creates an expectation of low effort, and that in turn creates a tendency to try to avoid effort in other areas.
Anecdotally, this is something that I see in others who adopt LLMs, to any degree. You would think that people would spend more time reviewing and testing code that they themselves did not write, but I am seeing the opposite. There is a tendency to accept larger changes or rewrites that would not have been accepted before, and a large number of generated tests replaces even a minimal amount of manual testing, so that I see PRs that completely do not work at all get sent on to review.
I think this study shows quite clearly that mental effort is not quantitive in that sense, and that reduced effort in one area of solving a problem rather creates an expectation of low effort, and that in turn creates a tendency to try to avoid effort in other areas.
This does make sense, but I think they needed to extend the study a bit more to show this concretely, in particular tying in some other form of question entirely (to demonstrate the effort reduction extending outward) or implying some actual penalty to skipping (if you go "oh but I review the LLM output for correctness" and then don't, it's a bit different than if someone tells you "oh you don't have to bother reviewing it at all").
But calculators don't habitually confabulate and cover up mistakes. If faced with a task you can do with a calculator, you need to verify the algorithm one time - or trust the manufacturer - and you're good to go. In contrast, using LLMs requires constant, intense skepticism. I think they are qualitatively different in that way.
They absolutely do. My nephew went to school in the late 2000s and his math teacher actively noticed a drop in thinking/problem-solving ability around the time graphing calculators were allowed for exams. Algebra, understanding functions, proofs. He actively fought to at least have a higher stream for talented kids focused on proofs instead of plug and play.
They're not probabilistic, true. A floating-point error will propagate through every time you make a calculation.
But the over-reliance on tools for education is nothing new.
People levered the same criticisms around LLMs at Google and Wikipedia, a decade or two ago. "People will just search the answer!", "They won't be critical about sourcing". I would argue the exact opposite happened, in those cases.
This is a fair point; there are very advanced calculators. I think my opinion is consistent, though, in that I know my times tables, didn't use CAS at all during my math courses, and think I'm better off because of it.
Also, I do think it matters that your TI-89 won't lie to you and say it has solved a problem when it actually hasn't.
«I know my answer is correct, I checked on a calculator» (the narrator: the formula used has nothing to do with what actually needs to be calculated) is also a thing that happens, so maybe we are not as much more doomed now than before as it seems.
They did, but I'd argue it runs into the same issue of "skip" not being a useful indicator. (Although yes, in that case you certainly couldn't compare it to a calculator!)
Indeed, testing the unique effects of LLMs by offering them as assistance in tasks that even some exam-allowed calculators can do sounds at best like «second intervention condition (fraction-capable calculator) needed to calibrate the results».
I'd love to see a list of alternatives for people who like Discord in general.
For example:
A hosted option (its fine if it can be self hosted, but I'm not interested)
Good moderation tools
Good image + video support
Good client diversity across platforms with mostly feature parity
etc...
I often see these lists come up and get a bit confused because for example IRCv3 is pretty much incomparable to Discord unless you limit Discord's functionality significantly (for those coming from Discord). I feel like "alternative" should be... mostly comparable?
There are also definitely things I don't like about Discord, of course, but from the perceptive of someone who is mid-30s, dad of two young kids, does OSS for fun on the side, etc. I really just want something I can pay for and forget.
Out of the FOSS Discord-likes, Fluxer seems to be the most polished and least shady option.
Has a hosted option and can be self-hosted, but no self-hosting docs yet pending an upcoming refactor that will make self-hosting easier
The plan so far is to later have a Docker image and a guide based on Docker Compose
Similar role-based moderation as Discord
Working voice and video calling using LiveKit
The closest to feature parity with Discord
The only thing it doesn't have yet among your requirements is client diversity, in part due to how new it is. The main developer has however expressed openness to third-party clients.
There's a lot more information on the how and why Fluxer was built in this blog post:
I had an absolutely terrible time with Matrix the two times I tried it (Nix and Gnome). The problem could be totally with me, but I used their official clients and just... couldn't connect, couldn't talk, took seconds to join servers. Everything felt really brittle (just a feeling). Like I said, totally could be my problem but the first user experience was atrocious and it happened twice to me across months of time difference.
I also felt that the client I was using was aesthetically very very bad, and I think for this type of software aesthetics does matter a lot. I'd give it a lot more slack (no pun intended) if everything else was smooth but this on top of the bad experience really left me a bad mark on me.
The last time I tried was maybe 6 months ago. I'm willing to try again.
The last time I tried was maybe 6 months ago. I'm willing to try again.
I know the client cinny has made decent progress in that time frame and it's worth another look. It's also aesthetically much nicer to my eyes than Element. And even today the Element client is stuff just as rough around the edges in my opinion as it was 6 months ago.
hum, sorry about that :/ Was this on desktop or mobile? Element Web generally gets good reviews for aesthetics. Element Classic on mobile is awful, but has been in maintenance mode for 3 years now; Element X on mobile on the other hand should be best-in-class (rust core + SwiftUI/Compose native UI on top).
In terms of server performance: joining perf is a known problem area. But once you're in a room, things should be fine - unless you're on a server which is struggling. Would be super interested to understand what went wrong here, it really shouldn't be that bad :(
Matrix is extremely brittle and janky. It has the basic features but falls over in real-world use because its design puts E2EE and federation first (which led to the whole "it's really a distributed database masquerading as a chat system" design), and it turns out when you do that, you just can't build a Discord competitor that actually works well.
Just yesterday I had a weird desync in a chat group that affected all my clients, some unfixably. Apparently it was root caused by... server load issues? No other chat system out there persistently corrupts room/sync state when the server has some transient load issues... and this was in a server hosted/managed by Element themselves.
Not to mention the moderation problems. Last year were getting CSAM auto-loaded and cached on their computers due to spam attacks, and there was nothing the moderation tools could do within the existing ecosystem.
Matrix is a neat idea and all that, but as a viable chat platform for the masses, it's sadly a failed experiment.
I often see these lists come up and get a bit confused because for example IRCv3 is pretty much incomparable to Discord unless you limit Discord's functionality significantly (for those coming from Discord). I feel like "alternative" should be... mostly comparable?
ObsidianIRC is decently competitive with Discord for text chat UX. i would really love if someone smashed Mumble into IRCv3 at high speed for voice chat capabilities though.
smashed Mumble into IRCv3 at high speed for voice chat capabilities though.
IRCv3 has been in development for well over a decade and barely has seen adaptation other than the most basic things. I remember IRCCloud being one of the bigger drivers behind v3, but their blog has been quiet since 2022.
Even with sleek apps like the one you are linking (or ircclour, the lounge, etc) I'd still not recommend that people switch back to IRC. Don't get me wrong, I like idling on #lobsters with the folks there. And I really used to be a die hard IRC user to the point of having written this thing just so I didn't need to switch to discord.
But, IRC simply isn't an ecosystem that fits with what people expect these days. Heck, even over a decade ago it already didn't fit what most people wanted out of a chat service. I remember trying to get a channel going for various communities and subreddits over the years and never really succeeding. As soon as we put up a discord link in the subreddit people started flooding in simply because of how much lower the barreer of entry is compared to IRC and still very much is.
Yes it is fine for technical people if they sit down for a moment to figure it all out. But that in itself already says something about how accessible IRC is compared to something like Discord. Already a mental hurdle sometimes for (slightly) technical people, not to mention the masses. Which is extremely easy to forget as well, because once you have figured out IRC it doesn't seem all that difficult. Causing a lot of IRC users to suffer from the curse of knowledge in discussions like these.
I am sure people are still working on it. In fact, I applaud their dedication and the effort they put in. But progress on both the specs and maybe more importantly their implementation has been such that it isn't making a huge difference to the current situation.
I'm not sure what barrier to entry you are referring to. If you use a web client and don't require registration is the barrier not actually the same as or lower than discord?
If you don't require registration people will not always get the same nickname when they rejoin for starters. You can set up discord that it also doesn't require registration, but generally that is a bad idea for moderation purposes. Anyway, assuming you do so people still have the option to create an account from within the discord client.
Compare that to IRC on the other hand. Registration of your nickname can be different per network. So you need to be aware of the network you are on, know the syntax for command registration. Heck, you even need to be aware that there are different networks. The fact that there are different networks also means that you as a user are now dealing with account fragmentation. Not necessarily a big deal, but still a thing.
On joining there is also the privacy aspect. Many networks don't cloak your IP by default. Which isn't entirely transparant either.
There is the fact that by default IRC clients don't have message history. Something that trips up a lot of new people who aren't aware of this at all. Which leads to situations where people will join, hang around for a minute, leave, mis a lot of conversation, rejoin and think nothing has happened.
Even if you do accept that IRC is more bare bones than discord (no chat history, no included media hosting, etc) it still requires more work as a user to get started and join somewhere.
These are just the first things that come to mind. There are many more things that make IRC just not as straightforward. Again, if you are slightly technically inclined it is easy enough to figure out. But that is exactly my point, you need to figure out how to work with IRC much more so than a lot of people will ever do so. And again, the fact that this is needed is often forgotten by people who have been using IRC for years.
There is the fact that by default IRC clients don't have message history. Something that trips up a lot of new people who aren't aware of this at all. Which leads to situations where people will join, hang around for a minute, leave, mis a lot of conversation, rejoin and think nothing has happened.
Depending on your IRC server and client, this is no longer true! IRCv3's chathistory extension doesn't only allow a smoother experience when connecting to IRC bouncers (like soju), but normal IRC servers have the choice to provide history, and at least both Ergo and UnrealIRCd do, per IRCv3's server support table.
no included media hosting
Almost the same deal! draft/FILEHOST is a proposed IRCv3 extension that's already supported by soju, Ergo, and UnrealIRCd (contrib). ObsidianIRC both supports it as a client and implements some extensions of its own (+obsidianirc/link-preview-{title,preview,meta}) (implemented server-side in an UnrealIRCd module) that use it to provide modern-style link previews.
This is what I find exciting about ObsidianIRC as a project—people are working to make at least one blessed IRCv3 client-server pairing legitimately competitive with Discord's feature set. A randomly chosen IRCd is still likely to be pretty primitive and not implement even just the ratified IRCv3 extensions, but there are small communities pushing to see what's possible when not necessarily designing for wide IRCd adoption. Fluxer and Stoat only currently care about one respective blessed client-server pair. I think it'd be most fair to evaluate ObsidianIRC the same way here.
Again, I applaud the work that as been done on IRCv3 and by extension people implementing it in clients like ObsidianIRC and server implementations like you mention.
But, you yourself also recognize the current context this is happening in.
A randomly chosen IRCd is still likely to be pretty primitive and not implement even just the ratified IRCv3 extensions, but there are small communities pushing to see what's possible when not necessarily designing for wide IRCd adoption.
Maybe in the future we see a comeback of IRC because of all this. But at the moment that is not the reality we find ourselves in. At least not in the original context I made my comment in. Which is the comment it all started with
There are also definitely things I don't like about Discord, of course, but from the perceptive of someone who is mid-30s, dad of two young kids, does OSS for fun on the side, etc. I really just want something I can pay for and forget.
IRCv3 doesn't offer that and even if we put water in our wine and tone down our expectation it still isn't that accessible. I can't help but mention the curse of knowledge again. Which I already gave context for, but as another example. Soju is a bouncer, which is a foreign concept for most people. In fact, it comes on top of getting to know the basics of IRC as it is an extra concept.
Even if we focus on just the client side. If you look at the landing page for obsidianIRC it still has some barriers in place. Let's assume people are familiar with discord it is clear that it styled like it. But, there are only a few networks available (likely those with ircv3 support) where most seem to be test networks and while I can connect to those without any context they would leave me confused (where are the channels, how do I discover channels).
Certainly, it is a lot better compared to many old school irc clients. But it effectively still requires that someone has read up on irc basics, knows what they want to join, likely has gotten some instructions, etc. Not to mention that for the features you might expect you really need to be on a server supporting them (which might be one of the more confusing things).
Where with discord people just click a link and are being onboarded to whatever server the link points to.
Again, I honestly do applaud the work people still do on IRCv3 and I really don't want to trivialize or downplay the work they have been doing. All I am saying is that for mass adoption, which I think you agree with, it isn't the right tool for the job. At least not at this moment.
From the name I assumed it was a plugin for Obsidian Notes, but I'm glad to see I was wrong. It does look to have a lot of the same Discord UX, but I really wish they would do something different. It shouldn't be too hard to add some sort of voice chat bridging.
To me, the best alternative right now for "it just works" is probably Root. It's not open source or federated or privacy oriented so a lot of people will have justified concerns there. But, it has pretty much all the features of Discord and already has cross platform (including mobile) support.
There's also a lot of potential there for apps and bots as they have a much deeper integration than in Discord. It's also not just a straight rip of Discord's UI like Fluxer and includes a lot of UX improvements.
Most of this went way over my head, but I did enjoy searching for his board games from his "data center" on BoardGameGeek, I might just pick up a copy of Quoridor!
djb has some interesting notes on leveraging Debian's support for installing multiple architectures to build and run Fil-C compiled programs on a standard Debian box, https://cr.yp.to/2025/fil-c.html. It would be cool if you could just add a Fil-C debian repo and install security sensitive software, whose performance doesn't matter, e.g. sudo, and have it just work.
Though, there has been quite a bit of discussion of Fil-C on lobste.rs of late, I had not seen a good overview of how it works under the covers. This article does a good job of providing that overview.
Would love a deep dive on how Fil-C works for a layman audience like myself, which has written some C, but doesn't have a good understanding of the compiler complexities behind its operation.
Whenever I see anything Oxide, I have to wonder who the intended customer base is. I can't imagine the market for artisanal EC2 in a box is very big. They're pretty shy about who's buying it, but I'm quite curious.
They mention a number of times that some of their customers require an updating mechanism that works across an air gap. Given the desire for an air gap, I think we can make some pretty good guesses about who are a few of their customers.
The part of the video that actually explains the acronym – “global regular expression print” – is 8:25 to 8:36. The nearest context checkpoint before that is at 7:38. You linked to 0:40. I think requiring people to watch or skip through 7 minutes of irrelevant content to understand your comment was a bit rude. If you just wanted to recommend the video as a whole, it would have been kinder to either say that – e.g. “long explanation, but has interesting historical context I never knew” – or to link to the video as a whole without an accurate-to-the-second timestamp.
Also, as far as I can tell, the word “grep” is not funny or crude, as OP had asked for.
I really enjoyed the whole video, and definitely didn't think your comment was rude, especially in the context of a lighter post to begin with, thanks for posting it!
Fastmail should have VJOURNAL support though you may need to create a new calendar with VJOURNAL enabled manually using curl. I documented how I did it for Nextcloud in the Readme, I think it should also work for fastmail.
Currently Agendafs only supports VJOURNALs, but it's in the backlog to support VTODOs and maybe even VEVENTs. I'm just not quite sure what the ideal interface is yet for those event types.
Guideline 13:
For utilities that use operands to represent files to be opened for either reading or writing, the '-' operand should be used only to mean standard input (or standard output when it is clear from context that an output file is being specified).
At my last job we had a bit of a tug of war between users like myself who prefer readline vi keybindings and those that prefer the default emacs keybindings. When trying to solve the problem I discovered that the majority of the key bindings do not overlap, so I create a merged config, https://github.com/lollipopman/bash-rsi
Not the focus of this particular blog post, but Julia Evans wrote another terminal blog post a while back which makes note of this under the topic of "Entering Text in the Terminal" https://jvns.ca/blog/2024/07/08/readline/ (the vim setting comes up later in the post than the readline sunb-heading).
Personally I think changing this readline behavior would throw me off more than actually switching my default shell.
I think I couldn't get the examples in the docs that show running an application under a pty provided by sequin to work, sequin -- foo would error out about unrecognized commandline arguments or similar. I ended up solving it by running the application I was interested in profiling under socat then piping that output to sequin and for others requiring interactive tty input, using script session.log and reading the recorded session.log with sequin.
I also wanted to see if trachet would give more specific results for some of the most common and universally supported private mode operations where sequin would just always report Enable private mode "cursor keys" whether I was enabling or disabling any of a myriad of behaviors.
Are there docs for how to customize the output? One thing I noticed when I tried it out was that bold/strong text is rendered with ANSI bold colors, but I have my terminal emulator to not treat bold text differently. I was curious to see whether there was an option I could use to pick a particular color to render bold text. Another one I noticed is that there is a background color on inline code, but not on syntax-highlighted code blocks (they’re just indented instead). And a third thing was that H1 markdown headers were rendered in ALL CAPS, when I was thinking that some documents will care about the case used for specific words in the headings.
It’s no problem if it’s not customizable, it was just the first thing I was curious about when I tried it out on some documents, and I couldn’t see anything mentioned about it in the pandoc manual online.
What was the use case that prompted you to contribute this? Is there a workflow where you render documents to the terminal frequently, or just thought it might be a fun feature to add?
Partly fun. Partly that I always have pandoc around and I often want to look at some document in the terminal, like a bunch of markdown readmes, and it's nicer to read those reflowed and with bold and italic being actually bold and italic and with clickable links. There's other "read markdown in the terminal" things out there but by adding the feature to pandoc I now have a "read anything in the terminal" program. Plus there was a backlog issue to add it so someone else wanted it at least once.
The pull request to Anaconda is a great example of how people are easily misled when a person or AI bot sounds confident, Fix: Add split_lock_detect to preserved arguments to prevent kernel crashes · Pull Request #7074 · rhinstaller/anaconda
I'm still hoping that Fil-C binaries find their way into Debian!
My favorite quote from the article, and one I didn't internalize early enough about the little candy phones in our pockets:
[Comment removed by author]
entr: watch these files and do this, such a simple interface and useful tool, great for running tests on a codebase
I use
entrtoo, it's great! Any time you're thinking "I wish I could have a--watchargument on this shell pipeline", you can just call it withentr.That's what I've used bacon for.
I really appreciate how this post leads with all the trade-offs of using a fringe mobile operating system. It provides a metal checklist of what I could or could not do with out if I chose to switch.
I think it misses the largest trade-off, which is that it's not just mobile payments which you lose, but also banking apps. This is especially crucial since in the UK to log on to mobile banking usually requires using the app for 2FA, which you then cannot do.
Heavily depends on your bank/banking app. All the ones I tried worked on Waydroid without any fiddling: ING, mBank, Revolut, and a few more.
Some of the bank apps print a warning, that your device might be insecure, but 2FA for gov services works nonetheless and I use it everyday.
I read on a forum that sometimes you have to reach out to your bank to allow installation on a compatibility layer like Waydroid, but it seems like they are obligated to comply with your request (at least in the EU/Poland).
It does indeed. Last I checked Monzo worked for me but HSBC didn't, which is one of the larger banks in the country. None of my building societys worked either.
In the UK they are not obligated to comply with that request.
Is this a banking policy at the national level? Can you write a letter to your representative about this? This seems like a horrible access issue along with exposing all citizens to US big tech. Last time I lived in the UK cash & plastic still worked for basically everything…
It is not policy, but it would not be hard to make the argument in court that it is needed to comply with cyber-security/data-security policy.
Except that a lot of these policies seem just as much built to allow the state into the surveillance rather than purely to protect users :|
I also liked the Degoogling checklist. Got me to write my own~
It’s quite the journey going down this path. I’m a decade in & the only things left I don’t have real replacement for is Voice (JMP is great, but I just don’t need a US phone number often enough to justify the cost) & YouTube (Peertube doesn’t have anywhere enough steam, & Nebula has some of the greatest hits, but lack the ubiquity). Now if you could get businesses off a GSuite & users off GMail… as private conversations require both sides to be off Google to truly work. …That & many worry about unGoogling without unMicrosofting too.
Proton has faced criticism for larping a bit with privacy, but it's still a real improvement over Google. They're obviously positioning themselves as a GSuite replacement, what with the recent release of Proton Meet which I hear works pretty well.
I have mixed feelings about Proton (I left them as my primary account several years ago), but even scattering your data across different platforms helps user to not have a single, all-knowing entity. I would welcome it—even if it’s just one step in the right direction (same with my feelings about Signal).
yeah, I don't think they're as trustworthy as they're depicted, especially once you get into VPN area where they appear to be NordVPN-in-a-trenchcoat and I think they did let govt access their users data (IIRC it was a bit more complicated, but I'm more wary since then)
Am I getting this wrong or they could have just used a calculator instead of an LLM? What I am trying to say is that this feels hardly as a new phenomenon. It seems alike moving from physical dictionary to digital one when studying a new language, or from sifting trough books in a library instead of using a search engine and wikipedia. The process went from labor intensive to more immediate. Are we really that worst off after these technological innovations?
as I mentioned in my other comment, they also tested reading comprehension and found the same affects, "Experiment 3: Convergent evidence from reading comprehension"
I'm not sure this test is actually testing anything...useful? Like if you did
s/AI/calculator/, such thatI might be inclined to also skip? This is a pretty short problem set that some people might not really care for, and by time the assistant is removed you're already mostly done. It's not clear to me that you can take much of note from this. (To be entirely frank, there have also just been better—and more concerning—studies done on the effect on thinking, in a much more intricate way.)
I agree that it's unclear how well this result generalizes and that the authors try to inflate the importance of the study. As always! Also, this study is still in review, which is worth noting. I think there is a conclusion to be made that the result supports, though.
One argument that I have heard from AI proponents is that because they are spending less time and effort writing code, they can now spend that time and effort on architecture / planning / reviewing etc. I think this study shows quite clearly that mental effort is not quantitive in that sense, and that reduced effort in one area of solving a problem rather creates an expectation of low effort, and that in turn creates a tendency to try to avoid effort in other areas.
Anecdotally, this is something that I see in others who adopt LLMs, to any degree. You would think that people would spend more time reviewing and testing code that they themselves did not write, but I am seeing the opposite. There is a tendency to accept larger changes or rewrites that would not have been accepted before, and a large number of generated tests replaces even a minimal amount of manual testing, so that I see PRs that completely do not work at all get sent on to review.
This does make sense, but I think they needed to extend the study a bit more to show this concretely, in particular tying in some other form of question entirely (to demonstrate the effort reduction extending outward) or implying some actual penalty to skipping (if you go "oh but I review the LLM output for correctness" and then don't, it's a bit different than if someone tells you "oh you don't have to bother reviewing it at all").
The third experiment does not test this AI/calculator difference
But calculators don't habitually confabulate and cover up mistakes. If faced with a task you can do with a calculator, you need to verify the algorithm one time - or trust the manufacturer - and you're good to go. In contrast, using LLMs requires constant, intense skepticism. I think they are qualitatively different in that way.
They absolutely do. My nephew went to school in the late 2000s and his math teacher actively noticed a drop in thinking/problem-solving ability around the time graphing calculators were allowed for exams. Algebra, understanding functions, proofs. He actively fought to at least have a higher stream for talented kids focused on proofs instead of plug and play.
They're not probabilistic, true. A floating-point error will propagate through every time you make a calculation.
But the over-reliance on tools for education is nothing new.
People levered the same criticisms around LLMs at Google and Wikipedia, a decade or two ago. "People will just search the answer!", "They won't be critical about sourcing". I would argue the exact opposite happened, in those cases.
This is a fair point; there are very advanced calculators. I think my opinion is consistent, though, in that I know my times tables, didn't use CAS at all during my math courses, and think I'm better off because of it.
Also, I do think it matters that your TI-89 won't lie to you and say it has solved a problem when it actually hasn't.
«I know my answer is correct, I checked on a calculator» (the narrator: the formula used has nothing to do with what actually needs to be calculated) is also a thing that happens, so maybe we are not as much more doomed now than before as it seems.
True! Let's hope :)
Right but my whole issue with the study is that it's not actually testing this, because:
They also tested reading comprehension and found the same affects, "Experiment 3: Convergent evidence from reading comprehension"
They did, but I'd argue it runs into the same issue of "skip" not being a useful indicator. (Although yes, in that case you certainly couldn't compare it to a calculator!)
Indeed, testing the unique effects of LLMs by offering them as assistance in tasks that even some exam-allowed calculators can do sounds at best like «second intervention condition (fraction-capable calculator) needed to calibrate the results».
I'd love to see a list of alternatives for people who like Discord in general.
For example:
I often see these lists come up and get a bit confused because for example IRCv3 is pretty much incomparable to Discord unless you limit Discord's functionality significantly (for those coming from Discord). I feel like "alternative" should be... mostly comparable?
There are also definitely things I don't like about Discord, of course, but from the perceptive of someone who is mid-30s, dad of two young kids, does OSS for fun on the side, etc. I really just want something I can pay for and forget.
I think that https://fluxer.app/ is exactly what you are referring to
This is a big one. Fingers crossed they do well with it, because it otherwise looks nice.
For a huge volume of users, a necessary feature of a Discord replacement is good video support.
Is it? Do you mean desktop share (streaming) or video calls (conferencing)?
Both, simultaneously. Screensharing and video conferencing, with noise cancellation at least as good as Krisp.
[Comment removed by author]
Out of the FOSS Discord-likes, Fluxer seems to be the most polished and least shady option.
The only thing it doesn't have yet among your requirements is client diversity, in part due to how new it is. The main developer has however expressed openness to third-party clients.
There's a lot more information on the how and why Fluxer was built in this blog post:
https://blog.fluxer.app/how-i-built-fluxer-a-discord-like-chat-app/
What's Matrix missing in that list? It feels the most full featured honestly
I had an absolutely terrible time with Matrix the two times I tried it (Nix and Gnome). The problem could be totally with me, but I used their official clients and just... couldn't connect, couldn't talk, took seconds to join servers. Everything felt really brittle (just a feeling). Like I said, totally could be my problem but the first user experience was atrocious and it happened twice to me across months of time difference.
I also felt that the client I was using was aesthetically very very bad, and I think for this type of software aesthetics does matter a lot. I'd give it a lot more slack (no pun intended) if everything else was smooth but this on top of the bad experience really left me a bad mark on me.
The last time I tried was maybe 6 months ago. I'm willing to try again.
I know the client cinny has made decent progress in that time frame and it's worth another look. It's also aesthetically much nicer to my eyes than Element. And even today the Element client is stuff just as rough around the edges in my opinion as it was 6 months ago.
hum, sorry about that :/ Was this on desktop or mobile? Element Web generally gets good reviews for aesthetics. Element Classic on mobile is awful, but has been in maintenance mode for 3 years now; Element X on mobile on the other hand should be best-in-class (rust core + SwiftUI/Compose native UI on top).
In terms of server performance: joining perf is a known problem area. But once you're in a room, things should be fine - unless you're on a server which is struggling. Would be super interested to understand what went wrong here, it really shouldn't be that bad :(
Matrix is extremely brittle and janky. It has the basic features but falls over in real-world use because its design puts E2EE and federation first (which led to the whole "it's really a distributed database masquerading as a chat system" design), and it turns out when you do that, you just can't build a Discord competitor that actually works well.
Just yesterday I had a weird desync in a chat group that affected all my clients, some unfixably. Apparently it was root caused by... server load issues? No other chat system out there persistently corrupts room/sync state when the server has some transient load issues... and this was in a server hosted/managed by Element themselves.
Not to mention the moderation problems. Last year were getting CSAM auto-loaded and cached on their computers due to spam attacks, and there was nothing the moderation tools could do within the existing ecosystem.
Matrix is a neat idea and all that, but as a viable chat platform for the masses, it's sadly a failed experiment.
Not the mention the "IRC-like" channels in Discord. Some of these options listed do not mimic IRC servers.
ObsidianIRC is decently competitive with Discord for text chat UX. i would really love if someone smashed Mumble into IRCv3 at high speed for voice chat capabilities though.
IRCv3 has been in development for well over a decade and barely has seen adaptation other than the most basic things. I remember IRCCloud being one of the bigger drivers behind v3, but their blog has been quiet since 2022.
Even with sleek apps like the one you are linking (or ircclour, the lounge, etc) I'd still not recommend that people switch back to IRC. Don't get me wrong, I like idling on #lobsters with the folks there. And I really used to be a die hard IRC user to the point of having written this thing just so I didn't need to switch to discord.
But, IRC simply isn't an ecosystem that fits with what people expect these days. Heck, even over a decade ago it already didn't fit what most people wanted out of a chat service. I remember trying to get a channel going for various communities and subreddits over the years and never really succeeding. As soon as we put up a discord link in the subreddit people started flooding in simply because of how much lower the barreer of entry is compared to IRC and still very much is.
Yes it is fine for technical people if they sit down for a moment to figure it all out. But that in itself already says something about how accessible IRC is compared to something like Discord. Already a mental hurdle sometimes for (slightly) technical people, not to mention the masses. Which is extremely easy to forget as well, because once you have figured out IRC it doesn't seem all that difficult. Causing a lot of IRC users to suffer from the curse of knowledge in discussions like these.
Work on IRCv3 continues at a steady pace, by a fairly small community of advocates, including James Wheare from IRCCloud.
I am sure people are still working on it. In fact, I applaud their dedication and the effort they put in. But progress on both the specs and maybe more importantly their implementation has been such that it isn't making a huge difference to the current situation.
I'm not sure what barrier to entry you are referring to. If you use a web client and don't require registration is the barrier not actually the same as or lower than discord?
The simple answer to that is have a look at the libera.chat "basic" documentation for people new to IRC.
If you don't require registration people will not always get the same nickname when they rejoin for starters. You can set up discord that it also doesn't require registration, but generally that is a bad idea for moderation purposes. Anyway, assuming you do so people still have the option to create an account from within the discord client.
Compare that to IRC on the other hand. Registration of your nickname can be different per network. So you need to be aware of the network you are on, know the syntax for command registration. Heck, you even need to be aware that there are different networks. The fact that there are different networks also means that you as a user are now dealing with account fragmentation. Not necessarily a big deal, but still a thing.
On joining there is also the privacy aspect. Many networks don't cloak your IP by default. Which isn't entirely transparant either.
There is the fact that by default IRC clients don't have message history. Something that trips up a lot of new people who aren't aware of this at all. Which leads to situations where people will join, hang around for a minute, leave, mis a lot of conversation, rejoin and think nothing has happened.
Even if you do accept that IRC is more bare bones than discord (no chat history, no included media hosting, etc) it still requires more work as a user to get started and join somewhere.
These are just the first things that come to mind. There are many more things that make IRC just not as straightforward. Again, if you are slightly technically inclined it is easy enough to figure out. But that is exactly my point, you need to figure out how to work with IRC much more so than a lot of people will ever do so. And again, the fact that this is needed is often forgotten by people who have been using IRC for years.
Depending on your IRC server and client, this is no longer true! IRCv3's
chathistoryextension doesn't only allow a smoother experience when connecting to IRC bouncers (like soju), but normal IRC servers have the choice to provide history, and at least both Ergo and UnrealIRCd do, per IRCv3's server support table.Almost the same deal!
draft/FILEHOSTis a proposed IRCv3 extension that's already supported by soju, Ergo, and UnrealIRCd (contrib). ObsidianIRC both supports it as a client and implements some extensions of its own (+obsidianirc/link-preview-{title,preview,meta}) (implemented server-side in an UnrealIRCd module) that use it to provide modern-style link previews.This is what I find exciting about ObsidianIRC as a project—people are working to make at least one blessed IRCv3 client-server pairing legitimately competitive with Discord's feature set. A randomly chosen IRCd is still likely to be pretty primitive and not implement even just the ratified IRCv3 extensions, but there are small communities pushing to see what's possible when not necessarily designing for wide IRCd adoption. Fluxer and Stoat only currently care about one respective blessed client-server pair. I think it'd be most fair to evaluate ObsidianIRC the same way here.
Again, I applaud the work that as been done on IRCv3 and by extension people implementing it in clients like ObsidianIRC and server implementations like you mention.
But, you yourself also recognize the current context this is happening in.
Maybe in the future we see a comeback of IRC because of all this. But at the moment that is not the reality we find ourselves in. At least not in the original context I made my comment in. Which is the comment it all started with
IRCv3 doesn't offer that and even if we put water in our wine and tone down our expectation it still isn't that accessible. I can't help but mention the curse of knowledge again. Which I already gave context for, but as another example. Soju is a bouncer, which is a foreign concept for most people. In fact, it comes on top of getting to know the basics of IRC as it is an extra concept.
Even if we focus on just the client side. If you look at the landing page for obsidianIRC it still has some barriers in place. Let's assume people are familiar with discord it is clear that it styled like it. But, there are only a few networks available (likely those with ircv3 support) where most seem to be test networks and while I can connect to those without any context they would leave me confused (where are the channels, how do I discover channels).
Certainly, it is a lot better compared to many old school irc clients. But it effectively still requires that someone has read up on irc basics, knows what they want to join, likely has gotten some instructions, etc. Not to mention that for the features you might expect you really need to be on a server supporting them (which might be one of the more confusing things).
Where with discord people just click a link and are being onboarded to whatever server the link points to.
Again, I honestly do applaud the work people still do on IRCv3 and I really don't want to trivialize or downplay the work they have been doing. All I am saying is that for mass adoption, which I think you agree with, it isn't the right tool for the job. At least not at this moment.
From the name I assumed it was a plugin for Obsidian Notes, but I'm glad to see I was wrong. It does look to have a lot of the same Discord UX, but I really wish they would do something different. It shouldn't be too hard to add some sort of voice chat bridging.
To me, the best alternative right now for "it just works" is probably Root. It's not open source or federated or privacy oriented so a lot of people will have justified concerns there. But, it has pretty much all the features of Discord and already has cross platform (including mobile) support.
There's also a lot of potential there for apps and bots as they have a much deeper integration than in Discord. It's also not just a straight rip of Discord's UI like Fluxer and includes a lot of UX improvements.
Most of this went way over my head, but I did enjoy searching for his board games from his "data center" on BoardGameGeek, I might just pick up a copy of Quoridor!
I gave that as a wedding present once.
I have a soft spot for an expertly crafted commit message, such as this one.
djb has some interesting notes on leveraging Debian's support for installing multiple architectures to build and run Fil-C compiled programs on a standard Debian box, https://cr.yp.to/2025/fil-c.html. It would be cool if you could just add a Fil-C debian repo and install security sensitive software, whose performance doesn't matter, e.g.
sudo, and have it just work.Though, there has been quite a bit of discussion of Fil-C on lobste.rs of late, I had not seen a good overview of how it works under the covers. This article does a good job of providing that overview.
Would love a deep dive on how Fil-C works for a layman audience like myself, which has written some C, but doesn't have a good understanding of the compiler complexities behind its operation.
Someone just posted a LWN article about Fil-C:
https://lobste.rs/s/mg0aur/fil_c_memory_safe_c_implementation
https://lwn.net/SubscriberLink/1042938/38d8dde9db211cab/
See also:
https://fil-c.org/invisicaps_by_example
Whenever I see anything Oxide, I have to wonder who the intended customer base is. I can't imagine the market for artisanal EC2 in a box is very big. They're pretty shy about who's buying it, but I'm quite curious.
We talk about customers when we can! For example, https://oxide.computer/blog/oxide-computer-company-and-lawrence-livermore-national-laboratory .
The answer boils down to “government, finance, Fortune 1000” being three huge verticals, though by no means are things exclusive to that.
All I can tell is that in telecoms it's also expected from the big vendors. Been on both sides of that.
They mention a number of times that some of their customers require an updating mechanism that works across an air gap. Given the desire for an air gap, I think we can make some pretty good guesses about who are a few of their customers.
grep: https://youtu.be/NTfOnGZUZDk?t=40
The part of the video that actually explains the acronym – “global regular expression print” – is 8:25 to 8:36. The nearest context checkpoint before that is at 7:38. You linked to 0:40. I think requiring people to watch or skip through 7 minutes of irrelevant content to understand your comment was a bit rude. If you just wanted to recommend the video as a whole, it would have been kinder to either say that – e.g. “long explanation, but has interesting historical context I never knew” – or to link to the video as a whole without an accurate-to-the-second timestamp.
Also, as far as I can tell, the word “grep” is not funny or crude, as OP had asked for.
I really enjoyed the whole video, and definitely didn't think your comment was rude, especially in the context of a lighter post to begin with, thanks for posting it!
I'm sorry. I watched this video a few years ago and tried to find the frame that's starting the explanation. Seems like I was totally off.
Very cool, I would love to give this a try in combination with fastmail, which supposedly has support for VTODO and VJOURNAL cards.
Fastmail should have VJOURNAL support though you may need to create a new calendar with VJOURNAL enabled manually using curl. I documented how I did it for Nextcloud in the Readme, I think it should also work for fastmail.
Currently Agendafs only supports VJOURNALs, but it's in the backlog to support VTODOs and maybe even VEVENTs. I'm just not quite sure what the ideal interface is yet for those event types.
I think a lot of the keybinds that readline uses that come from emacs are because readline by default uses emacs mode; you can change it to use vi mode: https://www.gnu.org/software/bash/manual/html_node/Readline-vi-Mode.html
(annoyingly, programs that are only emulating readline's default behavior will not be affected by this)
Also, the - convention seems to be a POSIX-ism too: https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html#tag_12_02
The - convention goes back to the original getopt written by Aaron S Cohen in 1979 https://lobste.rs/s/rzmesn/getopt_smaller
At my last job we had a bit of a tug of war between users like myself who prefer readline vi keybindings and those that prefer the default emacs keybindings. When trying to solve the problem I discovered that the majority of the key bindings do not overlap, so I create a merged config, https://github.com/lollipopman/bash-rsi
Not the focus of this particular blog post, but Julia Evans wrote another terminal blog post a while back which makes note of this under the topic of "Entering Text in the Terminal" https://jvns.ca/blog/2024/07/08/readline/ (the vim setting comes up later in the post than the readline sunb-heading).
Personally I think changing this readline behavior would throw me off more than actually switching my default shell.
Looks very nice, I used a similar tool in the past, https://saitoha.github.io/trachet/, which worked really well
Just tried using it after I ran into a couple of issues with
sequin, buttrachetis python 2.x only :'(damn, the python 2 to 3 curse strikes again!
What kind of issues did you encounter? We’d love to know so we can fix ’em.
I think I couldn't get the examples in the docs that show running an application under a pty provided by
sequinto work,sequin -- foowould error out about unrecognized commandline arguments or similar. I ended up solving it by running the application I was interested in profiling undersocatthen piping that output tosequinand for others requiring interactive tty input, usingscript session.logand reading the recordedsession.logwithsequin.I also wanted to see if
trachetwould give more specific results for some of the most common and universally supported private mode operations where sequin would just always reportEnable private mode "cursor keys"whether I was enabling or disabling any of a myriad of behaviors.Headline feature is a new
ansiwriter for attractive(?) terminal output, which as it happens was the work of yours truly.Are there docs for how to customize the output? One thing I noticed when I tried it out was that bold/strong text is rendered with ANSI bold colors, but I have my terminal emulator to not treat bold text differently. I was curious to see whether there was an option I could use to pick a particular color to render bold text. Another one I noticed is that there is a background color on inline code, but not on syntax-highlighted code blocks (they’re just indented instead). And a third thing was that H1 markdown headers were rendered in ALL CAPS, when I was thinking that some documents will care about the case used for specific words in the headings.
It’s no problem if it’s not customizable, it was just the first thing I was curious about when I tried it out on some documents, and I couldn’t see anything mentioned about it in the pandoc manual online.
It's not, watch this issue
What was the use case that prompted you to contribute this? Is there a workflow where you render documents to the terminal frequently, or just thought it might be a fun feature to add?
Partly fun. Partly that I always have pandoc around and I often want to look at some document in the terminal, like a bunch of markdown readmes, and it's nicer to read those reflowed and with bold and italic being actually bold and italic and with clickable links. There's other "read markdown in the terminal" things out there but by adding the feature to pandoc I now have a "read anything in the terminal" program. Plus there was a backlog issue to add it so someone else wanted it at least once.
very cool, thanks for adding this feature!
I am curious: Are you a regular haskell programmer or did you learn it to contribute to pandoc? If so, how was the experience?
This is awesome! And with OCS 8 hyperlink support!
@phy1729 suggested
cronas a name in chat, which is fun but maybe a bit non-obvious? Maybe "weekly-thread" even if a bit specific?+1 from cron or perhaps periodic
Nah, let's not bikeshed on this.
I think it's perfectly valid to bikeshed with it. Why does it need two tags? What if a new kind of regular/scheduled post gets popular?
then we get a tag. we only have 2 weekly posts that stay up for days every week now, let's not solve problems that don't exist right now. YAGNI.