Tiny Core Linux
dCore Import Debian Packages to Mountable SCE extensions => dCore X86 => Topic started by: sm8ps on December 22, 2014, 07:57:44 AM
-
Greetings and season's greetings to everyone involved in this amazing project! I have followed the development of TinyCore over years and have made several fruitless attempts of getting it to work. Too far off the mainstream concepts for my limited knowledge but always fascinating.
Lately, however, I had to dive a bit into initial RAM disks, squashfs and the like. Finally, it all started making sense and my last efforts finally got me through to a working TC 5.4 installation on an Acer Aspire One ZG5 notebook. Wicd, Chromium all worked well. However the repos lack recent updates for e.g. web browsers and it all seemed a bit abandoned to me. Many apps were missing that I could recall from older versions of TinyCore.
So I turn to the forum and find out why it seems so quiet around standard TinyCore. It took me some time to understand what dCore is all about and how amazing it is. Absolutely brilliant! I got the basics working with ethernet, flwm and wbar. My first test case was to loadsce Xournal which worked perfectly well. LibreOffice mostly and wireless not at all so far.
Before I continue tinkering with it all, I would like to get some questions cleared. They all fall into the beginners' category so please bear with me! It seems now would be a good time to spread the word about dCore but the lack of introductory information makes it hard for newcomers to start off.
I would be very willing to put it all together on the wiki. My notes usually are quite exact so that I could easily extract relevant information. I also do maintain my privat Mediawiki site with a couple of hundred pages so that I certainly could structure things appropriately.
To keep things tidy, let me stop this intro here and continue with the questions in a new posting.
Cheers!
Stefan Müller, Switzerland
-
Thanks for taking the time read these questions and maybe help me advance!
Notice: I am using ub-dCore-trusty, release December 19, 2014.
LibreOffice
Installing LibreOffice worked but there were no icons. So I created a mega-package from a file
containing "libreoffice, libreoffice-{gnome,style-human,l10n-de,help-de}". That did show icons and everything.
- The internationalization is not working. Is there some type of helper script needed?
- There is no icon for LO in wbar but there is one for OpenJDK Java 7 Policy instead. Can one automatically have icons in Wbar for all loaded extensions? (Chromium for instance does come with one but not Xournal.)
- The apps do not show in the list of Applications (FLWM menu). Similar question to the above. (Chromium and Xournal both do show up.)
Wireless
I have tried several different ways to get wireless working (with ethernet available), however none of them was successful. I had created a mega-package from a file containing "wireless, wireless-tools, wireless-3.8.13-tinycore, wpagui".
- The download breaks with the following error: "Connecting to repo.tinycorelinux.net (89.22.99.37:80) -- wget: server returned error: HTTP/1.1 404 Not Found -- md5sum failed for wireless-firmware.tar.gz, exiting.." So it seems that this package is missing.
- What are these different packages for? Should it, in principle, not be enough to import Wpagui? If not, how are these programs started in order to make Wpagui work (or Wicd for that matter)?
Wicd
I tried myself to simply import Wicd by itself. An icon appears in Wbar but it is non-funtional. When launching Wicd from the command line, it throws an ImportError "No module named gobject (File /usr/share/wicd/daemon/wicd-dameon.py", line 46, in <module>: import gobject).
- Is the package not supposed to get all of its dependencies? (It seems that I do not quite get the point!)
- What else is needed to get Wicd working?
Apps browser, persistence
One thing that I am deerly missing from standard TinyCore is the apps browser. I just wanted to express how useful something like that would be to control the loading and managing of apps. I do realize well that dCore is at a rather early stage. At least it would be nice to have all the information about {import,update,load}sce (etc?!) together in one place on the wiki.
- Is there anything more than those threee?
- As far as I can tell, persistence works the same way as with standard TinyCore, right?
Last but not least thought
I recall somebody writing in the forum years ago that TinyCore was already then just about exactly what Google was trying to achieve with ChromeOS. IMHO, dCore is yet another leap towards a truly universal mobile OS. Great respect to the developers!
-
Hi Stefan. I will try to answer your questions.
Libreoffice-
Ubuntu does not have an easy "locales-all" package like Debian does, the locales have to be built separately. I have just looked into it and see how to do it, I will hope to work that in to be automatic.
Wbar icons and WM menus, we are somewhat at the mercy of the files Debian uses, but we can make adjustments for those that are needed.
WIreless-
Wireless-firmware imports fine here on Utopic.
The Wireless package, like all others, are independent of the kernel modules needed. For beginners, I recommend importing "kernel-all-3.8.13-tinycore" assuming that is the current kernel version.
Wicd has issues starting, and I have not used it nor wpagui. I do aim to give them attention one day.
Appbrowser-
There are 48000 packages in Debian Wheezy, and more if other repos like backports are added to it. Not useful to have them listed all in one long list, but maybe with a Search function one could narrow down what they are looking for. I am not a C programmer, but maybe one day I can have a Xdialog type of graphical utility that can be a front end to importsce. Since in that case small size is not the main point but look and feel.
Persistence is the same as with Core.
I do wish there were more documentation on dCore, but all my time seems to be taken working on it and none left for the wiki. Any help in that direction is always appreciated. Of course, things have been moving so fast lately that the dCore utilities have been a moving target.
-
Thanks for your help, Jason! And thank you for your great work on dCore!
As for LibreOffice (and maybe other apps?): could one say that Debian would be easier to use for international users in general? (Sorry, I am not very familiar with Debian. In TC5.4 I had used getlocale.tcz.)
I double-checked about the missing wireless-firmware.tar.gz on 'http://repo.tinycorelinux.net/5.x{/x86}/import/' and indeed it does not show up. I do not understand how it can work in Unicorn, assuming it does refer to the same repo. (The loadsce-script and major version is the same in both versions, isn't it?) Importing kernel-all-3.8.13-tinycore fails with the same error.
The app browser would be especially useful for managing my own SCE-files. The import is no big deal, indeed (at least not at the moment) but I did like the ability to make apps available on demand or after boot by a few clicks, especially combined with the overview of available apps. -- It is just a wish from the lazy user's perspective. :)
My next goal is to get wireless working but for that I do need wireless-firmware.tar.gz and wpasupplicant working, if possible with a graphical tool. I can try with Unicorn but it might be a few days before I get some more tinkering time ...
Cheers!
sm
-
Debian at this time is easier to use with i18n since it has a nice little bundle of a package locales-all. Ubuntu I will have to code that in.
All the dCore x86 ports use the same x86/import repo, so it should just work. I will boot with Trusty to make sure.
Ondemand works with importsce and dCore. Use the flag "-o" with importsce for the resulting SCE to be ondemand.
I admit the wireless graphical tools are lacking right now in dCore. But wpasupplicant works, as well as the wireless commmands. At least in what manner I use them.
Thanks for your input.
In time I will create an Xdialog utility to use as a front end to importsce, the scarce resource is time.
-
I wanted to start over with Debian Jessie on a clean install. (The previous one contained parts from regular TC 5.4 as well as from ub-dCore-trusty.) Now I cannot even import any SCE and need some help, please!
I removed the folders 'opt', 'tce' from the partition where the boot options point at. Booting gets me to a working prompt. (There is one complaint some lines above that, stating "-sh: /usr/bin/tty: not found", followed by "sh: tty: unkown operand".) The folders 'opt', 'tce' have been recreated and populated with sensible content. Ethernet works fine. Now I want to follow http://tinycorelinux.net/dCore/x86/README/README-X-Desktop.txt.
'importsce -b Xprogs' seems to work fine. (Though, before asking if I want to import Xprogs, there is an error "grep: /mnt/sda6/tce/debinx*: No such file or directory".) Nevertheless the list of packages if fine, containing Xprogs, Xtc, fltk-1.1.10. The creation terminate seemingly OK, albeit too quickly. Indeed, the directory 'tce/import/Xprogs' remains empty as well as 'tce/sce'.
I have checked the script '/usr/bin/loadsce' but could not spot anything obvious. Can anybody tell me what I need to adapt?
-
The new dCore-jessie.gz from 26-Dec-2014 21:15 (suppose this is my local time zone; size is 10.1M) resolved my problem. Many thanks for working on this issue! :D
I am (slowly) getting closer to a reliable set-up ready to be posted. BTW, who can provide me with a login for the wiki?
Cheers!
sm
-
Hi sm,
dCore is still a bit of a fast moving target. But there is great need of documentation. I am not familiar with the wiki or it's login, but I will look into it as I need all the help there I can get.
JW
-
Hi sm8ps
You can login to the Wiki with your forum user name and password.
-
Thank you Rich.
-
I started a wiki article for dCore... in August... or something. But I'm a hopeless perfectionist, and I'm ashamed I didn't publish it when I had at least gotten the sections down -- as there is *no* dCore wiki page!
Then we could have gotten it into shape by now, and quite a bit of effort would have been saved.
Of course, I know I'm not really involved in the project, and should have no obligations... but stil... a lot can be achieved by just setting something up really nicely for the community to have clear goals, and gradually refine it.
But we can only affect the future -- so I'm going to publish it soon.
Here are the sections:
===== General Info =====
==== What is dCore? ====
dCore is a minimal live Linux system based on Tiny Core, with the ability to install and download .deb (Debian-based) packages... sharing scripts with TC... and so on...
===== Installing dCore =====
==== Basic Install ====
The process as described by Jason... but I will also provide a basic script here.
==== Installing to flash-drives ====
Without a GUI tool (just bootloader installation and config), but will also direct to the usual tools.
===== ARM info =====
==== A7 ====
==== A10 ====
===== Contributing =====
Easy ways to contribute.
===== Laptops =====
==== Suspend ====
Suspend to RAM...
And perhaps a special script for aquiring Wifi and suspend packages...
===== Development =====
Here I provide my own info, for providing some good focus for the development of dCore.
===== About this page =====
Feel free to contribute to this page... and so on...
That looks fine, right?
-
Hi LichenSymbiont
... as there is *no* dCore wiki page!
Logging in to the Wiki allows you not only to edit existing pages but also create new ones.
-
Oh, that I know.
What I was trying to say is that I was just wanting to polish the wiki page offline, then this little project just slipped out of my mind.
So I should have just created a rudimentary page, instead of setting an unecessarily high standard for it.
A happy new years to you (and all)!
I hope this will be the year of commercial high-end VR, and a great burst of productivity for Linux and TC!
-
Happy new year to everyone from me, too!
Thanks for sharing your ideas about structuring the wiki pages, LichenSymbiont! It is good that we get the opportunity to discuss things before setting them up. After all they should provide the primary source of information about dCore.
My projected layout is a bit larger scaled than just one page. Let me explain briefly: judging from my (rather limited) perspective, dCore will eventually replace standard TinyCore. I say this based on the availability of recent software which is rather limited for current versions of TinyCore. (I am happy to learn different if I should be wrong.) My personal experience had been to install TinyCore 5.4 only to find out that much of the software (e.g. web browsers) had been updated for the last time in 2012. The concept of dCore is absolutely ingenious by combining the TinyCore technology with the current repos of big distributions.
I believe that many people will come to seek information about dCore/TinyCore and there will be several different aspects to cover. The current state of the wiki seems a bit scattered, making it quite difficult for newcomers to find a way into the "Core".
I would like to see a second start page for dCore added to the wiki which is linked from the main page. The structure could be imposed by introducing a namespace ":dCore". Thus the page ":dCore:start" would serve as entry point to the dCore realm. For the moment, my focus lies on desktop installation because I believe that people needing smaller systems should have enough background knowledge to extract the necessary information by themselves. (This focus may shift in the future of course.)
Among the aspects to be covered I see the following. These are preliminary thoughts; the list is necessarily incomplete and should be reviewed. Adding items at a later time is not an issue, of course.
- Core Concepts (from a practical point of view):
- What does dCore provide & how does it work? (Links to existing pages useful but probably helpful to explain in simpler words -- at least for me it would have been ...)
- What more is needed for a full installation? (Network, software, user data, persistence; same remarks as above)
- Portability
- Typical Installation: Frugal install with persistence.
- set up live system via TinyCore & install on USB-stick
- install manually on hard-disk (boot-loaders!)
- Wireless
- manual installation from outside
- installation from dCore (over ethernet)
- Laptops
- Installation of software packages
- Strategies
- Dependencies
- Updates
- Examples
- Development
- Contributing
I have no experience with installation on ARM devices so probably the section on installation needs to be reshaped. To facilitate the discussion, I have created the dCore namespace and copied this structure there. Laying out the details can be more easily done in the discussion page than here in the forum: http://wiki.tinycorelinux.net/talk:dcore:welcome (http://wiki.tinycorelinux.net/talk:dcore:welcome)
What we should discuss here is the intended audience(s) and set-up(s). Not to exclude anybody but to have a clear view about what we intend to put forth. That will make it easier to lay out the structure. We can certainly serve several different types of audience and there is room for enlargement later. As you can tell, I aim for the 101 section. :)
Cheers!
Stefan Mueller
-
My personal experience had been to install TinyCore 5.4 only to find out that much of the software (e.g. web browsers) had been updated for the last time in 2012.
Extensions are user submitted - rather than pointing out that they are out of date, submit updated ones ;)
-
Hi sm8ps,
I welcome any interest in dCore and appreciate any help whether it be in testing or documentation - documentation is definitely in need. Development almost always stays ahead of documentation in almost any software project. I hope things may settle down in the near future and I will spend some time on documentation as well.
But let's please don't criticize Core in the dCore section. I encourage contribution to Core, the two are not in competition but are a little different and hopefully mutually beneficial implementations of the same concept. One reason there are no or almost no premade or contributed packages for dCore is I want that time and effort to go exclusively toward the Core repo.
-
@Juanito: I see your point and you are absolutely right. On the other hand I must admit that mastering TinyCore presents a challenge by itself. I do not really see a way to creating extensions on my own and it seems that many others feel the same way. That is why I admire the approach of dCore.
@Jason W (and everybody else involved in the development of TinyCore or dCore): I am sorry if I may have stepped on anybody's toes which was not my intention at all! As described, I have striven for getting TinyCore installed and I do fully admire its technological approach. I see dCore as an enrichment of TinyCore by external repositories but I do recognize that it is the Core technology which makes it all possible. So I am very, very far from criticizing TinyCore or any of *Core.
Maybe my judgement about the future of *Core is wrong but that is not important at all. I was just reflecting my experience and tried to put it into a scenario of approaching dCore. Technically it is entry level and so is my knowledge of the community but I am willing to learn.
Sincerely,
Stefan Mueller
-
Hi Stefan, it's all good.
What I will do is start a thread listing the basics of dCore usage, starting with the basics and appending to it as I can. Maybe that can help others create wiki entries. Most of dCore how to's are scattered in this forum section, I will try to distill what I can into that thread.
I will start a new thread so this one can focus on the discussion of the wiki.
-
Thanks for your encouraging words, Jason! Distilled forum information with your overview would be a great source for wiki pages. Though, I believe I already have studied and bookmarked the most important threads. So if you want to wait until we have set up something in the wiki that could save you some time. As a preliminary action, I have included the sources that I know of to the wiki page. Feel free to add what is missing!
Cheers!
sm
-
Ok, I would like to wait and see what you have already, and then I can help polish it if needed. I just found a major bug in the updated update routine in release candidates, it never ends. It is not that I don't have interest in anything but dCore and tending to bugs, I would like to be able to at least maintain my Core extensions I originally put up, but my TC time is somewhat scarce nowadays and I am forced to focus. I plan to spend time with deb2sce startup scripts and get more packages working which is my next goal once I smooth out the latest base dCore changes.
So thanks for volunteering your time with the dCore related wiki.
-
sm8ps:
"Thanks for sharing your ideas about structuring the wiki pages, LichenSymbiont!"
No problem! I hope we can create some great pages together! :)
"It is good that we get the opportunity to discuss things before setting them up. "
Indeed, especially now as it seems everyone is waiting for everyone else to publish first ^^
Not to worry though, as your structuring and ideas are very sound.
Your idea of making separate pages is very fitting, as I have some extra ideas which are relevant, but not really fit for the main page.
Like information for integrating other distros repos, as I think all the major distros have a fork/rewrite for their package manager, which can be run on other distros.
Like the Paludis package manager for Gentoo ebuilds: http://paludis.exherbo.org/overview/features.html
And about intended audiences: if we just have an install script for a basic graphical system, then it will be just as simple as TC -- if you are comfortable with a terminal package manager.
I have a nice JWM (Joe´s Window Manager) configuration, which would allow easy access to a terminal with the package manager.
With JWM we can create a menu with categories for common packages you might want to get (so just a click, and it will lauch a terminal with importsce -options package_name).
So no need for some extra program to view common packages -- just a lovely WM ^^
I have a fast application-listing script for it as well, and a partition listing script (so no need to open a file-manager and navigate to a disk).
But the JWM package in Debian is insanely huge, so we should probably use TC's or a custom build of it.
I'm not suggesting we create everything through scripts and JWM menus though, just the basics.
FLWM doesn't have a panel for tray-apps either, and JWM is fast and fully featured. It's also well-written.
Well, that was a lot about dCore usability improvements...
But what I was trying to get at, is that dCore can have a low entry-level, and still be very technical.
As to install all the things a new user would expect to find can be done with just the mouse.
Something not even TC has.
Back to the wiki:
So my intended audience is mostly developers (meaning anyone interested in contributing, and learn everything about dCore).
sm8ps:
As we will now have to cooperate, or at least communicate, we could simply work on separate pages.
You can get started on the intro page, and I on the development page, where I write a guide to the scripts, and list links and other stuff.
But I will first publish my writing that fits into the intro page, to the dCore:welcome discussion page.
Sounds good?
Edit:
I didn't think you had already fleshed out the page -- didn't even look at it (I must have lacked sufficient glycogen in my brain or something).
And it's looking good! still I will publish my introductory sections on the discussion page.
-
Well, I just edited the dCore:welcome page, and you can revert it, edit it or whatever, but I place some of my more polished writing directly on the page now.
-
LichenSymbiont,
glad to join forces with you! I am sure we can put up something useful together and over time will develop a usable work-flow. I suggest to extract single topics from the main page and develop them into individual pages that we can link to. That way we can work individually but still see each others progress.
My main concern is that we restrict the page contents as strictly as possible to one single topic. Sticking to such modularity will enable us to design something like page collections for different audiences. Entry level visitors probably want to know how to get their system up and running with some standard set-up whereas developers will want to know about tweaks and possibilities. Plus of course we can profit from each other's work without rewriting existing parts.
Acutally, I envision the welcome page giving a brief overview and linking to different page collections (including an index of all available pages). These collections will make the structure of sections obsolete but until then they can serve us as guiding lines as to what topics should be contained in the wiki. So for a first phase I suggest keeping the welcome page as link collection but replace it later by some more tailored collections.
My main question to you about structuring the content is if you can see to fit your topics in the given structure of sections. Possibly they are too closely tied to each other, which would make it difficult to isolate topics. Of course, we can change things as we make progress but I would like to have as clear a view as possible. For the time being, I have included your suggested topics in the overview (attributed to you by >LS) plus section about scripts.
This thread has shifted quite radically from its initial context. I suggest, we close it soon and shift the discussion of the structure of the wiki pages over to talk:dcore:welcome. I am looking forward to producing useful content together with you and others!
Cheers!
Stefan Mueller
-
RE jwm:
I see a bug in the dependency mechanism. The awk routine that was originally used and still used for extra repos works as needed, the new grep does not when there is a string of this package OR that package OR that package as is the case with jwm. The grep routine brings in all of those, not just the first one found.
I will fix the grep handling of this, that will greatly reduce the size of jwm.
jwm imported alone is about a 18mb SCE.
jwm with xorg-all as a dep is about a 3mb SCE.
jwm itself is about a 260kb Debian package, so if using a larger imported SCE from a file list as a dep, jwm.sce could be roughly as small as the 260kb package. I will work on this tonight.
-
I see a bug in the dependency mechanism. The awk routine that was originally used and still used for extra repos works as needed, the new grep does not when there is a string of this package OR that package OR that package as is the case with jwm. The grep routine brings in all of those, not just the first one found.
Wow, I didn't expect this to turn into you finding/fixing a bug!
That's great -- I thought it was just some Debian packaging flaw -- with JWM being used as a full-featured desktop or something.
But I didn't look into what packages were listed as dependencies very well... I should put this as a contribution suggestion as well: to keep both eyes on what the package manager is doing!
As you may catch some flaws and bugs.
glad to join forces with you!
Me too, I hope we will have an enjoyable and flowful cooperation.
A bit random: but do you use Stylish (the Firefox addon (which I think exists for Chrome as well), as a black theme is really good for the eyes. As I must say a dark background really makes writing and reading more enjoyable, and your eyes will thank you.
So for a first phase I suggest keeping the welcome page as link collection but replace it later by some more tailored collections.
All great ideas!
At first it's just for those who are involved with the project, and are working with the wiki.
Any wiki page saves people time and energy at this point -- well except us who spend time writing it.
So we have to keep it enjoyable first of all. And for me that means keeping the scope broad, and not make the process stale by a too narrow focus.
I will definitely be learning as I go along, as I will be looking up other package managers, and try integrating them with dCore.
Well, in a much more rudimentary way than the dCore scripts of course.
Cheers!
-
I just read the wiki page, and I wanted to say thank you for the contributions.
Oh, and below is (for now at least) the total options for importsce and the relevant entries in /etc/sysconfig/sceconfig.
Usage:
'importsce' with no options will prompt for characters of desired package name.
'importsce -l' to use a file list of packages - 'importsce -l FILENAME'.
'importsce -b' to add package to sceboot.lst.
'importsce -r' to use RAM for unpacking source debs.
'importsce -s' to list sizes of packages to be fetched and installed.
'importsce -d' to make use of existing SCE packages as dependencies. A select menu will appear.
'importsce -o' to add resulting SCE package to ondemand.
'importsce -n' for non interactive mode.
'importsce -u' for update mode, syncing a new debinx files.
'importsce -p' for preserve debinx mode, use existing rather than fetch new for better performance.
These options can be placed in a file called /etc/sysconfig/sceconfig so they do not have to be called on each import. Below are some entries the file can contain, I will update the file in the base of each dCore as ENTRY=FALSE so the user can just change it to ENTRY=TRUE and back up that file. The -u option is default and does not need to be specified.
The below is the same as the -p option. Not recommended for sceconfig use, but just per session use if one has already refreshed their debinx packages files.
PRESERVEDEBINXMODE=TRUE
The below is the -n option, will result in no prompts to answer, will run from start to finish by itself except in the case of being combined with the -s size option and not enough free space is found in RAM or storage.
NONINTERACTIVE=TRUE
The below is the -k option, man pages and docs in /usr/share will not be deleted before merging into the SCE.
KEEPDOC=TRUE
Below is the -d option, allowing one to choose one or more SCE packages to use as dependencies to reduce duplication of packages between the contents of SCEs.
DEPS=TRUE
The -r option. Use RAM for unpacking of the Debian, prebuilt, and data file packages. Most useful and necessary when a Windows filesystem is being used for the TCE directory. Import will not let one use a Windows filesystem for unpacking and will exit with a warning to use the -r option next time if a Windows filesystem is detected.
RAM=TRUE
This is the -s option, will calculate needed RAM and HD storage requirements in detail.
SIZE=TRUE
The -b option. Will enter resulting SCE name in /etc/sysconfig/sceboot.lst as to load on each boot.
ONBOOT=TRUE
The -o option. Will place SCE in the ondemand menu.
ONDEMAND=TRUE
-
I'm glad you're happy with it. :)
Now I wonder where to place all that info you posted. As it's such specific information, it would fit into a man-page for importsce.
But we can also place it on a specific importsce page.
The main-page should just contain the structuring info, links, and the basic information for now.
And I will mostly be writing a development page for the dCore wiki today.
-
'Using importsce' would be my suggestion for the page name; this would make it easy to search for, as like from Google.
-
Forgot to post my answer to Jason W this morning. Here it is:
Great, many thanks! For the time being, I have added a link to your posting to the list of sources that will be used for the wiki. Should happen soon!
-
Just read the dcore:core_concepts_explained page. One detail: though Core uses busybox symlink from /bin/busybox to /bin/ls. dCore has all it's busybox invocations in /bb, ie /bb/ls. /bb is last in the PATH in dCore, so installing the package that contains /bin/ls means that after SCE is loaded then /bin/ls from the full package will be used when "ls" is called at the command line unless /bb/ls is specified, or in a script useBusybox is invoked after /etc/init.d/tc-functions has been included with the line ". /etc/init.d/tc-functions".
-
Ah, I see. Thanks for proof-reading! I happened to browse some scripts yesterday where I noticed the /bb path but I did not see anything behind it. Now it makes perfect sense. Clever strategy, indeed! I will add your information in the wiki page soon.
Cheers!
sm
-
On browsing the wiki, though I may have said it before, but I want to say thanks for the work. I will peek in it and make aware of any changes as they my happen. I am hoping that the main concepts and routines are in place now and the focus can then be on packages and creating the needed startup scripts to get those working that do not now but can be in relation to dCore.
And, I am familiar with the "Smart Questions" classic thread. But it asks you to:
Try to find an answer by reading the manual.
Try to find an answer by reading a FAQ.
Try to find an answer by searching the Web.
Try to find an answer by asking a skilled friend.
Well, with dCore there is no manual (wiki is just materailzing), and there is no FAQ, if you find much on dCore via Google let me know, and if you have a friend well versed in dCore send him my way. What I am saying is that do not worry about perfection in contributions to dCore in the same way that we do with a normal existing project. If you have documentation but may contain errors, contribute. If you think you found a bug, let me know. I will let you know if there is need for correction. If in doubt, contribute. Sure, do the homework you are able at your own level of knowledge, but dCore is going in uncharted territory for both you and me, and we will make it work together. I say this for anyone in the future who wants to be a part of dCore and it's progress.
-
I've finished (at least the main stuff) my guide to the scripts, and created the development page for dCore:
http://wiki.tinycorelinux.net/dcore:development
Which I've linked to from the welcome page.
Take a peak... I don't completely understand the scripts (in fact I thought I understood more before I started the guide ;D), and I'm learning as I write.
So there might even be some huge flaw...
But I hope it will make it easier to understand the important specifics of dCore's scripts.
I will go through it again later tonight, and continue to study the scripts, and improve upon the guide.
And great work with the additional pages sm8ps!
JasonW:
Understood!
And "If you have documentation but may contain errors, contribute" is something I should really internalize!
I should at least contribute the general outline of things, so others can partake in the process.
-
This is awesome, many thanks for putting this most valuable information together! It will take me some time for reading it thoroughly.
Time is the scarce resource at the moment but I will get back to the wiki soon.
Cheers!
sm
-
Thanks!
I thought it was pretty awesome writing it -- but when I read it... it's just "Then...", line after line...
I think a well-documented script would be better. It could be uploaded to the ftp for dCore.
We will see if I get around to it... I think Jason would also be more comfortable with just adding a bit more documentation for the scripts, for instructive purposes?
Cheers!
-
Two quick suggestions without having given them too much thought:
. The readability could be improved by putting the individual points into a bullet or numbered list. I would indeed consider this helpful. (But I dislike the way it is implemented in Simplemachines forum ...)
. How can we make sure the information stays up-to-date with possible updates of the script? Should your comments maybe embedded into the script themselves? Or should we just keep an eye on the changelog? I think you should include a version number or date if possible.
Cheers!
sm
-
Yes, it definitely improved readability.
And I will only be keeping more and more in touch with the scripts, as now I really understand enough...
... I notice my typing is really smooth today, after typing a lot yesterday... I should really keep exercising writing and typing more consistently!
Oh, and I will be embedding the documentation in the scripts. Though I'm writing a overview of the scripts functionality now, so you get into the right context and mind-state when studying the scripts.
-
Greetings to anybody following this thread! I have not dropped dead but just pushed to the floor by a humongous load of work. However, now I do have some time to invest into dCore.
I put together a page about a beginners-101 installation of dCore:
http://wiki.tinycorelinux.net/dcore:usb_installation_test-drive (http://wiki.tinycorelinux.net/dcore:usb_installation_test-drive)
It is referenced from the welcome page http://wiki.tinycorelinux.net/dcore:welcome (http://wiki.tinycorelinux.net/dcore:welcome)
where I took the liberty of moving some things around in order to make its layout more clear.
If you find any mistakes, don't hesitate pointing them out! Proof-reading is very welcome!
Cheers!
Stefan
-
Thank you for your documentation!!
Couple of things:
Multiple virtual terminals via the multivt boot code.
Same persistence across reboots via backup like standard Core.
-
Same persistence across reboots via backup like standard Core.
I do not know much about *Core in general but it seems clear to me that the backup process is "inherited" from standard Core.
Do you mean that I should speak of *Core if possible in the article and only specifically mention dCore as it deviates? That might be helpful in order to make the distinction clear as there is quite a lot of material for TinyCore around but very little about dCore which can get confusing for novices.
Or is there anything to add with respect to backups?
-
Backup and persistence is exactly the same as in Core, same commands, same code, etc. So the instructions for backup and persistence in Core apply to dCore.
-
OK, got it! I shall include this information in the wiki soon.
Thanks for your continuous efforts with dCore!
-
well, I just had fast a look at http://wiki.tinycorelinux.net/dcore:usb_installation_test-drive ...
I wish I knew about that wiki before, it gives indeed few nice hints, which took me hours to discover ::)
If I can give few suggestions for improvements:
1) put a link to http://wiki.tinycorelinux.net/dcore:usb_installation_test-drive into http://tinycorelinux.net/dCore/x86/README , beginners deserve it
2) document all dcore boot options existing so far. Simply do a grep run search on the whole dcore initrd about "/proc/cmdline", that will take you where all boot options are
3) document all sce-import options existing so far. Unfortunately I know, that's not so simple, as they are spread around many scripts... ;)
-
Thanks for your substantial comments! I know what you mean when talking about discovery hours. :) Maybe you can extract some documentation from your discovery hours?
The wiki page about dCore has remained in a dormant state for the last few months. It is growing, though, and hopefully will soon reach a certain level of maturity so that we can "advertise" it more publicly.
1) I do not know who is in charge of the files section but I had wanted to comb through the README-files anyways. I will keep your suggestion in mind. JasonW must have write access for sure.
2) Great hint, thanks! AFAIKT most of the boot codes are well documented, so your method picking for the remaining ones is well appreciated. I shall put together a page on that or update an existing one.
3) JasonW has given a complete list (as of January 5th) in
http://forum.tinycorelinux.net/index.php/topic,17863.msg107914.html#msg107914 (http://forum.tinycorelinux.net/index.php/topic,17863.msg107914.html#msg107914)
which will serve as a base.
Cheers!
Stefan
-
You are welcome :)
Thanks for your substantial comments! I know what you mean when talking about discovery hours. :) Maybe you can extract some documentation from your discovery hours?
well, ok :)
for example, it would be honest to warn users who dl alsamixer, whose settings, if not appropriate, can produce damages.
In fact I read that in the dcore forum somewhere, I gave it a cautious try, and by me it was true, so I have to thank dcore community for that useful knowledge now.
Since it seems that info is kept somehow unknown to the mass of users, dcore could step already ahead ;)
3) JasonW has given a complete list (as of January 5th) in
http://forum.tinycorelinux.net/index.php/topic,17863.msg107914.html#msg107914 (http://forum.tinycorelinux.net/index.php/topic,17863.msg107914.html#msg107914)
which will serve as a base.
those are the "officials" :)
there are more...
I'm spending my last 2 weekends in digging out the "unofficial" ones... probably those are the remains of old tests, forgotten, use-drop codes, and so on... I don't know why they are kept hidden... anyway, they are coming out extremely useful, I built my whole new system on those hidden features, at such a level that, without them, there would NOT be my new system, at all ;D
I just say one: did you know you can already now exclude packages from importing, just putting them in a file named "PKGEXCLUDELIST"?
-
for example, it would be honest to warn users who dl alsamixer, whose settings, if not appropriate, can produce damages.
In fact I read that in the dcore forum somewhere, I gave it a cautious try, and by me it was true, so I have to thank dcore community for that useful knowledge now.
Since it seems that info is kept somehow unknown to the mass of users, dcore could step already ahead ;)
Would you please be more specific about the kind of damage and provide some sources? I would not know what to dig around for myself.
I'm spending my last 2 weekends in digging out the "unofficial" ones... probably those are the remains of old tests, forgotten, use-drop codes, and so on... I don't know why they are kept hidden... anyway, they are coming out extremely useful (...)
I just say one: did you know you can already now exclude packages from importing, just putting them in a file named "PKGEXCLUDELIST"?
Let me set up a page (or extend the existing one) about this subject and then you are invited to please add your valuable findings there. I shall ping you by PM, OK?
I built my whole new system on those hidden features, at such a level that, without them, there would NOT be my new system, at all ;D
Would you care to exhibit your system on a page under http://wiki.tinycorelinux.net/dcore:welcome#sample_installations (http://wiki.tinycorelinux.net/dcore:welcome#sample_installations)? It sounds very interesting!
-
Would you please be more specific about the kind of damage and provide some sources? I would not know what to dig around for myself.
I read it here http://forum.tinycorelinux.net/index.php/topic,18225.0.html , I did exactly what that person did, it happens the same, since I can't touch my speakers (inside the case) I put my nose on the holes from where the sound comes out, and after few secs it started smelling funny... I cut out the power at once.
You can try yourself, but careful, put your nose there!
Let me set up a page (or extend the existing one) about this subject and then you are invited to please add your valuable findings there. I shall ping you by PM, OK?
I have nothing against sharing my discoveries, but its a lot of stuffs and efforts in reorganizing, I don't know how many people would be really interested in that...
Would you care to exhibit your system on a page
my dcore box is very basic and generic, xorg,fluxbox,pcmanfm,leafpad,alsa,wireless,opera ... what is amazing is the size: 67 Mbytes ... ;D
-
Hi dicorer
Would you please be more specific about the kind of damage and provide some sources? I would not know what to dig around for myself.
I read it here http://forum.tinycorelinux.net/index.php/topic,18225.0.html , I did exactly what that person did, it happens the same, since I can't touch my speakers (inside the case) I put my nose on the holes from where the sound comes out, and after few secs it started smelling funny... I cut out the power at once.
You can try yourself, but careful, put your nose there!
That individual caused their own problem by setting all the volume controls to max and overdriving the speakers. Alsa has no
knowledge of the speakers power ratings nor of the capability of the amplifier driving them. When you set the controls on an
audio system too high it will clip the peaks of the waveform. The sections of the waveform that are clipped are applying a DC
voltage to your speakers and causing them to heat up. Speakers are not designed to handle DC voltages.
-
Thank you for your technical explanation of that phenomena :)
What I want to say is that, users deserve to know that "playing" with sound settings (in Linux/dCore is alsa), they can damage their speakers.
When I was young, I played with car stereos too, to bump up the sub-woofers and attract chicks :) but I was warned by many sides to pay attention to many technical details which could damage my very heavy and expensive sub-woofers ;)
Other matter is PCs, as for PCs, I work with PCs from the time of Commodere64 8) and never heard, before now, of such a thing as, play a note on your PC and burn your speakers.
But as I see, it is reality, and whatever is the cause I thing other users should be warned, as I was.
-
It is no different on Windows or OS X, or your stereo set.
-
Thanks curaga for your opinion, but you are not right ;)
I don't want to keep going on this OT, but I have to inform you that on Windows there is no such "complicated" mixer as alsamixer.
Btw, it so happen that on the same PC, I have a partition with Windows, and there, I have often to push the volume to 200% on VLC, to hear properly the dialogues.
-
dicorer - Does not alsa by default start with all channels muted? So it is up to you to test and see what level you want them on, if nothing else just not to be uncomfortably loud.
-
Sorry for also being off-topic, but this doesn't make sense. To me Alsa blew my speakers is not valid. Alsa is not to blame. When i open alsamixer on my system without sound level persistence, default master volume is not muted but set <50%. For argument sake, even if default volume was set higher, wouldn't it be logical to check volume level before play testing sound...and if using exterior speakers turn down the volume dial beforehand. Analogy: playing with a loaded handgun, accidently shot myself, stupid gun, must warn everyone that loaded guns are dangerous ???
-
this OT is becoming very annoying...
I don't personally care is the sound mixer for Linux is produced by alsa-corporation or capitanamerica-noprofit.
In the sound mixer available for OS Linux, there are lots of options, if someone who is not expert, set an incorrect option, that can damage the speakers.
That's a fact.
If you shoot yourself with a gun, you can't complain with the gun, because you grew up from the childhood everybody told you, movies, songs, school, guns are dangerous.
If you damage your speakers in your tiny pc, because you tried that option in the sound mixer for Linux, then nobody never told you, sound mixers for Linux are dangerous.
-
dicorer,
You are saying that the sound in Linux in general is dangerous. Even if so, that is not an issue with dCore and I don't think we are interested in the Linux vs Windows sound.
-
Let it be so then.
It started as an OT, but now I see it might be not.
I tested what that individual wrote, exactly under dCore-utopic, using alsa downloaded by sce-import.
As I said previously, I never heard of a sound mixer capable to produce hardware damages.
I used lots of OSs and never had such a issue.
Now I verified myself, this issue is real, verifiable for sure under dCore.
So if I were you, I would not rush as usual, denying and/or ignoring responsibilities and issues.
Said so, I see now clearly your attitude towards my efforts in improving this tool.
I had a bunch of glitches (or better, bugs) more to report, but I'm realizing its just useless.
I'll leave that to someone else, and good luck Ladies ;)
-
Good by troll.
-
+1
I have been patient, too patient while I watched one person waltz in and monopolize the dCore forum area and my time here which the drama would eventually cause users and contributers to lose interest. dicorer was rude from the start, was given chances but now has been banned.
Now we can move on with our usual business here.
-
If you shoot yourself with a gun, you can't complain with the gun, because you grew up from the childhood everybody told you, movies, songs, school, guns are dangerous.
My goal is to have everybody grow up from childhood and have an elaborate source telling them how to get going with dCore. :)
Back to topic now! I have put forth some two pages intended as technical reference of the boot process and its associated scripts for the rest of us. http://wiki.tinycorelinux.net/dcore:welcome?&#technical_reference (http://wiki.tinycorelinux.net/dcore:welcome?&#technical_reference)
I honestly do not know how much good it can do without studying the source code itself but maybe it can help others get a quicker over-view of how things work. There are still quite some big gaps, both in my understanding as well as in the exposition. So I would like to ask anybody with enough of an overview to point out any clues that I have missed. As of now, I am still working through the rest of the code and probably will get back with a list of questions.
Other than that I cleaned out http://wiki.tinycorelinux.net/dcore:welcome?&#core_concepts (http://wiki.tinycorelinux.net/dcore:welcome?&#core_concepts).
Cheers!
sm
-
Great changes to the wiki sm8ps! Especially having a more complete installation-guide, instead of my modified copy-pasta of the README.
But as it's now, the link to the sample installations isn't very useful ^^
The reasoning behind having a simple installation "script" at the introduction was just to show how simple it is. Hopefully it will be as simple as running an installation script in the future, and we can boast with that in the into instead ;)
Well, I don't have much time to spare installing and testing it, but I can at least outline some theoretical installations.
I don't want to continue the drama, but banning will probably not do much good. Remember: you don't have to deal with it yourself -- recruit the community.
All you need to do is make the standards clear, and anyone violating those standards will be dealt with by the community. Not suggesting lynching -- as that's the kind of world we live in. But if we lived in a world following basic principles, and people were properly educated... all we'd need is to communicate our standards, and the other person will be enlightened ^^
*Unicorns and butterflies appears all over the screen*
Damn, those Gentoo ebuilds... well, that will have to wait until I finish my super-GUI for Linux. Then you will just be able to download a proper Alsa config with a click as well, and many other useful config files.
-
I can't edit the message, but I must have skimmed over the "Installation of software packages" instead of the Sample Installations section, because I have the autohide toolbar addon for Firefox... hiding that section... and seeing only text without links, I thought it wasn't finished...
Well, just wanted to clear that up.
I will continue on a practical installation guide -- where you can just copy it down, pretty much. As it's important that people get it up and running as quickly as possible, and then learn from there, and make modifications.
But of course, the Readme's does a good job already with that, I just want to have it easily accessible from the Wiki.
-
LichenSymbiont -
Perhaps a ban was not necessary, after all he had already left. But his final insult was the last straw, and he made it clear it was his way or the highway , and he already chose the highway before action was taken. Even after I had made it clear I was interested in bug reports and just had fixed a bug or two he helped find, he quickly after accused me of continually ignoring and denying responsibility. I appreciate that the community is here and willing to stand united. As for dCore forum standards the standard here is the same as the rest of the forum, no real need to re-iterate general forum rules. They are well spelled out in the below link for anyone reading this and not familiar:
http://forum.tinycorelinux.net/index.php/topic,7738.0.html
But to put it simply, trolling is just cause for a ban. We all have our bad moments, I know I have had mine. And folks that know me know I am usually very patient. If a long time user or contributor has a bad moment we will work through it, but that was not the case with this member. Anyway, lets get back to business. :-)
-
LichenSymbiont -
Also, thank you for your work on the installation guide.
-
Yes, you are very patient and responsive. He just had skewed expectations.
But that's something I'd like to improve upon as well, perhaps by adding "don't put all responsibility on the developers, just be patient." in the contribution section of the wiki, to start with.
To all:
And about the installation guide with samples, I will be making a simple installation script, which anyone can improve upon.
And you can just give feedback here.
-
I've added
Write down the problems you've encountered in a text-file, and try make a neatly structured report. And be patient with the developers – who are developing in their own free time. The better your report, the better it can be addressed by the developers. Through this practise, you will be able to consider the problem better yourself, and might even be able to report a neat solution instead of just the problem!
To the contribution section of the welcome page now.
We should learn from our own and others mistakes, and improve things as best we can, instead of just reacting to something bad.
Even to social problems there are technical solutions :)
Hmm, and the dCore wiki should be more visible. Like having the link written out to the TTY when dCore is done booting, and a sticky.
As it's really getting into shape... it's better than nothing -- and people have been warned of the alphaness.
-
I have developed a page about setting up wireless:
http://wiki.tinycorelinux.net/dcore:wireless_set-up (http://wiki.tinycorelinux.net/dcore:wireless_set-up)
that is linked from the welcome page.
The main source was the following helpful forum entry by JasonW
http://forum.tinycorelinux.net/index.php/topic,17211.msg103304.html#msg103304 (http://forum.tinycorelinux.net/index.php/topic,17211.msg103304.html#msg103304)
Hmm, and the dCore wiki should be more visible. Like having the link written out to the TTY when dCore is done booting, and a sticky.
As it's really getting into shape... it's better than nothing -- and people have been warned of the alphaness.
Regarding the wiki, I do not think that we are there yet. Seen through the eyes of somebody seeking for information, there is quite little content so far. Other than the development page, the sample USB-installation, the new page about setting-up wireless and some incomplete technical information I am not seeing much useful information.
We are on the way of producing more and I do have some more pages in the works. However, the way it stands right now, I want to keep keeping it in a quiet alpha stage rather than publicly advertising an obviously unfinished oeuvre.
I am sure that by the end of this month we shall be at a point where the basic information is complete enough to provide more information than uncertainty. Then we can think of the best ways to make the dCore-section of the wiki more visible.
Cheers!
sm
PS: forgot to mention the development page in the original post. Sorry!
-
Just published Beginners-102, step-by-step outline on how to install a basic dCore-desktop with persistent home and opt under http://wiki.tinycorelinux.net/dcore:welcome?†-architecture (http://wiki.tinycorelinux.net/dcore:welcome?†-architecture).
"The human mind always makes progress, but it is a progress in spirals." (Madame de Stael)
-
I have produced two pages about localisation:
http://wiki.tinycorelinux.net/dcore:welcome?&#localisation (http://wiki.tinycorelinux.net/dcore:welcome?&#localisation)
Feed-back welcome!
-
sm8ps - Thanks for this much needed documentation. I have only had time to glance over it but it is looking good!
-
Added page about locales-all package, linked from
http://wiki.tinycorelinux.net/dcore:welcome?&#locale (http://wiki.tinycorelinux.net/dcore:welcome?&#locale)
Could somebody who is using dCore (Debian) please look over it? I had a working Jessie-installation but that is not functional at the moment.
-
Added page about layout switching on the console linked from
http://wiki.tinycorelinux.net/dcore:welcome?&#keyboard_layout (http://wiki.tinycorelinux.net/dcore:welcome?&#keyboard_layout).
-
Added page about substituting some more specific video driver packages for the xorg-all extension linked from http://wiki.tinycorelinux.net/dcore:welcome?&#video (http://wiki.tinycorelinux.net/dcore:welcome?&#video).
Does anybody have any information about doing the same for the wireless.sce? I am dearly lacking technical expertise in that field.
-
Hi
Thanks sm8ps a lot for your documentation!
About the video driver page, you could add the fact that some driver needs firmware.
-
You are welcome!
About the video driver page, you could add the fact that some driver needs firmware.
Unfortunately, I have reached the outer limb of my knowledge when it comes to dealing firmware. I have no experience with the subject but only some vague ideas about it. At best, they could serve to confuse any reader. :-[
Would you please add what is necessary to the wiki?
-
One very important tidbit. Compiling kernel modules for dCore is done on the Core release that the shared kernel was built with. No compiling moduiles on dCore but for personal use.
And once again and always thank you sm8ps for your hard work and dedication that is going into this.
-
Huh?! I am sorry but I do not know where to put your statement, both intellectually as well as editorially -- nor can I grasp its importance. Could you please provide some more background information or give a use case? That would probably help determine how/where to include this in the wiki.
Exploring unknown territory is fun past-time and I am learning a lot, albeit on a somewhat slow pace. I wish I knew some more of the technical technicalities like, well, drivers and firmware for example. :)
Thank you for making this excellent plattform for tinkering and learning available!
-
Probably anyone building kernel modules will already know that with the shared kernel that was built on Core, modules will have to be built there as well.
The main kernel image needs to be built with the same version of GCC as the modules. Preferably, just build with the same system.
So probably not a need for that to be in the wiki.
-
About the video driver page, you could add the fact that some driver needs firmware.
I happened to encountered the opportunity/necessity of diving more deeply into matters of drivers and firmware. So I could make sense of your comment and added it to the wiki.
So probably not a need for that to be in the wiki.
Amen! (http://en.wikipedia.org/wiki/Amen#Etymology) ::)
-
Sorry to revive a dormant thread but it seems to be the appropriate one. ;)
The boot-codes "opt" and "home" do create their respective directories in the specified partition if they did not exist already.
However, "tce" does not so; furthermore it takes a directory instead of a partition.
Is this expected behavior or am I over-looking something obvious?
-
I have investigated a bit on this and found out that the described behavior happens when specifying partitions by device files ('/dev/sdXn'); i.e. '/home/' and '/opt/' do get properly set up whereas 'tce/' does not.
This behavior changes if the boot-code is specified as "tce=LABEL=<LABEL>". In this case, 'tce/' does get properly set up.
I do not think that this is expected behavior.
-
The protocol is to specify tce=sda2 not tce=/dev/sda2. But if home and opt work when doing that, I can use that same logic for tce.
-
Aha, I did not know about this.
IMHO it would make sense to have the same behavior for all three boot-codes. I shall add the information to the wiki.
-
Not sure if this helps, but if dCore is based on Core then for consistency here's what the Core book says:
10.1. tce - extensions directory
The tce bootcode specifies where to locate and store the extensions
and backup. If it’s not given, the system will scan all drives for a
first-level directory called /tce. Thus it may improve boot time to
specify where it is.
It needs to be given when there are multiple such directories (for
example to use your USB installation even on machines with Core
on the hard disk), or if the directory is not named tce.
The bootcode supports both labels and UUIDs (universal
identifiers), which are a necessity with USB drives, as you can’t tell
beforehand how the USB stick might get named.
Examples:
• tce=sda1
• tce=sda1/mydir
• tce=LABEL=mydisk
• tce=LABEL=mydisk/mydir
• tce=UUID=fho4-3436t
• tce=UUID=fho4-3436t/mydir
10.5. home and opt - persistence
The home and opt bootcodes let you keep the respective directories
on a persistent disk. Each bootcode takes either a drive name, a
label, or an UUID.
These options are covered in more detail in the persistence chapter.
Examples:
• home=sda1
• home=LABEL=mydisk
• home=UUID=fho4-3436t
-
Right on the spot, nitram. Thanks!
-
Yeah, best to be expected to follow the longstanding boot code convention. The home and opt persistence was coded long ago, and has the /dev stripped from the entries if they exist evidently. The TCE directory setup was more recently (recent years) changed to call on tce-setup, and that stripping of /dev apparently was not added in. That is the reason they behave differently if the /dev is mistakenly added to the boot option line.
-
Agreed! I had neglected the CoreBook as reference. I have corrected the wiki.
-
Hi
I've added this to the wiki:
http://wiki.tinycorelinux.net/dcore:keyboard_layout_in_console#keyboard_layout_-_tinycore_way (http://wiki.tinycorelinux.net/dcore:keyboard_layout_in_console#keyboard_layout_-_tinycore_way)
kmaps could be added to the dCore repo.
-
Great, thanks a lot! I went over the structure and now your addition is better visible. I was wondering about what codes for the layout to use. Is there a list available from TC? A quick Google-search did not turn up much.
I did not know that regular TC-extensions can be used in dCore. Is there no substantial difference between the two?
I agree that adding kmaps to the dCore-repo would be very valuable for international users.
@JasonW: hope you see this! What do you say?
-
Great, thanks a lot! I went over the structure and now your addition is better visible. I was wondering about what codes for the layout to use. Is there a list available from TC? A quick Google-search did not turn up much.
look at the content of the tcz:
http://tinycorelinux.net/6.x/x86/tcz/kmaps.tcz.list (http://tinycorelinux.net/6.x/x86/tcz/kmaps.tcz.list)
I did not know that regular TC-extensions can be used in dCore. Is there no substantial difference between the two?
no differences
-
OK. Have added link to this list to the wiki.