Sorry for noob question: which keyboards is this compatible with? Can I use it with Kinesis Freestyle keyboard? I’d love to disable function overlay and reprogram some utility buttons but I didn’t find compatibility list.
RMK seems to be target more at home built keyboards. It really depends on the microcontroller used in your keyboard. If it uses a STM32, a RP2040 a CH32, an esp32 or a NRF chip, chances are you can get a config that works. (Basically anything that rusts embassy library supports.) However, as somone halfway through porting my keyboard, its not quite as easy as flashing QMK yet, because QMK provides a ton of configs for prebuilt keyboards, configs that you have to write on your own for RMK. The actual config writing is easier in RMK than QMK, but the fact that you have to write them at all makes RMK a bit harder if your keyboard is already supported by QMK.
Found this the other day, already about halfway through porting my keyboard from QMK to this. I think its really cool to see embedded rust applications where you can build/bring your own hardware.
Unfortunately, that is trivially untrue. One could imagine an ASIC that plays doom, but does not have the capability to do anything else (like the original analogue PONG circuit). Ergo, playing DOOM is not an indicator of being Turing complete. (note that this does not work with all games, a factorio ASIC would be Turing complete, because you can build a Turing machine inside factorio itself.)
Yeah, which in case of Typescript types is reflected in things such as limited recursion depth and such. While Dimitro worked around for development by modifying the Typescript compiler, the final thing runs as-is with regular Typescript, so it is subject to all the limitations (and works regardless). It’s not obvious that it would work
Really exited to see typst continue to improve, especially regarding HTML output. Im looking forward to being able to use a single markup language for both web and print, as latex-to-html isnt great, neither is MD/asciidoc-to-pdf.
Besides being obsessed with lightweight markup languages, lately I started writing my own mail client… mostly to write a composition format based on a lightweight markup language.
So I can send out emails with both a readable plaintext version (that my client would wrap, etc.) and a plain HTML semantic version. And I was considering Typst for this!
I actually have a friend that does email automation—ensuring HTML outputs and email presentation are correct across different clients is the worst part of her job she tells me. So many edge cases and lack of support for the standard.
I don’t have a lot of first-hand experience, but I hear that’s mostly layout. HTML fancy email is stuck using tables without CSS, and apparently table layouts that work across different mail clients are priced heirlooms passed from one generation to the next.
The styling I want to do is mostly what most mail clients let you do (bold, italics, etc.), and I think that’s reasonable to get to work.
Fortunately I didn’t have to touch this for years - but the last person to have this horrible task told me that they were writing HTML like “for browsers of 10 years ago” - maybe it’s 15 years now. Very limited set of CSS and still some table layouts. Or something actually improved in the last years.
If you include an HTML version and a plain text version of the contents of the email, then I think all mail clients (terminal clients included) will show you the proper version.
The main problem (IMHO) is that many HTML email composition systems have the plain text version as an afterthought, so it’s often horrible or unusable.
This is why I think a proper mail composition system should take care of making both versions nice. By using something like Markdown or Typst, the mail composition system can create a good-looking text version, reflow it properly (so you don’t have to care about wordwrapping) and a good-looking HTML version.
I guess it’s still a bit wasteful to send both versions of the content of the email when the text version would suffice, but I think it’s also true that the experience on non-terminal clients with plain text emails is also bad. So sending dual emails IMHO is more pragmatic right now.
I am not an expert on plain text email, but traditionally, plain text emails are wrapped to 80-character lines. This has “responsive design” issues; you might typically experience this by browsing mailing lists in a phone.
There is format=flowed, but I have not used it to learn if it works well and is widely supported.
ah I didn’t consider that. a lot of clients wrap to 72 lines by default, but I can see how that would still be enough to dissuade reading on a phone. honestly probably helps the quality of replies.
As ususual, I plan to participate for as long as I can complete the challenges within 1 day, and then ill peck at it till I get bored. I started when I was a student, and year over year I get farther, so if the trendline continues, I should eventually complete a year, then I guess Ill start going back and doing previous years?
Oh hey, I must have missed this being posted. Author here. This is my first ‘real’ article, and it took me way to long to write, so some sections might be a bit disjointed…
This whole complaining about rent seekers and then going about face and bragging about how everyone will need them and then they will be able to collect rent is really rubbing me the wrong way. Making me reconsider my usage of tailscale. At least there is headscale to fall back on.
Im surprised at how performant sshfs is. I always thought if it as a short term mounting option for when you infrequently need to acess a folder and dont want to go through the bother of setting up a full remote filesystem, but if it was something you wanted permanently mounted, you should really go with something higher performing. Happy to be shown to be wrong.
I think the issues with sshfs are less around performance per se, and more around not having all of the complex facilities that NFS and SMB provide for safe access (under some conditions) from multiple machines; e.g., leasing and cache coherence management, open after close consistency, etc.
I’ve never ever had good experiences with sshfs for anything but short term mounting, but that was for remote access, not local access. Though as I recall it was kinda unreliable, even when performance was good.
Sorry for noob question: which keyboards is this compatible with? Can I use it with Kinesis Freestyle keyboard? I’d love to disable function overlay and reprogram some utility buttons but I didn’t find compatibility list.
RMK seems to be target more at home built keyboards. It really depends on the microcontroller used in your keyboard. If it uses a STM32, a RP2040 a CH32, an esp32 or a NRF chip, chances are you can get a config that works. (Basically anything that rusts embassy library supports.) However, as somone halfway through porting my keyboard, its not quite as easy as flashing QMK yet, because QMK provides a ton of configs for prebuilt keyboards, configs that you have to write on your own for RMK. The actual config writing is easier in RMK than QMK, but the fact that you have to write them at all makes RMK a bit harder if your keyboard is already supported by QMK.
Found this the other day, already about halfway through porting my keyboard from QMK to this. I think its really cool to see embedded rust applications where you can build/bring your own hardware.
The big lesson from 1936 Turing:
Anything that’s Turing complete can run DOOM.
I’m wondering if we’re at the point where we can flip the definition on its head: something is Turing complete if it can run DOOM.
Unfortunately, that is trivially untrue. One could imagine an ASIC that plays doom, but does not have the capability to do anything else (like the original analogue PONG circuit). Ergo, playing DOOM is not an indicator of being Turing complete. (note that this does not work with all games, a factorio ASIC would be Turing complete, because you can build a Turing machine inside factorio itself.)
Actually, Doom is Turing-complete: NAND gates are possible, and they can be used to assemble any other gate.
I wonder how programmable are the SCRIPT lumps in a WAD file
Trivially though, no real-world system is Turing complete.
What do you mean? Because the tape isn’t infinite?
Yeah, which in case of Typescript types is reflected in things such as limited recursion depth and such. While Dimitro worked around for development by modifying the Typescript compiler, the final thing runs as-is with regular Typescript, so it is subject to all the limitations (and works regardless). It’s not obvious that it would work
Really exited to see typst continue to improve, especially regarding HTML output. Im looking forward to being able to use a single markup language for both web and print, as latex-to-html isnt great, neither is MD/asciidoc-to-pdf.
An impossibly difficult order, I’d love to see any of these tools support HTML export for use in email.
Are you in my head?
Besides being obsessed with lightweight markup languages, lately I started writing my own mail client… mostly to write a composition format based on a lightweight markup language.
So I can send out emails with both a readable plaintext version (that my client would wrap, etc.) and a plain HTML semantic version. And I was considering Typst for this!
I actually have a friend that does email automation—ensuring HTML outputs and email presentation are correct across different clients is the worst part of her job she tells me. So many edge cases and lack of support for the standard.
I don’t have a lot of first-hand experience, but I hear that’s mostly layout. HTML fancy email is stuck using tables without CSS, and apparently table layouts that work across different mail clients are priced heirlooms passed from one generation to the next.
The styling I want to do is mostly what most mail clients let you do (bold, italics, etc.), and I think that’s reasonable to get to work.
Fortunately I didn’t have to touch this for years - but the last person to have this horrible task told me that they were writing HTML like “for browsers of 10 years ago” - maybe it’s 15 years now. Very limited set of CSS and still some table layouts. Or something actually improved in the last years.
isn’t it kind of a faux pas to put HTML in emails?
If you include an HTML version and a plain text version of the contents of the email, then I think all mail clients (terminal clients included) will show you the proper version.
The main problem (IMHO) is that many HTML email composition systems have the plain text version as an afterthought, so it’s often horrible or unusable.
This is why I think a proper mail composition system should take care of making both versions nice. By using something like Markdown or Typst, the mail composition system can create a good-looking text version, reflow it properly (so you don’t have to care about wordwrapping) and a good-looking HTML version.
I guess it’s still a bit wasteful to send both versions of the content of the email when the text version would suffice, but I think it’s also true that the experience on non-terminal clients with plain text emails is also bad. So sending dual emails IMHO is more pragmatic right now.
why is that?
I worded that poorly.
I am not an expert on plain text email, but traditionally, plain text emails are wrapped to 80-character lines. This has “responsive design” issues; you might typically experience this by browsing mailing lists in a phone.
There is format=flowed, but I have not used it to learn if it works well and is widely supported.
Like many attempts to improve email, it was fucked by Microsoft’s refusal to implement it.
ah I didn’t consider that. a lot of clients wrap to 72 lines by default, but I can see how that would still be enough to dissuade reading on a phone. honestly probably helps the quality of replies.
On mailing lists, yes, but the vast majority of other mails have HTML.
the vast majority of other mails are also spam with tracking pixels etc.; I don’t think that makes it socially acceptable
I would have said that rst/Sphinx is pretty good, except I’m now writing fifth post-transform to massage the LaTeX output
As ususual, I plan to participate for as long as I can complete the challenges within 1 day, and then ill peck at it till I get bored. I started when I was a student, and year over year I get farther, so if the trendline continues, I should eventually complete a year, then I guess Ill start going back and doing previous years?
My first patch landed on this one! I wrote a single line to add
platform.architecture()on MacOS.It feels so good when one’s PR is accepted and the changes are upstreamed. Good work.
thank you :)
Same here, I did a single line bugfix in the zipapp module to avoid creating infinitely large zipfiles.
Well done !
thanks :)
Oh hey, I must have missed this being posted. Author here. This is my first ‘real’ article, and it took me way to long to write, so some sections might be a bit disjointed…
This whole complaining about rent seekers and then going about face and bragging about how everyone will need them and then they will be able to collect rent is really rubbing me the wrong way. Making me reconsider my usage of tailscale. At least there is headscale to fall back on.
Im surprised at how performant sshfs is. I always thought if it as a short term mounting option for when you infrequently need to acess a folder and dont want to go through the bother of setting up a full remote filesystem, but if it was something you wanted permanently mounted, you should really go with something higher performing. Happy to be shown to be wrong.
I think the issues with sshfs are less around performance per se, and more around not having all of the complex facilities that NFS and SMB provide for safe access (under some conditions) from multiple machines; e.g., leasing and cache coherence management, open after close consistency, etc.
I’ve never ever had good experiences with sshfs for anything but short term mounting, but that was for remote access, not local access. Though as I recall it was kinda unreliable, even when performance was good.