5 ms·

Tools for 2025

127 points by todsacerdoti 2y ago

gigatexal 2y ago
I really do like these kinds of posts. I like the author’s passion. Will check oils, radicle, and simplex out. Though I think getting my wife to try simplex over iMessage is unlikely to happen hah
patrickhogan1 2y ago
Thanks for the great write-up—Radicle and Simplex Chat look awesome, and I’m looking forward to checking them out! One tool that recently gave me that "this is how it should work feeling" was Flighty (iOS flight tracking). The UI, functionality, and flow felt so seamless—it was like music to my technophile ears. I wasn't even expecting much, because it was like "meh, its a flight tracker." But, it really wowed me. I always justify my tool obsession by saying that after installing thousands of tools and apps, you become a naturally good product manager. Because you have a high bar for quality and during the planning/mockup phase you have lots of patterns in your head of what great looks like.
oguz-ismail 2y ago
>oils Nah. Bash is well-maintained, you can have a bug fixed quickly. It's been months since I reported this <https://github.com/oils-for-unix/oils/issues/2068 https://github.com/oils-for-unix/oils/issues/2068> and still nothing.
- Otek 2y ago
  Not a oils maintainer, but: I took a look at your report, and it seems like it could use a bit more detail. Things like clearer steps to reproduce, expected vs. actual behavior, and a more descriptive title might help get it addressed faster. Open-source projects often have limited resources, so anything that makes it easier for maintainers to pinpoint the issue can speed things up. Maybe updating the report with more context could help move it along?
  - akovaski 2y ago
    Looking at the original posting, the maintainer knows what the bug is. The stopper is more along the lines of "This looks synthetic, so it's not high priority. If it's a priority for you, then you should fix it yourself or make an argument for its priority." followed by oguz saying "It's not actually my problem either, I'm not invested in osh.". (not actual quotes: https://github.com/oils-for-unix/oils/issues/1881#issuecomment-2332481217 https://github.com/oils-for-unix/oils/issues/1881#issuecomme...) The bug is that osh leaves the script fd open for the child process when executing a command, allowing the child command to mess with the parent script. I don't see this as a huge issue for everyday interactive use, but I'd prefer my shell to not do that. If I were executing programs with limited capabilities, I'd consider this a possible vector for security bugs. That is to say, I wouldn't use osh scrpts if I cared about security.
pjmlp 2y ago
There is no way out of traditional UNIX shells, because most folks don't control the servers, and getting snowflake shells being adopted across the company and customers hardly works. Also there are many UNIX deployments, where bash still isn't a given, one might be surprised with tsch or ksh.
- chubot 2y ago
  (author here) The best way to think about it is like Clang (OSH) + Swift or Rust (YSH) in the same project, as I explained in a table here: https://www.oilshell.org/blog/2024/09/retrospective.html#oils-is-bigger https://www.oilshell.org/blog/2024/09/retrospective.html#oil... You are right in the sense that Clang never replaced GCC on say Debian or Red Hat. As far as I remember, there are only a couple minor distros and one BSD that use Clang as the default. So even though Clang is extremely compatible with all sorts of GCC quirks, inertia is still strong And to probably 90% of people, Clang does the same thing as GCC. Probably 90% of people couldn't tell the difference between the two But I think many people are glad Clang exists, e.g. it pushed GCC forward (at least in error messages, in modularity, and probably more) And some people use ONLY Clang, not GCC --- On YSH, most people do think there needs to be a "clean slate" successor language to shell, and that's what YSH is aiming for. Notably, it's informed by re-implementing almost all of bash from scratch, and shares the same runtime The reasoning behind that is that I noticed that sort of like "make replacements", many alternative shells [1] are better in one dimension than their predecessor, but worse in other dimensions. Our goal is to be better in all dimensions, so a superset is a good way to achieve that. We learned the hard way that these 30-, 40-, 50- year old tools have very diverse users and usages - i.e. most people might use 10% of the features, but across all users, that's 100% of the features Nonetheless, OSH has been the most bash-compatible shell, by a mile, for a few years, and it's only getting more compatible. How fast it converges depends on contributions, and we're getting good PRs, but can always use more YSH also has a bunch of users that are providing great feedback, and helping to make it stable https://github.com/oils-for-unix/oils/wiki/Contributing https://github.com/oils-for-unix/oils/wiki/Contributing [1] https://github.com/oils-for-unix/oils/wiki/Alternative-Shells https://github.com/oils-for-unix/oils/wiki/Alternative-Shell...
  - deleted 2y ago
mythz 2y ago
First I've heard about issue with bash. I've been using OhMyZsh in all terminals for years which seems pretty active and auto updates fine whereever I'm using it, e.g in Linux, macOS, Windows/WSL. Zsh might have a slower release cadence but I'm really happy with my with Oh My Zsh setup and don't feel like I'm missing anything. The one area where I've stopped using bash/shell is in complex shell scripts which I'm now writing in TypeScript and executing with Bun by using: #! /usr/bin/env bun
- Melkor333 2y ago
  > The one area where I've stopped using bash/shell is in complex shell scripts which I'm now writing in TypeScript and executing with Bun by using: #! /usr/bin/env bun (blog author here) This is exactly what's wrong with bash (and zsh). It should NOT be hard to write a bit more complex scripts. But it's so ingrained into our heads that shell is "too hard" that people use ts/js/python/etc. And usually the UX to writing "glue code" is much worse than with a good shell like Ysh.
  - CRConrad 2y ago
    > But it's so ingrained into our heads that shell is "too hard" that people... ...That people apparently don't even try to learn bash. It isn't really all that hard.
deleted 2y ago
[deleted]
flowingfocus 2y ago
For anyone who is into decentralized protocols: here is a comprehensive list: https://codeberg.org/amjoseph/not-your-keys-not-your-name https://codeberg.org/amjoseph/not-your-keys-not-your-name
- patrickhogan1 2y ago
  Is there a similar list for decentralized applications that run on those protocols?
TheAceOfHearts 2y ago
I've probably been using fish shell [0] for close to 10 years now. When I need POSIX compliance or if I need to run a one-off bash command, I just call bash. It's exceedingly rare. Browsing through the documentation for Oils, it seems to be organized in a way that's very confusing. When you open the fish shell website it was two clear buttons for Tutorial and Documentation. [0] https://fishshell.com/ https://fishshell.com/
- Melkor333 2y ago
  (blog author here) Thanks for the feedback. I've raised this issue as well in the past and I think it has already gotten better. AFAIU there's a dedicated page planned for osh/ysh when you click on the headline which should make it much more clear.
incognito124 2y ago
I also recommend atuin.sh
- Melkor333 2y ago
  (Blog author here) Hehe yes, Use it for a long time now! But at least in my bubble people already talk quite a bit about it, other than Oils, Radicle or Simplex :)
