Language Selection

English French German Italian Portuguese Spanish

comparing "KDE 4" and "GNOME 3"

Filed under
KDE
Software

There is small trend currently to write a blog entry or article comparing "KDE 4" and "GNOME 3". Now, I'm not involved in the least with the GNOME 3 efforts (no big surprise there, I'm sure) so I can't and won't comment on what they are doing now or in the future (they can do so themselves quite well), but there are two interesting points I keep seeing raised that I really do want to address ... and I don't feel like commenting on every blog post out there. Wink

KDE 4 .. or the KDE Workspace?

What these blog entries are usually comparing is not "KDE 4" with "GNOME 3" but two of the KDE 4 workspace components, Plasma and KWin, with gnome-shell. Little more than that is compared in most of them when the topic is "KDE 4 or GNOME 3?". This is unfortunate because KDE 4 is a lot more than just the KDE Workspace, which is just one product that comes from KDE, just as GNOME 3 will be more than just gnome-shell.

A primary example is the KDE development platform. It consists of KDE's libraries built on top of Qt, Akonadi, Nepomuk/Strigi and others and represents one of the most important products we create. This platform started back in the 90s as a means to an end: getting the KDE desktop workspace functioning and sharing code and functionality efficiently between KDE apps in a way that guaranteed some consistency. These days, while it has kept this same set of purposes as an important part of its mission, the KDE development platform has taken on a much bigger role and a life of its own.

I'd love to see some thoughts that extend beyond Plasma/KWin out there and look at things such as the maturity of KDE's development platform compared to what others are offering right now or, as in the case of GNOME 3, in the near future.

Rest Here




Gnome 3

I sure hope Gnome developer don't mess up Gnome like the KDE developers did with KDE.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Openwashing: Facebook, Microsoft/Adobe and More

Hyperthreading From Intel Seen as Dodgy, Buggy

  • Intel Hyper Threading Performance With A Core i7 On Ubuntu 18.04 LTS
    Following the news yesterday of OpenBSD disabling Intel Hyper Threading by default within its OS over security concerns and plans to disable Simultaneous Multi Threading for other processors/architectures too, here are some fresh Intel HT benchmarks albeit on Ubuntu Linux. The OpenBSD developer involved characterized HT/SMT as "doesn't necessarily have a positive effect on performance; it highly depends on the workload. In all likelihood it will actually slow down most workloads if you have a CPU with more than two cores." So here are some benchmarks using a current-generation Intel Core i7 8700K six-core processor with Hyper Threading.
  • SMT Disabled by Default in -current
  • OpenBSD Will Disable Intel Hyper-Threading To Avoid Spectre-Like Exploits
    OpenBSD, an open source operating system that focuses on security, announced that it will disable Intel’s Hyper-Threading (HT) feature so that attackers can no longer employ Spectre-like cache timing attacks.
  • Intel’s hyperthreading blocked on OpenBSD amid hints of new Spectre-like bugs
    The maintainer of open source Unix-like operating system, OpenBSD, has announced that it will disable hyperthreading on Intel CPUs because of security concerns. It claims that simultaneous multithreading creates a potential new attack vector for Spectre-like exploits, and plans to expand its disabling of multithreading technologies to other chip manufacturers in the near future.

Programming/Development: ISO C++, Rust, FBGraphics and So-called 'DevOps'

  • Trip Report: C++ Standards Meeting in Rapperswil, June 2018
    A couple of weeks ago I attended a meeting of the ISO C++ Standards Committee (also known as WG21) in Rapperswil, Switzerland. This was the second committee meeting in 2018; you can find my reports on preceding meetings here (March 2018, Jacksonville) and here (November 2017, Albuquerque), and earlier ones linked from those. These reports, particularly the Jacksonville one, provide useful context for this post. At this meeting, the committee was focused full-steam on C++20, including advancing several significant features — such as Ranges, Modules, Coroutines, and Executors — for possible inclusion in C++20, with a secondary focus on in-flight Technical Specifications such as the Parallelism TS v2, and the Reflection TS.
  • Proposal for a staged RFC process
    I consider Rust’s RFC process one of our great accomplishments, but it’s no secret that it has a few flaws. At its best, the RFC offers an opportunity for collaborative design that is really exciting to be a part of. At its worst, it can devolve into bickering without any real motion towards consensus. If you’ve not done so already, I strongly recommend reading aturon’s excellent blog posts on this topic. The RFC process has also evolved somewhat organically over time. What began as “just open a pull request on GitHub” has moved into a process with a number of formal and informal stages (described below). I think it’s a good time for us to take a step back and see if we can refine those stages into something that works better for everyone. This blog post describes a proposal that arose over some discussions at the Mo
  • C gfx library for the Linux framebuffer with parallelism support
    FBGraphics was made to produce fullscreen pixels effects easily with non-accelerated framebuffer by leveraging multi-core processors, it is a bit like a software GPU (much less complex and featured!), the initial target platform is a Raspberry PI 3B and extend to the NanoPI (and many others embedded devices), the library should just work with many others devices with a Linux framebuffer altough there is at the moment some restrictions on the supported framebuffer format (24 bits).
  • 16 blogs and newsletters to follow for DevOps practitioners

Brave/Mozilla News

  • Deterministic Firefox Builds
    As of Firefox 60, the build environment for official Firefox Linux builds switched from CentOS to Debian. As part of the transition, we overhauled how the build environment for Firefox is constructed. We now populate the environment from deterministic package snapshots and are much more stringent about dependencies and operations being deterministic and reproducible. The end result is that the build environment for Firefox is deterministic enough to enable Firefox itself to be built deterministically.
  • Brave Launches User Trials for Opt-In Ads That Reward Viewers
    We’ve been busy building our new Basic Attention Token (BAT) platform, which includes a new consent-based digital advertising model that benefits users, publishers, and advertisers. Our first phase started last Fall with the integration of BAT into Brave Payments, and enabled users to anonymously distribute contributions to their favorite publishers and creators.
  • Get Paid For Watching Ads: Brave Browser Announces Opt-in Trials
    Brave, the web browser which garnered a huge fan following, predominantly for its ad blocking feature, and depriving advertisers of confiscating private data by blocking trackers is in the news again. And this time, users can earn some cash. In a blog post, Brave announced that it will be conducting voluntary testing of their new ad model in which they will showcase at least 250 pre-packaged ads to users who will sign up for their early access version. Thus, offering a small amount of money in the form of micropayments.