Language Selection

English French German Italian Portuguese Spanish

Four Flat Tires: Accelerated Knoppix

Filed under
Linux
Reviews
-s

Distrowatch says, "Japan's Alpha Systems has released Accelerated KNOPPIX 1.0, a fast-booting variant of the popular KNOPPIX live CD. By re-arranging the Cloop file system block and optimising the hardware detection and configuration step, the developers have succeeded in reducing the CD boot time to under 60 seconds, while maintaining the full functionality of the distribution. More details with illustrations of the technology" on their site. Whoohoo. To quote a famous American actor, "I feel the need, the need for speed!"

Before there was Super, before there was tuxmachines.org, even before there was PCLinuxOS, a good friend and I were always on the lookout for new techniques and methods for speeding up our systems. He was better at it than I, which is why he has his own distro now while I'm testing other's. But from parallel boot, compile options, to pre-linking, we would try about anything and send each other the results. When I saw the announcement for Accelerated Knoppix, I felt that old excitement rush back. Too bad it was short-lived.

My hardware is not exotic or bleeding-edge. It consists of a single-core 32-bit AMD Barton XP 2800+ sitting on a MSI KT4AV with 1 gig of Kingston ddr400 ecc ram. My add-in cards include a sound blaster live 5.1, BMG nvidia 6800oc video card, and a Prolink pixelview tv/radio card. My drives are your basic run-of-the-mill ata.

The boot screen has a customized splash with the instructions to use F2 and F3 for booting options. The only option I chose was lang=us and started timing when I hit enter. It took 2 1/2 minutes to get to a wallpapered background and hear the familiar knoppix, "Initiating Start Sequence" announcement. It took 6 more minutes before KDE was fully up and usable. Clicking on the Kmenu button took another 30 to 45 seconds before the menu appeared.

        

        

Having the wind taken out of my sails, I looked around just a bit. As you can see Accelerated Knoppix places icons on the desktop for each and every device it finds. There was no turning them off as it apparently isn't a kde function on their desktop. The menus seem chocked full of applications, but the menu was slow to respond and what I can only describe as "jerky" in operation. Applications were slow to open as well. Otherwise it seemed pretty much like the standard Knoppix fare to me.

        

        

There appears to be some documentation included in an Accelerated Knoppix folder on the desktop containing scripts that open pdf files probably describing some of their methods and techniques in Japanese. I had big plans of investigating and reporting on this topic, but with such poor performance, I lost interest. I have requests out to a few friends to test and will update this report if they have better luck. If you test and have better luck, please feel free to post. Perhaps there is something about my hardware with which Accelerated Knoppix had trouble. But for me in my mind, they still have work to do before this distro satisfies my deep seeded need for speed.

        

More in Tux Machines

