What's the future direction of TC?

[peterc]

Just out of curiosity, is there a TODO or roadmap for TinyCore? What can we expect for TC 4.0 and beyond?

[roberts]

Well, we just finished three dot oh! So four dot oh is a ways off! We still have many 3 dot x ahead.
Our direction comes from ideas and suggestions both from the team, and the community. 

Since we don't have a formal "Ideas and Suggestions" section of the forum, lets use this post.

So please discuss. What is needed in the base? What is desired? And there is always much that can be done outside the base via extensions.

[peterc]

One thing I was wondering about was porting TC to other architectures; x64 would be the low-hanging fruit, ARM would make a tremendous amount of Good Sense considering its recent surge in popularity and availability in low-end hardware.

Of course, that leads to the next issue: more architectures means that the current way of having extensions created by the community would inevitably mean that there would be inequalities between architectures; it's not too hard to imagine that extensions for ARM would be considerably outnumbered by those for x86. Which leads to the conclusion that if multiple architectures are adopted, a move to a script-based compilation procedure would be the way to go. That way, users don't contribute binaries, but compilation scripts. As an added bonus, this would go a long way toward prevent hostile submissions. (What's preventing users from adding a root kit or keystroke logger to their submission? I am certain that the vast majority of submissions are absolutely clean, but it only takes one rogue to spoil everything for everyone.) I would recommend against the NIH syndrome and take an existing system from one of the source-based distros. GoboLinux (while not exclusively source-based) has a very nice system with Compile, and many of the scripts (recipes) are only two lines. Other options would be SourceMage, CRUX, and of course Gentoo.

I hasten to add that I don't think that TC should become entirely source-based; rather, a hybrid, where the user can either build an extension from source or download it as a binary, but in both cases the extension would be created from the same script; the binary would have just been pre-compiled.

[roberts]

Actually at the very earliest stages we were promoting the posting of build scripts.
For GPL based extensions, we offer the sources with build scripts.
It take much effort to host and maintain the current repositories and to stay GPL compliant.

Perhaps for community contributed extensions more needs to be added to the .info file for build instructions for those that wish such?

I am certainly open to GoboLinux style of self contained extensions. But this again is in the community domain to build and contribute. Even though their is some overhead with self contained extensions there is equally many benefits. This could be seeded in the programming and scripting area. If/when successful then supporting infrastructure would surely follow.

For alternate architectures, we have microcore64, but for arm, I would want to wait for more stability and standardization. The early arm stuff does not do video well, current crop is a mixed bag. Many needed hardware drivers are not open source. Seems Adobe flash much be compiled to very specific cpu, etc. Also, would need to expand the team to include those that have such hardware. Certainly open to supporting more.

When you think about Android on tablets, it is a smallish OS to which you pick and choose adding applications, not much different in concept to Tiny Core. Android/Linux arm builds are very narrowly focused on a particular CPU. Whereas Tiny Core is more much generalized. Some have even suggested that Tiny Core be more focused on netbooks/tablets perhaps via meta-extensions? Again this could be community driven.

[roberts]

Here is an interesting read on current  Android/Linux on Arm.
http://projectgus.com/2010/07/open-source-in-android-tablets/

[tinypoodle]

IMHO the (successful) history of slackware dealing with ports without ever compromising the Intel(32) distribution or taking focus of it's developers away from it could teach a lot on the subject.

[ixbrian]

Since we don't have a formal "Ideas and Suggestions" section of the forum, lets use this post.

So please discuss. What is needed in the base? What is desired? And there is always much that can be done outside the base via extensions.

Here are a couple of ideas:

-Most other Linux distributions verify packages are digitally signed before installing them to improve the security of the system.  This helps prevent malicious packages from being installed (which could easily happen today with a Tiny Core system and a man in the middle attack).  Has something like this been considered for Tiny Core?   Perhaps this could be an optional feature that would only be enabled if the user had certain extensions (i.e. GPG) installed that could handle the signiture verification.  That way, it wouldn't increase the size of the Base, but if the user valued this type of security they could easily install the required extensions to enable this functionality. 

-As peterc pointed out, it seems like there isn't currently much in place to prevent malicious extensions from being submitted.  I'm not sure the best way to fix this is, but I agree that it is a problem.  Even source based systems aren't perfect (read "Reflections on Trusting Trust" by Ken Thompson, http://cm.bell-labs.com/who/ken/trust.html ) 

-Please GPL the backend CGI scripts that Tiny Core uses.  This would allow the community to make suggestions/improvements and better understand how everything works.  This would also allow people who setup their own tcz repository to run the CGI's on their own server so that their Tiny Core systems wouldn't need to have direct internet access for the appbrowser to work.   Plus, in my opinion anyway, opening up the backend code of a GPL project is the right thing to do (that's just me though, and is coming from a card carrying member of the Free Software Foundation..  )

[bmarkus]

An important and highly appreciated next step would be localization. I know, it is much up to the extensions, but lets start with the base and establish guidelines how to create extensions on a proper way and most important how to set it up. Actually TC is not UTF-8 friendly. I do not know how much size is saved not using UTF-8 however.

Personally when I try to set up a Hungarian environment I get only partial result, someting always fails and finally gave it up. BTW, TC tools like cpanel, appbrowser, ...also Englsih only.

[peterc]

An important and highly appreciated next step would be localization. I know, it is much up to the extensions, but lets start with the base and establish guidelines how to create extensions on a proper way and most important how to set it up. Actually TC is not UTF-8 friendly. I do not know how much size is saved not using UTF-8 however.

+1 for UTF-8 friendliness.

[curaga]

FLTK 1.1 does not support UTF-8, and we have no plans to move to an unstable/dev fltk. Beyond fltk and ncurses (and busybox), we are equipped to handle UTF-8.

The core fltk tools could get translation support (gettext), but any translations would remain extensions. Likewise, any fonts with more coverage shouldn't be in the base.

[bmarkus]

The core fltk tools could get translation support (gettext), but any translations would remain extensions. Likewise, any fonts with more coverage shouldn't be in the base.

Sounds good. Can we try it in one of the forthcoming betas?

[curaga]

Sounds good. Can we try it in one of the forthcoming betas?

It takes some work, and is not really a priority for us; any volunteers?

[eluring]

I have experience in using some of the gettext tools (xgettext, msgfmt, msgunfmt) in a bash environment and I am sure to get this done in tc, C++ (maybe with a little help), too.

My tc is running in LANG=de_DE.UTF-8, (having used the "vodoo" of TaoTePuh ((danke sehr)) posted on: August 15, 2010, 10:09:59 AM ) and after having installed a package of fonts my browser displays almost everything but east-asian, amharic and of course not: indic (no unicode, inicode).

So my short answer to the question

any volunteers?

is: I´d like to do it.

The score is now:

+4 for UTF-8 friendliness.

bmarkus, peterc, me and Tao (of course!) 

[tinypoodle]

I'd take the risk to bet browser doesn't support gothic

[curaga]

An update on the translations; after some research I found it doesn't really take much work on the apps itself, only ticking one box in fluid and adding a couple lines of code.

We're still discussing this, so wait a bit with the patches . Also note that this wouldn't enable utf-8 in the fltk apps for reasons noted above, iso-8859-1 only.


On avoiding the voodoo, we could of course post an extension with everything in locale-archive, but since that isn't modularizable in binary form, I doubt many users would like a 10mb+ pack with support for many languages they don't care for.