Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cicada – Unix shell written in Rust

github.com

Post reply on HN
Print view View original

141–150 of 168 posts

Re: Cicada – Unix shell written in Rust

#141

Post by LukeShu »

eridius wrote: post #121
arca_vorago wrote: post #89

I just have to say, while I respect the work and have been looking forward to nix tools being ported to rust, the first thing I do is see if it's GPL or not and if it's not it immediately loses points (not all of them), because I have been working hard to free up my stacks. I wish people would consider making core system tools like this GPL instead of MIT/BSD styles. Tivoization is a real threat to the freedom of use…

I just have to say, while I respect the work put into tools of the sort that you use, the first thing I do is see if it's GPL or not and if it is it immediately loses points (very nearly all of them), because GPL is awful. If I'm going to use a tool like this, I'm going to want to be able to check out the code, perhaps submit PRs, etc, but if it's GPL then I don't want to so much as look at the code because GPL is vi…

There are two points I want to address.

1. "the GPL really seems to do is protect the "freedom" of the original developer to ensure access to any changes made by other people" The GPL literally does not do that, the "other people" only have to give the modified sources to people who get the binary from them; they don't have to give the modified sources back to the original developer. As a non-theoretical example, the Grsec guys only give their Linux kernel modifications to their customers, and do not give the modifications back upstream to Linux. It's about making sure that the end user gets access to the code, which I know you said is silly because the users "don't care in the slightest", but...

2. You re-defining user to be someone who doesn't look at the code is silly. Given a piece of software I have absolutely no intention of being a "developer" for, I would still like to receive the source code. I would like to be able to study it to figure out how it works, the same as when I took apart and studied clocks as a kid (an activity that didn't magically transmute me from a "clock user" into a "clock maker"!). When some software on my computer (or the computer of a friend or family member) breaks, I would like to be able to pop open the source and see what's going on, the same as when I pop the hood when something goes wrong with a car--I'm not interacting with that software as a "developer", just as I'm not interacting with the car as a "car maker". Sure, the fact that I am a developer means I'm pretty qualified to know what I'm looking at when I look at the source, just as being an engineer at an auto company would make me pretty qualified to know what I'm looking at when I pop the hood of my car. But fundamentally, the relationship I have with that software/car is that of a user, not that of a developer. And even if I weren't a programmer, I would want to receive the source, so that when it breaks, and I ask my nephew or whoever to look at it, that he can see the source and isn't locked out from helping me out. We don't call farmers "engineers" for fighting for the "right to repair" their own farm equipment; and we shouldn't call computer users "developers" for fighting for the right to repair their own computers.

Re: Cicada – Unix shell written in Rust

#142

Post by LukeShu »

notheguyouthink wrote: post #94
arca_vorago wrote: post #89

I just have to say, while I respect the work and have been looking forward to nix tools being ported to rust, the first thing I do is see if it's GPL or not and if it's not it immediately loses points (not all of them), because I have been working hard to free up my stacks. I wish people would consider making core system tools like this GPL instead of MIT/BSD styles. Tivoization is a real threat to the freedom of use…

I'm not too familiar with licensing, can someone ELI5? Eg, normally I just choose MIT because licensing is not a concern of mine. I'd like credit, but beyond that, do whatever the hell you want with my work. Now, I'm not making core nix tools, but should I be choosing a different license? Man do I hate licensing.

Any recommendation of a "default" license to use if you don't care too much about licensing will always carry strong opinions of whoever is recommending it. So, instead, here's a decision tree of good recommendations based on the two biggest decisions that factor in to choosing a license:

                          start
                            |
                            V
           if I modify it, and give someone a
          compiled binary of that, should I also
         have to give (or offer) them the source?
                       |        |
                   yes |        | no
                       |        V
                       |      MIT/X11 license
                       |     (alternatively,
                       |      Apache 2.0, or
                       |      2- or 3-clause BSD)
                       V
                is it a library
                 or a program?
                   /      \
          library /        `----, program
                 V               \
    can it be used by programs    \
     that DON'T give/offer the     \
       source with binaries?        \
           |         \               \
       yes |          \ no            V
           V           `-----------> GNU GPL
        GNU LGPL                    (alternatively, GNU AGPL)
Whether or not you think the "default" choice to each question should be "yes" or "no" is something that people argue about plenty; whichever you choose, someone will tell you you chose wrong.

