Language Selection

English French German Italian Portuguese Spanish

NimbleX 2007 - As the Name Implies...

Filed under
Linux
Reviews
-s

NimbleX is a small slackware-based distribution that made its way onto DistroWatch's Waiting List last September. While many on the list seem to stop development and disappear off the net, it appears NimbleX is progressing onward. Their site has undergone a recent update as well as their distro. NimbleX 2007 was released on Christmas Day and I decided it sounded like an interesting project to test. In NimbleX I found a wonderful candidate for your small linux needs.

To quote the site:

"NimbleX is a small but versatile operating system which is able to boot from a small 8 cm CD, from flash memory like USB pens or Mp3 players and even from the network. Because it runs entirely from a CD, USB or network it doesn't require installation or even much hardware.

Most of the advantages are related to the small size, the combination of software packages and a pretty good hardware support. You can easily carry it with you and with the right combination of parameters you can make it do some interesting stuff. NimbleX is very customizable and can be easily made to satisfy your needs."

Continuing in quoting:

Some of the most obvious things are:

  • Access data on other computers without knowing the pass.

  • Surf the Internet, download files using various protocols
  • Chat with friends using a very nice IM application
  • Play movies because most of the codecs are supported
  • Play music either in the graphical interface and the CLI
  • Make NimbleX always save you data very easily
  • Use the built-in BlueTooth support to transfer files
  • Use a pretty good office suite - KOffice 1.6.1
  • Get organized with a very powerful app. - Kontact !
  • Debug other operating systems with NimbleX
  • Back-up data easily using various methods.
  • Make NimbleX boot on other computers over the LAN
  • Play some of the various KDE Games
  • Install software over the Internet using GSlapt
  • Control remotely Windows machines with rdesktop
  • Browse Windows networks with no complications
  • Read PDF documents with the built-in software
  • NimbleX can be made to boot form anything bootable
  • NimbleX can be very fast if you boot it from HDD / USB
  • You can use several graphical interfaces (KDE, IceWM, Fluxbox)
  • The command line has the most common commands so...
  • Extend NimbleX easily by adding new modules to it:
    • Firefox 2
    • Opera 9.1
    • GIMP
    • Gaim
    • NVidia 3D Drivers
    • EMU
    • Xara LX
    • KTorrent
    • KMobileTools
    • KOffice - full
    • KDE Web Dev
    • Bluefish
    • ISO Master

Recommended Requirements are:

  • CLI
    • Pentium II or better
    • 128 MB
  • GUI
    • Pentium III or better
    • 512 MB

Minimum:

  • CLI
    • Pentium or better
    • 64 MB
  • GUI
    • Pentium II or better
    • 128 MB

I didn't have a low spec machine on which to test NimbleX, so I tested it on my usual desktop and my newly acquired laptop. The grub splash screen kinda reminds me of one openSUSE used to use, but it's updated and customized. It has several boot option such as Boot into KDE, Boot to Commandline, or KDE in limba romana. The rest of the boot is in text mode and the next graphic seen is the customized KDE splash screen. The boot process itself isn't particularly speedy, but it's acceptable.

        

At the desktop one finds an original background of off-white with a large glossy gray X. I thought it was fairly nice in that it's not gaudy and does reflect the current system somewhat. If that background doesn't suit you, there are about 7 or 8 other original nimbleX wallpapers included in several tasteful colors. Although, it seems the developers or their graphic artists are partial to black and white (or off-white and gray).

The menus aren't exactly chocked full of applications, but it's sufficient to do most of your daily tasks. However, considering the download size of 200 mb (on the nose), one wonders how they managed to include KDE, not to mention the other apps. KDE may be slimmed down to meet this size requirement, but I didn't find a whole lot missing. There are even a few screensavers present. Large applications like OpenOffice.org and Firefox are not included, but it does of course have Konqueror and it does include Koffice.

        

