Tiny Core & Porteus

[Rava]

TinyCore? I find Porteus to be an excellent boot host for that. I download only two distribution files from the X86_64 port (vmlinux64 and corepure64.gz), place them into my syslinux directory, edit the porteus.cfg with a menu entry to handle those, and when I feel like getting all TC, I boot that way using Porteus as the intial boot host.

Same here, the bootstrap is via porteus.cfg and tinycore and puppy are mere menu entry to handle those.

Thought I could look into TC (=TinyCore) more, at least their x86-64 modules were 100% compatible with Porteus (should have been around the time of 5.0rc1 or 5.0rc2, and some TC modules have been amazingly small.

Unlike Porteus or forum.porteus.org TC has very strict and long-listed rules on how to make modules you have to adhere to if you want your module to be approved by TC; so I myself registered on their forum, but not even once managed to create one single TC module… because of the many TC module creation rules they demand all be followed, of course.

That has advantages and disadvantages.
Disadvantages: Noobs to the TC rules for modules like me can be put off completely on creating own modules for TC since the sheer amount of rules is overwhelming.
On the other hand, I presume the amazingly small size of some of their modules most probably is at least in part because of the long list of rules…

In short: transferring such strict module creating rules over to Port: strict adherence to such rules could increase the quality and ensure smallest possible module size but would also most likely ensure less modules get created overall. Way less modules I'd say. So, no, we at Porteus should keep our way of doing like we did it all these years.

Or in other words: one more reason why forum.porteus.org is my main Linux home and no other Live Linux distro even comes close.

[nanZor]

Ah, no problem - if you are just trying to make a "tcz" of something you compiled, or even something like a whole directory structure of stuff, perhaps this will help:

https://www.youtube.com/watch?v=yRm-YRuLFio

But yeah, like Porteus, TC is what you make it. Albeit for most control, there are no handy automated gui's for some stuff.

I should hope that lurkers don't see this as some sort of contest or devious way to suggest switching. What Porteus and TC have in common is a dedicated groups of devs doing this for US, year after year after year, who also appreciate user contributions to perhaps take some of the load off.

I've given Porteus a thumbs-up over there as well. We're all in the ram-oriented small family even if core concepts are different.

[nanZor]

I think I realized what you meant by so many "rules" for tcz submission when you want to distribute to the population at large and not just yourself.

Unlike creating a tcz (or module in Porteus terms) for just yourself to use, additional steps need to be done by the author, such as md5.txt files, description files and so forth when they are created for the rest of the community and follow an agreed-upon format setup years ago.

This is part of the infrastructure of the distribution system. For instance, if I use the built-in "app browser" (gui or commandline), I'll see the description of what your module is and it's provenance before I decide to download and install and it will be in your own words, not that of a repo manager. Perhaps I'll visit the website, github or other source you have included in the description myself before saying "yes". MD5 sum checking are submitted by the author as well as those are used internally in the system, not just for initial submission.

So it's not a "test" of submitter worthiness either. It just helps maintain the integrity of the distribution network, and takes a bit of a load off the main managers deluged from email submissions lacking detail and having to massage it all into shape.

Once received in the proper format, the submission will be run in an isolated environment machine, to make sure that someone isn't trying to sneak in something that may be harmful or otherwise illegal.

This also obviously keeps one from safer from trying to install a module from "Uncle Larry's L33T Warez Modules" repo, or from simple sloppiness / corruption in the distribution slowing the whole thing to a crawl.

The good news, is that just like here, if that is too much, a noob or anyone else can request that a tcz module be made! Either the devs or someone similarly skilled might make it and submit it once discussed. Thing is, just like the old days, "the last guy who touched it owns it" for the most part, so updates and user support *may* need to be made again by you. Which of course since you made the description file, people know who to ask for support.

Sorry this was so long and not about Porteus. But again -like here- if you have something absolutely cool that needs to be made, anyone can make a request if they don't want to do it themselves.

[nanZor]

Some up-front notes about the philosophy

This is just to save some time and not be an "official" channel of TC communications. Just my own view.

TinyCore is initially a tiny "core". It is up to you to build upon that if desired, and decide where to stop. So don't let the small size fool you - it's up to you how far you want to take it. It does NOT mean that TC forces you to become a tiny-resource zealout.

Why are all the video reviews of TinyCore so tiny on the screen? Who can work with that?

TinyCore - as delivered by default - on most modern high-resolution screens like 1920x1080 today will look pretty small. So how do you control that?

As delivered in it's tiny size, it relies upon the "tiny-x" server, rather than a full-size Xorg. Of course you can incorporate a full-blown full Xorg as you wish, but as delivered in the typical download, it relies upon Xvesa for 32-bit, and Xfbdev for the 64-bit port.

The 32-bit version actually has a gui control panel for that if you don't do it initially yourself in the bootloader config. But hey, not everyone is running a gui, so wanted to put this out there. 64-bit, you need to do it manually.

For 32-bit Xvesa, this would be done by modifying the "VGA=XXX" option. Or using the gui control panel later for that.

In the 64-bit version which uses Xfbdev, simply ignore that VGA= option, and use a line in say grub.cfg, permanently edited, or temporarily changed in the grub boot menu, (there is no gui control panel for that) which looks like this if you wanted 1024x768 for instance:

Code: Select all

set gfxpayload=1024x768x24

One good place to put this is in the specific boot-stanza you are using (TC, TCW) for instance.

For some, this is all they need. Many will incorporate the full Xorg, and of course now you have additional ways of controlling your resolution which many might be more familiar with.

So, ok this is not meant to be authoritative, official, comprehensive, nor expert advice. It serves merely as a hint for those who want to run with a minimal configuration and be able to see it on a modern high-res screen. But it doesn't mean you have to STOP there. It is only a small core as delivered. YOU put on the rest (like a full blown Xorg, different window managers, DE's, ad-infinitum) if so desired.

