Remaster - WallPaper

[netzen]

Remaster - Wallpaper

Hi,

I don't know if it will work well but I start to play with the idea of building VirtualBox'es .VDIs images as a way to make "howtos out-of-the-box". In this sense, people can download the VDI a "run de howto" in real environment...

I believe that the small size of TinyCore made possible this "new kind" of howto's, where is not only possible to give the information but to offer the .VDI file as part of the "tutorial".

Here is where I need help:

I successfully remaster TinyCore with a custom wallpaper (/opt/.backgrounds/tinytux.jpg) and was able to make it work with the following startup script.

Code: [Select]

[bootlocal.sh]
#!/bin/sh
# put other system startup command here
awk -f /usr/bin/set_jwm_background.awk -v type="image" -v value="/opt/.backgrounds/tinytux.jpg" -v outfile="/tmp/background.tmp" /home/tc/.jwmrc
mv /tmp/background.tmp /home/tc/.jwmrc
jwm -restart

I accomplish this code after taking a look at the source code:
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/release/src/fltk_projects/wallpaper/wallpaper.cxx

Here is the JPEG file I used:

(1024x768)
http://farm4.static.flickr.com/3539/3406491906_5bd641df1e_o.jpg

Here is my question: What is the right way to "setup" the new custom wallpaper to the custom-jpg-file?

Anyway, this is just for the howto (.vdi) tutorial purpose.

Thanks.

BTW, "tuxmolecule" is the name I am using convey the idea of "building elaborated systems using tiny tuxes together"...
[ TuxMolecule, made of TinyTuxes ]

[curaga]

Actually, your way is pretty nice

Only the "jwm -restart" is not needed, because jwm is not started yet at that point.

There is no "right way" really. Other ways to do that include:
- editing the file /etc/skel/.jwmrc directly
- using your script, but as an install script in a wallpaper extension (one that has only the wallpaper and then the script to change it as it's loaded).
- including the wallpaper, and either that bootlocal.sh or the edited /home/tc/.jwmrc in a backup that's included on the iso

[netzen]

Only the "jwm -restart" is not needed, because jwm is not started yet at that point.

Arigatou gozaimasu (thank you very much).

I'm thinking about the remaster because I believe that users maybe interested in remaster TC with they own domestic pictures or specific wallpapers in the case of some business users...

If we can make the "remaster" a simple task, that alone will help spread the "news" about TC...

Thanks.

[tobiaus]

one of the really great things about tc is that almost anything you'd need a remaster for, you can do with an extension instead. i say almost, because for example to get tc to boot from reiser, you'd need to have the reiser extension included in tc before you boot- thus, you need a full remaster for that. that's what i was thinking of when i wrote this:

was thinking about my comment that a frugal install is the closest thing to an os install using tcz, and i had this idea about making remaster the same way. in a frugal install, you mostly copy a couple files into place.

i'm also thinking of [someone] who remasters tc every time he upgrades, because he wants to use it with reiser. as i understand it, tc doesn't support resier until after boot has loaded extensions, thus tc can read and write reiser but not boot from it.

so he's got the extension it needs, but it doesn't load until he's booting.

now suppose you expanded the idea of tce/optional to remastering. you could have a folder called tce/remaster (it would already know where to look if it knew where tce was.) then all you'd need to do is run tc, stick the iso for tc into tce/remaster, put tce and/or tcz extensions (including scripts, new copies of bootlocal, mydata.tgz if you want it included, etc) in there, and enter "remaster" into the prompt. voila, it spits out tce/remaster/remaster.iso

this could mean that all [he] would need to do to upgrade is put an iso and a tcz in a folder and type "remaster" - i've thought of a couple reasons it could be more complicated, but before you tell me about them i want you to know i've thought of them. for someone that remasters every new version i wanted your opinion of the idea. i already realize you think tc generally doesn't need remastering, and i generally agree. i certainly hope i never need to remaster it.

here i'm referring to what i call "full remaster," which is a remaster that goes inside tinycore.gz. this is also the kind of remaster people usually refer to when they use the word "remaster"

when it comes to creating an iso however, some people (who do not want to create a multisession cd to accomplish the same thing) may want to simply add their extensions to the iso before they create a tc cd. it's not needed if they're just going to make a bootable usb, but it is helpful for people making cd's. again, it's not needed because you could also put the extensions on usb... even if it's not bootable, but then you have to carry both cd and usb around.

so i would have not only tce/remaster for adding extensions like reiser to tinycore.gz, but also tce/addtoiso for adding extensions to the iso file outside tinycore.gz. at the moment i don't know anyone with the time to do this, but i think it's a good way to make remastering as easy as adding extensions- even if it's usually unneeded, i think it could be easier when it is.

[mikshaw]

tce/remaster for adding extensions like reiser to tinycore.gz

I can't recall if the filesystems tce does this, but some extensions will install files into /usr/local and outside of user local.  If you were to have those extensions added to tinycore.gz, you risk losing parts of them if you also use PPI (/usr/local gets mounted over the files in tinycore.gz's /usr/local).  It's sort of the reverse of the problem you currently have if you use PPI with extensions that are not PPI compatible.  You could reinstall that app into tclocal after it is mounted to make up for it, but that means your new tclocal would not fully work with a non-remastered tinycore.gz, essentially the same as PPI with non-PPI-compatible extensions.

[tobiaus]

I can't recall if the filesystems tce does this, but some extensions will install files into /usr/local and outside of user local.  If you were to have those extensions added to tinycore.gz, you risk losing parts of them if you also use PPI

believe me i anticipated complications like that. i don't know if there is a way around them, and the idea is based on the hope someone would be able to figure out how to handle those.