Some of the other included applications are Kopete, MPlayer, Juk, K3b, tvtime, Transmission (a bittorrent client), Kasablanca (ftp client), Nmap, Kontact, and several games. I found all applications tested to function very well. I had no problems with any of them. Most opened very quickly as well. One extra of note is the multimedia support included. NimbleX had no trouble playing any of the media files asked of it.

        

If one is in need of other software, one can "extend" NimbleX with modules as similarly found in Slax. They have modules for many of the most popular applications today like OpenOffice.org, Firefox, and Gimp. They even have a module for the Nvidia 3D drivers. See above for the full list. In addition, Gslapt is included. There are several software repositories already set up and I had no problems installing a few test packages.

        

As I ran through the KDE Control Center and tested the included applications I became more and more impressed. If nothing else sets NimbleX apart from the crowd, the shear performance of their system should. This has got to be the fastest implementation of KDE I've ever experienced. I don't know how they did it, but they did it. That thing is just blazing fast. I've never seen anything like it. It made me wish I had an old machine laying around on which to test it.

NimbleX runs on a 2.6.16 kernel and uses Xorg 6.9.0. The KDE version included is 3.5.4, but that's not too bad considering 3.5.6 was just tagged yesterday.

Hardware detection was acceptable. Most of my hardware was detected and a start up sound greeted me on both the desktop and laptop. The desktop boots to a 1024x768 screen using vesa. My tv card is incorrectly configured (as all Linux distributions do) and my printer is detected. My scanner was completely ignored. My network card was detected and internet connectivity was available upon boot.

On my laptop the graphics were also set up to be 1024x768, while 1200x800 is desired. As stated, sound worked. The battery monitor and power saver seemed to work fine. The touchpad responded immediately and accurately. However, despite having Kwifimanager and Wireless Assistant in the menu, I wasn't able to get my wireless card working. Ndiswrapper seemed to install the driver, but using the ndiswrapper module left an error in the logs and no wlan (or other) device appeared. Of course this is a Broadcom 4311 card, and it only works in about 1/2 the distros I've tried. Those with natively supported cards should be much happier, given the included gui apps.

NimbleX mounts all detected partitions during boot. I also didn't find a hard drive installer. However, there are instructions for manual installation on the NimbleX site. Those instructions are sparce and not very newbie friendly.

In the end I still really liked NimbleX on my desktop machine from the livecd. It was cool looking, performed well above average, with acceptable software and hardware support. The harddrive install seems like too much trouble for me in these fast paced times, but the system fits on one of those small 8cm cdroms and would be wonderful to carry along for any livecd purpose. It might be similar to Slax in some ways, but I think it distinguishes itself by coming in such a small package and delivering awesome performance. NimbleX is accurately named.

NimbleX Homepage
Download NimbleX
NimbleX Manual

Their Screenshots

My Screenshots

Small Distros

As Texstar has proven with PCLinuxOS, and Warren Woodford with Mepis, it is still possible for the little startup/hobby distros to grow into real prominence and mingle and compete with the for-profit/heavily-subsidized distros. I love this dynamic variety.

Will NimbleX become one of the biggies? Who knows? But thanks, Susan, for showcasing another beginning distro.

Comment viewing options

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

More in Tux Machines