Or, as previously noted, use Porteus as the initial bootloader with only two TC distribution files and work your way up from there. Understandably, this cross-pollination is not officially supported. If it breaks, you get to keep both pieces.

Many so-called reviews on the net with tiny fonts and icons don't fully grok TC nor Porteus, because many are just booting the iso, running through menus with two turntables and a microphone, and don't understand that TC - like Porteus - to get the most out of them means you need to read a faq or two. Neither TC nor Porteus is your typical app-store distro.

[Rava]

Thanks nanZor for explaining some basics on TC… quite some people not seem to get the finer details like you described by the review videos using tiny fonts and tiny icons on a FullHD or larger screen.

don't understand that TC - like Porteus - to get the most out of them means you need to read a faq or two.

With Porteus you can register with the forum and ask questions if the RTFM is too much for you.

But often not many new folks appear in the forum even when a new Porteus version came out and the download numbers tell us people downloaded and tested it. (Because who would download a Linux system and not test / not use it?)
But that usually it means the people do not need any forum help, or they find what they are looking for by lurking in the forum and do not need registering themselves.

[nanZor]

Yes, they should register if nothing more than to say hello and perhaps state their use-case if they feel it is interesting.

This way, developers and user-contributors don't feel like they are operating in a vacuum for nothing.

Many don't realize how small these projects are, and how devs and user-contributors such as yourself keep it going for the benefit of others. Over the years some have moved on, or sadly passed away.

In some cases, this can mean the docs or wikis can become kind of stale, or perhaps need a little TLC to reflect the times. Where's THAT guy? Devs can't do it all. On the other hand, just changing a forum to say a discourse server with a bunch of like/dislike buttons and walking away serves no purpose other than a mere gloss-over which looks modern, but underneath is pretty much stale and in the long run be worse than what is was replacing....

Sorry - I'm getting off topic again.

I think that some don't realize exactly *why* Porteus, and for that matter TC (and Slitaz and knoppix et al) do things the way they do. Ie, designed primarily to run from removable media, and store data in a relocatable file ( porteussave.dat vs tc's mydata.tgz) for example, and not run as if it was installed to a hard drive with a bunch of small file writes that hurts usb drives for example. "When I reboot, nothing is saved, what's wrong?" Or, "why are there so many different ways of doing things?

Not understanding this up front is what may confuse those coming from the boot-the-iso and install-to-hard-drive mentality. Once figured out, one understands what is so special about Porteus, and why it is not like the other children.

It just saddens me to see reviews of Porteus and our like-minded projects in the same family being relegated to the "Run your old computers with these small distros!" - when in fact they work superbly on the most modern hardware. Reviewers miss the point. And not one mention of *why* porteussave.dat exists in the first place. Frugal install vs what Roberts of DSL called a "scatter mode" install with file-rot is all about. Oh well.

