Asciinema is awesome. I use it to capture all of the demos for TerminalTextEffects. Their Asciinema GIF Generator tool (AGG) produces high quality terminal recording GIFs by processing the asciicast file. This is the best solution I've found for producing short terminal recordings that can be shared in a README/docs as seen in the TerminalTextEffects repo/docs.
Using the raw file output and/or termsvg type solutions do not work for TTE due to the huge amount of data being written to stdout.
Awesome, glad you like it. The next release 0.13.0 will have a 'random_effect' option so you're not forced to handle it via shell function. It also significantly reduces the data being transferred and the CPU usage by adjusting the framerate to a more appropriate 60fps. It should perform much better on low end devices which are typically accessed via SSH such as raspberry pi's.
I just wanted to say this is absolutely gorgeous. I don't know if I have a use for this, but I love it and please keep doing this. It's mesmerizing and beautiful.
TTE reminds me of Compiz window manager from eons ago, the thing that got me to ditch Windows for Linux, except for the terminal.
Is there a way you can add something like TTE to tmux or vim as a screen saver or something that would trigger occasionally but not all the time? Do you pipe it? Make aliases?
How do you typically use it? What was your intent when you first wrote it, and what do you use it for now?
> Is there a way you can add something like TTE to tmux or vim as a screen saver
I'm not a big vim user, but anywhere you can run a shell command, you should be able to run TTE. As long as ANSI control sequences are respected, the animation should play. TTE will accept piped text or a file input.
> How do you typically use it?
The most common invocation method is either piped text from some other command or passing a text file via command line arg. It also works as a library and can be imported into existing Python applications to produce animations and animated prompts.
> What was your intent when you first wrote it
A post here on HN featured an animation of the Sneakers terminal decryption effect and I thought, I can do that in Python. I wrote a handful of simple effects and really enjoyed the process of writing effects and upgrading the engine to support new features. The effect requirement -> engine feature loop is very satisfying. So, I keep working on it when I have free time.
> what do you use it for now?
It's really more of a toy, and the delay it causes requires some thought when using it, but I've had people reach out with some interesting use cases. Shell startup / SSH motd is pretty common. It can be imported and used as a library, so you may find it as a splash screen or animated prompts in scripts. A few people have shared examples of using it as an animation tool to create advertisements or background animation for electronic music displays. Framework computers recently tweeted a video of TTE running on boot for one of their laptops.
Eventually, I'd like to fully document the API from an effect writing perspective and produce some tutorials. I won't consider the project 'finished' until that happens. I don't want to abandon it before people are able to write their own effects.
Coming from Windows XP, Compiz Fusion was nothing short of revolutionary. If Linux had a game ecosystem back then, it would have beaten the pants off of Windows. It was so much cooler than Windows.
15MB GIF file. I can't man, I just can't. I literally can not.
Can't seek. Can't select text. And I get to use 15x the bandwidth I should have to load it.
Please. Stop. Please. It's gross to take beautifully compressable, seekable, accessible text, shove it into the absolute worst format possible for video, and then call that good.
If you must insist, please at least link to the raw asciinema, or their web viewer. So that I can load it in a fraction of the time, pause it, seek forward and backward, and copy-paste text. I know, I know, who would want any of that. Much better a GIF that loops so fast it's basically meaningless to anyone but the creator.
asciinema.org is currently being hugged to death! The btop stream is from one of the servers, currently reporting 95% CPU usage: https://asciinema.org/s/olesiD03BIFH6Yz1
But it's chugging along!
asciinema server is Elixir/Phoenix, runs on BEAM, and even with lots of connections and high CPU usage it serves request fine. Power of the BEAM. Phew.
Currently it runs on just 2 VMs, 2 GB of RAM each, so I will probably need to scale it up very soon anyway :)
In an age where everything is about clouds, it’s pretty amazing to see a high-profile service like this running smoothly on just a couple of 2 GB VMs. That’s less RAM than a mid-range laptop, and those machines struggle to run a modern browser.
Modern hardware in conjunction with smart software choices can be very capable, but it's pretty negligent to run a service people depend on with such limited resources.
Sure, not every site needs to run on a highly-available elastic cluster of nodes, but the alternative mindset of actively rejecting this architecture is arguably even more harmful.
A healthy deployment should be able to scale up and down easily, if not automatically. I wouldn't want to be woken up at 3am because prod1 needs a CPU/RAM/disk increase and a reboot, and the users wouldn't like that either.
There’s few reasons for this. First, I don’t have infinite budget for this, in fact the budget is close to 0 (sponsorships and donations help). Second, the servers are sponsored by Brightbox, and I’ve been running asciinema.org there for over a decade because BB is reliable and they’re great chaps, but I don’t have infinite resources available there. Finally, I don’t want devops complexity in my side projects.
why wouldn't you cap a free service?
imo it's more irresponsible to demand other people keep a thing you don't pay for running just because you happen to depend on it.
Just because a service doesn't require direct payment doesn't mean that its users shouldn't have any expectations of availability. There should be fair usage limits, of course, even if the service is commercial, but being caught by surprise by a traffic surge and boasting that it runs on underpowered hardware when the project is 10+ years old is irresponsible IMO.
Also, any service can have a financial purpose, even if it's "free" for users. This very forum is "free", yet the cost of hosting it is indirectly paid for by being an ad for the company that runs it. HN also famously runs on underpowered hardware that routinely fails to meet demand, but that is beside the point.
Feel free to NOT use asciinema.org if it doesn't meet your expectations for a reliable service. You can always self-host the server in your ultra-reliable, super-scalable K8S cluster.
It's one of those projects where it really doesn't matter what language it's in, all of them will accomplish the job roughly the same. I'm happy for the dev to rewrite in whatever language motivates them to work on it, because with such a small codebase the chance it will affect functionality is low enough for it to not matter.
Most of the gripes about Go could've been apparent before a single line was written, with just some preliminary research. The packaging issues are valid for 2016, even though they are now resolved with Go modules.
Then the rewrites in ClojureScript, Elixir, and now Rust... Sheesh. All this tells me is that the authors are trend chasers rather than solid engineers, which erodes any trust I had in this project.
When a project has thousands of users it's irresponsible to use it as a testing playground. If there is a legitimate benefit from rewriting something in another language, which is rare to begin with, the decision should be researched thoroughly and committed to. Doing it this often signals that authors easily latch on to shiny new tech, and value their experience over their users'. When the next modern language comes along, will we see a similar post explaining why they chose to abandon Rust?
I value both my experience and the users, and every asciinema release was backward compatible with the earlier ones (with few exceptions, where language change was not a factor), changing nothing in terms of UI/UX/API. The language is an implementation detail.
Did asciinema hurt you? Because you seem to be on a vendetta here.
I’m not sure if you’re an asciinema user or not, but I am, and I’m happy to see the rewrite — it signals to me that the author is still passionate and invested in the project. And he added new features (live streaming) with the rewrite.
It’s people like you who make maintaining open source projects exhausting. Find a more worthwhile hill to die on.
There's so many things wrong with your comment that I'm not sure where to start.
First of all, nobody is on a vendetta or "dying" on any "hills" here... I'm just pointing out shoddy engineering as I see it.
Deciding to rewrite a project in another language rarely has any practical merits. If it's worth considering, then at the very least it should be thoroughly researched, and not done because the author "feels like it", as they've done multiple times already. If this was brought up in any technical meeting for a project with thousands of users, the person would be laughed out of the room, and for good reason. And, yet, because the project happens to be open source, it should be excused, or even celebrated? That is absurd.
The idea that providing the software gratis and with the freedoms to use and modify it should protect the authors from any criticism with how the project is managed is also absurd. Software should be held at the same levels of scrutiny regardless of its license or business model. There's always a contract between developers and users whether it is made explicit or implicit. Using a project with an established user base as your personal technical playground is irresponsible no matter how you look at it.
> And he added new features (live streaming) with the rewrite.
Ah, yes, I'm sure that would be impossible with any other language but Rust.
> It’s people like you who make maintaining open source projects exhausting.
And it's people like you who don't understand open source and only use it because they get something for "free". See? It's easy to villify someone without engaging with any of their arguments.
> When a project has thousands of users it's irresponsible to use it as a testing playground.
Well, what about motivation? If the author has left behind the original language and rewriting it provides them with motivation to continue then it's not "a testing playground", it's a viable way towards continued maintenance.
There are many ways to write code and maintain a project. Just because they don't align with your preferences doesn't make them shoddy.
Developer motivation is important, but the choice of language shouldn't be a primary factor in that. Being passionate about the domain and solving a problem for users should be the primary motivators. Otherwise it signals that once the developer gets bored of their chosen stack, which might include Rust and Elixir (omg BEAAAMM!!!) a few years from now, they will be compelled to abandon the project unless they're allowed to experiment with some other shiny new tech.
But everyone is ignoring the bigger picture here: this project has been written in 5 different languages over the course of its existence, including reversing to a previously used language. That is an insane and unprecedented statistic. Changing a language even once is rarely done, let alone this many times.
> Just because they don't align with your preferences doesn't make them shoddy.
These are not my preferences. Avoiding total rewrites, especially in another language, is a core principle of software engineering, not unlike, I don't know... using testing and version control. Developers may choose to disregard it, but at the very least they should be challenged for it. The fact this person hasn't for such a long time is another signal that this project is mismanaged.
In any case, I'm done defending what would be an uncontroversial opinion in any other setting.
"Rewrites should always be avoided" is not a core principle of software engineering. History has shown that rewriting large, monolithic applications often fails, and so rewrites of large applications often require extra effort to ensure the changes actually ship (like rewriting single views and proxying requests to a new service, for example). If a project is small enough that it can be rewritten and still shipped that extra effort is unneeded, and the fact that this project was rewritten and released makes that clear.
I don't understand why you're so hung up on the history of this project. If we were talking about software being used to send people to space I could see your point, but this is largely a single person project which is obviously being used to learn and have fun.
> "Rewrites should always be avoided" is not a core principle of software engineering.
Why are you misrepresenting what I said? I never claimed that rewrites should always be avoided. But that in most cases they're not a good idea, for various reasons that should be obvious to most developers.
> I don't understand why you're so hung up on the history of this project.
I'm not hung up on this project at all. I have come across it, but I'm not a user. I simply stated an opinion that shouldn't be controversial at all, yet for some reason, I keep having to defend it. So it seems that it struck a nerve with fans of the project who would rather attack me personally than acknowledge the poor decisions made by its author.
> If we were talking about software being used to send people to space I could see your point
It's a very popular project that many projects depend on. Lives don't need to depend on it for it to be managed responsibly.
Anyway, I think we both have better things to do than waste anymore of our time on this discussion, so let's just drop it.
OK, so why in this specific case is it a bad idea, other than you being personally offended by the number of languages used in the project's history?
You keep saying your opinion should be uncontroversial but you've offered no evidence other than an appeal to authority, and I think THAT should not go unchallenged.
My most popular project is maintained solely by me and is downloaded >1.3 billion times a year. That usage does not create a responsibility out of thin air. It got popular because people like it, it's fast, and it has excellent test coverage. I could decide to rewrite it in a compile-to-JavaScript language tomorrow for any reason I like and no one using it would be negatively affected in any way.
I think you are much too rigid on your views about software engineering and they don't comport with the reality of building and releasing projects to the world, for fun or profit.
Asciinema is one of the best products/tools I’ve ever used. I mean the auth/upload CLI flow is so straight to the point and easy to use, despite having to cross a few layers (yep I know other CLIs have something similar, it’s just that Asciinema has never “gotten in my way” when doing something with it)
This is great, congrats for such a huge accomplishment!
My only wish is if asciinema natively supported saving into svg or gif. This would allow you to easily add it to markdown files without the need to install side apps to convert the output to those formats.
I'm a huge fan of Asciinema, and this is awesome work.
Regarding the live streaming feature, I hacked a similar thing on top of s2.dev streams[1] (disclaimer: I am a co-founder), which could alleviate the need for a relay in this architecture[2]. Naturally showing off `btop` was the highlight for me as well :-D.
My favorite elixir project of all time now written in Rust.
Love to see it.
Have you guys added the ability to cleanse / watch command strings for sensitive items like secrets, keys etc? Seems easier than ever with advances in lightweight LLMs.
> Have you guys added the ability to cleanse / watch command strings for sensitive items like secrets, keys etc? Seems easier than ever with advances in lightweight LLMs.
Some games have this feature called "streamer mode", where some text that would normally be on screen is removed, like username or party codes. Makes sense for a terminal to do the same for other sensitive data.
Would actually be nice to standardize an environment variable for this. Obviously not something that you should rely upon when running random tools but can be a nice failsafe.
Threads like this want me to throw my laptop into a volcano and lobotomize myself. I have a bridge if you think an LLM can reliably generically redact passwords. Especially given the intersection of password quality and the type of person to let their passwords leak into output of a recorded terminal session.
I love leaving my baseline security in the hands of a hallucinating, unreliable token generator.
I'm sorry, I don't even know how to explain that this type of feature would be such a mis-feature, it's hard to even know how to explain it to somehow for whom its not obvious.
I’ve sometimes heard Twitch streamers mention that they use two computers for streaming. One is the computer you are seeing on stream, and the other computer is running OBS and using a HDMI capture device.
With this new live streaming feature in Asciinema, I could imagine that a small subset of programming streamers could skip buying a HDMI capture device. Specially the kind of developer who works exclusively in the terminal. This small group of people could now stream their terminal from the dev machine to the OBS machine using Asciinema 3, instead of capturing HDMI output.
That shouldn’t really matter for asciicinema streaming which 0 effect on any kind of performance.
The 2 device setup for game streaming was born because of the heavy CPU usage of x264 encoding. So you could have a PC for the game only while the streamig PC takes the encoding load.
But even then nowadays a lot of people moved on from that since you can use your GPU for encoding (Nvidia NVENC) which almost has 0% overhead and providing the same or slightly worse quality. Really OBS x264 should be only used for offline video recording say for a Youtube video
Another feature of this is that if your primary PC crashes, which happens sometimes especially with some games, your stream doesn’t go down too. This is more important for streams with more viewers and longer runtimes, as restarting the stream drops all the AFK viewers who may still be contributing ad revenue (or just boosting active viewer count which has other flow on benefits too).
You can see this effect in long streamathons/subathons as twitch automatically kills long streams so you’ll see multiday streams get cut up either manually by streamers or automatically by twitch every 24h or so, and the viewer count drops significantly and takes quite some time (many hours) to recover.
YouTube recompresses everything anyway so I found the higher quality you upload the better the result, especially for complex stuff like high-paced gameplay.
And at very high bitrates nvenc quality is just fine. It's mostly at the lower bitrates x264 really shines.
Of course for livestreaming there are different constraints.
Additionally, running on a different computer allows for eg adjusting scenes in OBS or moderating Twitch, without losing focus from the running app/game.
Yeah that makes sense. I was thinking that the two computer setup was also something they did to keep their streaming stuff completely separate from the rest of their life, to not accidentally doxx themselves on-stream and to not accidentally execute malware on the same host they do their email and banking etc on.
i think the setup you describe is used primarily to offload video encoding to a second pc, not something programming streamers (not running graphically intensive games) probably need not concern themselves with it
Asciinema is awesome. I use it to capture all of the demos for TerminalTextEffects. Their Asciinema GIF Generator tool (AGG) produces high quality terminal recording GIFs by processing the asciicast file. This is the best solution I've found for producing short terminal recordings that can be shared in a README/docs as seen in the TerminalTextEffects repo/docs.
Using the raw file output and/or termsvg type solutions do not work for TTE due to the huge amount of data being written to stdout.
https://docs.asciinema.org/manual/agg/
https://github.com/ChrisBuilds/terminaltexteffects
I pass my server motd / startup through a random tte[1] and it makes me happy every time. Thank you!
1: https://keeb.dev/static/login.mp4
Awesome, glad you like it. The next release 0.13.0 will have a 'random_effect' option so you're not forced to handle it via shell function. It also significantly reduces the data being transferred and the CPU usage by adjusting the framerate to a more appropriate 60fps. It should perform much better on low end devices which are typically accessed via SSH such as raspberry pi's.
I just wanted to say this is absolutely gorgeous. I don't know if I have a use for this, but I love it and please keep doing this. It's mesmerizing and beautiful.
TTE reminds me of Compiz window manager from eons ago, the thing that got me to ditch Windows for Linux, except for the terminal.
Is there a way you can add something like TTE to tmux or vim as a screen saver or something that would trigger occasionally but not all the time? Do you pipe it? Make aliases?
How do you typically use it? What was your intent when you first wrote it, and what do you use it for now?
Keep it up!
> Is there a way you can add something like TTE to tmux or vim as a screen saver
I'm not a big vim user, but anywhere you can run a shell command, you should be able to run TTE. As long as ANSI control sequences are respected, the animation should play. TTE will accept piped text or a file input.
> How do you typically use it?
The most common invocation method is either piped text from some other command or passing a text file via command line arg. It also works as a library and can be imported into existing Python applications to produce animations and animated prompts.
> What was your intent when you first wrote it
A post here on HN featured an animation of the Sneakers terminal decryption effect and I thought, I can do that in Python. I wrote a handful of simple effects and really enjoyed the process of writing effects and upgrading the engine to support new features. The effect requirement -> engine feature loop is very satisfying. So, I keep working on it when I have free time.
> what do you use it for now?
It's really more of a toy, and the delay it causes requires some thought when using it, but I've had people reach out with some interesting use cases. Shell startup / SSH motd is pretty common. It can be imported and used as a library, so you may find it as a splash screen or animated prompts in scripts. A few people have shared examples of using it as an animation tool to create advertisements or background animation for electronic music displays. Framework computers recently tweeted a video of TTE running on boot for one of their laptops.
Eventually, I'd like to fully document the API from an effect writing perspective and produce some tutorials. I won't consider the project 'finished' until that happens. I don't want to abandon it before people are able to write their own effects.
* ... Compiz [...] the thing that got me to ditch Windows for Linux [...] *
I thought that was the role of Enlightenment [1] but I guess I'm just old. :)
[1]: https://www.enlightenment.org/
Compiz. Beryl. Compiz Fusion. Unlocks some fun memories.
Also this video has some 6 million views now: https://youtu.be/xC5uEe5OzNQ?si=GOvwOTHV-RVQnxWv . I remember watching it and being awed by the cube effect.
That's certainly a trip down memory lane...
Coming from Windows XP, Compiz Fusion was nothing short of revolutionary. If Linux had a game ecosystem back then, it would have beaten the pants off of Windows. It was so much cooler than Windows.
It was also buggy as hell, but it was fun watching windows jiggle like jello.
t-rec is another great tool, which can record any window and produce a video or a gif.
Not quite the same thing, but sometimes I find it easier if I just want to share a gif of a terminal.
15MB GIF file. I can't man, I just can't. I literally can not.
Can't seek. Can't select text. And I get to use 15x the bandwidth I should have to load it.
Please. Stop. Please. It's gross to take beautifully compressable, seekable, accessible text, shove it into the absolute worst format possible for video, and then call that good.
If you must insist, please at least link to the raw asciinema, or their web viewer. So that I can load it in a fraction of the time, pause it, seek forward and backward, and copy-paste text. I know, I know, who would want any of that. Much better a GIF that loops so fast it's basically meaningless to anyone but the creator.
You can also just upload an MP4 on GitHub. Using GIFs on GitHub is pretty embarrassing.
asciinema.org is currently being hugged to death! The btop stream is from one of the servers, currently reporting 95% CPU usage: https://asciinema.org/s/olesiD03BIFH6Yz1
But it's chugging along!
asciinema server is Elixir/Phoenix, runs on BEAM, and even with lots of connections and high CPU usage it serves request fine. Power of the BEAM. Phew.
Currently it runs on just 2 VMs, 2 GB of RAM each, so I will probably need to scale it up very soon anyway :)
In an age where everything is about clouds, it’s pretty amazing to see a high-profile service like this running smoothly on just a couple of 2 GB VMs. That’s less RAM than a mid-range laptop, and those machines struggle to run a modern browser.
Webservers require an insignificant amount of CPU time in comparison to any graphical interface.
Modern hardware in conjunction with smart software choices can be very capable, but it's pretty negligent to run a service people depend on with such limited resources.
Sure, not every site needs to run on a highly-available elastic cluster of nodes, but the alternative mindset of actively rejecting this architecture is arguably even more harmful.
A healthy deployment should be able to scale up and down easily, if not automatically. I wouldn't want to be woken up at 3am because prod1 needs a CPU/RAM/disk increase and a reboot, and the users wouldn't like that either.
There’s few reasons for this. First, I don’t have infinite budget for this, in fact the budget is close to 0 (sponsorships and donations help). Second, the servers are sponsored by Brightbox, and I’ve been running asciinema.org there for over a decade because BB is reliable and they’re great chaps, but I don’t have infinite resources available there. Finally, I don’t want devops complexity in my side projects.
> service people depend on
why wouldn't you cap a free service? imo it's more irresponsible to demand other people keep a thing you don't pay for running just because you happen to depend on it.
Just because a service doesn't require direct payment doesn't mean that its users shouldn't have any expectations of availability. There should be fair usage limits, of course, even if the service is commercial, but being caught by surprise by a traffic surge and boasting that it runs on underpowered hardware when the project is 10+ years old is irresponsible IMO.
Also, any service can have a financial purpose, even if it's "free" for users. This very forum is "free", yet the cost of hosting it is indirectly paid for by being an ad for the company that runs it. HN also famously runs on underpowered hardware that routinely fails to meet demand, but that is beside the point.
Feel free to NOT use asciinema.org if it doesn't meet your expectations for a reliable service. You can always self-host the server in your ultra-reliable, super-scalable K8S cluster.
Sounds preferable compared to be woken up at 5 am by your cloud providers billing alert.
Just scaled it up, seems pretty stable and responsive again.
Tip: you might want to decrease the btop refresh rate. It's likely that at 100ms a considerable amount of CPU time is taken up by btop itself.
The CPU usage was single digit (%) with no viewers (but other requests being served) with btop at 100ms, so that's not adding a lot. But thanks!
That btop stream is lagging hard now, and jumping between full cpu and idle 0%.
Is the service crashing and restarting?
I was adding more VMs and restarting load balancer. Should be good now.
Thanks for the great service! Is there a way to mirror the streams? Like a Wikipedia dump?
Long live the BEAM!
The Asciinema clients have now gone from Python to Golang back to Python now to Rust
https://docs.asciinema.org/history/
https://blog.asciinema.org/post/and-now-for-something-comple...
It's one of those projects where it really doesn't matter what language it's in, all of them will accomplish the job roughly the same. I'm happy for the dev to rewrite in whatever language motivates them to work on it, because with such a small codebase the chance it will affect functionality is low enough for it to not matter.
That's... interesting.
Most of the gripes about Go could've been apparent before a single line was written, with just some preliminary research. The packaging issues are valid for 2016, even though they are now resolved with Go modules.
Then the rewrites in ClojureScript, Elixir, and now Rust... Sheesh. All this tells me is that the authors are trend chasers rather than solid engineers, which erodes any trust I had in this project.
> All this tells me is that the authors are trend chasers rather than solid engineers, which erodes any trust I had in this project.
Eh. I think my takeaway would be more that this is the authors passion / side project that they use to test and learn new languages.
> I think my takeaway would be more that this is the authors passion / side project that they use to test and learn new languages.
That's precisely it :) I believe I’ve finally found the ones that work well both for me and the project.
When a project has thousands of users it's irresponsible to use it as a testing playground. If there is a legitimate benefit from rewriting something in another language, which is rare to begin with, the decision should be researched thoroughly and committed to. Doing it this often signals that authors easily latch on to shiny new tech, and value their experience over their users'. When the next modern language comes along, will we see a similar post explaining why they chose to abandon Rust?
I value both my experience and the users, and every asciinema release was backward compatible with the earlier ones (with few exceptions, where language change was not a factor), changing nothing in terms of UI/UX/API. The language is an implementation detail.
What's your problem?
Did asciinema hurt you? Because you seem to be on a vendetta here.
I’m not sure if you’re an asciinema user or not, but I am, and I’m happy to see the rewrite — it signals to me that the author is still passionate and invested in the project. And he added new features (live streaming) with the rewrite.
It’s people like you who make maintaining open source projects exhausting. Find a more worthwhile hill to die on.
There's so many things wrong with your comment that I'm not sure where to start.
First of all, nobody is on a vendetta or "dying" on any "hills" here... I'm just pointing out shoddy engineering as I see it.
Deciding to rewrite a project in another language rarely has any practical merits. If it's worth considering, then at the very least it should be thoroughly researched, and not done because the author "feels like it", as they've done multiple times already. If this was brought up in any technical meeting for a project with thousands of users, the person would be laughed out of the room, and for good reason. And, yet, because the project happens to be open source, it should be excused, or even celebrated? That is absurd.
The idea that providing the software gratis and with the freedoms to use and modify it should protect the authors from any criticism with how the project is managed is also absurd. Software should be held at the same levels of scrutiny regardless of its license or business model. There's always a contract between developers and users whether it is made explicit or implicit. Using a project with an established user base as your personal technical playground is irresponsible no matter how you look at it.
> And he added new features (live streaming) with the rewrite.
Ah, yes, I'm sure that would be impossible with any other language but Rust.
> It’s people like you who make maintaining open source projects exhausting.
And it's people like you who don't understand open source and only use it because they get something for "free". See? It's easy to villify someone without engaging with any of their arguments.
> When a project has thousands of users it's irresponsible to use it as a testing playground.
Well, what about motivation? If the author has left behind the original language and rewriting it provides them with motivation to continue then it's not "a testing playground", it's a viable way towards continued maintenance.
There are many ways to write code and maintain a project. Just because they don't align with your preferences doesn't make them shoddy.
Developer motivation is important, but the choice of language shouldn't be a primary factor in that. Being passionate about the domain and solving a problem for users should be the primary motivators. Otherwise it signals that once the developer gets bored of their chosen stack, which might include Rust and Elixir (omg BEAAAMM!!!) a few years from now, they will be compelled to abandon the project unless they're allowed to experiment with some other shiny new tech.
But everyone is ignoring the bigger picture here: this project has been written in 5 different languages over the course of its existence, including reversing to a previously used language. That is an insane and unprecedented statistic. Changing a language even once is rarely done, let alone this many times.
> Just because they don't align with your preferences doesn't make them shoddy.
These are not my preferences. Avoiding total rewrites, especially in another language, is a core principle of software engineering, not unlike, I don't know... using testing and version control. Developers may choose to disregard it, but at the very least they should be challenged for it. The fact this person hasn't for such a long time is another signal that this project is mismanaged.
In any case, I'm done defending what would be an uncontroversial opinion in any other setting.
"Rewrites should always be avoided" is not a core principle of software engineering. History has shown that rewriting large, monolithic applications often fails, and so rewrites of large applications often require extra effort to ensure the changes actually ship (like rewriting single views and proxying requests to a new service, for example). If a project is small enough that it can be rewritten and still shipped that extra effort is unneeded, and the fact that this project was rewritten and released makes that clear.
I don't understand why you're so hung up on the history of this project. If we were talking about software being used to send people to space I could see your point, but this is largely a single person project which is obviously being used to learn and have fun.
> "Rewrites should always be avoided" is not a core principle of software engineering.
Why are you misrepresenting what I said? I never claimed that rewrites should always be avoided. But that in most cases they're not a good idea, for various reasons that should be obvious to most developers.
> I don't understand why you're so hung up on the history of this project.
I'm not hung up on this project at all. I have come across it, but I'm not a user. I simply stated an opinion that shouldn't be controversial at all, yet for some reason, I keep having to defend it. So it seems that it struck a nerve with fans of the project who would rather attack me personally than acknowledge the poor decisions made by its author.
> If we were talking about software being used to send people to space I could see your point
It's a very popular project that many projects depend on. Lives don't need to depend on it for it to be managed responsibly.
Anyway, I think we both have better things to do than waste anymore of our time on this discussion, so let's just drop it.
OK, so why in this specific case is it a bad idea, other than you being personally offended by the number of languages used in the project's history?
You keep saying your opinion should be uncontroversial but you've offered no evidence other than an appeal to authority, and I think THAT should not go unchallenged.
My most popular project is maintained solely by me and is downloaded >1.3 billion times a year. That usage does not create a responsibility out of thin air. It got popular because people like it, it's fast, and it has excellent test coverage. I could decide to rewrite it in a compile-to-JavaScript language tomorrow for any reason I like and no one using it would be negatively affected in any way.
I think you are much too rigid on your views about software engineering and they don't comport with the reality of building and releasing projects to the world, for fun or profit.
I love Asciinema and have made a small contribution, support the project with a donation: https://docs.asciinema.org/donations/#individuals
If you want to see how Asciinema looks when people are troubleshooting Linux systems: https://replay.sadservers.com/
Asciinema is one of the best products/tools I’ve ever used. I mean the auth/upload CLI flow is so straight to the point and easy to use, despite having to cross a few layers (yep I know other CLIs have something similar, it’s just that Asciinema has never “gotten in my way” when doing something with it)
This is great, congrats for such a huge accomplishment!
My only wish is if asciinema natively supported saving into svg or gif. This would allow you to easily add it to markdown files without the need to install side apps to convert the output to those formats.
I'm a huge fan of Asciinema, and this is awesome work.
Regarding the live streaming feature, I hacked a similar thing on top of s2.dev streams[1] (disclaimer: I am a co-founder), which could alleviate the need for a relay in this architecture[2]. Naturally showing off `btop` was the highlight for me as well :-D.
[1]: https://s2.dev/blog/s2-term [2]: https://docs.asciinema.org/manual/server/streaming/#architec...
> introducing terminal live streaming
Now we just need someone to develop ASCII-art vtuber avatars which overlay on top of the terminal.
Max Headroom v0.2
My favorite elixir project of all time now written in Rust.
Love to see it.
Have you guys added the ability to cleanse / watch command strings for sensitive items like secrets, keys etc? Seems easier than ever with advances in lightweight LLMs.
The CLI has been rewritten in Rust. The server is still Elixir/Phoenix - perfect for this feature.
> Have you guys added the ability to cleanse / watch command strings for sensitive items like secrets, keys etc? Seems easier than ever with advances in lightweight LLMs.
Please this has to be satire, right?
Some games have this feature called "streamer mode", where some text that would normally be on screen is removed, like username or party codes. Makes sense for a terminal to do the same for other sensitive data.
Would actually be nice to standardize an environment variable for this. Obviously not something that you should rely upon when running random tools but can be a nice failsafe.
It would be nice to censor my username from the prompt without changing my shell prompt.
No idea if it does this already though.
The file format is just plain text, you can use sed to change the username.
Why would it be satire? Seems like a real use case
s/mysekretpassword/••••••••••••••••/g
What about that should involve a large language model?
Obviously the part that determines what part of the output might be a password or other sensitive value.
Threads like this want me to throw my laptop into a volcano and lobotomize myself. I have a bridge if you think an LLM can reliably generically redact passwords. Especially given the intersection of password quality and the type of person to let their passwords leak into output of a recorded terminal session.
I love leaving my baseline security in the hands of a hallucinating, unreliable token generator.
I'm sorry, I don't even know how to explain that this type of feature would be such a mis-feature, it's hard to even know how to explain it to somehow for whom its not obvious.
> My favorite elixir project of all time now written in Rust.
It was written in Python before, no?
Yes, it's right there in the article.
Indeed - it was an invitation to the original commenter to clarify what they thought Elixir had to do with it...
The server is written in Elixir. https://news.ycombinator.com/item?id=45253390
Aha, but not the part that got rewritten in Rust. Makes more sense.
I’ve sometimes heard Twitch streamers mention that they use two computers for streaming. One is the computer you are seeing on stream, and the other computer is running OBS and using a HDMI capture device.
With this new live streaming feature in Asciinema, I could imagine that a small subset of programming streamers could skip buying a HDMI capture device. Specially the kind of developer who works exclusively in the terminal. This small group of people could now stream their terminal from the dev machine to the OBS machine using Asciinema 3, instead of capturing HDMI output.
That shouldn’t really matter for asciicinema streaming which 0 effect on any kind of performance.
The 2 device setup for game streaming was born because of the heavy CPU usage of x264 encoding. So you could have a PC for the game only while the streamig PC takes the encoding load.
But even then nowadays a lot of people moved on from that since you can use your GPU for encoding (Nvidia NVENC) which almost has 0% overhead and providing the same or slightly worse quality. Really OBS x264 should be only used for offline video recording say for a Youtube video
Another feature of this is that if your primary PC crashes, which happens sometimes especially with some games, your stream doesn’t go down too. This is more important for streams with more viewers and longer runtimes, as restarting the stream drops all the AFK viewers who may still be contributing ad revenue (or just boosting active viewer count which has other flow on benefits too).
You can see this effect in long streamathons/subathons as twitch automatically kills long streams so you’ll see multiday streams get cut up either manually by streamers or automatically by twitch every 24h or so, and the viewer count drops significantly and takes quite some time (many hours) to recover.
YouTube recompresses everything anyway so I found the higher quality you upload the better the result, especially for complex stuff like high-paced gameplay.
And at very high bitrates nvenc quality is just fine. It's mostly at the lower bitrates x264 really shines.
Of course for livestreaming there are different constraints.
Twitch streamers do that because they are streaming GPU intensive workload (video game) that would compete with streaming software for GPU resources.
It also prevents driver crash caused by a video game to crash a stream.
Additionally, running on a different computer allows for eg adjusting scenes in OBS or moderating Twitch, without losing focus from the running app/game.
Yeah that makes sense. I was thinking that the two computer setup was also something they did to keep their streaming stuff completely separate from the rest of their life, to not accidentally doxx themselves on-stream and to not accidentally execute malware on the same host they do their email and banking etc on.
[dead]
i think the setup you describe is used primarily to offload video encoding to a second pc, not something programming streamers (not running graphically intensive games) probably need not concern themselves with it
Asciinema was previously written in python
The live btop demo is really cool !
Congrats on shipping.
Oh I think I will be having some fun with the streaming capability. Sweet!
Wow nice release. Particularly impressive is the demo live stream of btop!
The power of rust and proper architecture allows an underpowered 2 vCPU VM to stream contents to hundreds of people.
I think that would be the power of Elixir and the BEAM.
whoa the live streaming is a game changing game changer no Twitch content pun intended (tho possibly maybe it was ...)
I, for one, look forward to our new RUST overlords...