Ok, this experiment has finished and I would like to share my outcome.
I migrated a debian server to dcore with the end goal of running everything in RAM (the SAN has failures all the time, so I don't want to be forced to reboot all the time). This is possible because core is so small and extension dirs are flexible. Having only added 2 compressed debian packages with their dependencies I can fit everything in RAM on this 512MB vps. Most memory stayed unused so far.
An issue I saw was that some strange entries in /etc/group were blocking uids that are normally used for real users (1000+ range):
messagebus:x:1000:messagebus
libuuid:x:1002:libuuid
Overall it took a considerably big effort, especially cause of my old default setup that used lvm for no reason and because I had to reinvent my own copy2fs for the extensions.
Installing debian packages (as long as these subtle bugs are out of the way) is flawlessly easy. The inbuilt search makes sce-import much more user friendly than the original tools from debian. Pressing Enter^Wq to confirm and ctrl-c to cancel installing the extension is great. Faster and less clunky to use. I wish the package description was displayed before pressing q though.
I also could just copy my old debian home folder over and back it up normally.
Now with easy and powerful tools to allow me to manage all those packages, convert stuff from tcz to sce, merging local and original debian stuff, optimize sces by merging them together without having to type many command manually I could imagine a lot of flexibility that would make lots of things I regularly need to do easier and faster.
Already being able to install debian packages *with dependencies* much easier means I'll waste less time compiling stuff myself.
I could also imagine blurring the borders between mydata and extensions more. Could be the same CLI. in the end it's all compressed packages that get loaded at different times of boot: pretce first, then tce, then mydata.
I was thinking of not saving the sce packages on disk at all and just re-downloading them on every boot. That means my boot medium can be nearly infinitely small but scripts could still create a working environment very easily with stuff always up-to-date. I think with so many mirrors (perhaps local in your house, building, company, ISP) it's quite feasible.
Now I'm just blabbering obviously, but perhaps you're curious nonetheless what crazy thoughts came up when I played with dcore. I definitely have too much local customization and special wishes to serve as a representative user, but perhaps my ideas and reasoning is still useful for someone.
It was hard work to test this with many things not directly usable, but I like where it's going. It will improve my core experience even if for base stuff I will try to stick to good old microcore extensions (e.g. simple, already personally customized Xorg extension with simple window manager, wpa_supplicant with custom dhcp and roaming scripts, lately uqmi + dhcp script) for LTE on the go...
I will probably use dcore for software that I now still install directly from the source (e.g. from mozilla or google). gimp, chromium, skype and so on, other big stuff that naturally has lots of dependencies that I'd rather never even see.
The stuff I use everyday, my base, I will keep clean though, I like to have a small, fended off system most of the day,
It's a good OS, never in my way, even though it's bare and raw. At some point I'm sure dcore will mean less work left for me.
For someone who was happy opening up tinycore live, installing wireless base, firefox from the appsbrowser and be done I think dcore is already a very nice alternative.
Btw: I'm playing with containers these days and I hate them so much... core might help me there one day, too.
Welcome
FAQ
Downloads
Wiki
