This looks like a solution looking for a problem. I’ve heard lots of things about grpc being absurdly complex. I think it’s cool, but I think I’ll stick with SSH. Thank you very much.
Indeed :) The point is not to get anyone to use rsync over gRPC, but to demonstrate that if you are already working in a corporate (or similar) environment with a landscape of RPC services using gRPC, Thrift, etc., you can now also speak rsync protocol over those channels, if it helps your project.
I’ve banned Googlebot on my personal site, though only through robots.txt and not the user-agent sniffing I use for other bots. I don’t really care about it being searchable anymore.
One of my favourite Firefox tweaks is making the scrollbar be chunky and easy to use. this hack reminds me that I’ve got that customisation on, and I’m thankful it still works, but I’m sadly certain it will go away at some point.
I keep reading of such things, but they are all way more complex than I want. Databases, code that extracts stuff thence, etc.
I just want a plain old 1990s web site made of flat HTML with no code in it whatsoever, kept in a filesystem, and some tooling to make that easier to maintain. Maybe even Markdown instead of HTML.
My websites are all just a bunch of HTML files and associated images, etc. The only tooling I use is my text editor and then ftp or rsync to upload the files to the server.
The only thing that’s annoying to maintain manually is an RSS feed. At some point I’ll get around to writing a script to automatically generate a feed file. Or possibly not.
I have tried quite a few static site generators - my favourite was sblg - but, other than the RSS feed, they all seem like overkill.
For a multi-person blog or a newspaper or something else with multiple contributors, perhaps with varying levels of tech savviness, then I can see the point of a CMS. For a single person’s website, I’ve never found anything that beats Notepad and an FTP client.
I started that way … wow, yes, about thirty years ago … and then migrated to various static site generators, supposedly to save time. But then I realised that I was spending significantly more time wrangling the site generators than I ever used to spend doing things manually. Hence my return to just editing files myself: I do that in 2025 because life’s too short!
I’ve been a paying user of Dropbox for a long time now. Probably 10+ years. The worst thing about it is that it works way too well (for me at least) and replacing it will be hard.
Having backups solved out is a huge relief. All of my devices can explode at the same time and I’ll not lose anything important.
That said, privacy concerns have been always on the back of my head, and the current situation with the US doesn’t help, so I’m in the process of learning how to manage my own backups reliably.
First step will be synchronizing my entire Dropbox with a NAS at home (a Debian cheap box with a couple of disks on RAID 1) and then backing that up regularly offsite, protected with a password.
Eventually I should be able to just remove Dropbox and start accessing my NAS directly via any of the solutions mentioned in the article, or just WebDAV/SMB/SFTP, or all at once.
Having backups solved out is a huge relief. All of my devices can explode at the same time and I’ll not lose anything important.
What Dropbox provides doesn’t meet my definition of backup.
Funny story: once, my wife used Dropbox to “backup” all her data from an external HDD. One time, the drive/cable/OS glitched and presented an empty filesystem, which Dropbox dutifully synced. We weren’t buying the packrat extension at the time but they took pity on us and restored it all. We did after that. But it’s still not “backup”
Not sure if the file recovery feature is available for all users or just paying ones nowadays, but yeah, without that feature it should not be considered a “backup”.
This happens when the article author chooses to paywall it in Medium because it gives them a payout. They are basically using Lobsters as a free traffic source.
for dead simple stuff like alias l=ls -la, I think using a function is overkill. That’s what most of my aliases look like. Anything else yeah, shell function or script file it is.
Aliases integrate more seamlessly with tab completion. You can write a custom tab completion for a wrapper shell function, but with an alias you don’t have to.
The remarkable thing here for me is that Ken Silverman - the genius behind the competing Build engine - got nerd-sniped into hand optimising some of the ASM routines for drawing.
Wow, I don’t see many Haskellers using the Debian provided compiler. I use Debian myself, so I’d be in the target demography, but I prefer to just use GHCup to install the development tools. This seems to be a trend across languages (RustUp is another example).
I am a big fan of stability, so I can see why you’d want to avoid the latest features. Nothing wrong with being compatible with older compilers. But I just see a lot of mistrust regarding the distro packaging. In the Haskell ecosystem, especially around Arch. Nowadays, it seems more conservative to actually avoid the distro packaging. Except for languages like C, where I think most people will prefer the system toolchain.
I’d love to hear the argument for using distro packaging. And what about all the Fedora users? Are they expected to search for the package names, or would you expect them to just use GHCup?
Sorry to go off a tangent, it just really caught my eye.
I guess this is OT but your comment led me to click on through to TFA at least…
Debian developer and Haskeller here (but not a packager of any Haskell stuff in Debian). It’s not just the compiler that’s the problem, the nature of Haskell means if you go with the system compiler you’re also pretty much bound to the system libraries and their versions as well. At least I think that’s how it works.
GHC has the concept of ‘boot libraries’, see version history. Some of the boot libraries are overridable, others are not: e.g. the version of version of base and template-haskell are fixed for each GHC release/version. But the vast majority of dependencies are typically not boot libraries. Since cabal-install v1.24 from 2016 (search for “Tech preview of new nix-style isolated project-based builds” in changelog) you have been able to install separate versions for each project. Documentation for a current version of cabal-install is available at how-to-build-like-nix.html.
A similar feature is available in stack, but I am not sure since when. (possibly it always had this feature)
Stackage is of particular interest because I’ve seen distributions use the Stackage to decide the versions they ship. So if your distro is downstream of Stackage, why not just use Stackage directly?
In my case the answer is just that I have used and known Debian for a long time, so I feel I have an idea of how upgrades, security issues and such are handled. I happen to not have the same relationship with Stackage, and I’m not sure what I would get out of going down that route, when the path I am on works for me.
I wouldn’t describe myself as a Haskeller - I am a beginner at Haskell, and I just want a basic environment that works. I don’t have a need to run the newest, latest version of package X, Y, or Z.
I prefer being in the comforting surroundings of Debian packages, rather than having to faff with finding the right compiler, installing it, pointing all the tools to it etc. etc. I am always baffled by tutorials that start with “Install the bleeding edge version by downloading a personal copy of everything”, that’s not my definition of “easy”, easy is “apt install” :-)
With regards to people not running Debian, contributing what is needed to compile is up to them. On Debian, at least, if you do not install all the libghc-*-dev packages, cabal will happily download and compile from Hackage. I expect the same to be the case for all the Fedora users.
I’ve never tried GHCup, so I don’t know what the experience going down that route is.
If you use a distro-packaged build of Firefox that comes from competent packagers, this will certainly be stripped out. Unfortunately it’s not clear to me that said competent packagers exist. Debian in most cases is very good at this kind of thing, but the Debian packager for Firefox is employed by Mozilla and has a terrible track record for removing even the most egregiously unpopular shit from Firefox.
Debian in most cases is very good at this kind of thing, but the Debian packager for Firefox is employed by Mozilla and has a terrible track record for removing even the most egregiously unpopular shit from Firefox.
I would suspect that “having a terrible track record for removing even the most egregiously unpopular shit” is likely a direct prerequisite of Debian’s permission to use the Firefox branding.
IOWs, if stripping-out ever happens, in any distro, the result will have to be called Iceweasel.
These Terms only apply to the Executable Code version of Firefox, not the Firefox source code.
…the “Executable Code” version of the Firefox web browser, which is the ready-to-run version of Firefox from an authorized source that you can open and use right away.
It sounds like this wouldn’t apply to distro packages, depending on what the undefined “authorized sources” are.
It’s the terms of service. You don’t have to agree to terms of service to use (read, modify, etc.) the source code, because the source code in itself does not offer any services.
You only have to agree to the terms of service to use a binary that presumably has the API keys (that would enable the binary to communicate with the provider of the service) compiled in. Whether you need to agree to these terms to use a given binary probably depends on whether it has Mozilla’s API keys compiled in.
Yes, and the would-be benevolent packager would take these there sources, which provide no services, and build his own executable code.
The question though is, did they need to accept the terms to download the sources? If the packager never needed to see the terms and didn’t agree to them, do the terms apply to this other binary?
The question though is, did they need to accept the terms to download the sources? If the packager never needed to see the terms and didn’t agree to them, do the terms apply to this other binary?
I’d expect that the packager would have to agree to the terms of service (and, transitively, agree to bind their users to those terms) in order to get the Mozilla API keys, or something like that.
Debian in most cases is very good at this kind of thing, but the Debian packager for Firefox is employed by Mozilla and has a terrible track record for removing even the most egregiously unpopular shit from Firefox.
Can you elaborate and/or provide a reference? The only identifier I could find for the packager was “Maintainers of Mozilla-related packages”:
It would also be good to get some clarity on the channels that could be used to ensure Debian is following its principles. I know they pride themselves on some form of internal democracy.
If you know of git-annex or any of his other work, you’ll know Joey Hess has been deeply involved in Debian in the past, but admittedly it’s not a super thorough source.
This is my first post in a series intended to draw programmers from outside the functional programming sphere into dependent typing, by showing off ways that dependent typing can be used to build ergonomic and misuse-resistant APIs in ways that would typically require macros in languages with less powerful type systems.
My target audience is still a bit vauge for this series, currently I’m targeting systems programmers that have decent experience with strongly typed languages, rust comes to mind since I’ve worked extensively in it personally, and has maybe tried haskell and gotten burnt by it.
Feedback is appreciated, I’m interested in hearing about how I can make posts like this more approachable to people with other backgrounds, and I’m also very interested in seeing examples of macros people would like to see disappear into the type system.
How strong is the compile time / run time phase separation in Idris?
Could this technique work with format strings that are chosen at run time, with the type system ensuring that the strings are compatible? (Assuming format strings come from a limited set that is fixed at compile time.)
For Idris 2, that’s a tricky one to answer extensively, I’ve got a whole several posts planned out explaining that. One of 2’s unique features among dependently typed languages, even counting Idris 1, is it’s integration of linear types, which are very similar to the affine types of rust’s ownership, but used for a totally different purpose of controlling the spill over between compile time and run time. Idris 2 has a rather expressive sub language, so to speak, for explicitly encoding the relationship between compile time and runtime.
For the second question, that wouldn’t be difficult, and I’ll probably getting around to covering something like that sooner or later, but basically you just need to write a function that “decides” (produces a proof of equality or a proof of inequality at runtime) whether or not the type signatures produced by two format strings are equal, and then you can pretty easily write up a procedure that reuses printfFmt to make a function that checks two format strings for compatibility at runtime, and then uses the types from the first to accept arguments for the latter. I may actually end up writing that as an addenda to this post.
I realized that the specific case you were asking about (where the format strings come from a limited set that is fixed at compile time) is actually basically trivial, so I’ve gone ahead and written a little addendum to the post showing that off.
I still think I’ll write another addenda later on that covers the case where the format string is generated at runtime and checked, at runtime, against a template format string for type compatibility, but that’s going to require some slight refactoring to make the implementation short enough to be suitable for tacking onto this blog post.
I like the sound of this, but note that it is disapproved here to have one’s own work be 25% or more of one’s submissions. Try to submit some other things that you find interesting before the next part of this series.
This is a common misconception of the rule. You can’t ignore the purpose of the rule and skip straight to the rule of thumb.
The purpose of the rule is:
Self-promotion: It’s great to have authors participate in the community, but not to exploit it as a write-only tool for product announcements or driving traffic to their work.
Writing high-quality educational content like this isn’t automatically “self-promotion” just because it was submitted by the author. It also doesn’t automatically become self-promotion based on ratios. Self-promotion is a type of spam, where spam is defined as frequent low-quality/unwanted content. The rule of thumb is just a way to detect the symptoms of self-promotion but cannot diagnose it alone.
Huh. For what it’s worth, I commented as I did because I figured someone would say it was against the self-promotion rule and I preferred to have the message delivered in what I thought would be a supportive, constructive way by a fellow admirer of dependent typing (me) rather than maybe in a more discouraging way by someone who disdains dependent typing.
I remember the intense discussion in the 00s about the necessity of encoding music in the .ogg format because it was free. Of course, that format didn’t work with my iPod, so it was kind of moot for a teenager who wanted to fall asleep listening to Coldplay.
The iPod supported AAC (MPEG-4 Advanced Audio Codec) and, because the iTunes Music Store distributed music in AAC (even after it went DRM-free), pretty much every player I’ve seen in the last 15+ years has been able to decode AAC. AAC gives better quality for the same bitrate as MP3 (MPEG-2 Audio Layer 3).
AAC was introduced 27 years ago, so any relevant patents expired long ago.
The article seems to be implying (without citation and without saying it clearly) that the patents expired recently but every other source I can find (as well as my own memory) says that it happened a long time ago: 2007 in Europe and 2015 or 2017 for the US depending on which patents you count as relevant.
It was. MP3 patents expired ages ago, it’s now 33 years old. Vorbis was really important twenty years ago, when MP3 and AAC patents were still valid. Before Vorbis, there was no good unencumbered way of sharing compressed audio. Now there are a few very good CODECs tuned for different data rates (including some the use less bandwidth than a GSM phone, for much better quality). The value of them has dropped because, unless you’re in a very resource-constrained environment, there’s ample storage capacity and bandwidth for lossless compression.
Importantly, audio has not grown in size as video has. CD audio is very close to the limits of human hearing (and above it for most people). Even uncompressed CD audio is pretty small now, in comparison to modern storage. When I got my first computer with a CD drive, it had a GB of hard disk space. A single CD took most of the disk uncompressed. Now, 1 TB SSDs are common and you could fit a lot of people’s music collection uncompressed in a corner of their phone’s storage. The main reason to want more than CD quality is if you’re doing mixing and need to be able to lose some quality along the way when you resample.
Video quality was not there. I don’t really notice the difference above 1080p but some people do for 4K (I do for a small number of scene types, but not most video). 4K HDR is a much higher raw data rate than DVDs and so there has needed to be an improvement in video CODEC quality. Even there, H.264 is 22 years old and so all of the patents should have expired and it’s perfectly adequate for most things.
Honestly the difference between 320kbit/s and 256kbit/s is so tiny that I always prefer 320kbit/s MP3 when I have the chance. It works everywhere and sounds at least as good as 256kbit/s AAC
According to Wikipedia, the last baseline AAC patent expires in 2028 and the last patent for extensions expires in 2031. So we’re still ways off from AAC being a safe format from a patent perspective.
Since the format was first introduced 1997 some version of it has to have become patent-free 20 years later in the US, like david_chisnall said upthread. That is, whatever patent expires 2028 must be for some technique that 1997 AAC was able to exist without.
I think it is worth noting MP3, like JPEG and gzip, remains Fine – I like Tim Terriberry’s quip that JPEG was “alien technology from the future” – and if something makes an alternative less convenient or otherwise attractive, we’re not suffering by using the old thing; we can handle a few extra bits. (Insert my recurring rant here about how this makes JPEG XL’s JPEG1 recompression a Good Idea, Really!)
Vorbis is an ancient relic, just like MP3, but with worse support. Opus is the standard audio codec for almost everything and supported by almost everything precisely because it is the best lossy audio codec currently in existence.
This doesn’t seem entirely honest: https://caniuse.com/opus – something that’s not supported by ~30% of phones can’t exactly be said to be supported by “almost everything” can it?
https://caniuse.com/ogg-vorbis and vorbis is supported actress the board & is in a lot of portable DAPs from the last 10 years (with Opus supported in many now too). Sometimes you seed curmudgeons to move on if the newer format offers clear wins—especially in quality & file size.
For some platforms there is a workaround; rather that forwarding mail, have the platform collect it from a mailbox using POP3 or IMAP. For example, Gmail have their “check messages from other accounts” functionality in their mailboxes, which picks up you mail from a mailbox as if it’s been received by the Gmail mailbox directly, and other platforms are adding similar options.
I would like to insist my fellow VPS users do this, rather than forward to gmail over SMTP, and further impact our VPS’s IP reputation. I’m fairly sure I’ve seen another Lobsters thread recently calling for POP3 tools to be dropped, unfortunately, last I checked, Google/GMail don’t do ingress from IMAP. I side-stepped the problem to some extent by buying in SMTP services from (coincidentally) Mythic Beasts.
The issue is that Google had no incentive to do this properly, where properly would’ve been telling Google that you’re forwarding email through / from a given email address. Instead, Google decided to treat the forwarder as the source of spam when spam is forwarded, with no way around this.
It makes perfect sense when we consider the fact that Google doesn’t want any email other than their own to work properly, so they have no reason whatsoever to do something that makes sense, or that had been practiced for decades before they existed.
Heh, I could’ve done a better job writing that specific bit. My underlying sentiment was that Lua gives me a lot of programming power. These days I find myself being drawn to the other camp and using configuration instead. The format itself (JSON, TOML, etc.) doesn’t really make a big difference to me.
I’m inclined to agree with you. One of my least favorite things about vim is that you need to learn some imperative language to change things that don’t actually require any kind of evaluation much less a full Turing-complete programming language. And the really nice thing about JSON and other static configuration languages is that they force tool/plugin authors to invest at least a little thought into their configuration. Some people really like maximally powerful tools for simple tasks, but I’m not among them.
For me it’s the lack of comments in JSON that are a deal breaker. I’m happy to have a declarative configuration (I don’t like conflating the coding and configuration you get with eg lua in neovim) but I absolutely have to have configuration comment able.
I strongly prefer a static configuration file over config written using a programming language.
I don’t believe config for a text editor has any business being Turing complete. Also it makes it impossible (or way more complicated) to get a nice configuration UI, whereas with JSON(C/5)+JSON Schema it can basically be autogenerated.
I don’t believe config for a text editor has any business being Turing complete.
Why? Clearly people get a lot of utility out of being able to programmatically configure their editors or else nobody would use Emacs, Vim, or Neovim, given their programmable configuration being such a core part of their designs.
Does that mean you’d rule out an editor based on its configuration syntax being JSON instead of Lua?
If so, I’m pretty surprised to hear about that being a deal-breaker. I spend maybe 0.01% of my time in an editor configuring it, but maybe that percentage is higher for others?
I spend maybe 0.01% of my time in an editor configuring it, but maybe that percentage is higher for others?
And of that 0.01%, how much of it would actually benefit from a Turing complete programming language? And if static configuration is for those of lesser intellect, why stop at Lua when you could go full C++? Are you even a real programmer if your configuration doesn’t require a compiler? /s
I know you’re being facetious, but I genuinely do benefit from having a full Turing complete language in my config. Maybe it doesn’t need to be Turing complete, but at the very least I heavily use effects and I/O calls. For example I have a homebrew “task runner” that can run a sequence of both shell and vim commands.
Are you doing I/O at config time, or are you doing it at runtime? Because it sounds like the latter. Being able to pass a program to your editor to run in response to some event is different than running some program to configure your editor.
Remember, this is a software project: the probability of the config format eventually growing some kind of conditional evaluation is pretty much 1. I’d rather use Lua (which already looks and behaves like a config language if you don’t use any keywords) than json-plus-random-extra-bits.
Remember, this is a software project: the probability of the config format eventually growing some kind of conditional evaluation is pretty much 1.
I mean, VS Code is a lot more flexible/dynamic/extensible than most editors, and while maybe it does have some kind of conditional evaluation somewhere, I’ve only ever interacted with static configuration. It seems like they do the obvious/sane thing and put the dynamic stuff in plugins that expose their own static configuration. In any case “supports dynamic configuration somewhere, but in practice you never have to deal with it” is wildly different from “we’re going to force all users to do configuration in a programming language even though almost none of them are ever going to need it”.
I can’t speak to vscode, I’m sure it’s very nice. We are still comparing two configuration languages that at their simplest are both key/value collections. Nobody’s forcing you to use the programming parts, that’s just hyperbole. You could just as easily say you’re forced to use JSON and if you have a requirement beyond what’s provided then you’re forced to install or create a plugin. There’s multiple options with various properties, and that’s about as strong as an opinion I feel is necessary here.
I probably would because I just do not enjoy JSON at all. I don’t even use an editor with a Lua config, but I don’t want to touch JSON, really. I’d rather have yaml or plain ini
If I’m expected to read or write that configuration, then yes. The issue isn’t evaluated versus static for me, it’s JSON‘s lack of support for comments.
This looks like a solution looking for a problem. I’ve heard lots of things about grpc being absurdly complex. I think it’s cool, but I think I’ll stick with SSH. Thank you very much.
They said it pretty clearly
Indeed :) The point is not to get anyone to use rsync over gRPC, but to demonstrate that if you are already working in a corporate (or similar) environment with a landscape of RPC services using gRPC, Thrift, etc., you can now also speak rsync protocol over those channels, if it helps your project.
Upstream SSH with the static buffers or hpn-ssh?
I just use upstream and accept the inefficiency these days. But if I was doing more performance critical things, it would be an issue.
When scp is too slow, use qcp which is designed to do well with high-bandwidth high-latency lossy links.
This is nice and old-school.
My static site is buckling under the strain of ai scrapers. I wonder when that problem will need addressing at this entry level.
I’m sorely tempted sometimes. I’m not convinced Google remain relevant in search anymore.
I’ve banned Googlebot on my personal site, though only through robots.txt and not the user-agent sniffing I use for other bots. I don’t really care about it being searchable anymore.
If Google isn’t relevant than what is?
Decentralised social media, rss feeds, and stuff built around those things to aid in discovery. Things like Lobsters! But it depends on what you want.
Many (most?) of the non-Google search engines use Bing as their index.
One of my favourite Firefox tweaks is making the scrollbar be chunky and easy to use. this hack reminds me that I’ve got that customisation on, and I’m thankful it still works, but I’m sadly certain it will go away at some point.
I keep reading of such things, but they are all way more complex than I want. Databases, code that extracts stuff thence, etc.
I just want a plain old 1990s web site made of flat HTML with no code in it whatsoever, kept in a filesystem, and some tooling to make that easier to maintain. Maybe even Markdown instead of HTML.
My websites are all just a bunch of HTML files and associated images, etc. The only tooling I use is my text editor and then
ftporrsyncto upload the files to the server.The only thing that’s annoying to maintain manually is an RSS feed. At some point I’ll get around to writing a script to automatically generate a feed file. Or possibly not.
I have tried quite a few static site generators - my favourite was sblg - but, other than the RSS feed, they all seem like overkill.
For a multi-person blog or a newspaper or something else with multiple contributors, perhaps with varying levels of tech savviness, then I can see the point of a CMS. For a single person’s website, I’ve never found anything that beats Notepad and an FTP client.
That’s how I built it 29 years ago, yes, but life’s too short now.
I started that way … wow, yes, about thirty years ago … and then migrated to various static site generators, supposedly to save time. But then I realised that I was spending significantly more time wrangling the site generators than I ever used to spend doing things manually. Hence my return to just editing files myself: I do that in 2025 because life’s too short!
Oh my. You confirm my darkest fears. I am dismayed.
You’re describing ikiwiki (where the “wiki” part is entirely optional)
I’ve been a paying user of Dropbox for a long time now. Probably 10+ years. The worst thing about it is that it works way too well (for me at least) and replacing it will be hard.
Having backups solved out is a huge relief. All of my devices can explode at the same time and I’ll not lose anything important.
That said, privacy concerns have been always on the back of my head, and the current situation with the US doesn’t help, so I’m in the process of learning how to manage my own backups reliably.
First step will be synchronizing my entire Dropbox with a NAS at home (a Debian cheap box with a couple of disks on RAID 1) and then backing that up regularly offsite, protected with a password.
Eventually I should be able to just remove Dropbox and start accessing my NAS directly via any of the solutions mentioned in the article, or just WebDAV/SMB/SFTP, or all at once.
What Dropbox provides doesn’t meet my definition of backup.
Funny story: once, my wife used Dropbox to “backup” all her data from an external HDD. One time, the drive/cable/OS glitched and presented an empty filesystem, which Dropbox dutifully synced. We weren’t buying the packrat extension at the time but they took pity on us and restored it all. We did after that. But it’s still not “backup”
Not sure if the file recovery feature is available for all users or just paying ones nowadays, but yeah, without that feature it should not be considered a “backup”.
@cosmic-boi, is it in your power to enable the full article?
Everyone else, do we need a “paywall” tag? I’d rather avoid following links to them.
When this happens I flag it as “broken-link”. I cannot access the content so I think that is the correct flag.
This happens when the article author chooses to paywall it in Medium because it gives them a payout. They are basically using Lobsters as a free traffic source.
https://freedium.cfd/https://medium.com/shaffan-mustafas-blog/why-i-still-use-ruby-on-rails-7581464b86be
Does lobste.rs even allow posting links that require accounts?
Try this Friend Link: https://medium.com/shaffan-mustafas-blog/why-i-still-use-ruby-on-rails-7581464b86be?sk=02dbbd69852ab586a44064ccb3d8a2eb
That worked for me, at least this once, thank you. In future please consider an unencumbered link for submissions.
For sure. I’m working on building out my own blog (in Rails!) that won’t have a paywall :)
Have the ai scraper bots not found you yet?
Think the locusts moved on by now. Fingers crossed.
I don’t think I agree with their implicit definition of edge computing. Edit to add: this reads like an advert.
I tend to use shell functions, which have most of the listed benefits of both (though not the no-reloading one).
yeah. i never really got the point of aliases, when functions exist
my guess is that aliases were implemented first, and now they can’t be removed without breaking things for people
for dead simple stuff like
alias l=ls -la, I think using a function is overkill. That’s what most of my aliases look like. Anything else yeah, shell function or script file it is.Aliases integrate more seamlessly with tab completion. You can write a custom tab completion for a wrapper shell function, but with an alias you don’t have to.
In fish you can use the
--wrapsswitch tocompleteto inherit the existing completions (I think).I’d be Surprised if aliases are older than functions.
One significant difference is aliases don’t work in non-interactive contexts. Which avoids some footguns
Remember bash is a combination of interactive features from (t)csh with extended POSIX (k)sh. The C shell predates the Bourne shell.
The original Bourne shell did not have functions https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/man/man1/sh.1
But 2BSD csh did have aliases https://www.tuhs.org/cgi-bin/utree.pl?file=2BSD/man/csh.u
So I think aliases are older.
Therefore, I’m surprised. Thanks :)
I enable aliases in bash scripts, they’re good for some specific tricks.
The remarkable thing here for me is that Ken Silverman - the genius behind the competing Build engine - got nerd-sniped into hand optimising some of the ASM routines for drawing.
Wow, I don’t see many Haskellers using the Debian provided compiler. I use Debian myself, so I’d be in the target demography, but I prefer to just use GHCup to install the development tools. This seems to be a trend across languages (RustUp is another example).
I am a big fan of stability, so I can see why you’d want to avoid the latest features. Nothing wrong with being compatible with older compilers. But I just see a lot of mistrust regarding the distro packaging. In the Haskell ecosystem, especially around Arch. Nowadays, it seems more conservative to actually avoid the distro packaging. Except for languages like C, where I think most people will prefer the system toolchain.
I’d love to hear the argument for using distro packaging. And what about all the Fedora users? Are they expected to search for the package names, or would you expect them to just use GHCup?
Sorry to go off a tangent, it just really caught my eye.
I guess this is OT but your comment led me to click on through to TFA at least…
Debian developer and Haskeller here (but not a packager of any Haskell stuff in Debian). It’s not just the compiler that’s the problem, the nature of Haskell means if you go with the system compiler you’re also pretty much bound to the system libraries and their versions as well. At least I think that’s how it works.
GHC has the concept of ‘boot libraries’, see version history. Some of the boot libraries are overridable, others are not: e.g. the version of version of
baseandtemplate-haskellare fixed for each GHC release/version. But the vast majority of dependencies are typically not boot libraries. Since cabal-install v1.24 from 2016 (search for “Tech preview of new nix-style isolated project-based builds” in changelog) you have been able to install separate versions for each project. Documentation for a current version of cabal-install is available at how-to-build-like-nix.html.A similar feature is available in stack, but I am not sure since when. (possibly it always had this feature)
Stackage is of particular interest because I’ve seen distributions use the Stackage to decide the versions they ship. So if your distro is downstream of Stackage, why not just use Stackage directly?
In my case the answer is just that I have used and known Debian for a long time, so I feel I have an idea of how upgrades, security issues and such are handled. I happen to not have the same relationship with Stackage, and I’m not sure what I would get out of going down that route, when the path I am on works for me.
I wouldn’t describe myself as a Haskeller - I am a beginner at Haskell, and I just want a basic environment that works. I don’t have a need to run the newest, latest version of package X, Y, or Z.
I prefer being in the comforting surroundings of Debian packages, rather than having to faff with finding the right compiler, installing it, pointing all the tools to it etc. etc. I am always baffled by tutorials that start with “Install the bleeding edge version by downloading a personal copy of everything”, that’s not my definition of “easy”, easy is “apt install” :-)
With regards to people not running Debian, contributing what is needed to compile is up to them. On Debian, at least, if you do not install all the libghc-*-dev packages, cabal will happily download and compile from Hackage. I expect the same to be the case for all the Fedora users.
I’ve never tried GHCup, so I don’t know what the experience going down that route is.
If you use a distro-packaged build of Firefox that comes from competent packagers, this will certainly be stripped out. Unfortunately it’s not clear to me that said competent packagers exist. Debian in most cases is very good at this kind of thing, but the Debian packager for Firefox is employed by Mozilla and has a terrible track record for removing even the most egregiously unpopular shit from Firefox.
I’m curious to see what Fedora will do.
I would suspect that “having a terrible track record for removing even the most egregiously unpopular shit” is likely a direct prerequisite of Debian’s permission to use the Firefox branding.
IOWs, if stripping-out ever happens, in any distro, the result will have to be called Iceweasel.
That or LibreWolf. Either one would be a big improvement IMO.
From the new Terms of Service:
It sounds like this wouldn’t apply to distro packages, depending on what the undefined “authorized sources” are.
I think you’re parsing it the wrong way around.
It’s the terms of service. You don’t have to agree to terms of service to use (read, modify, etc.) the source code, because the source code in itself does not offer any services.
You only have to agree to the terms of service to use a binary that presumably has the API keys (that would enable the binary to communicate with the provider of the service) compiled in. Whether you need to agree to these terms to use a given binary probably depends on whether it has Mozilla’s API keys compiled in.
Yes, and the would-be benevolent packager would take these there sources, which provide no services, and build his own executable code.
The question though is, did they need to accept the terms to download the sources? If the packager never needed to see the terms and didn’t agree to them, do the terms apply to this other binary?
What you’re describing would be a flagrant DFSG violation, so any packager would hopefully not package it in the first place if so.
I’d expect that the packager would have to agree to the terms of service (and, transitively, agree to bind their users to those terms) in order to get the Mozilla API keys, or something like that.
Does this new EULA conflict with the DFSG?
Edit: this doesnt apply to the source code anyway
Can you elaborate and/or provide a reference? The only identifier I could find for the packager was “Maintainers of Mozilla-related packages”:
https://qa.debian.org/developer.php?login=team%2Bpkg-mozilla%40tracker.debian.org
It would also be good to get some clarity on the channels that could be used to ensure Debian is following its principles. I know they pride themselves on some form of internal democracy.
I wish I had a better reference but all I have is https://hachyderm.io/@joeyh/113082688008129977 and recollections of other discussions I’ve had with him.
If you know of git-annex or any of his other work, you’ll know Joey Hess has been deeply involved in Debian in the past, but admittedly it’s not a super thorough source.
Hehe, I created one with just the Debian logo in it mapped to that code point for similar reasons.
Came expecting some kind of Lenovo-powered thing and left pleasantly surprised.
This is my first post in a series intended to draw programmers from outside the functional programming sphere into dependent typing, by showing off ways that dependent typing can be used to build ergonomic and misuse-resistant APIs in ways that would typically require macros in languages with less powerful type systems.
My target audience is still a bit vauge for this series, currently I’m targeting systems programmers that have decent experience with strongly typed languages, rust comes to mind since I’ve worked extensively in it personally, and has maybe tried haskell and gotten burnt by it.
Feedback is appreciated, I’m interested in hearing about how I can make posts like this more approachable to people with other backgrounds, and I’m also very interested in seeing examples of macros people would like to see disappear into the type system.
How strong is the compile time / run time phase separation in Idris?
Could this technique work with format strings that are chosen at run time, with the type system ensuring that the strings are compatible? (Assuming format strings come from a limited set that is fixed at compile time.)
For Idris 2, that’s a tricky one to answer extensively, I’ve got a whole several posts planned out explaining that. One of 2’s unique features among dependently typed languages, even counting Idris 1, is it’s integration of linear types, which are very similar to the affine types of rust’s ownership, but used for a totally different purpose of controlling the spill over between compile time and run time. Idris 2 has a rather expressive sub language, so to speak, for explicitly encoding the relationship between compile time and runtime.
For the second question, that wouldn’t be difficult, and I’ll probably getting around to covering something like that sooner or later, but basically you just need to write a function that “decides” (produces a proof of equality or a proof of inequality at runtime) whether or not the type signatures produced by two format strings are equal, and then you can pretty easily write up a procedure that reuses
printfFmtto make a function that checks two format strings for compatibility at runtime, and then uses the types from the first to accept arguments for the latter. I may actually end up writing that as an addenda to this post.That linear type machinery sounds interesting! I’ll look out for your future articles, thanks!
I realized that the specific case you were asking about (where the format strings come from a limited set that is fixed at compile time) is actually basically trivial, so I’ve gone ahead and written a little addendum to the post showing that off.
I still think I’ll write another addenda later on that covers the case where the format string is generated at runtime and checked, at runtime, against a template format string for type compatibility, but that’s going to require some slight refactoring to make the implementation short enough to be suitable for tacking onto this blog post.
I like the sound of this, but note that it is disapproved here to have one’s own work be 25% or more of one’s submissions. Try to submit some other things that you find interesting before the next part of this series.
This is their first ever submission. You can’t extrapolate a trend of only posting their own things from a single submission.
This is a common misconception of the rule. You can’t ignore the purpose of the rule and skip straight to the rule of thumb.
The purpose of the rule is:
Writing high-quality educational content like this isn’t automatically “self-promotion” just because it was submitted by the author. It also doesn’t automatically become self-promotion based on ratios. Self-promotion is a type of spam, where spam is defined as frequent low-quality/unwanted content. The rule of thumb is just a way to detect the symptoms of self-promotion but cannot diagnose it alone.
Huh. For what it’s worth, I commented as I did because I figured someone would say it was against the self-promotion rule and I preferred to have the message delivered in what I thought would be a supportive, constructive way by a fellow admirer of dependent typing (me) rather than maybe in a more discouraging way by someone who disdains dependent typing.
I went through a phase of reaping $HOME like /tmp; it helped me be explicit about what I wanted to keep dot file wise.
I remember the intense discussion in the 00s about the necessity of encoding music in the
.oggformat because it was free. Of course, that format didn’t work with my iPod, so it was kind of moot for a teenager who wanted to fall asleep listening to Coldplay.Time sure fly…
The iPod supported AAC (MPEG-4 Advanced Audio Codec) and, because the iTunes Music Store distributed music in AAC (even after it went DRM-free), pretty much every player I’ve seen in the last 15+ years has been able to decode AAC. AAC gives better quality for the same bitrate as MP3 (MPEG-2 Audio Layer 3).
AAC was introduced 27 years ago, so any relevant patents expired long ago.
Why wasn’t that true for MP3?
It is true of MP3!
The article seems to be implying (without citation and without saying it clearly) that the patents expired recently but every other source I can find (as well as my own memory) says that it happened a long time ago: 2007 in Europe and 2015 or 2017 for the US depending on which patents you count as relevant.
It was. MP3 patents expired ages ago, it’s now 33 years old. Vorbis was really important twenty years ago, when MP3 and AAC patents were still valid. Before Vorbis, there was no good unencumbered way of sharing compressed audio. Now there are a few very good CODECs tuned for different data rates (including some the use less bandwidth than a GSM phone, for much better quality). The value of them has dropped because, unless you’re in a very resource-constrained environment, there’s ample storage capacity and bandwidth for lossless compression.
Importantly, audio has not grown in size as video has. CD audio is very close to the limits of human hearing (and above it for most people). Even uncompressed CD audio is pretty small now, in comparison to modern storage. When I got my first computer with a CD drive, it had a GB of hard disk space. A single CD took most of the disk uncompressed. Now, 1 TB SSDs are common and you could fit a lot of people’s music collection uncompressed in a corner of their phone’s storage. The main reason to want more than CD quality is if you’re doing mixing and need to be able to lose some quality along the way when you resample.
Video quality was not there. I don’t really notice the difference above 1080p but some people do for 4K (I do for a small number of scene types, but not most video). 4K HDR is a much higher raw data rate than DVDs and so there has needed to be an improvement in video CODEC quality. Even there, H.264 is 22 years old and so all of the patents should have expired and it’s perfectly adequate for most things.
Honestly the difference between 320kbit/s and 256kbit/s is so tiny that I always prefer 320kbit/s MP3 when I have the chance. It works everywhere and sounds at least as good as 256kbit/s AAC
According to Wikipedia, the last baseline AAC patent expires in 2028 and the last patent for extensions expires in 2031. So we’re still ways off from AAC being a safe format from a patent perspective.
Since the format was first introduced 1997 some version of it has to have become patent-free 20 years later in the US, like david_chisnall said upthread. That is, whatever patent expires 2028 must be for some technique that 1997 AAC was able to exist without.
I think it is worth noting MP3, like JPEG and gzip, remains Fine – I like Tim Terriberry’s quip that JPEG was “alien technology from the future” – and if something makes an alternative less convenient or otherwise attractive, we’re not suffering by using the old thing; we can handle a few extra bits. (Insert my recurring rant here about how this makes JPEG XL’s JPEG1 recompression a Good Idea, Really!)
But why not use 128 opus which also sounds just as good and saves space?
Everything supports MP3, lots of things don’t support OGG.
Also I’m confused about the choice between OGG Vorbis and OGG Opus, but MP3 is MP3
Vorbis is an ancient relic, just like MP3, but with worse support. Opus is the standard audio codec for almost everything and supported by almost everything precisely because it is the best lossy audio codec currently in existence.
This doesn’t seem entirely honest: https://caniuse.com/opus – something that’s not supported by ~30% of phones can’t exactly be said to be supported by “almost everything” can it?
Compare to MP3: https://caniuse.com/mp3
That says it’s supported in WebM.
Yes, which is great if you have a video which uses Vorbis or Opus for its audio, but not so great if what you want is to play audio.
WebM is a generic media container and is usable for non-video use cases. An audio only webm works just fine in an
<audio>element, including on iOS.I didn’t know that. I’ll add it to the pile of information that might’ve been useful to know if just using MP3 everywhere wasn’t an option.
https://caniuse.com/ogg-vorbis and vorbis is supported actress the board & is in a lot of portable DAPs from the last 10 years (with Opus supported in many now too). Sometimes you seed curmudgeons to move on if the newer format offers clear wins—especially in quality & file size.
Looks like Vorbis is just as unsupported as Opus, so I don’t understand why one would choose it in favor of MP3
The main drawback of ogg vorbis , in my opinion, is the container format’s limited metadata support.
I would like to insist my fellow VPS users do this, rather than forward to gmail over SMTP, and further impact our VPS’s IP reputation. I’m fairly sure I’ve seen another Lobsters thread recently calling for POP3 tools to be dropped, unfortunately, last I checked, Google/GMail don’t do ingress from IMAP. I side-stepped the problem to some extent by buying in SMTP services from (coincidentally) Mythic Beasts.
The issue is that Google had no incentive to do this properly, where properly would’ve been telling Google that you’re forwarding email through / from a given email address. Instead, Google decided to treat the forwarder as the source of spam when spam is forwarded, with no way around this.
It makes perfect sense when we consider the fact that Google doesn’t want any email other than their own to work properly, so they have no reason whatsoever to do something that makes sense, or that had been practiced for decades before they existed.
buzzer sounds and that’s a NOPE from me!
Heh, I could’ve done a better job writing that specific bit. My underlying sentiment was that Lua gives me a lot of programming power. These days I find myself being drawn to the other camp and using configuration instead. The format itself (JSON, TOML, etc.) doesn’t really make a big difference to me.
I’m inclined to agree with you. One of my least favorite things about vim is that you need to learn some imperative language to change things that don’t actually require any kind of evaluation much less a full Turing-complete programming language. And the really nice thing about JSON and other static configuration languages is that they force tool/plugin authors to invest at least a little thought into their configuration. Some people really like maximally powerful tools for simple tasks, but I’m not among them.
For me it’s the lack of comments in JSON that are a deal breaker. I’m happy to have a declarative configuration (I don’t like conflating the coding and configuration you get with eg lua in neovim) but I absolutely have to have configuration comment able.
i wanted to comment just this, choosing json over lua is the worst possible take i have EVER heard
I strongly prefer a static configuration file over config written using a programming language.
I don’t believe config for a text editor has any business being Turing complete. Also it makes it impossible (or way more complicated) to get a nice configuration UI, whereas with JSON(C/5)+JSON Schema it can basically be autogenerated.
Why? Clearly people get a lot of utility out of being able to programmatically configure their editors or else nobody would use Emacs, Vim, or Neovim, given their programmable configuration being such a core part of their designs.
Is it actually JSON? Config file without comments?
I think it’s JSONC
Does that mean you’d rule out an editor based on its configuration syntax being JSON instead of Lua?
If so, I’m pretty surprised to hear about that being a deal-breaker. I spend maybe 0.01% of my time in an editor configuring it, but maybe that percentage is higher for others?
And of that 0.01%, how much of it would actually benefit from a Turing complete programming language? And if static configuration is for those of lesser intellect, why stop at Lua when you could go full C++? Are you even a real programmer if your configuration doesn’t require a compiler? /s
I know you’re being facetious, but I genuinely do benefit from having a full Turing complete language in my config. Maybe it doesn’t need to be Turing complete, but at the very least I heavily use effects and I/O calls. For example I have a homebrew “task runner” that can run a sequence of both shell and vim commands.
Are you doing I/O at config time, or are you doing it at runtime? Because it sounds like the latter. Being able to pass a program to your editor to run in response to some event is different than running some program to configure your editor.
There’s definitely a f couple places where I define groups of keybindings via for loops.
Remember, this is a software project: the probability of the config format eventually growing some kind of conditional evaluation is pretty much 1. I’d rather use Lua (which already looks and behaves like a config language if you don’t use any keywords) than json-plus-random-extra-bits.
I mean, VS Code is a lot more flexible/dynamic/extensible than most editors, and while maybe it does have some kind of conditional evaluation somewhere, I’ve only ever interacted with static configuration. It seems like they do the obvious/sane thing and put the dynamic stuff in plugins that expose their own static configuration. In any case “supports dynamic configuration somewhere, but in practice you never have to deal with it” is wildly different from “we’re going to force all users to do configuration in a programming language even though almost none of them are ever going to need it”.
I can’t speak to vscode, I’m sure it’s very nice. We are still comparing two configuration languages that at their simplest are both key/value collections. Nobody’s forcing you to use the programming parts, that’s just hyperbole. You could just as easily say you’re forced to use JSON and if you have a requirement beyond what’s provided then you’re forced to install or create a plugin. There’s multiple options with various properties, and that’s about as strong as an opinion I feel is necessary here.
I probably would because I just do not enjoy JSON at all. I don’t even use an editor with a Lua config, but I don’t want to touch JSON, really. I’d rather have yaml or plain ini
If I’m expected to read or write that configuration, then yes. The issue isn’t evaluated versus static for me, it’s JSON‘s lack of support for comments.
Oh! Zed supports comments in its JSON config files even though the JSON spec disallows them.
For example: https://github.com/zed-industries/zed/blob/2b160f4f3cc7c5f7806545acb68884e475ca10a0/assets/keymaps/default-macos.json#L2