KDE: Linux and Qt in Automotive, KDE Discover, Plasma5 18.01 in Slackware

  • Linux and Qt in Automotive? Let’s meet up!
    For anyone around the Gothenburg area on Feb 1st, you are most welcome to the Automotive MeetUp held at the Pelagicore and Luxoft offices. There will be talks about Qt/QML, our embedded Linux platform PELUX and some ramblings about open source in automotive by yours truly ;-)
  • What about AppImage?
    I see a lot of people asking about state of AppImage support in Discover. It’s non-existent, because AppImage does not require centralized software management interfaces like Discover and GNOME Software (or a command-line package manager). AppImage bundles are totally self-contained, and come straight from the developer with zero middlemen, and can be managed on the filesystem using your file manager This should sound awfully familiar to former Mac users (like myself), because Mac App bundles are totally self-contained, come straight from the developer with zero middlemen, and are managed using the Finder file manager.
  • What’s new for January? Plasma5 18.01, and more
    When I sat down to write a new post I noticed that I had not written a single post since the previous Plasma 5 announcement. Well, I guess the past month was a busy one. Also I bought a new e-reader (the Kobo Aura H2O 2nd edition) to replace my ageing Sony PRS-T1. That made me spend a lot of time just reading books and enjoying a proper back-lit E-ink screen. What I read? The War of the Flowers by Tad Williams, A Shadow all of Light by Fred Chappell, Persepolis Rising and several of the short stories (Drive, The Butcher of Anderson Station, The Churn and Strange Dogs) by James SA Corey and finally Red Sister by Mark Lawrence. All very much worth your time.

GNU/Linux: Live Patching, Gravity of Kubernetes, Welcome to 2018

  • How Live Patching Has Improved Xen Virtualization
    The open-source Xen virtualization hypervisor is widely deployed by enterprises and cloud providers alike, which benefit from the continuous innovation that the project delivers. In a video interview with ServerWatch, Lars Kurth, Chairman of the Xen Project Advisory Board and Director, Open Source Solutions at Citrix, details some of the recent additions to Xen and how they are helping move the project forward.
  • The Gravity of Kubernetes
    Most new internet businesses started in the foreseeable future will leverage Kubernetes (whether they realize it or not). Many old applications are migrating to Kubernetes too. Before Kubernetes, there was no standardization around a specific distributed systems platform. Just like Linux became the standard server-side operating system for a single node, Kubernetes has become the standard way to orchestrate all of the nodes in your application. With Kubernetes, distributed systems tools can have network effects. Every time someone builds a new tool for Kubernetes, it makes all the other tools better. And it further cements Kubernetes as the standard.
  • Welcome to 2018
    The image of the technology industry as a whole suffered in 2017, and that process is likely to continue this year as well. That should lead to an increased level of introspection that will certainly affect the free-software community. Many of us got into free software to, among other things, make the world a better place. It is not at all clear that all of our activities are doing that, or what we should do to change that situation. Expect a lively conversation on how our projects should be run and what they should be trying to achieve. Some of that introspection will certainly carry into projects related to machine learning and similar topics. There will be more interesting AI-related free software in 2018, but it may not all be beneficial. How well will the world be served, for example, by a highly capable, free facial-recognition system and associated global database? Our community will be no more effective than anybody else at limiting progress of potentially freedom-reducing technologies, but we should try harder to ensure that our technologies promote and support freedom to the greatest extent possible. Our 2017 predictions missed the fact that an increasing number of security problems are being found at the hardware level. We'll not make the same mistake in 2018. Much of what we think of as "hardware" has a great deal of software built into it — highly proprietary software that runs at the highest privilege levels and which is not subject to third-party review. Of course that software has bugs and security issues of its own; it couldn't really be any other way. We will see more of those issues in 2018, and many of them are likely to prove difficult to fix.

