dCore-5.0.alpha1 released

[Jason W]

Team Tinycore is pleased to announce the testing release of dCore-5.0.alpha1, Core made from Debian Wheezy compatible files that uses import and the SCE package format.  Features include:

• Debian Wheezy (Debian Stable) library compatibility.
• Fully functional toolchain when importing build-essential and pertinent development packages.
• Support for custom packages that are not available via Debian.
• SCE package format: imported packages include the package and it's needed dependencies in one file, files contained are symlinked to live filesystem.
• Meta packages to simplify usage are available.
• Support for custom startup scripts.
• Premade SCE packages for kernel modules and wireless.

Files can be found at:

http://tinycorelinux.net/5.x/x86/release_candidates/

A brief intro to the use of import:

The command as regular user "import iceweasel" will import iceweasel and it's needed dependencies and place them in an sce file in the sce/ directory in the users TCE directory.  "import -b iceweasel" will import it and add it to the sceboot.lst file to be loaded at boot.  The command "loadsce iceweasel" will install it.

For efficiency, a file list can be made of one's favorite packages and import can be used to make one mega package out of the list.  Example, a file named mydesktop that contains xfce4, leafpad, iceweasel, exaile, smplayer, etc, etc , one package per line, will make an sce of those packages that will be named mydesktop.sce.  If the file is located on /mnt/sda2, the usage would be:

import -f /mnt/sda2/mydesktop

Premade SCE packages are available at:


http://tinycorelinux.net/5.x/x86/sce/

Fetching them is done with the sce-fetch.sh command.  "sce-fetch.sh wireless-tools" will fetch wireless-tools.sce, the command "loadsce wireless-tools" will install it.

Needed for X desktop use are the SCE packages:

Xprogs.sce
Xtc.sce

A simplified manner of installing Xorg is using the Xsetup.sh script:

http://tinycorelinux.net/5.x/x86/Xsetup.sh

Download it, use the command "chmod +x Xsetup.sh" and run it.  This will install the familiar flwm_topside window manager and xorg-all, the Xorg meta package that contains support for all the Xorg video drivers.  Also needed may be graphics-3.8.10-tinycore for some hardware.

Readmes are available at:

http://tinycorelinux.net/5.x/x86/README/

The command "readme.sh wireless-tools" will display that readme.

[theYinYeti]

I’m really impressed with this project. The possibility to pick any debian package and make a TC package out of it is excellent!
I can’t help wondering, though, what will happen to this project from TC5 on, as I gathered that the SCM package format will be dropped, or won’t it?

[bmarkus]

dCore-5.0.alpha1.iso

isolinux.cfg configured to load core.gz but there are no such only dCore.gz therefore boot fails.

[vinnie]

Awesome, that's why you were so busy jason! Effectively a feature like that could fully replace the scm packages, but could you explain me how work these packages? :
1) you can choose whether to install them in a loop or in ram?
2) you can uninstall (as the scm) during the execution time of the os?
3) apart for the support of debian packages, the dcore is fully compatible with the core features?

I can’t help wondering, though, what will happen to this project from TC5 on, as I gathered that the SCM package format will be dropped, or won’t it?

I think the scm has been abandoned for the lack of interest by packagers, but if this new system works well I think it will maintain itself

[Jason W]

Thanks bmarkus, I have not tried the ISO only the dCore.gz so I did not catch that.

vinnie and theYinYeti,
The SCM has been dropped, basically since without an automated way to make them like the CDE model it was just too time intensive once you get past the simple apps.  The SCE has replaced the SCM, as it contains all it's needed dependencies in one file.

The SCE only uses mount mode, it is not copied to RAM.  They cannot be uninstalled since like the TCZ the files exist in the regular filesystem, the SCE is not self contained although it contains multiple packages inside of it.  And dCore aims to support all core features, it simply draws on the Debian repo for it's extensions.  But the extension installing/updating features of the TCZ are not all supported by the SCE, but that is partially due to the differences in package type.

[theYinYeti]

Thank you for the clarification Jason W.
Let me repeat: it is an awesome project! :-)

One thing I liked a lot about DSL, years ago, was that it was light enough to support my 24MB RAM Toshiba laptop, but I still could enable “Debian compatibility mode” and install packages from Debian Woody repositories :-p

Nice work!

[vinnie]

And dCore aims to support all core features, it simply draws on the Debian repo for it's extensions.  But the extension installing/updating features of the TCZ are not all supported by the SCE, but that is partially due to the differences in package type.

So there are only sce extensions in dcore and not tcz?

[roberts]

dCore-5.0.alpha1.iso

isolinux.cfg configured to load core.gz but there are no such only dCore.gz therefore boot fails.

Fixed on server for next iso creation.

[roberts]

And dCore aims to support all core features, it simply draws on the Debian repo for it's extensions.  But the extension installing/updating features of the TCZ are not all supported by the SCE, but that is partially due to the differences in package type.

So there are only sce extensions in dcore and not tcz?

That's why sces are not just merged into Core.
dCore the 'd' is for Debian and also for different from Core.
no tcz support in dCore.

You may want to read http://forum.tinycorelinux.net/index.php/topic,14332.msg91108.html#msg91108
which explains why sce.

