Language Selection

English French German Italian Portuguese Spanish

Puppy Linux: Your new best friend

Filed under
Linux

On occasion I have a need for a tiny, lightning fast Linux distribution to boot into in order to check various issues on a machine. Either that or I just don’t want to monkey around with someone else’ data. Either way, I will often grab for either a CD or flash drive containing my favorite “micro” distribution, Puppy Linux.

Puppy Linux is one of those distributions that you just might come to depend on and you will want to get to know the ins and outs of this little beauty. Why? It’s not a vanilla Linux distribution. Because of its size there are many tools that are used that might not be your average tool. There are so many ways Puppy Linux can help you out. But before that can happen, you will want to get to know Puppy Linux. In this introductory article, I will show you around Puppy so he can some day be your best friend.

What is Puppy Linux?




More in Tux Machines

LWN on Linux: LTS, API, Pointer Leaks and Linux Plumbers Conference (LPC)

  • Cramming features into LTS kernel releases
    While the 4.14 development cycle has not been the busiest ever (12,500 changesets merged as of this writing, slightly more than 4.13 at this stage of the cycle), it has been seen as a rougher experience than its predecessors. There are all kinds of reasons why one cycle might be smoother than another, but it is not unreasonable to wonder whether the fact that 4.14 is a long-term support (LTS) release has affected how this cycle has gone. Indeed, when he released 4.14-rc3, Linus Torvalds complained that this cycle was more painful than most, and suggested that the long-term support status may be a part of the problem. A couple of recent pulls into the mainline highlight the pressures that, increasingly, apply to LTS releases. As was discussed in this article, the 4.14 kernel will include some changes to the kernel timer API aimed at making it more efficient, more like contemporary in-kernel APIs, and easier to harden. While API changes are normally confined to the merge window, this change was pulled into the mainline for the 4.14-rc3 release. The late merge has led to a small amount of grumbling in the community.
  • Improving the kernel timers API
    The kernel's timer interface has been around for a long time, and its API shows it. Beyond a lack of conformance with current in-kernel interface patterns, the timer API is not as efficient as it could be and stands in the way of ongoing kernel-hardening efforts. A late addition to the 4.14 kernel paves the way toward a wholesale change of this API to address these problems.
  • What's the best way to prevent kernel pointer leaks?
    An attacker who seeks to compromise a running kernel by overwriting kernel data structures or forcing a jump to specific kernel code must, in either case, have some idea of where the target objects are in memory. Techniques like kernel address-space layout randomization have been created in the hope of denying that knowledge, but that effort is wasted if the kernel leaks information about where it has been placed in memory. Developers have been plugging pointer leaks for years but, as a recent discussion shows, there is still some disagreement over the best way to prevent attackers from learning about the kernel's address-space layout. There are a number of ways for a kernel pointer value to find its way out to user space, but the most common path by far is the printk() function. There are on the order of 50,000 printk() calls in the kernel, any of which might include the value of a kernel pointer. Other places in the kernel use the underlying vsprintf() mechanism to format data for virtual files; they, too, often leak pointer values. A blanket ban on printing pointer values could solve this problem — if it could be properly enforced — but it would also prevent printing such values when they are really needed. Debugging kernel problems is one obvious use case for printing pointers, but there are others.
  • Continuous-integration testing for Intel graphics
    Two separate talks, at two different venues, give us a look into the kinds of testing that the Intel graphics team is doing. Daniel Vetter had a short presentation as part of the Testing and Fuzzing microconference at the Linux Plumbers Conference (LPC). His colleague, Martin Peres, gave a somewhat longer talk, complete with demos, at the X.Org Developers Conference (XDC). The picture they paint is a pleasing one: there is lots of testing going on there. But there are problems as well; that amount of testing runs afoul of bugs elsewhere in the kernel, which makes the job harder. Developing for upstream requires good testing, Peres said. If the development team is not doing that, features that land in the upstream kernel will be broken, which is not desirable. Using continuous-integration (CI) along with pre-merge testing allows the person making a change to make sure they did not break anything else in the process of landing their feature. That scales better as the number of developers grows and it allows developers to concentrate on feature development, rather than bug fixing when someone else finds the problem. It also promotes a better understanding of the code base; developers learn more "by breaking stuff", which lets them see the connections and dependencies between different parts of the code.