As for the "alternatives" in parenthesis at the leaves of the chart: if you don't care about licenses, the default is probably fine, but if someone told you that you should use one of the alternatives at that leaf, I wouldn't argue. (Apache 2.0 comes in over MIT if you care about patents, AGPL comes in over GPL if you care about SaaSS)

Re: Cicada – Unix shell written in Rust

#143

Post by LukeShu »

eridius wrote: post #123
notheguyouthink wrote: post #94

Earlier quoted context omitted.

I'm not too familiar with licensing, can someone ELI5? Eg, normally I just choose MIT because licensing is not a concern of mine. I'd like credit, but beyond that, do whatever the hell you want with my work. Now, I'm not making core nix tools, but should I be choosing a different license? Man do I hate licensing.

If you don't care about licensing, MIT, or BSD, is a fantastic choice. Definitely don't choose GPL. The only people who should ever choose GPL are people who do care about licensing and have specifically made the decision that they like what the GPL does. But if you don't care about licensing, then you can't make an informed choice about whether GPL is appropriate, and it's far better to err on the side of using a pe…

If you don't care about licensing, GPL is a fantastic choice. Definitely don't choose MIT or BSD. The only people who should ever choose MIT are people who do care about licensing and have specifically made the decision that they like what the MIT license does. But if you don't care about licensing, then you can't make an informed choice about whether MIT is appropriate, and it's far better to err on the side of using a copyleft license (e.g. GNU) than using a permissive license like MIT.

You've just said "if you can't make an informed decision, then you should make the choice that I agree with" (from other comments, you clearly are someone who does care about licensing, and don't like the GPL). It works just as well both ways. You even slipped in some loaded propaganda words ("restrictive viral"), just in case anyone had any doubt that you weren't offering objective advice.

Fundamentally, there's a choice, and there's no getting around that with "if you don't care" defaults.

Re: Cicada – Unix shell written in Rust

#144

Post by Too »

skissane wrote: post #25
vidarh wrote: post #23

Earlier quoted context omitted.

I lean towards wanting all my tools to support at least one common structured format (and JSON generally would seem the best supported) these days. It'd be great if there was a "standard" environment variable to toggle JSON input/output on for apps. If you did that, then e.g. a "structured" shell could just default to turning that on, and try detecting JSON on output and offering according additional functionality. T…

I wish there was a way for pipes to carry metadata about the format of the data being passed over the pipe, like a MIME type (plain text, CSV, JSON, XML, etc). Ideally with some way for the two ends of the pipe to negotiate with each other about what types each end supports. I think that sort of out-of-band communication would most likely need some kernel support. Maybe an IOCTL to put a pipe into "packet mode" in wh…

Programs can determine if the receiving output is a TTY or not and enable e.g. colored output accordingly, sounds like something similar.

Re: Cicada – Unix shell written in Rust

#145

Post by eridius »

LukeShu wrote: post #143
eridius wrote: post #123

Earlier quoted context omitted.

If you don't care about licensing, MIT, or BSD, is a fantastic choice. Definitely don't choose GPL. The only people who should ever choose GPL are people who do care about licensing and have specifically made the decision that they like what the GPL does. But if you don't care about licensing, then you can't make an informed choice about whether GPL is appropriate, and it's far better to err on the side of using a pe…

If you don't care about licensing, GPL is a fantastic choice. Definitely don't choose MIT or BSD. The only people who should ever choose MIT are people who do care about licensing and have specifically made the decision that they like what the MIT license does. But if you don't care about licensing, then you can't make an informed choice about whether MIT is appropriate, and it's far better to err on the side of usin…

No, I said if you can't make an informed decision, go with the licenses that are widely regarded as being the least restrictive.

> You even slipped in some loaded propaganda words

GPL proponents describe the GPL as viral, and I'd be surprised if anyone tried to argue that it's not a restrictive license, so I'd hardly call that "propaganda".

> If you don't care about licensing, GPL is a fantastic choice.

This is incredibly wrong, and it's kind of horrifying to me to see you try and trick uninformed people into picking something viral and restrictive like the GPL. You should be ashamed of yourself.

If you don't care about licensing, do not pick GPL. The license exists specifically for people that believe in what that license does, and it's literally the worst possible license choice for someone who doesn't care about the license.