Sorry - got philosophical there...

[Rava]

It just saddens me to see reviews of Porteus and our like-minded projects in the same family being relegated to the "Run your old computers with these small distros!" - when in fact they work superbly on the most modern hardware. Reviewers miss the point.

You are correct on that, and especially when mentioning TC (and Slitaz and Knoppix et al)

Only one example: In reviews usually Knoppix gets mentioned as the Linux distro with the best hardware support of all Live Linux Systems. Not why it designed to be a live system. And not what a Live System means and why it differs from any Linux system that is installed the usual way. And what possible advantage the Knoppix or Porteus or TC or Puppy or DSL approach holds for the user.

At least de.wikipedia gets is quite right.

translated using https://www.deepl.com/translator
Knoppix: Grundprinzip von Knoppix (first paragraph only)

The basic principle of a live system is first the complete renunciation of an installation; the required components of the system are loaded into the RAM instead. In addition to common use, this makes it possible, for example, to test in advance whether the existing hardware is compatible with the respective Linux kernel version. Other special areas of application are emergency as well as diagnostic work on the computer, for example in the case of a virus infection or a hardware defect. General security aspects can also play a role, since an operating system that is started from a non-recordable medium can only be compromised for the duration of a session at most (i.e. it is restored to its original state at the next startup).

Added in 5 minutes :

In some cases, this can mean the docs or wikis can become kind of stale, or perhaps need a little TLC to reflect the times.

What is meant by TLC here? I seem not to get the abbreviation. Not even https://www.deepl.com/translator was able to help me, nor a DDG search.
I am quite sure you neither meant the girl band TLC (group) nor the TV channel https://tlc.de

[ncmprhnsbl]

What is meant by TLC here?

TLC=tender loving care

[nanZor]

Hmm.. that's one way for those guys to put it, but lacks important detail as to almost mis-characterize Knoppix, or for that matter Porteus' importance.

Like for instance, Knoppix is not designed to be "updated" in the usual sense. That is, if you install it and run an update/upgrade on it like you would with Debian, you'll break many of his customized work-arounds for the bleedging edge drivers and software that make it all work. Best to install Debian proper if you want that. So it's not a daily full-update distro either, but many aren't warned up front.

I just wish I was more concise and to the point with my writing. I'd probably clean up / remove stale Wikipedias entries for TC and Porteus while I was there.

[Rava]

I just wish I was more concise and to the point with my writing. I'd probably clean up / remove stale Wikipedias entries for TC and Porteus while I was there.

As in:
editing your above posts
or
editing wikipedia?

[nanZor]

Heh, both! My english-teacher back in school would be ashamed of my long winded prose.

Often overlooked in our live environment family, is GRML Linux. That small group has done a nice job with theirs too.

Knoppix - I saw the start of the hard-drive mentality early on due to the good hardware detection. Even though not designed specifically to be a traditional hard drive install, the first thing many want to do is put it on a fixed-disk - which it wasn't really created for.

Anyway, I still get a lot of pleasure out of using TC and Porteus on very modern hardware right out of the box with no additions for what I do.

Still, nothing beats Porteus for ease-of-installation on usb with very modern hardware. Just unarchive the image to a fat32 stick and that's it for the most part! What kind of boot-sorcery is this??? (although I see Gparted Live has the same capability with their zip file distribution). Amazed.

[Rava]

Knoppix - I saw the start of the hard-drive mentality early on due to the good hardware detection. Even though not designed specifically to be a traditional hard drive install, the first thing many want to do is put it on a fixed-disk - which it wasn't really created for.

Depends. You can install it as a live system just like you can install TC or Porteus in the same way, this way Knoppix keepsits advantages of being a live system the way it was created.
If you mean by "traditional hard drive install" as in: converting it into a standard hard drive install, then I agree. People not get that much is lost of what makes Knoppix special.

E.g. Why I love Porteus is that by changing the default user who runs X from root to guest it is much safer than many of the other live systems. (Some years ago it was yours truly to suggest that change, and it was voted upon. Only approx 20 to 25 people voted on it, and lucky us the majority voted for "non-root user to start X by default") E.g. Puppy has only the root user, at least the puppies I tried. It is often argued that this is no security risk since it is a live system.

