Language Selection

English French German Italian Portuguese Spanish

June 2006

KDE Switches To CMake

Filed under
KDE

The KDE4 build system is now centered around CMake. If you are a developer, CMake will be much easier to learn, handle and maintain than what you are used to so far.

Portland Project betas common tools for GNOME, KDE

Filed under
Software

The Portland Project, the collaborative venture of Linux vendors and developers to simplify the process of porting and integrating applications for Linux desktops, has announced the beta release of its first application tools for the Linux desktop's GNOME and KDE environments.

The Office 2007 demo and Linux

Filed under
Linux

Have you wondered what's really behind Microsoft's web-based Office 2007 demo beta? I did, and what I found was more than a little interesting.

Kernels 2.6.17.2 and 2.6.17.3 released

Filed under
Linux

Linux 2.6.17.2 is out with: "Assorted fixes, see the diffstat and short summary of the fixes below." Linux 2.6.17.3 has also been released, it addresses: "Another SCTP remote crash fix, CVE-2006-2934."

More Details.

How Open Source Saved My Neck

Filed under
Misc

Though Microsoft might disagree, open source software in many cases can be a real cost saver. It can also save your neck. Literally.

Edgy sudoers file: syntax error

Filed under
HowTos

I lately updated my dapper box to edgy eft. Has edgy eft is unstable and had just been started up, it happens to get surprise. Today, update-manager stopped to work.

ratpoison

Filed under
Software

Well, I have used LOTS of window managers... KDE, Gnome, XFCE, FVWM, Windowmaker, etc... So recently I decided to try a new one, of a new kind to me: ratpoison.

GPL version 3 evaluation committees admit Stallman is ultimate 'decider'

Filed under
OSS

Evaluation committees are hard at work on the latest draft of the General Public License (GPLv3), but members of those groups say it will ultimately be up to one person to decide what the license will look like when it's finished in early 2007.

Switch to Ubuntu

Filed under
Ubuntu

Remember those “Switch” adverts from Apple? Well, the Switch is happening all over again. But this time people are switching away from Mac and onto Ubuntu.

Enterprise Unix Roundup: Digging in the Open Sandbox

Filed under
OS

While those of us here in the United States are getting ready for some serious holiday loafing-about next week, our friends across the pond are getting some work (and perhaps some schmoozing) done at the Open Source Business Conference (OSBC) Europe in London.

More in Tux Machines