Linux Kernel Development

  • New Sound Drivers Coming In Linux 4.16 Kernel
    Due to longtime SUSE developer Takashi Iwai going on holiday the next few weeks, he has already sent in the sound driver feature updates targeting the upcoming Linux 4.16 kernel cycle. The sound subsystem in Linux 4.16 sees continued changes to the ASoC code, clean-ups to the existing drivers, and a number of new drivers.
  • Varlink: a protocol for IPC
    One of the motivations behind projects like kdbus and bus1, both of which have fallen short of mainline inclusion, is to have an interprocess communication (IPC) mechanism available early in the boot process. The D-Bus IPC mechanism has a daemon that cannot be started until filesystems are mounted and the like, but what if the early boot process wants to perform IPC? A new project, varlink, was recently announced; it aims to provide IPC from early boot onward, though it does not really address the longtime D-Bus performance complaints that also served as motivation for kdbus and bus1. The announcement came from Harald Hoyer, but he credited Kay Sievers and Lars Karlitski with much of the work. At its core, varlink is simply a JSON-based protocol that can be used to exchange messages over any connection-oriented transport. No kernel "special sauce" (such as kdbus or bus1) is needed to support it as TCP or Unix-domain sockets will provide the necessary functionality. The messages can be used as a kind of remote procedure call (RPC) using an API defined in an interface file.
  • Statistics for the 4.15 kernel
    The 4.15 kernel is likely to require a relatively long development cycle as a result of the post-rc5 merge of the kernel page-table isolation patches. That said, it should be in something close to its final form, modulo some inevitable bug fixes. The development statistics for this kernel release look fairly normal, but they do reveal an unexpectedly busy cycle overall. This development cycle was supposed to be relatively calm after the anticipated rush to get work into the 4.14 long-term-support release. But, while 4.14 ended up with 13,452 non-merge changesets at release, 4.15-rc6 already has 14,226, making it one of the busiest releases in the kernel project's history. Only 4.9 (16,214 changesets) and 4.12 (14,570) brought in more work, and 4.15 may exceed 4.12 by the time it is finished. So far, 1,707 developers have contributed to this kernel; they added 725,000 lines of code while removing 407,000, for a net growth of 318,000 lines of code.
  • A new kernel polling interface
    Polling a set of file descriptors to see which ones can perform I/O without blocking is a useful thing to do — so useful that the kernel provides three different system calls (select(), poll(), and epoll_wait() — plus some variants) to perform it. But sometimes three is not enough; there is now a proposal circulating for a fourth kernel polling interface. As is usually the case, the motivation for this change is performance. On January 4, Christoph Hellwig posted a new polling API based on the asynchronous I/O (AIO) mechanism. This may come as a surprise to some, since AIO is not the most loved of kernel interfaces and it tends not to get a lot of attention. AIO allows for the submission of I/O operations without waiting for their completion; that waiting can be done at some other time if need be. The kernel has had AIO support since the 2.5 days, but it has always been somewhat incomplete. Direct file I/O (the original use case) works well, as does network I/O. Many other types of I/O are not supported for asynchronous use, though; attempts to use the AIO interface with them will yield synchronous behavior. In a sense, polling is a natural addition to AIO; the whole point of polling is usually to avoid waiting for operations to complete.