Programming Leftovers: LibreOffice, KDE, and More

  • Nibble Stew: Building a part of LibreOffice on Windows using only Meson and WrapDB

    In earlier posts (starting from this one) I ported LibreOffice's build system to Meson. The aim has not been to be complete, but to compile and link the main executables. On Linux this is fairly easy as you can use the package manager to install all dependencies (and there are quite a few of them). [...] It does on my machine. It probably won't do so on yours. Some of the deps I used could not be added to WrapDB yet or are missing review. If you want to try, the code is here. The problematic (from a build system point of view) part of compiling an executable and then running it to generate source code for a different target works without problems. In theory you should be able to generate VS project files and build it with those, but I only used Ninja because it is much faster.

  • Regression fix: Missing lines in docx

    Interoperability is a very important aspect of the LibreOffice. Today, LibreOffice can load and save various file formats from many different office applications from different companies across the world. But bugs (specially regression bugs) are inevitable parts of every software. There are situations where the application does not behave as it should, and a developer should take action and fix it, so that it will behave according to the expectation of the user. What if you encounter a bug in LibreOffice, and how does a developer fix the problem? Here we discuss the steps needed to fix a bug. In the end, we provide a test and make sure that the same problem does not happen in the future. [...] The bug reporter should carefully describe the “actual results” and why it is different from the “expected results”. This is also important because the desired software’s behavior is not always as obvious as it seems to be for the bug reporter. Let’s talk about a recently fixed regression bug: The “NISZ LibreOffice Team” reported this bug. The National Infocommunications Service Company Ltd. (NISZ) has an active team in LibreOffice development and QA.

  • Beginning with Season of KDE 2022 - post #1

    I usually learn something between semesters when I have holidays. During September - October 2021, I tried learning some Qt and looking around codebase for KDE apps. But something just didn't work out. I suspect my leaning style wasn't correct.

  • KDE Gear 22.04 release schedule finalized

    It is available at the usual place https://community.kde.org/Schedules/KDE_Gear_22.04_Schedule Dependency freeze is in six weeks (March 10) and Feature Freeze a week after that, make sure you start finishing your stuff!

  • Python sets, frozensets, and literals

    A Python "frozenset" is simply a set object that is immutable—the objects it contains are determined at initialization time and cannot be changed thereafter. Like sets, frozensets are built into the language, but unlike most of the other standard Python types, there is no way to create a literal frozenset object. Changing that, by providing a mechanism to do so, was the topic of a recent discussion on the python-ideas mailing list. [...] In the end, this "feature" would not be a big change, either in CPython, itself, or for the Python ecosystem, but it would remove a small wart that might be worth addressing. Consistency and avoiding needless work when creating a literal frozenset both seem like good reasons to consider making the change. Whether a Python Enhancement Proposal (PEP) emerges remains to be seen. If it does, no major opposition arises, and the inevitable bikeshed-o-rama over its spelling ever converges, it just might appear in an upcoming Python—perhaps even Python 3.11 in October.

  • Terraform For Each Loop Examples - buildVirtual

    The Teraform for each meta argument allows you to use a map or a set of strings to deploy multiple similar objects (such as virtual machines) without having to define a separate resource block for each one. This is great for making our Terraform plans more efficient! Note: for_each was added in Terraform 0.12.6, and support for using it with Terraform modules was added in 0.13. Let’s go straight into looking at some examples of how to use Terraform for each loops.

  • Strange Computer Languages: A Hacker’s Field Guide | Hackaday

    Why do we build radios or clocks when you can buy them? Why do we make LEDs blink for no apparent purpose? Why do we try to squeeze one extra frame out of our video cards? We don’t know why, but we do. That might be the same attitude most people would have when learning about esolangs — esoteric programming languages — we don’t know why people create them or use them, but they do. We aren’t talking about mainstream languages that annoy people like Lisp, Forth, or VBA. We aren’t talking about older languages that seem cryptic today like APL or Prolog. We are talking about languages that are made to be… well… strange.

  • Perl Weekly Challenge 149: Fibonacci Digit Sum and Largest Square
  • My Favorite Warnings: precedence | Tom Wyant [blogs.perl.org]

    Perl possesses a rich and expressive set of operators. So rich, in fact, that other adjectives can come to mind, such as prolix, or even Byzantine. Requests for help navigating Perl's operator space appear repeatedly on outlets such as PerlMonks. These seem to me to involve two sorts of confusion: precedence (discussed here) and functionality (string versus numeric -- maybe another blog post). The precedence warnings category has some help here, though as of Perl 5.34 there are only two diagnostics under it:

  • Niko Matsakis: Panics vs cancellation, part 1

    One of the things people often complain about when doing Async Rust is cancellation. This has always been a bit confusing to me, because it seems to me that async cancellation should feel a lot like panics in practice, and people don’t complain about panics very often (though they do sometimes). This post is the start of a short series comparing panics and cancellation, seeking after the answer to the question “Why is async cancellation a pain point and what should we do about it?” This post focuses on explaining Rust’s panic philosophy and explaining why I see panics and cancellation as being quite analogous to one another.

Linux Foundation and OSI Leftovers (Openwashing PR)

  • Why you want labels for software, just like for food

    Here is my own synthesis, as simple as possible, of a much geekier post about a very geeky concept that, in an age where so much depends on how software is used AROUND you, becomes every year more important for everybody. A Software Bill of Materials (SBOM) is becoming an increasingly expected requirement from software releases. Reading through blog posts and social media, there still seems that some confusion persists about what an SBOM can/could do for your project.

  • The Linux Foundation makes record progress in addressing talent shortages

    The Linux Foundation summarises the progress made in 2021 towards its goal of ensuring anyone can start an open-source technology career.

  • EV charging software goes open source with Project Everest [Ed: There is no such this as "the Linux open-source foundation"; this is greenwashing and openwashing all-in-one]

    The development and expansion of the EV charging software ecosystem is a critical component to the mainstream adoption of electric vehicles. However, the industry has become complex and fragmented, with multiple isolated solutions and inconsistent technology standards. This slows and threatens the adoption of EVs. In response, PIONIX has developed a project called EVerest, an open-source software stack designed to establish a common base layer for a unified EV charging ecosystem. EVerest has gained some serious cred in the developer world, with its biggest support LF Energy (the Linux open-source foundation for the power systems sector). I spoke to the project’s brainchild, Dr. Marco Möller, managing director of PIONIX, to find out more.

  • Spotlight on Libre Space Foundation, OSI Associate Member

    Did you know that one of OSI’s members is leading the effort to take open source to infinity and beyond?! Libre Space Foundation (LSF) is a non-profit foundation registered in Greece whose vision is “an Open and Accessible Outer Space for all.” The organization works to promote, advance and develop free and open source technologies and knowledge for space. Recently, Libre Space Foundation, on behalf of the OpenSatCom.org activity of the European Space Agency, partnered with Inno3 to investigate open source development models in the satellite communications industry and share their findings in a report. As the authors explain, “..the SATCOM industry has been traditionally multiple vertical ecosystems and moved towards some standardization (through efforts like CCSDS, ECSS, DVB, etc.) on various of its parts. Yet it is far from an Open Ecosystem and specific actions should be taken to explore this direction for the benefit of the SATCOM industry.”

