Linux

I tried to make a very ordinary Plasma panel today: application launcher on the left, task list in the middle, clock and tray on the right, two rows high. The exciting new desktop framework objected chiefly to the phrase “two rows high.”

My naive attempt was to unlock widgets and drag everything until the intended geometry emerged. Instead, spacers collapsed, the task list consumed surprising amounts of space, and a widget escaped onto the desktop. Locking widgets prevented accidents but also concealed the controls I needed. The panel toolbox and I are no longer exchanging holiday cards.

The underlying Plasma idea remains compelling. Applets are not written solely for one fixed panel. A containment provides an environment, and a widget can adapt its presentation to a desktop or panel form factor. Data engines separate obtaining information from drawing it, which should stop every clock, weather display and device monitor from inventing its own polling machinery.

The current limitation is that abstraction has advanced farther than ordinary control. Layout negotiation needs better constraints and better feedback. A widget may technically adapt to a narrow panel while becoming practically useless. Removing a panel or moving an applet should be easy to undo. Multi-screen behavior also needs to preserve placement reliably; a temporary display change should not redecorate the entire desktop by surprise.

I had better results after creating a fresh panel, adding the expanding task list first, and placing fixed-size widgets around it. That is a workaround, not a discoverable interaction. The framework knows which item expands, but the user receives little explanation of why dragging another item does nothing.

Plasma’s spectacular jobs, such as transformed widgets and alternative containments, demonstrate the architecture. Its success will depend on boring jobs: stable panel sizing, predictable alignment, keyboard access, recovery from mistakes and sensible behavior when a screen disappears.

My practical conclusion is to keep the panel simple and lock it once arranged. I am optimistic about Plasma, but novelty does not excuse friction in actions performed every day. A desktop earns trust by remembering where the clock was. Rotating the clock is strictly optional.

I opened a long PDF in Okular today, searched for a phrase, added a note, and then printed three selected pages. The first three actions worked well. The printer produced pages two through four instead of the pages I thought I had selected.

My naive response was to repeat the job with different numbers. That merely consumed more paper, proving that printers remain the most effective mechanism for converting uncertainty into physical objects.

The confusion came from document page labels not matching the PDF’s internal page sequence. The introduction uses roman numerals, while the print dialog expects physical page positions. Okular displays both pieces of information in different contexts, but the distinction is too easy to miss when acting quickly.

As a viewer, Okular is already a substantial improvement over keeping separate programs for PDF and other document types. Search, text selection and navigation feel consistent because the shell supplies them while backends handle formats. That mechanism also exposes limitations: a backend may render well but lack annotations, forms or reliable printing details.

Annotations are useful, but I would not treat them as safely embedded in every source document without checking how that format stores them. Exporting or sharing a marked document deserves a test copy first.

My practical conclusion is to verify page labels in print preview and keep original documents untouched until annotation behavior is clear. Okular has become my default viewer, but “default” does not mean “incapable of surprising me.” That title remains permanently reserved for printing.

KDE 4.0 is out, so I installed the release packages and tried to conduct an ordinary day with them. I read mail, edited code, moved files and used a browser. By mid-afternoon I had also restarted Plasma and learned several new ways not to configure a panel.

My naive expectation was that the version number marked a direct successor to my mature KDE 3 desktop. I copied over habits even when settings could not be copied: right-click here, drag this there, expect every old control in approximately the old location. That turns 4.0 into a scavenger hunt it cannot win.

The candid result is mixed. Dolphin is quick and pleasantly focused for local file work. Okular opens the documents I need and gives them a consistent interface. KWin without ambitious effects is stable on this machine. Oxygen makes the applications look related, though a few small icons still require concentration.

Memory use is not alarmingly different in this limited test, although comparing young and mature sessions by one number would prove very little.

Plasma is the weak centre. Basic panel and desktop behavior works, but arranging widgets is awkward, configuration is thin, and occasional crashes make the entire workspace feel less reliable than the applications deserve. Some conveniences from KDE 3 simply are not present. Hardware integration and notifications also have visible seams.