GregDavidson 2y ago
bash, ksh, zsh and a few other shells have the awesome feature that if you call them with a link named "sh" they accept Posix Bourne-shell syntax. This means you can make them your /bin/sh system shell which will be used to log you in and your login scripts can then set environment variables for your whole session. This feature is something I count on. Some system shells (not dash) also allow login scripts to export essential shell functions to the session environment. I would love to use a nicer shell, fish, oilsh, rc, etc. but it's gotta provide this key Posix compatibility. The Posix Bourne shell language is pretty simple. This is not a big ask.
- chubot 2y ago
  OSH behaves like that too -- it's POSIX and bash compatible At some point I will update the home page to make that a bit more clear - https://oils.pub/ https://oils.pub/
  - GregDavidson 2y ago
    You just got a convert! Huge value in sh compatibility. Bash, not so much!
stavros 2y ago
Signal has the same thing as Simplex. You can change your user ID at any time, and the only thing that does is that the old ID can't be used to find you.

Tools for 2025

127 points by todsacerdoti 2y ago

I really do like these kinds of posts. I like the author’s passion. Will check oils, radicle, and simplex out. Though I think getting my wife to try simplex over iMessage is unlikely to happen hah

patrickhogan1 2y ago

Thanks for the great write-up—Radicle and Simplex Chat look awesome, and I’m looking forward to checking them out! One tool that recently gave me that "this is how it should work feeling" was Flighty (iOS flight tracking). The UI, functionality, and flow felt so seamless—it was like music to my technophile ears. I wasn't even expecting much, because it was like "meh, its a flight tracker." But, it really wowed me. I always justify my tool obsession by saying that after installing thousands of tools and apps, you become a naturally good product manager. Because you have a high bar for quality and during the planning/mockup phase you have lots of patterns in your head of what great looks like.

