Tritech Service System: More Information
Latest version is 2.0.3d :: POST-2.0 UPDATES: 2.0.1 fixes an initscript bug which is in some cases serious. This bug causes initscripts to prematurely terminate, rendering some parts of the system unusable without running some initscripts manually. 2.0.2 fixes "LVM2 not working due to missing libreadline.so.6" and "phome fails to mount on boot because USB devices do not enumerate fast enough." 2.0.3 fixes broken ImageMagick and adds screenshot menu options, "Edit - in Set FB Wallpaper" item in GQView to change the wallpaper, minor software upgrades, and a more verbose and robust early boot which drops to a shell if there is a problem instead of halting the system. As of 2.0.3, CRE is now considered the mainstream TSS, and "CRE" will not appear in the version number from now on. 2.0.3d fixes Intel graphics chips in X.org, as well as other very minor bugs.
TSS Sneak Peek!
Curious as to what we're developing for the upcoming releases of the Tritech Service System? Here's a brief explanation of what we're looking at doing for the next release. TSS has been using a huge initramfs package to boot ever since its inception, and that's fine for a relatively small system, but the TSS package count is growing, and the "one huge package" way of booting up is starting to get painful as the initial RAM filesystem has already shot over 100MB once decompressed. Add the fact that decompression takes insane amounts of memory and requires both the compressed AND uncompressed file to remain in memory during the process, and you have a disaster for any low-memory (under 256MB) machine. Adding it all together makes the ugliness clear: 12MB for the kernel + 33MB for all the packages + 106MB for the uncompressed packages + 33MB or more to decompress = even a 192MB machine is probably going to fail to boot!
So, in an upcoming release of TSS, we're completely changing the way that the entire system works. Chances are that almost no new software packages will be added, but the entire TSS framework will be changed in ways that make future features and new packages extremely simple to put in place. The wrapper system which is currently used to unpack TSS from a single gigantic LZMA archive will do something totally different: unpack the desired individual packages at boot time! We've already combined "base" and "ext" packages, and added package information files which specify package name, description, dependencies, category (base vs. ext), and type (application, library, dependency fulfillment, etc.), allowing package selection to be much more friendly to people that are not as seasoned in the details of Linux packaging. By moving to a dependency check and individual unpacking at boot time instead of pre-generating a huge single package, we will have a vast number of new possibilities. TSS could be installed to a hard drive or other storage medium and operated from that medium as a traditional Linux distribution. An option could be presented at boot which would allow a custom package list to be loaded, allowing customization of the system even after it's built and burned to a CD. Packages can be specified at system build time to be placed in the ISO, but not in the initially booted system, which would retain our goal of boot media independence while taking advantage of the high capacity of modern optical and flash media. A network server on the LAN or Internet could be used to pull a package list and then pull the desired packages required for booting in a truly live fashion, allowing package updates and changes without throwing out old TSS CDs (when TSS 2.1 becomes "old" that is!) For systems with very little available RAM, packages can be deleted from the initial RAM filesystem as they are decompressed, freeing up that space for other packages waiting to be decompressed and filling the "low-spec machine" hole that TSS currently cannot.
When this is completed, the new TSS will feel mostly the same as the current series from the user's point of view, but feature addition will practically explode shortly after its release. By the time the first revision thereafter is released, we should have at least some of the features mentioned above implemented. If you have suggestions, let us know! Send an email to firstname.lastname@example.org with your questions, comments, suggestions, and feature requests. Keep watching this page for future announcements, and thanks again for using the Tritech Service System!
Originally, we planned to make release 2.1 contain these changes, but due to time constraints and a large list of tiny bugs for the 2.0.x release series that need to be resolved, we are instead making 2.1 a transitional release which will only feature updated software packages and a lot of bug fixes. We may build 2.1 from the UTSS packages we've been working on all along, but that decision is still on the table. Stay tuned. EDIT: UTSS will become TSS 3.0, and 2.1 is scrapped entirely.
E-mail questions, comments, suggestions, or feature requests to jody at c02ware.com.