Just a quick nod to the OpenSuse team, which looks to have a great looking KDE desktop for their new 11.2 Release. Congratulations!
Now, about those changes to make Firefox integrate better with KDE — you'll be releasing those upstream to KDE for the inclusion to all distros, right? :D
=-=-=-=-=
Powered by Bilbo Blogger
I am a big fan of the KDE desktop but their current KDE 4.3.2 release is still missing tools that are required for a 'complete desktop experience', specifically for system administration tasks with a Graphical User Interface.
Reading around the web, there are many requests and suggestions about ways to improve the KDE Desktop. It is very important to note that KDE 3.5.x was years in development to get to the functionality and stability that the 3.5.x release had; KDE 4.3.2 has only been in development for a bit over two years and its capabilities are already very impressive.
KDE 4.3.2 may have an impressive list of capabilities, but the desktop isn't yet complete for those Point-and-Click types. Here is my wish list for the near future of KDE development, to allow full system administration within the GUI of KDE.
1. KDESudo access to saving files
I would love to be prompted for a sudo password when trying to edit a file which I have no write access to, such as if a desktop computer is going to be used for an application like Motion and the user doesn't know various command-line editors. Browsing to /etc/ and opening a file with Kate (or KWrite, or any app) should allow for read-only access, and prompt for a password if the user wants to edit and save that file.
2. Administrative Mode in System Settings
Various parts of System Settings require that the root user makes changes, such as for user auto-logins and for adding printers. I am not sure the status of this. Launching 'kdesudo systemsettings' allows a user to get around this, for now.
3. Printer setup tools
In Debian at least, printers can be added in KDE by launching 'kdesudo systemsettings' and then using the Printer Configuration module, assuming the user has installed the package 'system-config-printer-kde'. Access to this should be tied in with point number two, above. Also, any machine with CUPS (which is likely any Linux machine that prints) can set up printers in http://localhost:631 — but we all knew that one by heart, right?
4. User Account Tools
Adding users to a multi-user system like Linux is important, yet it is missing in KDE's System Settings. The application 'kuser' can be installed and launched with 'kdesudo kuser' but it isn't integrated into the System Settings as far as I can tell.
5. Services and Daemons
There should be an application to start/stop/setup system daemons that happen at boot; there is an addon located here which looks to do the job on Kubuntu, but this should be a standard module within System Settings, to allow a user to stop MySQL or to change when SSH is launched, etc.
6. FUSE File System Setups
The FUSE system is great; it allows users to mount a remote file system on their current setup, without needing root access that a regular filesystem mount needs.
For example, at home my Laptop gets its wireless signal and connects to my big computer's music collection, providing transparent streaming of my music to the laptop without having all of those files on the laptop itself. For someone familiar with the command line and mounting filesystems this is pretty easy; for a computer (or even Linux) newbie it isn't so clear what needs to be done.
I would really like a System Settings module which allows for certain file systems to be mounted at login depending on various conditions. For example, if my wireless access point is 'lefty@home' then my sshfs:/ and fusesmb:/ file systems should mount; if my access point is "corporation-WEP" when I am at work, then FUSE file systems which I have defined for my work needs should mount, etc.
7. Package installation integration
Using some software requires that additional packages are installed to make that first app work properly in certain situations. If I want to open a .doc file, for example, I would need OpenOffice or KOffice or some other application which can read the closed, binary Microsoft document format. If I try to open a .doc file and I have no applicable software available, KDE should offer a list of options and install the needed software (and not limit my options to KDE applications in the process).
8. Graphics setup configuration
Adding a second monitor to my home computer required setting up an XOrg config file (because Xorg doesn't use those by default any longer) and then defining a Virtual Desktop size that would be equal to, or larger than, the total resolution of my two monitors added together. I had to add this to my Screen section of my /etc/X11/xorg./conf file (completely outside of KDE), and the whole process isn't very intuitive:
SubSection "Display"
Viewport 0 0
Depth 24
Virtual 3048 2048
EndSubSection
KDE would do well to extend the capabilities of KRandR to allow these setups to work with minimal hassle to the end user, as well as to insert various modules into that xorg.conf file to allow for 3D rendering etc, regardless of the driver used (assuming the driver is capable of this with some module modifications). KRandR sits in the Tray of your plasma task bar, but it should be accessible within System Settings. There is a Disp[lay section with information about Multiple Monitors but it doesn't do anything to assist in the setup.
9. Hardware information
In KDE3 I could see my hardware, capabilities, and even the serial number of some of the hardware peripherals installed onto my computer. KDE4 could do this and so much more, but currently the Hardware module in System Settings only discusses software backends for HAL Power Management, for Networking, and for Bluetooth devices. Where is the information about my RAM? About my processor speed? This information is all inside KInfoCenter but there isn't a way to access that from System Settings. Granted, this is information and not something with settings, but it should still be within System Settings.
10. KDE4 Technologies need clarification
Akonadi? Nepomuk? If you're not a KDE user or developer these names mean nothing to you; as a KDE user I am still unsure what these do. They need more descriptive naming in the System Settings to describe what it is I am looking at. Don't call it Anokadi in system Settings; call it Anokadi Data Storage or whatever it does. Even Aaron Seigo, the KDE hacker, puts it this way in a recent post
Jargon Is Bad:
There's a lot more jargon in KDE, though: nepomuk (search service!), krandr (screen settings!), kwin compositing (desktop effects!), akonadi ... If we can keep the jargon out of what we see when using the software, it will help people immensely.
Notice even Aaron didn't tell us what Akonadi is? :D
All and all, I love KDE, its capabilities, its sensible defaults, its configurablity, its beauty, its speed... I just hope to see KDE 4 allow users to control their whole desktop better from an administrative perspective. Give it time, it will happen. The best part about KDE is that it keeps improving, by leaps and bounds.
Any Graphical Administration suggestions that readers can provide? Please, leave a comment, and enjoy your Free Software.
=-=-=-=-=
Powered by Bilbo Blogger
shell$ sudo m-a preparea-i) VirtualBox with Module Assistant:shell$ sudo m-a a-i virtualbox-ose-source
/etc/modules so that they auto load at boot time. Note that because I had the older kernel modules loaded, I am going to remove (-r) them first, and then load in the newly built modules:shell$ sudo modprobe -r vboxdrvshell$ sudo modprobe -r vboxnetfltshell$ sudo modprobe vboxdrvshell$ sudo modprobe vboxnetflt
I have a .deb file, where can I install it?
If the software package was compiled for Debian, I can install it on nearly any recent Debian release. Currently I have XTightVNCViewer installed with the Debian package release 1.2.9-21 (from the Stable branch) even though I run a Sid desktop, because this older package has functionality which isn't available in the Sid package at version 1.3.9-5. Other than some dependency resolutions, mixing Debian software branches (Stable, Testing, and Unstable) isn't recommended but it isn't difficult to do, and my experiences with it have been a rather stable setup when it needs to be done. (Let me repeat, this is not recommended nor supported). Debian releases infrequently enough that this mixing probably isn't needed much; if a package is still relevant there will be a new release for it.
Ubuntu came onto the scene a few years ago with the goal to release Debian Sid (Unstable) as a stabilized set of packages. Not to start a flame war, but Ubuntu's success in this has been questionable, depending on who you ask or your own experiences.
The repackaging of Debian was at first welcomed by many in the Debian community, but early into the project the Ubuntu developers forked and changed the way Debian works for their own distribution. This is Free Software and there is nothing wrong with that approach, although there has been much said about Ubuntu's contributions upstream.
With that split from Debian, however, came no split with the package manager or its tools. Ubuntu now requires separate package releases for each OS release; a quick stop at GetDeb.net shows that you have to search for your specific version of Ubuntu to find a package which will work for your setup. These aren't repositories to keep your software up-to-date like Debian is designed for; these are downloadable packages to be installed much like a Windows .exe file would be installed: download and double-click.
When SuSE Linux took the Red Hat package format, RPM, it led to the increase of Dependency Hell for RPM-based distributions. Red Hat, Suse, and Fedora all use RPM files but they're incompatible; without knowing which release and distribution a package was created for, that package is nearly useless and attempting to install it will lead to a failure or massive headaches when trying to resolve its dependencies. O perhaps it will just luckily work, all depending on the software and its complexity.
Ubuntu is doing the same to the .deb package format. Their frequent OS releases means that every package needs to be recompiled for that release. Applications downloaded from GetDeb.net or one of the many other Ubuntu-focused software sites may no longer work when the OS is upgraded; without a repository there is no way to upgrade the 3rd party packages. (Note: These sites provide a valuable service to the Ubuntu community, but seem to disregard Debian completely; the purpose of this Open Request is not to stop or deride these sites at all.)
Debian, on the other hand, has always used .deb files and has encouraged using software repositories for accessing new software and for keeping it up-to-date. While mixing Debian released packages from one OS release to the next isn't recommended or supported, it does work. Downloading individual .deb files for installation works but it isn't the recommended method. Perhaps mixing Ubuntu packages (from one release to the next) would work also, I am not sure.
But the real problem here is that Ubuntu is using the .deb package format and giving it both a bad name (due to dependency breakages), and its packages are named .deb but don't work on Debian, the very system that the packages were designed for.
With Ubuntu's frequent release cycle and with the nature of Free Software, the package management tools that Ubuntu uses (dpkg, apt, aptitude) should be modified to accept packages in a Ubuntu-specific package extension: .ubu files. This could happen at any release; perhaps after this next release it could be worked on, to be ready in time for the next LTR or even the next 'short term' release in order to give time for testing.
While the packages themselves may be internally identical to a .deb file, these .ubu files would specify that the packages are for Ubuntu and not for Debian. SuSE should have done that and didn't; Ubuntu doesn't have to make this same mistake. Debian users wouldn't have to be confused trying to know if a .deb file will work on their system or not. Ubuntu would get the great package management that Debian has but with better branding of their packages and software. Debian would have its branding as well, and perhaps both Debian and Ubuntu could still install one another's packages with unknown results, just as it is now.
The new .ubu files wouldn't impart any release info in their file names as they are; either the name itself could be 'packagename.904.ubu' or maybe the extension should specify the release, for example 'packagename.u904'. I don't have the answers to this, but naming separate distribution packages the same isn't helpful at all.
Ubuntu may be here to stay, but please, keep Debian's package extension .deb for Debian.
=-=-=-=-=
Powered by Bilbo Blogger
I had a hell of a time last night trying to capture video in KDEnlive, the great video editor.
It's not KDEnlive's fault that the Firewire stack is such a mess on Linux. My Debian Sid system seems to be using a new Firewire (ieee1394) stack that isn't complete or something. With some work I was able to get the Firewire control and capture working for our Panasonic video camera.
First I plugged in the camera and at a command prompt, ran 'dmesg' to give the recent list of kernel activity:
lefty@bigboi:~$ dmesg
Oct 5 23:48:11 bigboi kernel: firewire_core: rediscovered device fw0
Oct 5 23:48:11 bigboi kernel: firewire_core: phy config: card 0, new root=ffc2, gap_count=7
Oct 5 23:48:11 bigboi kernel: firewire_core: giving up on config rom for node id ffc0
Oct 5 23:48:11 bigboi kernel: firewire_core: skipped bus generations, destroying all nodes
Oct 5 23:48:12 bigboi kernel: firewire_core: rediscovered device fw0
Oct 5 23:48:12 bigboi kernel: firewire_core: phy config: card 0, new root=ffc2, gap_count=7
Oct 5 23:48:12 bigboi kernel: firewire_core: giving up on config rom for node id ffc0
Oct 5 23:48:12 bigboi kernel: firewire_core: skipped bus generations, destroying all nodes
Oct 5 23:48:12 bigboi kernel: firewire_core: skipped bus generations, destroying all nodes
Oct 5 23:48:12 bigboi kernel: firewire_core: giving up on config rom for node id ffc2
Oct 5 23:48:12 bigboi kernel: firewire_core: giving up on config rom for node id ffc0
Oct 5 23:48:12 bigboi kernel: firewire_core: giving up on config rom for node id ffc0
While my computer recognized the camera, it didn't seem to like it much and I am not sure why exactly. To get Firewire working, first I unloaded the modules (drivers) and then reloaded them:
lefty@bigboi:~$ sudo lsmod |grep fire
firewire_sbp2 14920 0
firewire_net 13728 0
firewire_ohci 23232 0
firewire_core 47360 3 firewire_sbp2,firewire_net,firewire_ohci
crc_itu_t 1884 1 firewire_core
scsi_mod 148496 5 firewire_sbp2,sg,sr_mod,sd_mod,libata
lefty@bigboi:~$ modprobe -r firewire_net
lefty@bigboi:~$ modprobe -r firewire_sbp2
lefty@bigboi:~$ modprobe -r firewire_ohci
lefty@bigboi:~$ modprobe -r firewire-core
lefty@bigboi:~$ modprobe firewire-ohci
lefty@bigboi:~$ modprobe firewire-net
lefty@bigboi:~$ modprobe firewire-sbp2
lefty@bigboi:~$ modprobe firewire-core
Now 'dmesg' has better information:
lefty@bigboi:~$ dmesg
Oct 5 23:49:42 bigboi kernel: firewire_ohci 0000:02:03.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Oct 5 23:49:42 bigboi kernel: firewire_ohci: Added fw-ohci device 0000:02:03.0, OHCI version 1.0
Oct 5 23:49:43 bigboi kernel: firewire_core: created device fw0: GUID 0011060000200a4a, S400
Oct 5 23:49:43 bigboi kernel: firewire_core: created device fw1: GUID 008045803173ad59, S100
I knew from the past that video capture in Kino and KDEnlive both use /dev/raw1394 rather than the device created above (/dev/fw0), and I also knew that I needed read access to that file /dev/whatever, so I addedmyself to the video group:
lefty@bigboi:~$ sudo adduser lefty video
The user `lefty' is already a member of `video'.
Had this been a new addition to that group, I would have had to log out and log back in for that change to take effect. Then, I changed the group for that file and gave group-read (and write, why not) permissions:
lefty@bigboi:~$ sudo chown :video /dev/fw0
lefty@bigboi:~$ sudo chmod g+rw /dev/fw0
Finally, I linked the new Firewire device to a location that I knew KDEnlive (which uses the dvgrab program, actually) would look for the video capture, /dev/raw1394 as I had stated:
lefty@bigboi:~$ sudo ln /dev/fw0 /dev/raw1394
Note that the above is *not* a symbolic link (not 'ln -s' ). This is a hard link which points to the exact device that I needed to access.
Now KDEnlive was able to capture fine, finally! Then I noticed that my battery was getting low from all of this work, so I had to unplug the camera to put in a new battery, causing all of the above work to fail. I had to redo it all but now that I knew what to do, it was much easier.
I hope this works for others and enjoy your video editing with KDEnlive!
=-=-=-=-=
Powered by Bilbo Blogger
