dcore-101

[Jason W]

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. 

[sm8ps]

@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

[Jason W]

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.

[sm8ps]

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

[Jason W]

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. 

[LichenSymbiont]

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.

[LichenSymbiont]

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.

[sm8ps]

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

[Jason W]

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.

[LichenSymbiont]

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!

[Jason W]

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

[LichenSymbiont]

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.

[core-user]

'Using importsce' would be my suggestion for the page name; this would make it easy to search for, as like from Google.

[sm8ps]

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!

[Jason W]

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".