4 ms·

Last time I checked, micro should have been called macro based on the binary file size.

• 3836293648 1y ago
  Well, it is orders of magnitude larger than nano, so...
• sime2009 1y ago
  Seriously? We're going to complain about a couple megs in a text editor in the year 2025?
  • mixmastamyk 1y ago
    Yes, couldn’t use on my router because of its size. No reason for a TUI to be so big. Advanced features outside of syntax highlighting not useful. Should have a light version. I installed nano with CUA keybindings instead.
  • prmoustache 1y ago
    Like my mother say. Small stream makes huge rivers. Not caring about a couple of megs here and there is what makes some modern systems so bloated.
• pxc 1y ago
  Isn't the relatively large binary just because it's written in Golang? Go executables each ship their own copy of the Go runtime. That alone accounts for a big chunk of small programs like this. Nano also links against ncurses, which is about as big as the compressed tarball for micro. I'm looking at the dependency closures of each right now in nix-tree[1], and micro's closure's total size is 15.04 MiB while nano's is 12.78 MiB-- not really "orders of magnitude" (as a sibling commenter suggests) when you look at it like that. Admittedly, nano's dependencies (`file` and `ncurses`, on my system) are likely to ship as part of the "base system" of any Linux distro anyway; the real size it adds to any distro is negligible. But there's no indication to me that micro is meaningfully "bloated", as the meme goes; it seems like what is required to run it is reasonable and comparable to other tools that serve the same purpose. -- 1: See: https://github.com/utdemir/nix-tree https://github.com/utdemir/nix-tree ; Try `nix run nixpkgs#nix-tree -- $(nix build --no-link --json nixpkgs#nano | jq -r .[0].outputs.out)`
  • deleted 1y ago
    [deleted]
  • prmoustache 1y ago
    The reason may help understand why but it is not really interesting from the point of view of the user or those packaging it with their OS.