@damo I completely agree. I'm not talking about a standard BunsenLabs, or even a BunsenLabs-lite, this came up in the context of a "base" metapackage which would install the absolute minimum for a desktop setup. Leaf/Mousepad instead of Geany, no media player... This isn't even talking about fitting on a CD - while there's still a lot to be pared off the current apps list I'd have hoped it would be much less than that. (Perhaps impossible though.)
No new users would be expected to install bunsen-base and just that. Of course it would be hard to use. They'd install bunsen-standard which would pull in bunsen-base plus a lot more...
...including a "proper" browser, probably iceweasel.
@cpoakes many thanks for your input! I was hoping for some constructive feedback like this.
I had in fact been giving serious thought to adding some new debian alternatives, and even now am not totally opposed to the idea. Came up 5 days ago, first brought up in 2013. Original reference here: http://ubuntuforums.org/showthread.php?t=1501719
Why I started thinking about something else:
Editing Debian Alternatives is quite bothersome, involving several long commands in a terminal. Compared with that, my suggestion involves editing one line in .xsessionrc (or perhaps another file).
Edits are done as root, requiring a password. I prefer to avoid sudo as much as possible if there's a userland alternative. Just on principle.
I'd regard the system-wide character of alternatives settings as a disadvantage. Surely it's better if each user can configure their own preferred apps?
Even so, the idea of creating new x-text-editor or x-image-viewer alternatives is rather appealing... especially if the packagers of such apps would add them to their apps' 'provides' fields. Is there actually much chance of that happening?
There does indeed not seem to be any "master list" of alternatives, but there is a list of virtual package names, including things like x-terminal-editor, which has its own page and required behaviour, so obviously some of these "alternatives" are quite established.
...run "update-alternatives --install" from the postinst and "update-alternatives --remove" from the prerm scripts in the bunsen package defining the dependencies.
Sorry, I'm not following you here. What kind of bunsen package are you referring to here? What dependencies? There will be no BunsenLabs versions of executables like editors.
Just add global launchers (/usr/share/applications/*.desktop) to match.
Again, why use a global system-wide launcher, when you can have individual user files in ~/.local/share/applications?
I don't think these shell commands belong in .xsessionrc for every Xsession. If I add multiple DEs (like xfce), it puts unnecessary cruft in my environment and sets up a DE I am not using. This belongs to a more BL specific script like /etc/xdg/openbox/environment or /etc/xdg/openbox/autostart (or the .config/openbox versions if you must).
I can see a case for moving those variables to ~/.config/openbox/environment, if there was a likelihood or running some other DE where they weren't needed. Though, why would a defined bl-text-editor be a problem on an XFCE session?
The long-term goal of enabling a BunsenLabs session to coexist with XFCE or some other DE's on the same computer is desirable, but not at all easy. CrunchBang never achieved this and early LXDE was notorious for messing with peoples' systems IIRC. I doubt if Gnome or KDE would leave all the settings of other DEs untouched. Anyway, by all means, let's do our best to be good neighbours with all these others...
I think these binaries/links should be global to parallel the structure of x-www-browser and x-www-terminal, not user specific.
This is the same issue again. I'd say - the more user-specific the better!
You can't assume the presence of $HOME/bin (or any directory under user control). You need to add:
mkdir -p $HOME/bin
I don't even like managing the contents of $HOME/bin or even requiring it in the users path. I think it is the users' domain and should remain that way. The DE should manage executables in system locations for all users (/usr/bin, /usr/local/bin).
It's the same grand theme: system-wide vs user-specific. Anyway, surely you're aware that the whole CrunchBang, and hence BunsenLabs, setup is based on a set of user configuration files which are pasted into ~/ at the end of an install? Messing with the user's domain on a grand scale. That's what the whole thing is all about.
And why add leading underscores to the env variables? This is traditional for system variables that 1) might clash with user defined names, and 2) are not intended to be modified by the user. Clearly not your intent given the comment.
No indeed. I intended quite the opposite. I had got the idea that the underscore was reserved for private variables to keep them distinct from system variables! Google didn't help. Thanks for putting me right there.
After purging each, and doing 'apt-get autoremove':
links2: After this operation, 5,640 kB of additional disk space will be used. dillo: After this operation, 2,915 kB of additional disk space will be used.
And I think Dillo looks way prettier than 'links2 -g', but that's just one person's opinion...
If everyone really hates Dillo so much, I won't throw a sulk or anything if another small browser goes in bunsen-base.
...I jest slightly, but for a quick google it can't be beat - or something else you might want to try, navigate to /usr/share/doc and see if there's any faster way to browse installed docs (also views .tar.gz files).
Yes, for some badly designed web pages you have to scroll down through navigation stuff before you get to the real content (not good for SEO btw) but I use Dillo every day, even though Iceweasel is my standard browser for "normal" web use. Dillo is FAST, that's the only point. If your browser isn't up and running, you don't have to wait for some quick result.
Anyway, my suggestion to add Dillo to a "base install" instead of Iceweasel or Google Chrome is because:
It's just a placeholder. Sometimes while setting up an install you need access to the web, to look something up or navigate to a download page and get something.
Any other browser would be bigger, and still likely to be replaced anyway. Helps keep the .iso size down.
Think of it like installing Leafpad. Sometimes that's all you need.
Once a "better" browser is installed, you can remove Dillo, but it's not really taking up that much disk space.
The Debian alternatives system is a great idea and works well... for terminal emulators and web browsers. Pretty much everything else it handles is CLI stuff. There is a gnome-text-editor alternative, but not many editors add themselves to it, so not a lot of use.
It would certainly be nice to free our menus and scripts from hard-coded references to a particular text editor or file manager which force users to search around and edit everything when they change an app.
I thought of this system - if anyone can see a snag in it, please point it out before I put any more work into it!
OK ~/.xsessionrc is only referenced in X sessions so it's perfect for setting up stuff which would get in the way in a tty. Let's set some environment variables there, and maybe make symlinks in ~/bin from them, so they can be used in scripts, config files and menus, called with gmrun or dmenu... Then if the user wants to change one of them, it's only one file to edit. Also, unlike alternatives this is per-user, not system-wide.
Something like this:
# edit these to taste: _BL_TEXT_EDITOR='/usr/bin/geany' _BL_IMAGE_VIEWER='/usr/bin/mirage' _BL_FILE_MANAGER='/usr/bin/thunar' _BL_MEDIA_PLAYER='/usr/bin/vlc' export _BL_TEXT_EDITOR _BL_IMAGE_VIEWER _BL_FILE_MANAGER _BL_MEDIA_PLAYER ln -sf "$_BL_TEXT_EDITOR" "$HOME/bin/bl-text-editor" ln -sf "$_BL_IMAGE_VIEWER" "$HOME/bin/bl-image-viewer" ln -sf "$_BL_FILE_MANAGER" "$HOME/bin/bl-file-manager" ln -sf "$_BL_MEDIA_PLAYER" "$HOME/bin/bl-media-player"
We could also put .desktop files in ~/.local/share/applications/ so they would appear in auto-generated menus and can be referenced in tint2rc.
eg for bl-text-editor.desktop:
[Desktop Entry] Type=Application Version=1.0 Name=Text Editor Exec=bl-text-editor %F Icon=/usr/share/icons/Adwaita/scalable/apps/accesories-text-editor-symbolic.svg Terminal=false Categories=GTK;Development;IDE; MimeType=text/plain;text/x-chdr;text/x-csrc;text/x-c++hdr;text/x-c++src;text/x-java;text/x-dsrc;text/x-pascal;text/x-perl;text/x-python;application/x-php;application/x-httpd-php3;application/x-httpd-php4;application/x-httpd-php5;application/xml;text/html;text/css;text/x-sql;text/x-diff; StartupNotify=true
Yes I was surprised at first not to get an email app - but I would probably have uninstalled it anyway and put in Icedove...
It's a tricky topic, default apps, and raises the question of how complete a system BL (or, previously, #!) should be, and for that matter what constitutes completeness.
Anyway, you can't do anything without some kind of terminal, text editor, image viewer and web browser, but after there it gets more difficult. CrunchBang was a "full-featured" setup in its way, but Philip did say, at one point in the "ideas for Janice" thread, that he was thinking about making a well-configured basic system and letting people install their own choice of media player, pdf viewer...
That could be an option for BunsenLabs, although there's also something to be said for a setup that already does most of the usual things that people use computers for, even if they might want to change some of the apps later.
^There hasn't been a help pipemenu in #! for a long time if I remember right. It's been commented out since Waldorf at least. We're hoping that the new one will have some links that are helpful to new users at least.
PS damo, how about adding links to the Debian forum and wiki in the Debian section?
...providing users with this option is just to ask for a lot of support-questions. NOBODY should stay on SysVinit unless they have the skill and knowledge to do it on their own. And the users that are able to do it on their own, doesn't need Bunsen to be Init-agnostic.
btw XFCE and LXDE are in a different category altogether from our modest little community. Even so, do they really provide support for all init options? How about Mint DE? Do they support systemd?
@michaelrutherford as Zill says I'm sure everyone here appreciates your desire to help, and would like to join in the "welcome!".
But I also agree with Zill on the desirability of keeping the information in one place. As it is, it can already be difficult to keep track of what's going on...
...that virtual install still gets the Black Freezes, even after uninstalling light-locker and xscreensaver, so neither of them is the culprit. Very annoying though. Up till now I've always been able to get back by hitting the keyboard. Personally, I'm happy enough to have the screen blanked after a certain period of inactivity, as long as I can get it back again!
A reminder - Wally is not a prototype BunsenLabs, it's a Waldorf clone on Debian Jessie. It includes screen not through any choice of mine but because it was in #! Waldorf.
I'd go for leaving it out - it's not really a core functionality after all, though yes multiplexers are useful sometimes.
xfce4-terminal has tabs, new windows and some of the same features of terminator, though I don't know if it goes quite as far.
How often is the black screen irreversible? ie even if you tap a key it doesn't light up again? Does it depend on the hardware/BIOS? I'd never hit that issue till yesterday on a VirtualBox Jessie. It just shrank to a small black box and the only way out was to kill the "power" on it, just as Sector11 said. That one had light-locker installed btw.
With all the greatest respect to smacz and all the work he's done here I'm beginning to wonder if light-locker isn't trying too hard to be helpful and picking up on any cue it can find to lock things up...
To return to the Original Post by borborygmi, i3lock looks very nice with his script, and seems to behave itself - just locking the screen when you ask it to. Anyway, I'm going to use it for a while and see how it goes.
OK I'll own up here. I don't know a lick of Python either.
It was still easy to look through that script, find the system calls and replace the dbus commands with systemctl ones. If there was a single command that worked on all init systems and did not require the editing of sudoers, then for sure I would recommend we use it.
Meanwhile, I still stand by my claim that the number of users who want to use something other than the Debian default systemd but who would be unable to edit bl-exit, or use an alternative, is extremely small.
( I suppose in the future it might not be totally out of the question to provide a bunsen-exit-sysvinit package. Not a high priority though. )
If you want to fix it you'll have to open all the files in /usr/lib/lib-cb-welcome, find lines that look like 'sudo apt-get install -y cb-meta-libreoffice' and remove the '-y'. Then when you run the script you'll be prompted about the authentication. Yes, a lot of work.
sudo sed -i 's/\-y//g' /usr/lib/lib-cb-welcome
lib-cb-welcome is a directory so it would have to be
sudo sed -i 's/\-y//g' /usr/lib/lib-cb-welcome/*
Why have you escaped the first hyphen btw?
EDIT: It is normally a really bad idea, but the `--force-yes` option will install packages without authentication:
sudo sed -i 's/\-y/--force-yes/g' /usr/lib/lib-cb-welcome
@schylis -- wait for johnraff's response to this suggestion before trying this.
Normally not approved of, but since we are in the experimental zone here anyway, either way would be OK, although a better option would be --allow-unauthenticated in this case. Again:
sudo sed -i 's/\-y/--allow-unauthenticated/g' /usr/lib/lib-cb-welcome/*
But I haven't tried this...
Just ran into this, fwiw: http://www.shallowsky.com/linux/x-screen-blanking.html
@schlyis sorry about the cb-welcome issues. I thought it would work OK as-is but because some packages are in a local repository they have no gpg key. If you scroll up after one of the failed installs you'll see:
WARNING: The following packages cannot be authenticated!
E: There are problems and -y was used without --force-yes
This is because cb-welcome uses the "yes" option. If you want to fix it you'll have to open all the files in /usr/lib/lib-cb-welcome, find lines that look like 'sudo apt-get install -y cb-meta-libreoffice' and remove the '-y'. Then when you run the script you'll be prompted about the authentication. Yes, a lot of work.
That script is now being rewritten for BunsenLabs as bl-welcome. The current version is on GitHub: https://github.com/BunsenLabs/bunsen-welcome but it's not really ready to use yet...