Security: OpenSSL, IoT, and LWN Coverage of 'Intelpocalypse'

  • Another Face to Face: Email Changes and Crypto Policy
    The OpenSSL OMC met last month for a two-day face-to-face meeting in London, and like previous F2F meetings, most of the team was present and we addressed a great many issues. This blog posts talks about some of them, and most of the others will get their own blog posts, or notices, later. Red Hat graciously hosted us for the two days, and both Red Hat and Cryptsoft covered the costs of their employees who attended. One of the overall threads of the meeting was about increasing the transparency of the project. By default, everything should be done in public. We decided to try some major changes to email and such.
  • Some Basic Rules for Securing Your IoT Stuff

    Throughout 2016 and 2017, attacks from massive botnets made up entirely of hacked [sic] IoT devices had many experts warning of a dire outlook for Internet security. But the future of IoT doesn’t have to be so bleak. Here’s a primer on minimizing the chances that your IoT things become a security liability for you or for the Internet at large.

  • A look at the handling of Meltdown and Spectre
    The Meltdown/Spectre debacle has, deservedly, reached the mainstream press and, likely, most of the public that has even a remote interest in computers and security. It only took a day or so from the accelerated disclosure date of January 3—it was originally scheduled for January 9—before the bugs were making big headlines. But Spectre has been known for at least six months and Meltdown for nearly as long—at least to some in the industry. Others that were affected were completely blindsided by the announcements and have joined the scramble to mitigate these hardware bugs before they bite users. Whatever else can be said about Meltdown and Spectre, the handling (or, in truth, mishandling) of this whole incident has been a horrific failure. For those just tuning in, Meltdown and Spectre are two types of hardware bugs that affect most modern CPUs. They allow attackers to cause the CPU to do speculative execution of code, while timing memory accesses to deduce what has or has not been cached, to disclose the contents of memory. These disclosures can span various security boundaries such as between user space and the kernel or between guest operating systems running in virtual machines. For more information, see the LWN article on the flaws and the blog post by Raspberry Pi founder Eben Upton that well describes modern CPU architectures and speculative execution to explain why the Raspberry Pi is not affected.
  • Addressing Meltdown and Spectre in the kernel
    When the Meltdown and Spectre vulnerabilities were disclosed on January 3, attention quickly turned to mitigations. There was already a clear defense against Meltdown in the form of kernel page-table isolation (KPTI), but the defenses against the two Spectre variants had not been developed in public and still do not exist in the mainline kernel. Initial versions of proposed defenses have now been disclosed. The resulting picture shows what has been done to fend off Spectre-based attacks in the near future, but the situation remains chaotic, to put it lightly. First, a couple of notes with regard to Meltdown. KPTI has been merged for the 4.15 release, followed by a steady trickle of fixes that is undoubtedly not yet finished. The X86_BUG_CPU_INSECURE processor bit is being renamed to X86_BUG_CPU_MELTDOWN now that the details are public; there will be bug flags for the other two variants added in the near future. 4.9.75 and 4.4.110 have been released with their own KPTI variants. The older kernels do not have mainline KPTI, though; instead, they have a backport of the older KAISER patches that more closely matches what distributors shipped. Those backports have not fully stabilized yet either. KPTI patches for ARM are circulating, but have not yet been merged.
  • Is it time for open processors?
    The disclosure of the Meltdown and Spectre vulnerabilities has brought a new level of attention to the security bugs that can lurk at the hardware level. Massive amounts of work have gone into improving the (still poor) security of our software, but all of that is in vain if the hardware gives away the game. The CPUs that we run in our systems are highly proprietary and have been shown to contain unpleasant surprises (the Intel management engine, for example). It is thus natural to wonder whether it is time to make a move to open-source hardware, much like we have done with our software. Such a move may well be possible, and it would certainly offer some benefits, but it would be no panacea. Given the complexity of modern CPUs and the fierceness of the market in which they are sold, it might be surprising to think that they could be developed in an open manner. But there are serious initiatives working in this area; the idea of an open CPU design is not pure fantasy. A quick look around turns up several efforts; the following list is necessarily incomplete.
  • Notes from the Intelpocalypse
    Rumors of an undisclosed CPU security issue have been circulating since before LWN first covered the kernel page-table isolation patch set in November 2017. Now, finally, the information is out — and the problem is even worse than had been expected. Read on for a summary of these issues and what has to be done to respond to them in the kernel. All three disclosed vulnerabilities take advantage of the CPU's speculative execution mechanism. In a simple view, a CPU is a deterministic machine executing a set of instructions in sequence in a predictable manner. Real-world CPUs are more complex, and that complexity has opened the door to some unpleasant attacks. A CPU is typically working on the execution of multiple instructions at once, for performance reasons. Executing instructions in parallel allows the processor to keep more of its subunits busy at once, which speeds things up. But parallel execution is also driven by the slowness of access to main memory. A cache miss requiring a fetch from RAM can stall the execution of an instruction for hundreds of processor cycles, with a clear impact on performance. To minimize the amount of time it spends waiting for data, the CPU will, to the extent it can, execute instructions after the stalled one, essentially reordering the code in the program. That reordering is often invisible, but it occasionally leads to the sort of fun that caused Documentation/memory-barriers.txt to be written.