But… when the live system is installed on the hard drive (but kept as a live system) then the internal (or external) partitions are all mounted, and even if they would be mounted ro at boot, since root is the one starting X in Puppy, any attacker could easily overtake the system (via an unfixed bug in the browser or any other program that goes online as root) and remount all drives rw and then install his rootkit and whatnot.

And I run all my Porteus without the save changes. I want my Porteus to forget everything unless I explicitly told it otherwise.
Since I also use some VFAT USB-thumbdrives for booting Porteus I developed a suite of two scripts - that is really only only script:
(Off topic)

Code: Select all

guest@porteus:/usr/local/bin$ file make-991-usr_local_bin.sh
make-991-usr_local_bin.sh: POSIX shell script, Unicode text, UTF-8 text executable, with escape sequences
guest@porteus:/usr/local/bin$ file make-992-rootcopy.sh 
make-992-rootcopy.sh: symbolic link to make-991-usr_local_bin.sh

The script determines if it should act as 992-rootcopy or as 991-usr_local_bin by the name it was executed as.
I will present these in Community effort some day. You have to hard code the folders where your scripts and programs are (that is what make-991-usr_local_bin.sh is for) or where your root and guest settings are (that is what make-992-rootcopy.sh is for) on an ext2/3/4/other-linux-partition in the script itself. (I was simply too lazy to go for the external .conf file approach and went with the saving the settings in the script itself)

When you set up the base/ files 991-* and 992-* as symlinks then at next boot the most recent created 992-rootcopy*.xzm or 991-usr_local_bin*xzm are loaded.
My script only creates the modules and creates a symlink to the most recent module.
In base/ you also have a symlink to the symlink.

Better to explain it via example:

Like so: $PORTDIR/base/
991-usr_local_bin_RECENT.xzm -> /what/ever/Porteus_modules/5.0/991-usr_local_bin_RECENT.xzm

and in /what/ever/Porteus_modules/5.0/ you e.g. have:
991-usr_local_bin_RECENT.xzm -> 991-usr_local_bin_2021-11-26.xzm

The symlink in /what/ever/Porteus_modules/5.0/ gets created each time anew when make-991-usr_local_bin.sh got started, and of course make-991-usr_local_bin.sh also creates the actual module itself as "991-usr_local_bin_YYYY-MM-DD.xzm" (in the above example that translated into 991-usr_local_bin_2021-11-26.xzm) from the predefined folder.
But I digress. *runs away*

If you want to comment on the spoiler part (my script solution) please do so via PM. When I created the thread in Community effort then there is an on-topic thread to comment on it.

[nanZor]

I'll check that out - and apologies since I'm the one taking it off topic. But yes, it brings back memories of showing others coming from other systems that wanted to run everything as root. And then they ask me to fix a broken system, when I find out that they thought chmod 777 was the fix to everything.

Thanks, I'll check out the spoiler and comment if needed over there.

[burdi01]

But… when the live system is installed on the hard drive (but kept as a live system) then the internal (or external) partitions are all mounted, and even if they would be mounted ro at boot, since root is the one starting X in Puppy, any attacker could easily overtake the system (via an unfixed bug in the browser or any other program that goes online as root) and remount all drives rw and then install his rootkit and whatnot.

To use the system a user has to have mounted the filesystem(s) containing his/her data -- e.g. at least his/her home partition. And that data is the only precious asset (to him/her) on that system -- after all the system partition(s) can be restored from a backup. So in a non-root scenario an attacker can still create havoc for the user. Actually I would recommend backing up the user data as well -- and possibly more frequently than the system backup.
Running as root in effectively single-user systems such as Porteus, Puppy, PartedMagic and the like therefore is OK(ish). For multi-user systems confidentiality alone would require the users to be more restricted (so to not run as root).

[Rava]

they ask me to fix a broken system, when I find out that they thought chmod 777 was the fix to everything.

Oh well. They asked for it.

Running as root in effectively single-user systems such as Porteus, Puppy, PartedMagic and the like therefore is OK(ish).

OK(ish)? Think about it. any device you can plug in could be corrupted in the background by a hijacked system, even files that are to be read by root only since root can do anything he wants. He is called superuser for a good reason. And all backups you think you are creating could be corrupted as well.

Unless there is a good reason for being root it is best to start everything as non-root-user by default, especially X. And when a program demands otherwise e.g. gparted then you just give it the root password.
Of course the root password should be changed into something better than "toor".

My approach is obviously "better safe than sorry". To each his own I guess.