Re: Cicada – Unix shell written in Rust

#146

Post by eridius »

goodplay wrote: post #140
eridius wrote: post #134

Earlier quoted context omitted.

Read what I said. The "end user" doesn't care in the slightest about source access. Everything the GPL is concerned about only matters to other developers, not to end users.

As an end-user, I do. Being prevented from fixing my own (expensive) device is not something I would voluntarily subject myself to. For context, here's a comment I posted a while ago ( https://news.ycombinator.com/item?id=13527205 ): I used to be a big fan of permissive licenses until I bought a $700+ android phone a couple of years back and discovered that it did not "support" my native language (it could render the…

> Being prevented from fixing my own (expensive) device is not something I would voluntarily subject myself to

If you can fix it, you're a developer, not a plain old user.

Re: Cicada – Unix shell written in Rust

#147

Post by solidsnack9000 »

skissane wrote: post #27
vog wrote: post #24

Earlier quoted context omitted.

Nice idea! Maybe this issue is similar to that of command completion, but could also result in a similar mess. Every command has its "-h" or "--help", showing the syntax, available options and so on. But since even that is not really standardized, separate command-line completion rules are written for every command. And for every shell.

Define a standard format for describing command syntax. I'd suggest basing it on JSON, but you could use XML or Protobuf or Thrift or ASN.1 or Sexprs or whatever. Embed in executables a section containing the command syntax description object. Now when I type in a command, the shell finds the executable on the path, opens it, locates the command description syntax section (if present), and if found uses that to provi…

This is actually a very interesting problem. The format would be an IDL, since you're describing a "struct" of options, array-valued fields, and "typed" fields that are constrained to certain grammars (numbers, &c.).

Re: Cicada – Unix shell written in Rust

#148

Post by solidsnack9000 »

elcritch wrote: post #126
brandur wrote: post #3

Amazing work! Between this, Alacritty [1], and coreutils [2], we're getting pretty close to a plausible all-Rust CLI stack. While Cicada is pretty clearly modeled on the "old" generation of shells (sh, Bash, Zsh, etc.), one has to wonder what a more modern shell might look to address some of the problems of its predecessors like pipes that are essentially text-only, poor composability (see `cut` or `xargs`), and terr…

One thing lacking in traditional shell utilities is difficulty having a universally understood way of passing metadata about the content of the pipes/streams. Other commentators have (rightly!) pointed out the difficulties of requiring a single "structured object" in the core of the ecosystem... but if there were a way to gracefully support multiple structured object formats and let tooling build on top of that. Got…

One might not need native support to get started: with a wrapper that recognized the coreutils, for example, one could translate the data appropriately.

    corehttp ls -l ...

Re: Cicada – Unix shell written in Rust

#149

Post by solidsnack9000 »

peteretep wrote: post #70

Apologies for the off-topic nature of this, but: Something that's been capturing my imagination recently is sshing into a machine, pushing an appropriate shell binary to /tmp, and then executing it. If you have an exotic preference for shell (or vim config, or whatever), we've presumably generally got sufficient bandwidth these days to do a virtually instant user-space install and execution, no?

Arx is intended to allow exactly this instant user-space install and execution: https://github.com/solidsnack/arx

Re: Cicada – Unix shell written in Rust

#150

Post by wtetzner »

eridius wrote: post #146
goodplay wrote: post #140

Earlier quoted context omitted.

As an end-user, I do. Being prevented from fixing my own (expensive) device is not something I would voluntarily subject myself to. For context, here's a comment I posted a while ago ( https://news.ycombinator.com/item?id=13527205 ): I used to be a big fan of permissive licenses until I bought a $700+ android phone a couple of years back and discovered that it did not "support" my native language (it could render the…

> Being prevented from fixing my own (expensive) device is not something I would voluntarily subject myself to If you can fix it, you're a developer, not a plain old user.

You're suggesting that developers can't be users? Also, end users don't have to be the ones to fix things to benefit. If they're unhappy with something, they would have the freedom to pay a developer to customize their software however they like, or even get a skilled friend to work on it.

Being able to work on my own car is an important freedom, even if I don't know anything about cars. I can get a knowledgeable friend to look at it, or I can hire a mechanic, and it doesn't have to be a mechanic from the manufacturer.

Also, it doesn't matter how much of the population uses their freedom for it to be important.

Post reply on HN