In defense of NIR

Shortly after I joined the Mesa team at Intel in the summer of 2014, I was sitting in the cube area asking Ken questions, trying to figure out how Mesa was put together, and I asked, “Why don’t you use LLVM?” Suddenly, all eyes turned towards Ken and myself and I realized I’d poked a bear. Ken calmly explained a bunch of the packaging/shipping issues around having your compiler in a different project as well as issues radeonsi had run into with apps bundling their own LLVM that didn’t work. But for the more technical question of whether or not it was a good idea, his answer was something about trade-offs and how it’s really not clear if LLVM would really gain them much. That same summer, Connor Abbott showed up as our intern and started developing NIR. By the end of the summer, he had a bunch of data structures a few mostly untested passes, and a validator. He also had most of a GLSL IR to NIR pass which mostly passed validation. Later that year, after Connor had gone off to school, I took over NIR, finished the Intel scalar back-end NIR consumer, fixed piles of bugs, and wrote out-of-SSA and a bunch of optimization passes to get it to the point where we could finally land it in the tree at the end of 2014. Initially, it was only a few Intel folks and Emma Anholt (Broadcom, at the time) who were all that interested in NIR. Today, it’s integral to the Mesa project and at the core of every driver that’s still seeing active development. Over the past seven years, we (the Mesa community) have poured thousands of man hours (probably millions of engineering dollars) into NIR and it’s gone from something only capable of handling fragment shaders to supporting full Vulkan 1.2 plus ray-tracing (task and mesh are coming) along with OpenCL 1.2 compute. Was it worth it? That’s the multi-million dollar (literally) question. 2014 was a simpler time. Compute shaders were still newish and people didn’t use them for all that much more than they would have used a fancy fragment shader for a couple years earlier. More advanced features like Vulkan’s variable pointers weren’t even on the horizon. Had I known at the time how much work we’d have to put into NIR to keep up, I may have said, “Nah, this is too much effort; let’s just use LLVM.” If I had, I think it would have made the wrong call. Read more

Databases: MongoDB/NoSQL, Firebird, and Rqlite/SQLite

  • Top 10 features of MongoDB Atlas | FOSS Linux

    MongoDB is a NoSQL general-purpose document-oriented database that is free to use. It is a scalable, versatile NoSQL document database platform built to overcome the constraints of previous NoSQL solutions and the approach of relational databases. It helps the user store and deals with an enormous amount of data. MongoDB’s horizontal scaling and load balancing capabilities have given application developers unprecedented flexibility and scalability. There are different MongoDB editions; however, we will focus on MongoDB Atlas in this article. MongoDB Atlas is a multi-cloud database service created by the MongoDB team. Atlas makes it easy to deploy and manage databases while also giving users the flexibility they need to develop scalable, high-performance global applications on the cloud providers of their choice. It is the world’s most popular cloud database for modern applications. Developers can use Atlas to deploy fully managed cloud databases on AWS, Azure, or Google Cloud. Developers can relax easily knowing that they have rapid access to the availability, scalability, and compliance they need for enterprise-level application development.

  • Node-firebird-driver-native version 2.4.0 has been released with a few features added.

    Node-firebird-driver-native version 2.4.0 has been released with a few features added.

  • Rqlite 7.0 Released For Distributed Relational Database Built Atop SQLite - Phoronix

    Rqlite 7.0 is now available as a lightweight, distributed relational database. This open-source database system for cluster setups is built atop SQLite while aiming to be easy-to-use and fault-tolerant.