various thoughs & questions

[jls]

Hi

• move the sce from the upgrade dir could be done also during shutdown.
  
• updatesce -a
  order
  right now the script processes the sces in alphabetic order but I have the feeling that it's better to process them using a dep tree created from all the sce, starting from root, in my case base, starting from the ones already mounted in their mount order.
  
• show the sce loaded during boot per default (showapps)
  
• during the sce creation if a dep is present on the upgrade dir, that sce should be checked and not the one on the sce dir.
  
• it would be helpful to write a script that creates the dep tree of the sce files.
  
• if I change the .dep of an sce, does sceupdate will notice the changes and re-import the sce again?
  
• importsce & updatesce could be improved for readability using colors like it happens for example during (d) Core boot
  
• Are u Jason the only one behind dCore? is dCore a 1 man only distro? If yes, is it considerable a serious distro or is it a game/joke.
  
• where is Robert?
  

[Jason W]

Hi, here are my thoughts on it.

1.  Ok, sounds logical to move the SCEs from the update directory during shutdown since boot time is seen as more valuable than shutdown time.  And SCEs can be quite large as opposed to the average Core tcz updates thus a much greater slowing of boot time.

2. I had thought of that, and since the packages included in a dependency SCE can change due to a change in Debian or dCore specific dependencies.  I will create reverse tree updating order.

3.  I don't want to make changes to the user experience unless needed, having to issue boot codes to see extensions loaded on Core and then having to use a boot code to not see them on dCore would just add to confusion for those who use both.  I want dCore and Core to differ in it's usage only where absolutely necessary.

4.  I agree, I see what needs to be changed, will only take a few lines of code.

5. A script for a dep tree would be useful.  Perhaps it could be contributed.

6.  If a dep file is changed, yes, it's new contents is what is used by importsce/updatesce.

7.   That is perhaps a future wish list item.  One thing I would like is if dCore had an FLTK Appbrowser.  What I would like to see is the least difference in the user experience between Core and dCore.

8.  The forum history shows that the foundation of dCore was put in place by Robert as a means to bring Tinycore to other archetectures, initially armv7.  I thought it would be nice to also have an x86 port of it, and I was able to get involved.  And I see it as an offering of Tinycore, not as a distro in and of itself.   I know you meant nothing bad by it, but as for dCore being a joke, I have seen Tinycore called that in another distro's forum.  Yet there are folks at IBM and NASA that take Tinycore seriously enough to use it (source: Google search).  dCore is not the first offering to leverage Debian packages, nor the first to basically be able to exist as a one man show when needed.  Concepts are what make a distro.  Pristine boot, backup, mounted & symlinked packages, frugal install, live filesystem in RAM without Unionfs, these are the central distro concepts of Core and  dCore.  I see the design of making it possible for one person to support 4 different x86 ports and (so far) one arm port with one portable set of scripts as a plus and not a liability.   There are still things that need working on, I want to focus more on startup scripts for packages that need them to work in dCore to expand our package availability - and from the start Tinycore packages have often needed startup scripts to work with the symlinked install method.  But wIth 1 and a half years of continual progress and maintenance (feature adds, updates, quick bugfixes, supporting new Debian/Ubuntu repo releases),  I don't feel the need to defend or justify the existence of dCore further, I will simply direct future inquires to this thread. 

[Jason W]

Upon re-reading I see my answer to #8 looks a bit more harsh and defensive than I intended.  My basic point is that dCore is a small community of both developers and users but hopefully is providing something of value without taking away from standard Core. 

And for #9, Robert has posted in the past few weeks, and in either case I feel better to let him answer questions regarding his time here.

[roberts]

In regards to my status I refer you to my May 13, 2013 post: http://forum.tinycorelinux.net/index.php/topic,142.msg89043.html#msg89043

While I don't think it appropriate to post more about my current health challenges here, needless to say I have many and therefore the reason I have handed off all aspects of the project to the Team.

Given that more than a year has past, it is quite obvious that Team Tiny Core is more than capable to carry on with the project.

[CentralWare]

@jls: I can understand where you're coming from (ie: one man show) as so many software packages/apps down to linux distributions have come and gone over the years (no pun intended Robert's involvement in DSL! ) but depending on your technical background, even when someone abandons a GPL source-based project, that always leaves the door open for someone else to carry the torch when it's worthwhile.  Even if Team Core were to call it quits entirely, there are enough copies of the Core Concepts floating around to where anyone with the means can resurrect it or even start it over from scratch.  dCore isn't "my" calling (from what I've read so far; I have a completely different path I'm aiming for) but I love the idea that people are finally willing to think "outside the box" when compared to the main-stream.  A "joke?"  You never know.  If you know enough of recent U.S. History...  The "Pet Rock" started off as nothing more than a joke...  a few million dollars profit later he was still laughing!

