[PC-BSD Dev] Questions

Kris Moore kris at pcbsd.com
Mon Sep 15 10:56:47 PDT 2008

A.Y. wrote:
> Well guys, I want make clear some questions, about what plans should I have :)
> 1. CrashLogs.
> Now they storing at ~/
> It makes a homedir a garbage dir after few months.
> move it to dir like ~/crashlogs wouldn't be a problem.
> But, what sense in these logs? Many OSes have "send-them-your-crash-log" 
> feature; I think PC-BSD should have one too.
> What do you say?
> Also, CrashHandler should a little bit evolve - it should store its settings, 
> and display us what command (or program) bring this crash, which logs do we 
> sent, which logs didn't we sent, allow to delete both sent and not logs, to make 
> crash-logs dir clean. It should allow user check a check boxes called ("Do not 
> display me"), ("Send logs in deep night"), ("Send logs immediately after crash, 
> do not ask me"), ("Don't send logs, I'm paranoid"), ("Delete logs after sending 
> (or immediately, if i prefer not send logs)")
> And could be good if we gather reboot-hung reports too, if possible.
> I could write some softy which could handle and sort similar crash logs, and 
> report stats with most crashed apps;

I agree that we can cleanup the crash log location. Right now, logs are
supposed to get cleaned up automatically, and then we also have a
cleanup script which runs at shutdown and removes any that were missed.
However, fixing it up to use some sort of ~/.crashlogs/ dir should be a
good solution I think. Your other ideas for improvements to CrashHandler
is good also, which ones would you like me to do? Tim, do you have any
feedback since you originally wrote it?

  2. Services.
> PC-BSD 7 introduce very good feature - concept "Service". it have controls 
> "Start, Stop, Restart, Enable, Disable"
> But his have no "settings". I think this should be discussed. I wrote 
> ACPI-support for notebooks as Service, but had a problem: I have no ways to user 
> specify their vendor; The workaround was made, but I thinks Services should 
> anyway have "Settings", and scripts which callbacked after settings are set 
> (I'll explain why restart isn't sufficient).
> for example, they could have optional file "preferences.cfg" and some UI to 
> configure it, via simple conventions in structure file:
> Each parameter in UI have "select" for controlling, and have three vars in 
> config, for example:
> vendor_label="Specify your notebook vendor"
> vendor_selected="asus"
> vendor_values="None:
> Asus:asus
> Toshiba:toshiba
> Sony:sony"
> I think that could be useful for future, services not always generics, and may 
> have some configurable options too;
> Another use: we could add option "Root allowed"  in SSH service. here we need 
> callback - script, which is started when we change settings (it simple 
> repopulate settings to /etc/ssh/sshd.conf if I'm not mistaken)

I think this is an excellent idea as well. We should discuss the
preferences.cfg UI specification, and then figure out how to create the
UI on the fly. Maybe like this?


title: SSHD Settings
element1: radio
element1.text: Enable root login via SSH
element1.options: enabled, disabled

element2: combobox
element2.text: Enable root login via SSHD?
element2.options: combo1, combo2, combo3

element3: checkbox
element3.text: Allow root login?
element3.options: checked

We'll have to put some thought into it, but I think something along
those lines may work and allow us to create nice settings dialogs.

> 3. Services again...
> If we have PC-BSD 7.0, and 7.1 is going to be after half-year, how we deploy new 
> services? via updates 7.0.1 ... 7.0.100 ?
> Could we discuss some way for user to download and install services, in same way 
> as PBI, maybe exactly in PBI format?
> What I see is:
> PBI mysql, installs many files (maybe even a mysql.ini editor if there any), and 
> a PC-BSD-MySQL service, which can be easily start, stop, ... =  controlled by 
> average user, who don't know much about rc.d, in way that doesn't allow typo 
> mistakes, like "/us*e*/local/etc/rc.d/mysql.sh start", or similar;;
> something else, what installs as PBI but all what it contains - a directory with 
> all service-required files.
> In that way we could update services without whole system updates, and count of 
> useful services will grow.

That was my original idea behind the services menu. If we have a PBI
that runs as service, it can install its script configuration into
/PCBSD/Services/ that way the user can control it via GUI. Also, we can
issue online updates to add new services to the default system, such as
your acpi one, I can package that up as a patch, and issue it online.

> 4. When we install PC-BSD we have option to choose language. When we made a 
> choice, smart scripts changes some ".skel" files, change login.conf and rebuild 
> its db. After successfull install, is there any way to change a whole language, 
> in a correct way?  I think that System installed as "English" and localized via 
> "special wizard" to russian (for example), must have no differences with system, 
> which was installed as "Russian" - this is mandatory I think.
> So, this bring me to thought that all options, actions what accessible via 
> install, *must be* in system after install. Switching language should check if 
> we have all required packages, if not ask to download or insert CD/DVD, or maybe 
> specify path where packages could be found.

So far I haven't put anything into the OS to change the entire language
on the fly post-install. However, maybe we can put something into the
System GUI? That way you can change languages, or even install multiple
language packages, and setup users as different utf profiles in login.conf?

> 5. Resolution.
> PC-BSD is user-friendly OS. Friendly users love to play games :) Games love to 
> hungs. Some cases with hang app could not switch resolution back to normal, and 
> stay with low for example. in that case user have struggles to setup back 
> resolution, right click on desktop didn't bring anything that can switch resolution.
> But even if it was there, I recommend us to have a little and very simple 
> plasmoid in left-top corner with single option: "switch to normal resolution" 
> and settings where can be specified which resolution for us is "normal". It 
> helps user to quickly solve his little problem, and user will be happy :)

