X-Git-Url: http://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/75271fca661bb7eaf7e18decd54e6f9807aa134e..003c712cede7d2663ce55393faba09763dbeeb2b:/blog/archive/2011/07/07.rss diff --git a/blog/archive/2011/07/07.rss b/blog/archive/2011/07/07.rss index 0875d8d9bc..cac3601b3f 100644 --- a/blog/archive/2011/07/07.rss +++ b/blog/archive/2011/07/07.rss @@ -260,5 +260,128 @@ sidelinjen.</p> + + What is missing in the Debian desktop, or why my parents use Kubuntu + http://people.skolelinux.org/pere/blog/What_is_missing_in_the_Debian_desktop__or_why_my_parents_use_Kubuntu.html + http://people.skolelinux.org/pere/blog/What_is_missing_in_the_Debian_desktop__or_why_my_parents_use_Kubuntu.html + Fri, 29 Jul 2011 08:10:00 +0200 + +<p>While at Debconf11, I have several times during discussions +mentioned the issues I believe should be improved in Debian for its +desktop to be useful for more people. The use case for this is my +parents, which are currently running Kubuntu which solve the +issues.</p> + +<p>I suspect these four missing features are not very hard to +implement. After all, they are present in Ubuntu, so if we wanted to +do this in Debian we would have a source.</p> + +<ol> + +<li><strong>Simple GUI based upgrade of packages.</strong> When there +are new packages available for upgrades, a icon in the KDE status bar +indicate this, and clicking on it will activate the simple upgrade +tool to handle it. I have no problem guiding both of my parents +through the process over the phone. If a kernel reboot is required, +this too is indicated by the status bars and the upgrade tool. Last +time I checked, nothing with the same features was working in KDE in +Debian.</li> + +<li><strong>Simple handling of missing Firefox browser +plugins.</strong> When the browser encounter a MIME type it do not +currently have a handler for, it will ask the user if the system +should search for a package that would add support for this MIME type, +and if the user say yes, the APT sources will be searched for packages +advertising the MIME type in their control file (visible in the +Packages file in the APT archive). If one or more packages are found, +it is a simple click of the mouse to add support for the missing mime +type. If the package require the user to accept some non-free +license, this is explained to the user. The entire process make it +more clear to the user why something do not work in the browser, and +make the chances higher for the user to blame the web page authors and +not the browser for any missing features.</li> + +<li><strong>Simple handling of missing multimedia codec/format +handlers.</strong> When the media players encounter a format or codec +it is not supporting, a dialog pop up asking the user if the system +should search for a package that would add support for it. This +happen with things like MP3, Windows Media or H.264. The selection +and installation procedure is very similar to the Firefox browser +plugin handling. This is as far as I know implemented using a +gstreamer hook. The end result is that the user easily get access to +the codecs that are present from the APT archives available, while +explaining more on why a given format is unsupported by Ubuntu.</li> + +<li><strong>Better browser handling of some MIME types.</strong> When +displaying a text/plain file in my Debian browser, it will propose to +start emacs to show it. If I remember correctly, when doing the same +in Kunbutu it show the file as a text file in the browser. At least I +know Opera will show text files within the browser. I much prefer the +latter behaviour.</li> + +</ol> + +<p>There are other nice features as well, like the simplified suite +upgrader, but given that I am the one mostly doing the dist-upgrade, +it do not matter much.</p> + +<p>I really hope we could get these features in place for the next +Debian release. It would require the coordinated effort of several +maintainers, but would make the end user experience a lot better.</p> + + + + + What should start from /etc/rcS.d/ in Debian? - almost nothing + http://people.skolelinux.org/pere/blog/What_should_start_from__etc_rcS_d__in_Debian____almost_nothing.html + http://people.skolelinux.org/pere/blog/What_should_start_from__etc_rcS_d__in_Debian____almost_nothing.html + Sat, 30 Jul 2011 14:00:00 +0200 + +<p>In the Debian boot system, several packages include scripts that +are started from /etc/rcS.d/. In fact, there is a bite more of them +than make sense, and this causes a few problems. What kind of +problems, you might ask. There are at least two problems. The first +is that it is not possible to recover a machine after switching to +runlevel 1. One need to actually reboot to get the machine back to +the expected state. The other is that single user boot will sometimes +run into problems because some of the subsystems are activated before +the root login is presented, causing problems when trying to recover a +machine from a problem in that subsystem. A minor additional point is +that moving more scripts out of rcS.d/ and into the other rc#.d/ +directories will increase the amount of scripts that can run in +parallel during boot, and thus decrease the boot time.</p> + +<p>So, which scripts should start from rcS.d/. In short, only the +scripts that _have_ to execute before the root login prompt is +presented during a single user boot should go there. Everything else +should go into the numeric runlevels. This means things like +lm-sensors, fuse and x11-common should not run from rcS.d, but from +the numeric runlevels. Today in Debian, there are around 115 init.d +scripts that are started from rcS.d/, and most of them should be moved +out. Do your package have one of them? Please help us make single +user and runlevel 1 better by moving it.</p> + +<p>Scripts setting up the screen, keyboard, system partitions +etc. should still be started from rcS.d/, but there is for example no +need to have the network enabled before the single user login prompt +is presented.</p> + +<p>As always, things are not so easy to fix as they sound. To keep +Debian systems working while scripts migrate and during upgrades, the +scripts need to be moved from rcS.d/ to rc2.d/ in reverse dependency +order, ie the scripts that nothing in rcS.d/ depend on can be moved, +and the next ones can only be moved when their dependencies have been +moved first. This migration must be done sequentially while we ensure +that the package system upgrade packages in the right order to keep +the system state correct. This will require some coordination when it +comes to network related packages, but most of the packages with +scripts that should migrate do not have anything in rcS.d/ depending +on them. Some packages have already been updated, like the sudo +package, while others are still left to do. I wish I had time to work +on this myself, but real live constrains make it unlikely that I will +find time to push this forward.</p> + + +