dCore Import Debian Packages to Mountable SCE extensions > dCore X86

various thoughs & questions

(1/3) > >>

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.

Navigation

[0] Message Index

[#] Next page