An update on GnuPG

The GNU Privacy Guard (GnuPG) is one of the fundamental tools that allows a distributed group to have trust in its communications. Werner Koch, lead developer of GnuPG, spoke about it at Kernel Recipes: what's in the new 2.2 version, when older versions will reach their end of life, and how development will proceed going forward. He also spoke at some length on the issue of best-practice key management and how GnuPG is evolving to assist. It is less than three years since attention was focused on the perilous position of GnuPG; because of systematic failure of the community to fund its development, Koch was considering packing it all in. The Snowden revelations persuaded him to keep going a little longer, then in the wake of Heartbleed there was a resurgent interest in funding the things we all rely on. Heartbleed led to the founding of the Core Infrastructure Initiative (CII). A grant from CII joined commitments from several companies and other organizations and an upsurge in community funding has put GnuPG on a more secure footing going forward. Read more

Ubuntu: GNOME, New Video, Ubuntu Podcast, Refreshing the Xubuntu Logo

  • Ubuntu 17.10: We're coming GNOME! Plenty that's Artful in Aardvark, with a few Wayland wails
    Ubuntu has done a good job of integrating a few plugins that improve GNOME's user experience compared to stock GNOME – most notably a modified version of the Dash-to-Dock and the App Indicator extensions, which go a long way toward making GNOME a bit more like Unity. It's worth noting that Ubuntu's fork of Dash-to-Dock lacks some features of the original, but you can uninstall the Ubuntu version in favour of the original if you prefer. In fact you can really revert to a pretty stock GNOME desktop with just a few tweaks. Canonical said it wasn't going to heavily modify GNOME and indeed it hasn't.
  • What’s New in Ubuntu 17.10 Artful Aardvark
  • Ubuntu Podcast: S10E33 – Aggressive Judicious Frame
    This week we’ve been protecting our privacy with LineageOS and playing Rust. Telegram get fined, your cloud is being used to mine BitCoin, Google announces a new privacy focused product tier, North Korea hacks a UK TV studio, a new fully branded attack vector is unveiled and Purism reach their funding goal for the Librem 5.
  • Refreshing the Xubuntu logo
    Earlier this year I worked a bit with our logo to propose a small change to it – first change to the logo in 5 years. The team approved, but for various reasons the new logo did not make it to 17.10. Now we’re ready to push it out to the world.

Intel Linux and GCC Work

  • Intel Begins Landing GFNI Support In GCC 8
    Intel compiler engineers have begun landing "GFNI" support within the GNU Compiler Collection as one of the new ISA extensions not expected until the Icelake processor debut.
  • Control-Flow Enforcement Technology Begins To Land In GCC 8
    Intel Control-flow Enforcement Technology (CET) support has begun landing within the GNU Compiler Collection (GCC) for this code safety feature. Patches have been in the works for several months while now the start of the patches are being merged to mainline. Coincidentally, at the same time Intel is also landing their GFNI instruction patches in GCC as well.
  • Intel Continues Landing New i915 DRM Features For Linux 4.15
    Jani Nikula has sent in another drm-intel-next update for David Airlie's DRM-Next tree. They continue prepping more updates to their Direct Rendering Manager (DRM) for targeting the upcoming Linux 4.15 cycle. There have already been several Intel "i915" DRM driver updates queued in DRM-Next for this new kernel version. Past pulls have included marking Coffeelake graphics as stable, continued Cannonlake "Gen 10" graphics enablement, various display improvements, and quite a lot of other low-level code improvements.