oguz-ismail 2y ago

>oils Nah. Bash is well-maintained, you can have a bug fixed quickly. It's been months since I reported this <https://github.com/oils-for-unix/oils/issues/2068 https://github.com/oils-for-unix/oils/issues/2068> and still nothing.

Otek 2y ago
Not a oils maintainer, but: I took a look at your report, and it seems like it could use a bit more detail. Things like clearer steps to reproduce, expected vs. actual behavior, and a more descriptive title might help get it addressed faster. Open-source projects often have limited resources, so anything that makes it easier for maintainers to pinpoint the issue can speed things up. Maybe updating the report with more context could help move it along?
- akovaski 2y ago
  Looking at the original posting, the maintainer knows what the bug is. The stopper is more along the lines of "This looks synthetic, so it's not high priority. If it's a priority for you, then you should fix it yourself or make an argument for its priority." followed by oguz saying "It's not actually my problem either, I'm not invested in osh.". (not actual quotes: https://github.com/oils-for-unix/oils/issues/1881#issuecomment-2332481217 https://github.com/oils-for-unix/oils/issues/1881#issuecomme...) The bug is that osh leaves the script fd open for the child process when executing a command, allowing the child command to mess with the parent script. I don't see this as a huge issue for everyday interactive use, but I'd prefer my shell to not do that. If I were executing programs with limited capabilities, I'd consider this a possible vector for security bugs. That is to say, I wouldn't use osh scrpts if I cared about security.

pjmlp 2y ago

There is no way out of traditional UNIX shells, because most folks don't control the servers, and getting snowflake shells being adopted across the company and customers hardly works. Also there are many UNIX deployments, where bash still isn't a given, one might be surprised with tsch or ksh.

chubot 2y ago
(author here) The best way to think about it is like Clang (OSH) + Swift or Rust (YSH) in the same project, as I explained in a table here: https://www.oilshell.org/blog/2024/09/retrospective.html#oils-is-bigger https://www.oilshell.org/blog/2024/09/retrospective.html#oil... You are right in the sense that Clang never replaced GCC on say Debian or Red Hat. As far as I remember, there are only a couple minor distros and one BSD that use Clang as the default. So even though Clang is extremely compatible with all sorts of GCC quirks, inertia is still strong And to probably 90% of people, Clang does the same thing as GCC. Probably 90% of people couldn't tell the difference between the two But I think many people are glad Clang exists, e.g. it pushed GCC forward (at least in error messages, in modularity, and probably more) And some people use ONLY Clang, not GCC --- On YSH, most people do think there needs to be a "clean slate" successor language to shell, and that's what YSH is aiming for. Notably, it's informed by re-implementing almost all of bash from scratch, and shares the same runtime The reasoning behind that is that I noticed that sort of like "make replacements", many alternative shells [1] are better in one dimension than their predecessor, but worse in other dimensions. Our goal is to be better in all dimensions, so a superset is a good way to achieve that. We learned the hard way that these 30-, 40-, 50- year old tools have very diverse users and usages - i.e. most people might use 10% of the features, but across all users, that's 100% of the features Nonetheless, OSH has been the most bash-compatible shell, by a mile, for a few years, and it's only getting more compatible. How fast it converges depends on contributions, and we're getting good PRs, but can always use more YSH also has a bunch of users that are providing great feedback, and helping to make it stable https://github.com/oils-for-unix/oils/wiki/Contributing https://github.com/oils-for-unix/oils/wiki/Contributing [1] https://github.com/oils-for-unix/oils/wiki/Alternative-Shells https://github.com/oils-for-unix/oils/wiki/Alternative-Shell...
- deleted 2y ago

mythz 2y ago

First I've heard about issue with bash. I've been using OhMyZsh in all terminals for years which seems pretty active and auto updates fine whereever I'm using it, e.g in Linux, macOS, Windows/WSL. Zsh might have a slower release cadence but I'm really happy with my with Oh My Zsh setup and don't feel like I'm missing anything. The one area where I've stopped using bash/shell is in complex shell scripts which I'm now writing in TypeScript and executing with Bun by using: #! /usr/bin/env bun

Melkor333 2y ago
> The one area where I've stopped using bash/shell is in complex shell scripts which I'm now writing in TypeScript and executing with Bun by using: #! /usr/bin/env bun (blog author here) This is exactly what's wrong with bash (and zsh). It should NOT be hard to write a bit more complex scripts. But it's so ingrained into our heads that shell is "too hard" that people use ts/js/python/etc. And usually the UX to writing "glue code" is much worse than with a good shell like Ysh.
- CRConrad 2y ago
  > But it's so ingrained into our heads that shell is "too hard" that people... ...That people apparently don't even try to learn bash. It isn't really all that hard.

deleted 2y ago

[deleted]

flowingfocus 2y ago

For anyone who is into decentralized protocols: here is a comprehensive list: https://codeberg.org/amjoseph/not-your-keys-not-your-name https://codeberg.org/amjoseph/not-your-keys-not-your-name

patrickhogan1 2y ago
Is there a similar list for decentralized applications that run on those protocols?

TheAceOfHearts 2y ago

I've probably been using fish shell [0] for close to 10 years now. When I need POSIX compliance or if I need to run a one-off bash command, I just call bash. It's exceedingly rare. Browsing through the documentation for Oils, it seems to be organized in a way that's very confusing. When you open the fish shell website it was two clear buttons for Tutorial and Documentation. [0] https://fishshell.com/ https://fishshell.com/

Melkor333 2y ago
(blog author here) Thanks for the feedback. I've raised this issue as well in the past and I think it has already gotten better. AFAIU there's a dedicated page planned for osh/ysh when you click on the headline which should make it much more clear.

incognito124 2y ago

I also recommend atuin.sh

Melkor333 2y ago
(Blog author here) Hehe yes, Use it for a long time now! But at least in my bubble people already talk quite a bit about it, other than Oils, Radicle or Simplex :)

GregDavidson 2y ago

bash, ksh, zsh and a few other shells have the awesome feature that if you call them with a link named "sh" they accept Posix Bourne-shell syntax. This means you can make them your /bin/sh system shell which will be used to log you in and your login scripts can then set environment variables for your whole session. This feature is something I count on. Some system shells (not dash) also allow login scripts to export essential shell functions to the session environment. I would love to use a nicer shell, fish, oilsh, rc, etc. but it's gotta provide this key Posix compatibility. The Posix Bourne shell language is pretty simple. This is not a big ask.

chubot 2y ago
OSH behaves like that too -- it's POSIX and bash compatible At some point I will update the home page to make that a bit more clear - https://oils.pub/ https://oils.pub/
- GregDavidson 2y ago
  You just got a convert! Huge value in sh compatibility. Bash, not so much!

stavros 2y ago

Signal has the same thing as Simplex. You can change your user ID at any time, and the only thing that does is that the old ID can't be used to find you.