Btrfs in Next Fedora

  • Btrfs by default, the compression option

    Hi, The change proposal has a 'compression option' and we kinda need to get organized. https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Compression - Compression saves space, significantly reduces write amplification and therefore increases flash lifespan, and in some cases increases performance. - Desired but not a requirement of the change proposal. 1. Goal: probably the goal performance wise is to perform as good or better than now. Is it OK if there's a write time performance hit for a small percent of folks, for a high value target like usr that isn't updated that often, and is also updated out of band (offline updates typically, but also isn't something directly related to the daily workload)? How to decide this? 2. Benchmarking: this is hard. A simple tool for doing comparisons among algorithms on a specific bit of hardware is lzbench. https://github.com/inikep/lzbench How to compile on F32. https://github.com/inikep/lzbench/issues/69 But is that adequate? How do we confirm/deny on a wide variety of hardware that this meets the goal? And how is this test going to account for parallelization, and read ahead? Do we need a lot of data or is it adequate to get a sample "around the edges" (e.g. slow cpu fast drive; fast cpu slow drive; fast cpu fast drive; slow cpu slow drive). What algorithm? 3. Improvements and upgrades. We'll do plan A, but learn new things later, and come up with plan B. How do we get the plan A folks upgraded to plan B? Or just don't worry? 4. The whole file system (using a mount option) or curated (using an XATTR set on specific "high value" directories)? This part is elaborated below. A. do this with a mount option '-o compress=zstd:1' - dilemma: it doesn't always lead to equal or better performance. On some systems and workloads, write performance is slightly reduced. What about LZO? B. do this with per directory XATTR - dilemma: the target directories don't exist at install time, depending on whether the installation is rsync, rpm, or unsquashfs based. C. do the install with '-o compres=zstd', then set XATTR post-install - dilemma: the installed files won't have XATTR set, only new files inherit; does a 'dnf update' overwrite files and therefore the XATTR is not inherited, or are they new files and do inherit the XATTR? D. Which directories? Some may be outside of the installer's scope. /usr /var/lib/flatpak ~/.local/share/flatpak /var/lib/containers/ ~/.local/share/containers/ ~/.var ~/.cache (Plausible this list should be reversed. While compressing ~/.cache may not save much space, it's likely hammered with more changes than other locations, hence more benefit in terms of reducing write amplification.) For reference, the above is mostly from the description in the RFE bug attached to the feature's tracker bug. But I think it's best to have most discussion here and leave the bug for implementing+testing the implementation details. https://bugzilla.redhat.com/show_bug.cgi?id=1851276 Thanks, -- Chris Murphy

  • Fedora Developers Evaluating Compression Options For Btrfs-By-Default Proposal

    The proposal for using Btrfs by default on the Fedora desktop is gaining a fair amount of traction and interest from the community and could possibly move ahead but further testing and decisions are still to be made. First of all, today marks a Fedora Btrfs test day for those wanting to help in evaluating this change proposal. Check it out if you have spare system(s) and interested in helping make the decision whether Fedora desktop spins should transition from EXT4 to Btrfs by default.

  • Btrfs to be the Default Filesystem on Fedora? Fedora 33 Starts Testing Btrfs Switch

    While we’re months away from Fedora’s next stable release (Fedora 33), there are a few changes worth keeping tabs on. Among all the other accepted system-wide changes for Fedora 33, the proposal of having Btrfs as the default filesystem for desktop variants is the most interesting one.

today's howtos

Btrfs Could be the Default Filesystem on Fedora Linux Starting With Fedora 33

If things go well, you’ll have Btrfs as the default filesystem on Fedora starting with the Fedora 33 release. Here are more details on this topic. Read more

Linux company SUSE outbids competitors for fast-growing start-up Rancher Labs

  • Linux company SUSE outbids competitors for fast-growing start-up Rancher Labs

    SUSE, a Linux distribution company controlled by private equity firm EQT, has agreed to acquire Rancher Labs, a start-up with technology that helps organizations run software in virtual containers across many servers. The companies announced the deal Wednesday but didn't disclose the terms. Two people familiar with the deal said SUSE is paying $600 million to $700 million. The transaction suggests that even during a recession, demand remains high for technology that can enable companies to operate more efficiently. Talks between the companies began in the spring, and the process became competitive with additional bids, Ursheet Parikh, a partner at Rancher backer Mayfield Fund, told CNBC on Tuesday. There were "lots of Zoom calls," Parikh said. In the past few years, with the rise of start-ups such as Docker, containers became a trendy alternative to more traditional virtualization technology for running applications on each computer server in a company data center. Amazon, Microsoft and other cloud providers came out with services that developers can use to place code in containers, and in 2017 SUSE introduced its own service for managing containers. The companies haven't finalized integration plans as the deal still faces regulatory approval.

  • SUSE to Acquire Rancher Labs, Creating World’s Largest Organization Exclusively Dedicated to Powering Digital Transformation With Open Source and Cloud Native Solutions

    Today, SUSE embarks on a new chapter in our incredible 28-year journey. I am thrilled to share that, SUSE has signed a definitive agreement to acquire Rancher Labs, a market-leading, Enterprise Kubernetes Management vendor based in Cupertino, California.    This is an incredible moment for SUSE and for our industry, as two open source leaders join forces to create the world’s largest independent organization dedicated exclusively to powering digital transformation with open source and cloud native solutions. I want to share my perspective on why we chose Rancher, and how this acquisition will benefit our customers, partners, and communities.