@Jason: I haven't read much/enough into the dCore project (I got the impression it was basically core + .deb, then elsewhere read something about it being focused initially on ARM processors (?) which sounded great as I was planning to put ARM, RISC and ARM/PI on my to-do list this Spring for a few projects) but other than supporting or implementing Debian packages, is there actually any other differences between TC and dCore?  (Meaning, why would I take the dCore route for an Arm7 as opposed to TinyCore/Arm7 - OTHER than .deb's?  Forgive me if I haven't done my homework yet, there's a lot still on the plate.)  As for NASA...  drop me a link if you would as to where they're implementing TC -- I'd love the read!  (I worked at NASA/Ohio until 2000...  this would be an interesting twist to see where they've gone since shortly after the turn of the century as they were sorely behind the times, especially when it came to desktop/server environments!)

@Roberts: It always sucks when a good guy is down - and always seems to be it happens to the good guys.  (You don't hear of Joe Schmo murderer who gets 20 to life...  comes down with a life threatening ailment...  but then again, not too many people would care - if not cheer it on!)  You could have launched the TC project out of pure spite...  vindication...  profit...  who knows, but the endless thanks goes out to you and those like you willing to break with standards and start thinking, and ultimately producing "outside the box."  (LMAO...  though your default hostname IS BOX!!!)  God speed with your health battles and though you may not hear it often enough, of the hundreds of posts I've already read personally, you've grown somewhat of a fan base.

[Jason W]

Centralware -

When dCore started, it was the first Tinycore push into Armv7.  That is not a big deal to me but you wondered why choose dCore armv7 when there was Core armv7.

Also, the Nasa blog that mentions using Tinycore for a project -

https://modelingguru.nasa.gov/community/atmospheric/boinc/blog/2009/10/13/modele-on-tiny-core-linux

It is the first search result when Googling the terms "tinycore nasa". 

[Jason W]

Some good suggestions were brought up in this thread, and they are now implemented in release candidates.

To summarize:
Updated SCEs now moved during shutdown.

Reverse tree update of SCEs that have dep files, whether updating the whole SCE directory at once or one at a time.

Checking against an SCE that exists in the update dir rather than in the TCE dir - both for updatesce functions as well as importing and using that SCE as a dep.  The update function actually already did that as I looked at the code, but now they both do.

The only thing left is to make updatesce recognize if the tree of dep files provide the needed package dependencies of an SCE.  The needed data is stored in each SCE, I will tackle that next but for now the other things are in release_candidates to be tested.  That, and for a script to show the dep tree of an SCE which is info that can be nice to know.

[Jason W]

Editing a dep file or re-importing an SCE using the -d dependency option and choosing a different set of deps as the first should now result in the SCEs that depend on that one to need an update when updatesce is run.

IOW, say desktop.sce depends on xorg.sce which depends on base.sce.  Now changing base.sce.dep from containing "mc" to "mc1" or nothing or "file" will result in both desktop.sce and xorg.sce reporting needs for updates. Uploaded to release candidates.

[Jason W]

Centralware -

I see I missed the gist of your question.  And very interesting that you worked at NASA!  I work in a factory myself.  :-) To more accurately answer your question, the idea is to be as little as possible difference between Core and dCore, especially in user experience, besides the source of the packages.  And that yes, dCore was initially focused on porting dCore to other architectures, initially ARM.  I hope one day to be able to have the time and hardware to put more focus there.

JW

[Jason W]

And thanks JLS for bringing these ideas and bug reports to my attention. 

[yoshi314]

since it's a question thread more or less, i'd like to ask how does one put together the dcore initrd from git sources? What exactly do i need to put together a working initrd ?

[Jason W]

The files that make up the dCore-wheezy.gz and other initrd's come from a Debian install for library compatibility.  The git sources are our dCore relates scripts and other files.

[yoshi314]

well, i was more instested in what comes from what package into the initrd, as it seems that there are plenty of files being added as compared to git tree state.

i'd like to put togeter a custom initrd from completely different distribution.

[Jason W]

Oh, I see.   The initrd files were initially taken from a Debian install, only what was needed like with Core.

I would have to do a package search on the files, just like anyone else.  Possibly with a Debian install and an unpacked dCore-*.gz, a scripted "find" command combined with Debians package search command "apt-file search /path/to/file" could make it quick.  I will get to that in time, perhaps it is something someone here can contribute.

[yoshi314]

I thought for a moment that there was an automated script to do so. Well, i can hopefully figure it out on my own, as i am planning something weird