I don't know if we would need to use a special plasmoid for this, since 
I wouldn't want it on my screen all the time :) However, what about it 
we setup a special key-stroke? Like Win + Ctrl + R or something which 
"restores default resolution"?

> 6. When starting system, we start kdm, and if xorg.conf have errors we dropped 
> back to console, to "nowhere" using understanding of user :)
> Can we change a kdm-startup script, so if kdm exits unnormally (and system isn't 
> going to shutdown), we immediately try to start graphical xorg configuration 
> util, so user can make experiments, and could find his driver (or monitor 
> frequency).

Take a look here:


That what we run right now instead of just kdm, we'll just need to write 
some code which detects if kdm / xorg failed for some reason, and then 
kicks off the setup_xorg() code again. I had originally wanted to do 
that, haven't figured out a good way to code it yet, to reliably detect 
if Xorg fails or not.

> 7. Post a Bug
> Currently, for post a bug or suggestion, user had to register. Users hate 
> registrations after first day in Internet, because all forums, blogs etc. have 
> this annoying registration :)
> I propose: Simple plasmoid somewhere on desktop, click it bring a big (but not 
> giantic) textarea, where user ask to describe problem, optional field for his ID 
> (he allowed to leave here nick, name, email, phone or empty so we can identify 
> him, if he want to), and button "Send Report" which simply post bug.
> Why this helps us? Because users lazy. If you need more reasons - ask some guy 
> who is sitting an windows to fulfill all steps required for post bug in KDE; and 
> then ask him, if he ever will post bugs, if his document just disappeared, and 
> it was very, very important. He could spent 15 secs to complain about it, but no 
> way 3-7 minutes.

I think this would be a great idea / plasmoid to develop. Maybe we can 
have it send all the error requests to a mailing list which we can 
monitor to see what kind of errors users are reporting.

> Well, this is more than enough for Monday, I think :)
> I'm now at yerenkow in irc, not at yerenkow_pc2 (forgot to disconnect in morning)
> P.S. As always, sorry for my hard-to-understand English

Good ideas there, keep them coming! You're English is just fine :) Lets 
keep brainstorming these ideas for 7.1 so we can have some cool new 


Kris Moore
PC-BSD Software

More information about the Dev mailing list