Hi, Please also be aware that there could be different developer. Debug / hacking / patch to different part of the system could happen like:
- debug certain library in OS snap - debug Kernel snap: we probably still need to use android bsp/library like what we do in ubuntu phone now. So the kernel snap might also include some device tree binaries with/without source code. - new bsp programming happened inside chip vendor. We are not only need to make end-user / high-level programmer happier, without make the life of lower level developer worse (you know that sometime low level developer need to work even without network enable) BR, YC 2015-06-16 19:37 GMT+08:00 Rick Spencer <[email protected]>: > When I develop for the phone, I: > > 1. Work on my application inside Qt Creator on my desktop until I am > either "done" or need to develop against specific phone capabilities that > are hard to mock on the desktop. This is a normal run -> debug -> edit -> > run cycle that everyone is familiar with on the desktop. > 2. Use "Run on Device" to test it on the device. This command packages the > applications, moves any old version on the phone out of the way, runs my > app, and gives me a full account of what is happening (error messages, > stdout messages, etc...) within QtCreator. > > Contrast #2 with my experience yesterday on snappy. I accomplished #1, my > service was running fine, but then I had to snappy build (fair enough), > snappy remote intstall (fair enough), and then my snap doesn't work on the > device. And I got absolutely no feedback from the system what the problem > was. I learned that I can grovel through systemctl to launch the service, > and look in syslog and journctl to read my stdout after sshing into the > device. In other words, I was forced to content with the internal > implementation details of snappy. > So, I think we need 3 things: > 1. An admin shell on the device to make admin commands discoverable and to > hide the implementation details of the system. > 2. A developer shell (could just be expanded snappy remote) run from the > desktop that hides all the implementation detailss of snappy from the > developer, and makes it easy to deploy, test, and debug snaps on a snappy > image, just like QtCreator does for the phone. > 3. SSH for the rare times when someone needs to grovel around the system > and deal with snappy implementation details. > > I get that we care about making it comfy for people who are used to Ubuntu > working a certain way. However, snappy does not work that way. I think we > should rather be focused on making snappy easy to use. > > Cheers, Rick > > On Tue, Jun 16, 2015 at 4: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. >> 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. >> >> I'm not convinced that this shell approach is inherently good or bad for >> these network vendors, but it's a fact that they all do this, and snappy >> shell gives a path towards this kind of user experience. >> >> >> 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). >> >> I also mentioned smoothing the move to a more minimal system (without >> some of the tools you like). But on this Comfy part, it's fair to point out >> we should judge this one on its own merits though. >> >> >> Snappy shell needs not be required for all snappy based images and/or >> needs not be on port 22, it is rather an optional interface to snappy, much >> like webdm is an useful tool and default web user experience. (Perhaps it >> should be implemented as a completely separate addon, but it felt more >> natural to tie it to the main command-line tool.) Perhaps we'll have a >> snappy router image where it makes sense to make this shell the default, >> with or without direct shell access enabled, while a snappy media-center >> image would not have it. >> >> Cheers, >> >> On Mon, Jun 15, 2015 at 6:42 PM, Gustavo Niemeyer < >> [email protected]> wrote: >> >>> I'm personally two-hearted about this idea. >>> >>> On one hand, I can see the appeal, and have used something similar to >>> that myself for Smart Package Manager, where people could use a shell to >>> type in the all of the subcommands that they could use under the "smart" >>> command line tool. It was a neat way to type several subcommands in a row >>> without the cost of initializing the in-memory graph cache necessary for >>> computing operations, and was expensive to do. >>> >>> On the other hand, there's no relevant init cost for the snappy cli, and >>> custom shell can become an annoyance rather than an advantage. For example, >>> I use traditional unix tools such as grep, sed, awk, sort, all the time >>> when interacting with textual output from dpkg, apt, etc, and also use text >>> files as temporary storage, shell variables, etc. Being in a custom shell >>> means people will be constrained in an unusual way within an atypical shell >>> to the tasks which they tend to understand otherwise. >>> >>> The thing that fired my worries while reading your message was the part >>> where you say the goal is to deliver a slick console user experience as >>> found when telneting into network equipment. While I don't have much >>> experience there, the few times I did that I found myself within an alien >>> and apparently clumsy environment where I'd have to re-learn everything. It >>> wasn't a smooth feeling at all. >>> >>> 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? >>> >>> >>> >>> On Mon, Jun 15, 2015 at 12:50 PM, Loïc Minier <[email protected]> >>> wrote: >>> >>>> User experience >>>> >>>> When you SSH into a Snappy system, you currently end up on a shell >>>> prompt. Wouldn’t it be great to actually land in Snappy itself? >>>> >>>> Welcome to Snappy Ubuntu Core 15.04 >>>> >>>> snappy# >>>> >>>> How do I get started? >>>> >>>> snappy# help >>>> >>>> Usage: >>>> >>>> <command> [<arg>...] >>>> >>>> Available commands >>>> >>>> booted Flag that rootfs booted successfully >>>> >>>> build Builds a snap package (aliases: bu) >>>> >>>> config Set configuration for an installed package. >>>> >>>> [... edited for brievety...] >>>> >>>> shell Start a shell >>>> >>>> update Update all installed parts >>>> >>>> versions (deprecated) please use "list" >>>> >>>> Simple commands like install, update etc. work as expected: >>>> >>>> snappy# info >>>> >>>> release: ubuntu-core/15.04/stable >>>> >>>> architecture: amd64 >>>> >>>> frameworks: webdm >>>> >>>> apps: >>>> >>>> snappy# list -v >>>> >>>> Name Date Version Developer >>>> >>>> ubuntu-core 2015-06-11 3 ubuntu* >>>> >>>> webdm 2015-06-11 0.9 * >>>> >>>> generic-amd64 2015-06-11 1.1.1 * >>>> >>>> We should revisit some commands or aliases to have a friendlier, more >>>> rewarding user experience, e.g. update could provide some output when >>>> no update is available and entering a shell command like ls would hint >>>> at using help: >>>> >>>> snappy# update >>>> >>>> System is up-to-date! >>>> >>>> snappy# ls >>>> >>>> No such command; “help” for a list of commands >>>> >>>> Configuration is only possible for snaps that have the required hook >>>> and may be set manually by key or globally from an URL, and of course >>>> immutable configs can’t be changed. >>>> >>>> snappy# config >>>> >>>> (config)# list >>>> >>>> Name Date Version Developer >>>> >>>> ubuntu-core 2015-06-11 3 ubuntu >>>> >>>> config-example 2015-06-15 1.0.6 canonical >>>> >>>> webdm 2015-06-11 0.9 >>>> >>>> (config)# config xkcd-webserver >>>> >>>> No config found for this snap >>>> >>>> (config)# config ubuntu-core >>>> >>>> (ubuntu-core)# show >>>> >>>> autopilot: true >>>> >>>> timezone: Etc/UTC >>>> >>>> hostname: localhost.localdomain >>>> >>>> (ubuntu-core)# set autopilot false >>>> >>>> Config set >>>> >>>> (ubuntu-core)# exit >>>> >>>> snappy# config config-example set -u >>>> https://conf.example.com/config-example.yaml >>>> >>>> Config set >>>> >>>> A new shell command is provided to start the default user’s >>>> interactive shell or to run commands ( under “sh -c”). >>>> >>>> Goals of snappy shell >>>> >>>> >>>> - >>>> >>>> Deliver a slick console user experience as found when SSH-ing (or >>>> telnet-ing) into network equipments such as switches, routers, firewalls >>>> etc. >>>> - >>>> >>>> Allows restricting access to the shell while allowing for useful >>>> features such as update, install etc. (could be controlled by a new >>>> allowed-cli-commands ubuntu-core config or similar) >>>> - >>>> >>>> Smoothes transition into a Comfy world where the regular rootfs >>>> becomes smaller and smaller. >>>> >>>> >>>> Implementation >>>> >>>> This user experience would be delivered by the main “snappy” binary >>>> when it’s launched as “snappy-cli” as the basename of argv[0]. If this >>>> feature is not enabled by default, or from a shell, you would run “snappy >>>> cli” to start an interactive snappy shell session. NB: cli is to avoid >>>> confusion with the shell command to run a command or an interactive >>>> shell. >>>> >>>> SSH integration could be done in multiple ways: >>>> >>>> 1. >>>> >>>> integrate a SSH server in snappy itself; I don’t know how hard this >>>> is in go today; this might be a worthwhile exercise long-term to get a >>>> smaller rootfs >>>> 2. >>>> >>>> configure SSH server and login to always start /bin/snappy-cli >>>> instead of the user’s shell, then lookup the user’s shell in the >>>> passwd database to run the preferred shell with “snappy shell” >>>> 3. >>>> >>>> (preferred) configure the user’s shell to /bin/snappy-cli and >>>> create a new snappy-only ubuntu-core config for the preferred >>>> interactive >>>> shell (defaults to /bin/bash); drawback: this would be system-wide >>>> as we don’t have per-user configs >>>> >>>> >>>> Questions? Comments? Pile on at: >>>> https://docs.google.com/document/d/1DeR2JoCBDX2C1r6a2wV60uqvi7a89OwHh5gJ19tBZvM/edit >>>> >>>> Cheers, >>>> -- >>>> Loïc Minier >>>> >>>> -- >>>> snappy-devel mailing list >>>> [email protected] >>>> Modify settings or unsubscribe at: >>>> https://lists.ubuntu.com/mailman/listinfo/snappy-devel >>>> >>>> >>> >>> >>> -- >>> gustavo @ http://niemeyer.net >>> >> >> >> -- >> snappy-devel mailing list >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snappy-devel >> >> > > -- > snappy-devel mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snappy-devel > >
-- snappy-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel
