why do you leave TinyCoreLinux and where do u go after?

[mocore]

#2 - I do a lot of development work in scripting languages, or languages that have their own "special" package management - python, node, go, etc. TBH, these languages don't really fit well with core's philosophy. Development in python isn't so bad - set up a virtualenv on some sort of persistent medium, and go to - but I'd love a way to (easily) install something from pypi system-wide and have it persist across reboots. (This is actually a discussion I'd love to have if anyone has any input)

tho i dont use it alot
with node - npm
i have the  '~/.npm' cache linked to a persistant copy
to save space and avoid npm redownloding
  anoyingly it seems to install npm still must use network
to check if modifyed / etag then get 304 and install from cache

[mocore]

But it is not official...

at least it would (i think) be benificial to have a recomended method or methods
to get to a localy created copy of most if not each package

 so with
 core + compiletc + source + script
anyone can ( at least try to) recreate a tcz from the repo

so that
 $version/tcz/src/ *-build.sh  (i know from diging around some can be found )

could be as available as tcz .info .list ect

i figured that is what the initended perpose of
 http://git.tinycorelinux.net/index.cgi?url=buildscripts/
might be ?

# some times im at the gulags
# other times im runing what ever i can manage to boot ! inc core

[Juanito]

Sadly some extensions could be lost in 5.x because nobody (excluding creator - maybe missing) knows how it was compiled for TinyCore.

I don't think this applies to many extensions - the creator is perhaps missing, but I'm not sure how many users have tried to contact the creator and, supposing he/she is missing, attempted to compile an extension themselves. Many of the extensions have build scripts and/or explanations of what to do and also have copies of various patches that were applied.

[vinnie]

@hiro: When you create a package would be best to remain essential to specify dependencies, especially for minimal software as mpd.
However if you had a script platform you can:
1) allowed to discuss and comment on unnecessary dependencies
2) create a fork of the package reusing the exposed code (share a code would be more immediate than send binary)


How Amat says, it would be essential to have an official system, a system that survives to its creators (and for examples Arslan has disappeared, I have not received his reply even by private messages, his absence is truly remarkable).

@juanito
That some people have adopted the form of scripts and properly documented their work is nothing more than their own merit and perhaps the demonstration that it is a good system providing a higher continuity.

[hiro]

I generally don't put any of my build scripts, because I often don't use build scripts.
And that means anyone can rebuild my packages by reading the source's README or INSTALL. I will also rebuild something to fit certain criteria, but only if there is a tester (I can't test 5.x stuff right now for example), you just have to kick me hard enough

On the other hand there is the problem that the autoconfig hell often gets used to make the software link against as many libraries as possible, and even if you put the same shell comands to compile the package you might get different dependencies because of your loaded *-dev library packages. This is a general problem with build scripts and not limited to tinycore and with all the other complexities like the many different build systems used by people the idea of having something like gentoo is at the least very difficult and in the extreme - plainly - gentoo.

There is also crux btw, if you search for a lunix with small default install, but still including standardized build scripts, etc.
But IMHO if you play a bit with crux, gentoo, build some 20 packages or so on each and compare to tinycore you will see that the benefits don't outweigh the problems through complexity.

[justauser]

I love tinycore but found that I wanted to run a server that needed recent php and other packages.  moved to ubuntu because it generally gets updated/latest of everything.  The dcore stuff might help me solve this problem.  I really prefer tinycore and still use for some purposes, but new/latest packages are the key for me.

[chattrhand]

Hello TinyCoreTeam,

since Knoppix I'm a Linux user, but not a coder. Meanwhile I have tried a huge stack of LiveLinux-CD/DVD on desktops, laptops and mac. Actually I am using mainly ctBankix, LinuxMint, Knoppix and Tails Linux. The sound and printers work fine, except for TC.

However, the ease of  installation on an USB-Stick, its low size/fast boot, flexibility and the wide range of extensions are enough reasons to NOT leave TC.

With TC 5.0.1 also iMac sounds fine, but:
abiword or libreoffice are missing on the repositories.

Trying older frugal installations with TC 5.0.1 I found that abiword and other extensions do not work.

Actually TC 5.0.1 is applicable only for sound on Mac.
For standard use I need TC 4.7.7 with its repositories.

So I hope the TC project will continue. It is great!

Thanks for your attention
chattrhand

[bmarkus]

On the other hand there is the problem that the autoconfig hell often gets used to make the software link against as many libraries as possible, and even if you put the same shell comands to compile the package you might get different dependencies because of your loaded *-dev library packages. This is a general problem with build scripts and not limited to tinycore and with all the other complexities like the many different build systems used by people the idea of having something like gentoo is at the least very difficult and in the extreme - plainly - gentoo.

