You are not logged in.
Hi,
I'm a recent adopter of BunsenLabs, and I'd like to share some considerations that are strictly personal but that, maybe, could be somehow useful for developers. Please consider that they are not critical but rather a kind of "mental notes" and impressions I had at first contact with BL.
Premise: I'm not a Linux expert, but I'm not even a totally noob. So, to say, I use apt-get instead of Synaptic.
What really impressed me of BL is its elegance and pragmatic minimalism: looking at the beautiful screenshots on the website I had the feeling of a lightweight and highly customizable distro, without the need to remove things after installation. So after a quick test under VM, I installed BunsenLabs on my "retro" Pentium 4 system and I'm still very happy with it.
The only notes that I would bring to light:
- there should be a graphical UI to allow changing easily date and time, keyboard layout and desktop resolution: I know you can do it by terminal, but it is quite strange to have "Clip-it" pre-installed and not a panel for these fundamental options
- also "hardinfo" should be installed by default, IMHO, to easy check systems specs and compatibility, especially on older machines
- BL community REALLY need a wiki. BL is clearly a highly customizable distro with great potential. But to "unleash" this potential a brief and concise wiki would be perfect (e.g. to explain various basic settings for conky, tint, compositor; to install alternative drivers etc). In short, to enjoy BL customization.
Thank you very much for all your efforts on this wonderful project.
Last edited by Scandy (2016-03-21 13:17:42)
Offline
Another wiki request! The drum beat grows louder for this. As discussed in another thread, I think the main argument against the BL wiki is that because Bunsen is by nature so closely tied with it's "upstairs" big brother, Debian, that a wiki would be like 90% the same information as the wiki.debian site.
But if the time comes where the site moderators, and keepers of the flame here, do decided to launch one, I will be contributing heavily. I already keep a OneNote notebook filled with my learned extracts etc..
"I have not failed, I have found 10,000 ways that will not work" -Edison
Offline
I see, but I'd personally appreciate a very "light" and "welcome-like" wiki, more focused on "moving first steps" in BunsenLabs: menu, panel customizations, a summary of general philosophy and stop. Only the most common first steps, and then, for more complex / specific tutorials, resending to Debian documentation.
Also the fact of considering the Debian wiki useful for BL could be a subject of the BL wiki itself!
Last edited by Scandy (2016-03-21 13:47:04)
Offline
Besides not having much BunsenLabs-specific content, there are also issues with moderating and keeping all pages up to date. Previous experience with the Crunchbang wiki showed exactly these problems.
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
An up-to-date nice wiki would be cool, but as others have said it is a non-trivial thing to set up. That's why the Help section in the main menu has links to the Debian and Arch wikis, and to Openbox, Tint2 and Conky configuration. IMO it isn't necessary to duplicate all that, but in time I can see us having more information on the BL website.
Be Excellent to Each Other...
The Bunsenlabs Lithium Desktop » Here
FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt «» BunsenLabs on DeviantArt
Offline
An up-to-date nice wiki would be cool, but as others have said it is a non-trivial thing to set up. That's why the Help section in the main menu has links to the Debian and Arch wikis, and to Openbox, Tint2 and Conky configuration. IMO it isn't necessary to duplicate all that, but in time I can see us having more information on the BL website.
Even a "First steps" page between "Installation" and "Resources" would be nice (I'd let the "Repositories" chapter only under the "Installation" page, removing from main menu, but it's my personal taste).
What do you think about my other observations?
Thank you!
Offline
Another wiki request! The drum beat grows louder for this. As discussed in another thread, I think the main argument against the BL wiki is that because Bunsen is by nature so closely tied with it's "upstairs" big brother, Debian, that a wiki would be like 90% the same information as the wiki.debian site.
But if the time comes where the site moderators, and keepers of the flame here, do decided to launch one, I will be contributing heavily. I already keep a OneNote notebook filled with my learned extracts etc..
A wiki is not just a piece a software; it requires serious time and effort to create and maintain. Or you'll end up with out-of-date information before you know (the Debian wiki is an example – especially on more complicated subjects, pages are still deadling with Squeeze, Etch or Woody).
We could agree on a portal-like page where forum threads of merit are collected in categories, plus some more text. Tagging threads would be the obvious solution, but related FluxBB plug-ins are outdated, and the FluxBB code is horrible enough to make me not to want to implement one. If we'd ever upgrade to one of the FluxBB successor projects (as mentioned), tagging would come as an extra.
Just creating overview threads about certain topics (in a separate forum section?) would be another solution.
Personally, I'd rather not introduce yet another PHP-or-worse wiki software which needs to be maintained. I also think that it's no use duplicating information all over the place, that the wiki needs re. certain topics are already served well elsewhere (Gentoo/Arch wiki), and that we're too small to have a wiki with proper maintenance. It'd be better to rally up the folks at forums.debian.net to make a move towards cleaning up the main Debian wiki. Ceterum censeo.
Offline
@Scandy
There is a gui for setting resolution and monitors (arandr) - "Menu -> Preferences -> Display"
Again, have a look in the Preferences and Help submenus. There are links to wikis and manpages, which have many of the settings you asked about.
I take the point that things could be easier for a new user who is unfamiliar with the interface, but we are trying to strike a balance. FWIW I think it is a good thing that the commandline has to be used for many things - that is necessary for a "lightweight yet fully-functional" distro. If someone isn't willing to use it then maybe BL isn't the best choice for them.
Be Excellent to Each Other...
The Bunsenlabs Lithium Desktop » Here
FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt «» BunsenLabs on DeviantArt
Offline
How about just using github wiki? https://help.github.com/articles/about-github-wikis/
Offline
Horizon_Brave wrote:Another wiki request! The drum beat grows louder for this. As discussed in another thread, I think the main argument against the BL wiki is that because Bunsen is by nature so closely tied with it's "upstairs" big brother, Debian, that a wiki would be like 90% the same information as the wiki.debian site.
But if the time comes where the site moderators, and keepers of the flame here, do decided to launch one, I will be contributing heavily. I already keep a OneNote notebook filled with my learned extracts etc..
A wiki is not just a piece a software; it requires serious time and effort to create and maintain.
Yea I never said it was easy or trivial in creation and upkeep. Just saying if such a welcome page or project *were* started, I'd be happy to contribute.
"I have not failed, I have found 10,000 ways that will not work" -Edison
Offline
It'd be better to rally up the folks at forums.debian.net to make a move towards cleaning up the main Debian wiki.
That would be nice. There's a reason I regularly rob stuff from Arch
At any rate a first steps page, along with a page addressing common problems might be useful. More advanced stuff is likely best left in the forums, however.
One thing to note is that google search, if you use it, can be prefaced with Bunsenlabs to filter out stuff from other places. I had to do this with Crunchbang for quite some time because I had so heavily trained google to return Ubuntu references. Google seems to do a better job filtering than the in-built forum search.
Offline
I did suggest a while back that we could have a sticky index of sorts in the howtos section of the forums that could list useful articles. Multiple forum mods could keep this post updated, arranged into categories so people could easily find what they were looking for without having to know what to search for (or even discover things they didn't know they could do - something I'd personally find very useful as a relative newcomer to these parts). I reckon it would have the simplicity of a wiki front-page with only a fraction of the additional overhead.
Lenovo IdeaPad Yoga 13 | BunsenLabs Hydrogen (x64)
Intel Core i7-3537U | Intel HD4000 | 8GB DDR3 | 256GB SSD
Offline
@Eraph: Even better and anyone can start and administer such thread (even a normal user ).
Offline
I did consider starting it but I wanted a consensus on it being a solution first. Whether it's read only or not I don't think matters so much, the first post will be continually updated, additional posts would just be rolling comments with such as suggestions for additions and alterations and so on.
Lenovo IdeaPad Yoga 13 | BunsenLabs Hydrogen (x64)
Intel Core i7-3537U | Intel HD4000 | 8GB DDR3 | 256GB SSD
Offline
@Scandy
There is a gui for setting resolution and monitors (arandr) - "Menu -> Preferences -> Display"Again, have a look in the Preferences and Help submenus. There are links to wikis and manpages, which have many of the settings you asked about.
I take the point that things could be easier for a new user who is unfamiliar with the interface, but we are trying to strike a balance. FWIW I think it is a good thing that the commandline has to be used for many things - that is necessary for a "lightweight yet fully-functional" distro. If someone isn't willing to use it then maybe BL isn't the best choice for them.
Hi damo,
thank you. Really, even before my first post I found and tried arand, but simply I had not realized that I should go in "Output > VGA-0 > Resolution" and click the first button on the left (no tooltip...) to apply a new resolution (but, in my defense, I have sought in vain in "Help" and "Informations"). O:)
So this is exactly what I was writing about: a couple of pages for first steps in BL. The "jump" between Installation and Resources IMHO is a bit too "long": even a medium linux user could not know exactly which of the various components is tint2, Openbox, Conky etc. and what they do (and so, where to look in external resources). Personally, still I have not understood how to change keyboard layout and why I can edit notifications appearance by UI, and date/time only by terminal.
I agree that using terminal is good, but BL has a UI and IMHO some very basic operations should be performed by that (otherwise I would use a command-line-only distro).
I would not like and I don't want another Ubuntu or Elementary, I really like (and LOVE) BL as is!
But some short, introductory contents IMHO could help to speed-up first steps, with a better user experience overall. I don't care if these contents will be in Wiki, HTML or hendecasyllables.
IMHO a dedicated section here in the forums, well organized in some subsections reflecting the Openbox menu, and with reply disabled, would be perfect.
Offline
.... Really, even before my first post I found and tried arand, but simply I had not realized that I should go in "Output > VGA-0 > Resolution" and click the first button on the left (no tooltip...) to apply a new resolution (but, in my defense, I have sought in vain in "Help" and "Informations"). O:)
I think it is assumed the user might explore the options available (that wasn't personal BTW!)
..even a medium linux user could not know exactly which of the various components is tint2, Openbox, Conky etc. and what they do (and so, where to look in external resources).
The website homepage says "Pre-configured Openbox window manager with tint2 panel and conky system monitor", which is quite explanatory IMO. There are very comprehensive links in the Help menu for those exact things. I still don't agree that we need to reproduce wikis/faqs for external applications - I fail to see how these couldn't be any more explicit:
Help -> Openbox -> Openbox Website -> Openbox Documentation
Help -> Tint2 Wiki -> Tint2 Wiki: Configuration
Help -> Conky -> Conky Configuration Settings
etc
------------------------
IMHO a dedicated section here in the forums, well organized in some subsections reflecting the Openbox menu, and with reply disabled, would be perfect.
It is being discussed, as you can see
Be Excellent to Each Other...
The Bunsenlabs Lithium Desktop » Here
FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt «» BunsenLabs on DeviantArt
Offline
Documentation is often a problem with open source development.
If documentation is not lacking entirely, it is often short and technical to explain things to peer developers. And there is always the 'use the source, Luke' attitude.
Creation of end user documentation is left to ... end users, explaining things to their peers.
Problem is that end users that create documentation - each in his/her tempo - gain experience and after some time loose interest in it. After some time then, when another nooby does not pick it up, it gets outdated very quickly - are we not all too familiar with searches that turn up info that has become outdated or obsoleted.
Also people move on, from a relatively easy distro to more demanding ones, and quickly forget about any documentation they left behind.
Offline
^ Ain't that the truth.
Same with HowTo's in forums ... always check the date.
Debian 12 Beardog, SoxDog and still a Conky 1.9er
Offline
Well I'm not thrilled with the idea of having the How To pages be on the forums... but it'd be better than nothing I suppose. I think a wiki page would be ideal. The main focus though should be:
A. Keep it up to date.
B. Don't make it complete rehash of the debian / arch wiki's. It should be as much as possible, exclusive to Bunsenlabs. Of course an explanation as to what the different names of software are about, would be good. Like what Damo was referring to, what conky is/does, what compton is/does, tint2..etc..
"I have not failed, I have found 10,000 ways that will not work" -Edison
Offline
Documentation is often a problem with open source development.
If documentation is not lacking entirely, it is often short and technical to explain things to peer developers. And there is always the 'use the source, Luke' attitude.
Creation of end user documentation is left to ... end users, explaining things to their peers.
Problem is that end users that create documentation - each in his/her tempo - gain experience and after some time loose interest in it. After some time then, when another nooby does not pick it up, it gets outdated very quickly - are we not all too familiar with searches that turn up info that has become outdated or obsoleted.Also people move on, from a relatively easy distro to more demanding ones, and quickly forget about any documentation they left behind.
In some ways, Linux is also a fast moving target when it comes to documentation. What I mean is that sometimes documentation quickly loses relevancy. For instance, the #! forums is a treasure trove of how-to's etc but it pays to understand that it is not always relevant to a problem involving Jessie.
Usually, if I write an actual program, provided it is not fairly short and self-explanatory, I consider it my responsibility to properly document my code. This is not just for other eyes, it also help me to remember why I set things up a certain way. But given that, it is not really documentation intended for the end-user, because I still work on the assumption that anyone reading it can read and understand whatever language I am developing in.
I tend to use the wider web to come up with my solutions. If I end up having to pull from more than one source to come up with said solution, then usually I end up posting a HOW-TO here. That not only helps other people but also helps me if I ever need to remember how I arrived at said solution. Examples of sources I pull info from: These forums, arch wiki, sometimes arch forums, Ubuntu, Debian, stack exchange, individual blogs and more. As I said, my criteria for posting a HOW-TO usually depends on how much time/effort I have in any given solution. If a simple google search gives me a reasonable hit without having to dig ten pages or combine info from various sources, then I am not usually going to bother with a HOW-TO.
Any Linux user should become familiar with man pages and consider working on their google-fu (or whatever search engine you prefer).
Offline