On Tue, Jun 16, 2015 at 5:44 AM, Loïc Minier <[email protected]> wrote:
> You're suggesting to kill the idea entirely; that might be a valid > standpoint, but you've dismissed this a bit quickly. > > First, consider that the networking industry is proposing this today: in > all products, for all major brands, you end up in a custom CLI experience. > I certainly agree it's painful to learn a new one each time, much like it's > a pain to learn how to use/configure a new piece of software of any kind. > Right, exactly. > But at least we get to define this one and offer it as a base for others > to derive from. Perhaps frameworks/snaps could extent the command set with > additional commands, e.g. to manage the ASIC, or provide hardware > diagnostics etc. > Can we define something that is less painful instead of assuming it has to be painful? Second, you've dismissed the other benefits towards delivering a more > locked down user experience (e.g. I want to ship a critical piece of > hardware based on snappy, they may/may not install apps, they may/may not > change the config of snaps, they may/may not run random shell commands). > Repeating what I actually proposed: So, here is an idea: rather than redoing the whole shell, can we identify what are the winning aspects of that integrated shell (good help? pleasant command names? etc) and try to replicate that within a traditional shell? gustavo @ http://niemeyer.net
-- snappy-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel
