bl-welcome - Brave Horizons

hhh · 2016-07-23 21:28:56

Continued from here...
https://forums.bunsenlabs.org/viewtopic.php?id=2414

What about splitting more of bl-welcome to root menu items? So leave browsers/flash out if and have items under network. Link scripts, help files or forum discussions (I suggest this for rapidly changing issues like flash) as needed.

Split off a bunch of the latter half of the script... printer, java, dev at least. So just sources, laptop check/fix, offer Debian backports, and a note about seeing the root menu?

pvsage · 2016-07-23 22:38:47

^ That sounds like a good idea to me.

Another thing I've been thinking about is the Stern Warning page. I was wondering if that could be handled through `less` the way some package update notifications are; even just having to use 'q' to exit `less` should be enough to grab a new user's attention.

johnraff · 2016-08-01 06:15:52

hhh wrote:

What about splitting more of bl-welcome to root menu items?

This sounds good. bl-welcome has grown and grown, and not everything there necessarily needs to be done right after the first login. A quick check for issues to fix, repos to be added, and a note to check the menu looks like the way to go.

The Root Menu, of course, belongs to the user. Once it's been installed we can't push changes via package upgrades - except by the clumsy way of asking users to copy stuff from skel or rerunning the user-setup script. The exception is pipe menus. These are dynamically generated by BL scripts, so can be updated any time by a package upgrade.

So leave browsers/flash out if and have items under network. Link scripts, help files or forum discussions (I suggest this for rapidly changing issues like flash) as needed.

Yes, yes. All kinds of links. That could go in an expanded "network" pipemenu... except that "Network" isn't a pipemenu. "WWW Browsers" is though. Would it be OK to put a Flash section in there?

Split off a bunch of the latter half of the script... printer, java, dev at least.

Right. A lot of the code in those later pages can be re-used, but not completely as-is. But we'd have to make a new pipemenu to put all that stuff in I guess. Existing users wouldn't get it without doing that messy procedure mentioned above, but maybe it's only the new users who would benefit from this anyway?

What time-scale are we looking at here?

For reference, here's a list of what bl-welcome does at the moment:

Issue warning.
check-repos: add any missing "contrib" or "non-free" enties to sources.list. This should be unnecessary in the future.
apt-update and apt-upgrade
system-tweaks
- Offer to install PAE kernel if processor supports it. (For users who installed from CD)
- If laptop detected, offer to upgrade xfce4-power-manager from backports and remove fdpowermon if not needed.
Offer to install extra images.
" Libreoffice. (now removed)
" printing support. (now removed)
" Java
Offer to add Debian Backports.
Offer Flash options.
Development options.
- version-control-tools
- ssh-server (now removed)
- lamp-stack
- packaging-tools

Also due to be added to bl-welcome in Deuterium:

Offer to add BL backports.
Rework all the Flash stuff.
Offer to do the volti>volumeicon switch and all the reconfiguration that goes with it. (For existing users only, Deuterium will have that OOTB.)
Maybe offer to rewrite the composition>tint2 stuff in autostart? (Basically remove the ampersand at the end of bl-compositor --start & to make sure compton is up before moving on to the next item.)

Last edited by johnraff (2016-08-12 01:40:08)

johnraff · 2016-08-03 04:40:32

For a start, 6) Libreoffice and 7) Printing can be dropped from bl-welcome right away as they're already available in the pipemenus.
Done in deuterium.

Also the Dev>ssh-server install option could perhaps be moved to the ssh-config-pipemenu. @Pythonistas: no problem?

Last edited by johnraff (2016-08-03 04:44:18)

xaos52 · 2016-08-03 16:36:18

^ bl-sshconfig-pipemenu should be modified to add a menu entry that allows the package 'bunsen-meta-ssh' to be installed?
Should it run an 'gksudo apt-get update' first, followed by 'gksudo apt-get install bunsen-meta-ssh', or is the latter sufficient? Or perhaps 2 separate menu entries for both actions?