In most cases you can disable optional packages using --disable-..... argument in configure to make result predictable. If not used it is an issue of the buildscript and not autoconfig.

[hiro]

@bmarkus:
Yes, to fix it you would have to put some logic somewhere, I would probably also put it in the build script. But I try also not to make my buildscripts unnecessarily complex. I like that I can just reboot, load all libraries that I want to link against and then compile with the standard ./configure; make; sudo make install
All that without reading any special documentation or even grepping undocumented configure/build scripts for disable- flags.

[bmarkus]

All that without reading any special documentation or even grepping undocumented configure/build scripts for disable- flags.

Now you know where is the problem Nothing is free, you must learn, read, invest time. Or take the consequences.

[hiro]

Yes, I'm really happy tinycore lets me workaround many complexities that I 1) don't think are worth being complex and 2) I can't remember anyways

[vinnie]

@hiro

I generally don't put any of my build scripts, because I often don't use build scripts.
And that means anyone can rebuild my packages by reading the source's README or INSTALL...

ok, so we do not take advantage from your work besides created package and you can not remember all the details and exceptions to the compilation of every single program or you have a great memory!

..and even if you put the same shell comands to compile the package you might get different dependencies because of your loaded *-dev library packages...

The last time I start a script to create a package, I do it on a minimal tinycore (only with fluxbox Basic).
I always thought that tinycore is the best way to understand the real dependencies of a package.

But IMHO if you play a bit with crux, gentoo, build some 20 packages or so on each and compare to tinycore you will see that the benefits don't outweigh the problems through complexity.

But crux or gentoo do not have the same other characteristics of tinycore.

...I can't remember anyways

bingo!


to justauser and chattrhand:
Beyond the goodness realization of a distro (and tinycore there is really a lot), I also believe that the usability of a distro are highly dependent from the available applications.

[webb]

I've left and returned several times since 2011. I like Tiny Core best of any linux I've used. I use it as my main machine for software development whenever possible. The longest stretches were for a year during 2012-2013, and for the last 4 months until now.

Tiny Core has some kickass advantages, mainly that it's not a bloated pile of festering crap, yet it's still readily and highly usable. It's package install system is the easiest, fastest, and most impervious to damage of any I know. See htop in 1 page! No systemd! Doesn't eat up all your resources. Good learning experience.

Now disadvantages: less hardware support (e.g., for random wifi cards). Maybe dCore solves this, but I run big ram apps (e.g., R) and need 64-bit, and there's no dCore for CorePure64 AFAIK. When I successfully install a large, complex package, I sometimes find it goes easier to install to /usr or /usr/local instead of to ~/.local, then find it easier to just not restart for a long time, then, when I do, I just sudo make install it again instead of making a tcz. I don't think this is a good practice, but only mention it to say that if the route to making a tcz was as easy as possible, I would contribute more, and I suspect others would, too.

Where did I go? Sometimes installing and setting up necessary software takes more time and learning than I have available, and I have to fall back to e.g., Ubuntu server until my workload lightens up.

Don't worry, I'll be back soon

[Juanito]

Now disadvantages: less hardware support (e.g., for random wifi cards).

Wifi (and video cards and printers) are difficult to support because you need the hardware to test - this is one area where the user base can really help by reporting what works/doesn't work and working with us to fix it for the benefit of all.

..but I run big ram apps (e.g., R) and need 64-bit, and there's no dCore for CorePure64 AFAIK.

I don't know if you've looked at the 6.x/7.x corepure64 repos lately, but you might be surprised at how many extensions they contain 

[noordinaryspider]

I didn't actually leave, just took a brief hiatus to learn more about a couple of issues that interested me:

The whole Free Software/Open Source issue, which doesn't need to be rehashed here, and how much convenience I as an individual was willing to give up for the sake of ethics.

All the security issues that were raised with the Snowden revelations.

I've been using Trisquel and Debian and learning at a pace that is comfortable for me, an average user who hates the term "self taught" to describe what I actually do, which is a lot of trial and error and rabbit trailing off of what PEOPLE take the time to tell me and answers that PEOPLE take the time to give to my sometimes strange questions.

I found DSL shortly after getting rid of Windows in 2004/2005ish and found it much easier to understand than the newbie distros of the day (Mandrake, Ubuntu, Simply Mepis, etc.) but was not around much during its demise. I use netinstall .isos to recreate the look and feel of DSL and am ready to start playing around with Tinycore again.

It runs great on my Eee PC 700! I've been away for awhile and I'm very impressed.

I'm disgusted with the bloat of mainstream distros and utterly revolted by the waste: the human potential of the people who make the hardware that the "average joe" replaces every few years, the hours "average joe"  spends at a job he hates to pay for the hardware he replaces every few years, and the environmental costs of disposing of ewaste.