I've used finnix forever as my go to live recovery distro, and have never heard of knoppix.
From a cursory search, it appears that finnix is focused on the command line while knoppix provides a desktop environment. Don't most distros offer live boot environments these days? I know I've done this with Fedora, Debian, Suse, and Alpine at least..
Yeah, in my book (used Knoppix, never heard of or don't remember Finnix), Knoppix had 2 uses: restore systems but primarily try out if Linux worked on an unknown PC. And also run Linux on Windows PCs at school.
> On 23 October 2005, Finnix 86.0 was released. Earlier unreleased versions (84, and 85.0 through 85.3) were "Knoppix remasters", with support for Linux LVM and dm-crypt being the main reason for creation. However, 86.0 was a departure from Knoppix, and was derived directly from the Debian "testing" tree.[7]
My reading of this is that early versions of Finnix were based on Knoppix. However, according to the wikipedia sidebars, the initial release of Knoppix was 30 September 2000, while the initial release of Finnix was March 22, 2000. Something something beta/pre-release versions?
> Finnix 0.01 was based on Red Hat Linux 6.0, and was created to help with administration and recovery of other Linux workstations around Finnie's office.[citation needed] The first public release of Finnix was 0.03, and was released in early 2000, based on an updated Red Hat Linux 6.1.
If I had to venture a guess, I'd say compression. Knopper picked up and became maintainer of a kernel module called "cloop" that supports zlib-compressed loopback filesystems.
If Knoppix had this and Finnix didn't, or if Knopper was able to supply enhancements and bugfixes in order to support Knoppix releases, then he was likely able to fit a much more complete system onto a given CD or DVD.
But idk what kind of compression early Finnix used, if any. (Nowadays, everything uses SquashFS, right?)
Anyone have some recommendations for a live distro that can run from ram?
It'd be nice to have a live image that I can put on a partition, that I can then delete the partition out from under while doing a bootstrap onto that same disk. Very useful on cloud instances that aren't great about letting you bring your own ISO.
I had some weird debian-live scripts thst tried doing a tmpfs & copying a btrfs snapshot onto it and launching that, but I never felt great about it, quite a hack.
There are many which could fit your description. Tiny core, puppy linux varients (voidpup, with the void pkg manager, is pretty nice), etc.
However, I think the nicest put together ones are fatdog64 & porteus.
fatdog64 is built from scratch (basically, "Beyond Linux From Scratch"), but uses a lot of slackware tooling & ethos, so its quite compatible with slack pkgs & slackbuilds. If you dive deeper, its actually got a lovely cohesive design, behind the minimalistic gui which IMHO does it a huge disservice.
Eg: it has scripts to run containerised or UML'ised versions of itself, from within itself. Down to optionally having a nested X session with full gui.
Porteus (or the more bleeding edge Porteux variant) has more conventional look & feel out of the box.
Both Fatdog & Porteus(x) have much more flexible initrd systems than tiny core/puppy, where you can copy configs in from a static location (rather like alpine's overlay tarball), or bind mount stuff in. Critically, this is all before the main rootfs goes live, so you can affect how various disks & services are handled on a machine-by-machine basis, if needed.
(plus they're not restricted to the root-only approach which puppy needlessly adheres to religiously)
Plus, these were the original IMMUTABLE distro's, long before that was adopted by some distro-giants.
In other words, with a little thought, you have TONS of flexibility. Including the scenario you mentioned.
PS: to install either, it can be as simple as setting up a bootloader (which IMHO ought to be a distro agnostic task anyway), and copying over ... 2 files (by default, fatdog shoves its main rootfs squashfs module INSIDE the initrd). With porteus, you will have a fully setup xfce, cinnamon or gnome (yes) setup with ... 4 files.
The unique problem here is that while many of these are designed to run nicely from USB drive, I don't get the impression that many will let you remove the USB drive after boot.
FatDog talks about running from a RAM layer, which is cool. But I believe even this is still a RW layer atop the underlying root which needs to remain mounted.
Nope, puppy (all variants), fatdog, and porteus (all variants, including porteux & nemesis - which is arch based) can all boot in a mode where you can unplug/unmount the storage device from which it booted.
What did Knoppix get right that this got wrong, to the point where Knoppix quickly became synonymous with live-distrubution?
From a cursory search, it appears that finnix is focused on the command line while knoppix provides a desktop environment. Don't most distros offer live boot environments these days? I know I've done this with Fedora, Debian, Suse, and Alpine at least..
if knoppix was one of the first live distros to offer a full desktop environment, that's definitely what they got right.
My reading of this is that early versions of Finnix were based on Knoppix. However, according to the wikipedia sidebars, the initial release of Knoppix was 30 September 2000, while the initial release of Finnix was March 22, 2000. Something something beta/pre-release versions?
> Finnix 0.01 was based on Red Hat Linux 6.0, and was created to help with administration and recovery of other Linux workstations around Finnie's office.[citation needed] The first public release of Finnix was 0.03, and was released in early 2000, based on an updated Red Hat Linux 6.1.
So it seems that it was based on Knoppix later
If Knoppix had this and Finnix didn't, or if Knopper was able to supply enhancements and bugfixes in order to support Knoppix releases, then he was likely able to fit a much more complete system onto a given CD or DVD.
But idk what kind of compression early Finnix used, if any. (Nowadays, everything uses SquashFS, right?)
I never tried Finnix, but GRML helped me a few times so far.
It'd be nice to have a live image that I can put on a partition, that I can then delete the partition out from under while doing a bootstrap onto that same disk. Very useful on cloud instances that aren't great about letting you bring your own ISO.
I had some weird debian-live scripts thst tried doing a tmpfs & copying a btrfs snapshot onto it and launching that, but I never felt great about it, quite a hack.
However, I think the nicest put together ones are fatdog64 & porteus.
fatdog64 is built from scratch (basically, "Beyond Linux From Scratch"), but uses a lot of slackware tooling & ethos, so its quite compatible with slack pkgs & slackbuilds. If you dive deeper, its actually got a lovely cohesive design, behind the minimalistic gui which IMHO does it a huge disservice.
Eg: it has scripts to run containerised or UML'ised versions of itself, from within itself. Down to optionally having a nested X session with full gui.
Porteus (or the more bleeding edge Porteux variant) has more conventional look & feel out of the box.
Both Fatdog & Porteus(x) have much more flexible initrd systems than tiny core/puppy, where you can copy configs in from a static location (rather like alpine's overlay tarball), or bind mount stuff in. Critically, this is all before the main rootfs goes live, so you can affect how various disks & services are handled on a machine-by-machine basis, if needed.
(plus they're not restricted to the root-only approach which puppy needlessly adheres to religiously)
Plus, these were the original IMMUTABLE distro's, long before that was adopted by some distro-giants.
In other words, with a little thought, you have TONS of flexibility. Including the scenario you mentioned.
To get a flavour, have a quick look over
- [the fatdog faq](https://distro.ibiblio.org/fatdog/web/faqs/faq.html)
- [this old blog post] (https://www.lightofdawn.org/wiki/wiki.cgi/FatdogIsVersatile)
PS: to install either, it can be as simple as setting up a bootloader (which IMHO ought to be a distro agnostic task anyway), and copying over ... 2 files (by default, fatdog shoves its main rootfs squashfs module INSIDE the initrd). With porteus, you will have a fully setup xfce, cinnamon or gnome (yes) setup with ... 4 files.
The unique problem here is that while many of these are designed to run nicely from USB drive, I don't get the impression that many will let you remove the USB drive after boot.
FatDog talks about running from a RAM layer, which is cool. But I believe even this is still a RW layer atop the underlying root which needs to remain mounted.
(as can tiny core, alpine, etc)