This happens because 4.0 is not only a set of ported programs. Qt 4, new libraries, a new desktop shell, new hardware plumbing and revised applications all meet at once. The architecture creates room for future improvement, but users interact with current code, not future room.

I can use KDE 4.0 for testing and for a limited second session. I cannot recommend replacing a carefully tuned KDE 3 work environment yet. That is not a condemnation of the project; it is a description of my desk today.

The practical conclusion is to install with a clean user, keep important work elsewhere, and report narrow failures. KDE 4.0 shows enough of the intended system to be exciting, but the release number should not be mistaken for accumulated polish. Zero is a wonderfully round number. It is not a maturity metric.

After a driver update, newly opened windows sometimes became black under KWin’s OpenGL compositor. The same windows were fine with XRender. Turning off every effect changed nothing, which at least got the animations out of the suspect list.

The useful split was the texture-from-pixmap path. Under X11 compositing, the server redirects a window into a pixmap. KWin’s OpenGL path then uses the driver’s texture-from-pixmap support to bind that pixmap as a texture for the scene. XRender composites the pixmap through a different route. Applications had painted the right pixels; the OpenGL path was failing to present them.

I could make it happen by opening two terminals, covering one, and uncovering it. Damage arrived, but the exposed window stayed black or returned in strips. Switching to the previous driver fixed that exact sequence. The newer driver also behaved if I disabled its acceleration option, slowly.

That made a much better report than “KWin draws black windows.” I included the X server, Mesa, kernel and driver versions, the OpenGL backend, hardware identifiers, and the short cover/uncover sequence. I also noted that XRender worked. That last fact tells a driver developer far more than a screenshot of a black rectangle.

Screenshots were awkward: some captured the correct window even while the display showed black. The redirected pixmap could be fine while the texture or final scanout was stale. A camera photo was ugly but honest.

I am using XRender for normal work and keeping the failing setup available for testing. Reinstalling KWin would only replace the code that asks the driver to bind the same pixmap. The break is farther down the path, and now there is a reproducible way to reach it.

I created a KVM guest to test packages without sacrificing another partition. The installer booted, the guest saw a disk, and I congratulated myself until copying files inside it reduced the entire machine to sludge.

My first attempt was to add more guest memory and another virtual processor. The copy became no faster, while the host began swapping. This is a reliable way to make two operating systems unhappy with one setting.

KVM uses the processor’s virtualization extensions to run guest code directly in a special execution mode. That avoids translating every ordinary instruction, but devices are a different matter. The guest still talks to emulated hardware, and each operation may require work in the userspace machine emulator and the host kernel. My slow copy was dominated by the virtual disk path, not by a shortage of arithmetic.

Moving the guest image off the host’s busy system disk helped. Using a simpler virtual disk setup and avoiding unnecessary host caching also made behavior more consistent, though the safest setting depends on what guarantees the storage actually provides. I am not going to trade filesystem integrity for a prettier benchmark. The benchmark will not visit me in hospital.

Preallocating space also avoided some pauses caused by repeatedly extending a sparse image during installation.

Processor support also needs verification rather than assumption. The KVM modules must load, virtualization must be enabled by firmware, and the host kernel needs the appropriate architecture module. Once that path works, compute-heavy tasks can be surprisingly close to native speed. Graphics and storage remain much more obviously virtual.

For my package-testing guest, one virtual processor and enough memory to avoid guest swapping are sufficient. The host must retain enough memory for its own cache and applications. I now measure CPU, host disk activity and swapping separately before changing the virtual machine configuration.

KVM is already useful because it fits into Linux rather than requiring a separate host operating environment. It is not a declaration that every emulated device is free. My practical conclusion is to size the guest modestly and find the actual bottleneck. Adding virtual hardware to cure slow virtual I/O only creates a more lavishly furnished traffic jam.