Horizon_Brave · 2016-08-03 22:25:32

I sort of suggested this here a while back...but was met with dismissal...
https://forums.bunsenlabs.org/viewtopic.php?id=1762

hhh · 2016-08-03 22:29:35

^ I wouldn't call that dismissal, and now we're discussing it again. I'll rename the thread in your honour.

Horizon_Brave · 2016-08-03 22:40:58

hhh wrote:

^ I wouldn't call that dismissal, and now we're discussing it again. I'll rename the thread in your honour.

Okay, now you're just mocking me

johnraff · 2016-08-04 03:08:26

hhh wrote:

^ I wouldn't call that dismissal

Neither would I. (I just went back and re-read it.) We were just coming up to the First Official Release - not an ideal time to discuss reworking a large, complicated central part of the new user's experience.

Also, @hhh

johnraff wrote:

What time-scale are we looking at here?

The things we can easily do for Deuterium and things that might be implemented in Helium are two different issues. Of course, Helium might be totally different anywyay... (eg https://forums.bunsenlabs.org/viewtopic.php?id=2142)

Last edited by johnraff (2016-08-04 03:14:08)

johnraff · 2016-08-04 04:02:55

xaos52 wrote:

^ bl-sshconfig-pipemenu should be modified to add a menu entry that allows the package 'bunsen-meta-ssh' to be installed?

That would enable us to drop the ssh-server install page from bl-welcome.

Should it run an 'gksudo apt-get update' first, followed by 'gksudo apt-get install bunsen-meta-ssh', or is the latter sufficient? Or perhaps 2 separate menu entries for both actions?

Two separate entries sounds a bit like overkill, just to let users skip apt-get update because they've already run it that day! Let's run the apt update anyway - this is something most users will run only once in a long time.

A popup terminal to run the commands would be desirable really, a system call like this?

x-terminal-editor -T 'Install SSH server' -e sh -c 'sudo apt-get update && sudo apt-get install bunsen-meta-ssh && { echo "OK, installed"; sleep 2;} || { echo "ERROR (press a key to close)"; read;}'

So the user sees the messages.

Even better, a test for the install status of openssh-server to determine whether or not to show that item?

All this reminds me, I was thinking at some time to make a small default /usr/bin/bl-installer script which would pop up a terminal (unless it was being called from a terminal), source the functions from bl-include.cfg and install whatever packages it was sent as arguments, along with optional "title" and "message" texts. That could replace a certain amount of the code in all the "install" pipemenus, and allow any other python, lua or whatever script to call it if an installation was needed. Maybe even a future bl-welcome might use it.

I'll try it out right now (should be quite simple) and post a proof-of-concept ASAP.

hhh · 2016-08-05 01:16:41

johnraff wrote:

Also, @hhh
johnraff wrote:
What time-scale are we looking at here?
The things we can easily do for Deuterium and things that might be implemented in Helium are two different issues. Of course, Helium might be totally different anywyay... (eg https://forums.bunsenlabs.org/viewtopic.php?id=2142)

I don't know what time scale. There is a ton of stuff on the plate. I'd guess between October and January, with a heavy dose of "when it's ready", for deuts?

jessie LTS could last for quite a while, I think the deuterium upgrade will be fairly major and we should take our time with it. Hydrogen/stretch will be determined by Debian development, more or less.

We should just plug ahead as time allows. I'll try and pick up the pace on my end again.

johnraff · 2016-08-05 05:28:12

^OTOH if we put all we've got into Deuterium there won't be anything left for Helium!

My vote is to draw a line - decide what's going into Deuterium - and get it out a bit sooner than January, for sure.

The trickier stuff can indeed be released "when it's ready". In that second bracket I'd include, for example, any changes to bl-welcome that go beyond just moving some installs into pipemenus.

Like, a major rewrite of bl-welcome to a menu-style selection system: that could take a long time to get right, and I don't see any point in holding up the rest of Deuterium for months while waiting for that to get done. Most of the other Deuterium stuff is already done, and some of it is quite urgent, like getting the new volumeicon setup pushed out into new installs.

Let's check off the Deuterium to-do list, off-load the trickier stuff to "later", and push out Deuterium in September even? Does that sound doable?

hhh · 2016-08-05 05:37:17

That's fine as a plan.

johnraff · 2016-08-05 05:58:08

@xaos52 Rather than distract this thread too much, I put up an example install script here: https://forums.bunsenlabs.org/viewtopic.php?id=2524

If you have time, could you take a look and see if a call to 'bl-install bunsen-meta-ssh' would be likely to do the job in bl-sshconfig-pipemenu? Also, of course any input you have on the script itself will be most appreciated!

johnraff · 2016-08-05 06:00:39

@hhh so a bit of triage is called for I guess.

hhh · 2016-08-05 06:04:41

Yes, let's get vitals stable and take it from there.

pvsage · 2016-08-05 06:49:02

I agree, you should focus on taking care of the vitals and easily doables for Deuterium. We can afford to defer anything beyond that to Helium development.

Note the pronoun shift above. I've been really out-of-the-loopy with Hydrogen because reasons, but I hope to be more hands-on with Helium.

johnraff · 2016-08-05 07:26:47

pvsage wrote:

...I hope to be more hands-on with Helium.

Great!

pvsage · 2016-08-11 12:11:18

If adding the ssh server is such a minimal operation, and the client is part of the standard Debian install anyway, why not include it in the ISO and fugghadeaboutit in bl-welcome or the pipemenus? Are there any vulnerabilities (current or foreseeable) that having the server running as a daemon would potentially open the user to?

Head_on_a_Stick · 2016-08-11 17:31:07

pvsage wrote:

Are there any vulnerabilities (current or foreseeable) that having the server running as a daemon would potentially open the user to?

Well, they would have port 22 open and listening so if we were to do that then we would also have to disable root login from ssh.

I would also think a firewall would then be recommended.

For the record, I am opposed to including ssh in the base system.

#1 2016-07-23 21:28:56

bl-welcome - Brave Horizons

#2 2016-07-23 22:38:47

Re: bl-welcome - Brave Horizons

#3 2016-08-01 06:15:52

Re: bl-welcome - Brave Horizons

#4 2016-08-03 04:40:32

Re: bl-welcome - Brave Horizons

#5 2016-08-03 16:36:18

Re: bl-welcome - Brave Horizons

#6 2016-08-03 22:25:32

Re: bl-welcome - Brave Horizons

#7 2016-08-03 22:29:35

Re: bl-welcome - Brave Horizons

#8 2016-08-03 22:40:58

Re: bl-welcome - Brave Horizons

#9 2016-08-04 03:08:26

Re: bl-welcome - Brave Horizons

#10 2016-08-04 04:02:55

Re: bl-welcome - Brave Horizons

#11 2016-08-05 01:16:41

Re: bl-welcome - Brave Horizons

#12 2016-08-05 05:28:12

Re: bl-welcome - Brave Horizons

#13 2016-08-05 05:37:17

Re: bl-welcome - Brave Horizons

#14 2016-08-05 05:58:08

Re: bl-welcome - Brave Horizons

#15 2016-08-05 06:00:39

Re: bl-welcome - Brave Horizons

#16 2016-08-05 06:04:41

Re: bl-welcome - Brave Horizons

#17 2016-08-05 06:49:02

Re: bl-welcome - Brave Horizons

#18 2016-08-05 07:26:47

Re: bl-welcome - Brave Horizons

#19 2016-08-11 12:11:18

Re: bl-welcome - Brave Horizons

#20 2016-08-11 17:31:07

Re: bl-welcome - Brave Horizons

Board footer