The concept behind dCore is to more easily maintain the Core philosophy across many platforms without having to build and maintain many platform specific repositories

[SamK]

Some unordered questions, simply in as they occurred to me.


Once an SCE app is imported is it possible to apply a security upgrade (issued by Debian) to an active dCore system, or is a rebuild of the SCE app required to incorporate it?

...dCore aims to support all core features, it simply draws on the Debian repo for it's extensions.

As it draws on Debian Stable does this imply an app in SCE format inherits the same degree of app stability?  Is it vulnerable to upgrade changes at an OS (dCore) level?

The SCE has replaced the SCM, as it contains all it's needed dependencies in one file.

Does this mean an SCE app is resistant to breakage?  For example is it vulnerable to SCEs created from custom packages that are not available via Debian?  Is there any degree of sharing common dependencies in an SCE?


Can an SCE be managed a single entity?  e.g. can it be removed (not unloaded/uninstalled) from a system as a single unit in a similar manner that an SCM was?  How do a user do it?


Have any tentative comparisons been done of RAM usage for similar SCE v TCZ systems?  If so the figures might be informative.

[vinnie]

That's why sces are not just merged into Core.
dCore the 'd' is for Debian and also for different from Core.
no tcz support in dCore.

You may want to read http://forum.tinycorelinux.net/index.php/topic,14332.msg91108.html#msg91108
which explains why sce.

interesting, thanks roberts

[roberts]

Some unordered questions, simply in as they occurred to me.


Once an SCE app is imported is it possible to apply a security upgrade (issued by Debian) to an active dCore system, or is a rebuild of the SCE app required to incorporate it?

dCore is not Debian. Nor is it traditionally "installed". dCore uses mounted squashfs as tcz and scms did. There is no rebuild, as apps are typically imported. We are only supplying scripts ( the import suite in the base of dCore ) and some server side typically setup/data scripts. You might want to think download script as used for flash.

...dCore aims to support all core features, it simply draws on the Debian repo for it's extensions.

As it draws on Debian Stable does this imply an app in SCE format inherits the same degree of app stability?  Is it vulnerable to upgrade changes at an OS (dCore) level?

Stability was another reason of our choice of Debian stable. Also, like the scm format, sces are not subject to the rolling release breakage of tcz dependencies. dCore is an embedded Linux with mainly busybox calls to ash and awk. Changes in the base should have little to do with applications. Same as Core.

The SCE has replaced the SCM, as it contains all it's needed dependencies in one file.

Does this mean an SCE app is resistant to breakage?  For example is it vulnerable to SCEs created from custom packages that are not available via Debian?  Is there any degree of sharing common dependencies in an SCE?


Can an SCE be managed a single entity?  e.g. can it be removed (not unloaded/uninstalled) from a system as a single unit in a similar manner that an SCM was?  How do a user do it?

sces can be removed as a single entity without breakage, although not dynamically. Like tczs, a reboot is needed to effect., i.e.,simply rm the target sce and reboot, if such was loaded.

Have any tentative comparisons been done of RAM usage for similar SCE v TCZ systems?  If so the figures might be informative.

I doubt much change, but like scms, sces are larger physically and require similiar persistent storage.

Not mentioned but another area that may be of interest is that sce, even custom compiled, unlike tczs do not need to be relocated to /usr/local/. Standard compilation methods, when required, are supported.

Sces have been used in the Allwinner A10 port since its initial post and now Jason has implemented them for x86. The goal being to preserve Core's philosphy while trying to support multiple platforms without the need to do relocate compiliations for tcz respositories for each and every platform.

[Jason W]

dCore-5.0.alpha2 now available:

* Fixed bug in sce-fetch.sh, -i now works, added -b to add to sceboot.lst
* Fixed bug in isolinux.cfg on server to specify dCore.gz
* Added initial sceboot.lst to tce-setdrive.

Files available at:

http://tinycorelinux.net/5.x/x86/release_candidates/

As a result, these files have also changed:

http://tinycorelinux.net/5.x/x86/Xsetup.sh
http://tinycorelinux.net/5.x/x86/README/README-X-Desktop.txt

[Jason W]

In addition to Robert's more thorough explaining of the dCore philosophy and design, one thing that import and dCore share in common with Core is the support of things that are either too new or too old for Debian.  Gtk1 is available in dCore, XMMS is already there and can be fetched with the command "import xmms".  Same with Firefox and Emelfm2, neither of which are in Debian.  Iceweasel is frozen at version 10, and a Firefox at version 10 is quite dated though stable.  "import firefox" and "import emelfm2" will get those packages at their latest upstream versions.  The latest firefox will be maintained since it is popular.  More Gtk1 apps can be built and made available.  The rule there is that extra packages need to be not available in Debian nor should they conflict with existing Debian packages.

[Jason W]

dCore-5.0.alpha3 now available:

* Fixed bug in tce-setup to quiet terminal output from startup scripts

Files available at:

http://tinycorelinux.net/5.x/x86/release_candidates/

Use the command "loadsce -d pkgname" for debug mode if you want to log the output of startup scripts to /var/log/sce.log.