18
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: + + + + + + Line 6:
Line 12: + + + +
Talk:Features/Terminal Sharing (view source)
Revision as of 12:57, 6 August 2009
, 12:57, 6 August 2009no edit summary
This sounds quite fun and useful. Is there a reason this couldn't be integrated with the Terminal activity itself, with these features enabled when the activity is shared? -[[User:Eben|Eben]] 02:04, 25 July 2009 (UTC)
This sounds quite fun and useful. Is there a reason this couldn't be integrated with the Terminal activity itself, with these features enabled when the activity is shared? -[[User:Eben|Eben]] 02:04, 25 July 2009 (UTC)
: There is no major technical reason that this sharing functionality could not be integrated into the main Terminal activity. However, there is a security issue. The Terminal activity exposes the full power of the user over the machine. On an XO in the default configuration, this includes root access with no password. Even without root access, anyone participating in the activity could easily "rm -rf .sugar" and delete your entire Journal, etc. Advising users not to share the Terminal with people they don't trust might be sufficient... I'm not sure how to reach consensus on this point.
:ShareTerm, simply by not being named "Terminal", is treated as a normal activity, and so is sandboxed by Rainbow... if Rainbow is present. If Rainbow is not present, then ShareTerm has no security advantage at all.
:Adding sharing to Terminal itself, in an unsafe fashion, would have the distinct advantage of allowing deep technical troubleshooting and problem-solving directly over the collaboration system. I could invite an expert onto my machine to perform arbitrary upgrades and maintenance, and watch them as they work. Perhaps you can think of a clever user interface that will ensure "unsafe sharing" is only performed after careful consideration? Perhaps an activity that can only be shared with "Friends"? [[User:Bemasc|Bemasc]] 17:57, 6 August 2009 (UTC)
== Feature Acceptance ==
== Feature Acceptance ==
what would be the downside of packing the needed packages inside the activity? I guess one criteria for adding to the platform is: is this worthy for several activities? -[[User:Erikos|Simon Schampijer]] 04 August 2009 (UTC)
what would be the downside of packing the needed packages inside the activity? I guess one criteria for adding to the platform is: is this worthy for several activities? -[[User:Erikos|Simon Schampijer]] 04 August 2009 (UTC)
: My principal reason for wanting Screen to be a Sugar dependency is to avoid shipping binaries inside .xo bundles. I strongly believe that .xo bundles should be "noarch", to run on any platform. I would be happy to ship the Screen source code and compile it on the user's machine, but gcc is not a sugar dependency either.
: Additionally, as Eben noted, the functionality described here is quite close to Sugar's fundamental mission, and there is an argument for including it in Terminal. Making Screen a Sugar dependency allows us to make these kinds of decisions later. It also opens a door for other shared activities that make use of a shared command line. [[User:Bemasc|Bemasc]] 17:57, 6 August 2009 (UTC)