Tiny Core Linux
Off-Topic => Off-Topic - Tiny Core Lounge => Topic started by: jls on October 05, 2013, 02:48:42 PM
-
Thanx
-
Well, your questions will be difficult to answer if the people who leave don't read/post here anymore...
There were a few posts a little while ago from someone who finally said he was moving on. I think he was a new Linux user basically looking for an out-of-the-box distro, which TC really isn't. I myself might have found TC discouraging (this was 4 years ago) if it was the first Linux distro I had tried. Due to a couple of hardware issues it took me some time to get things working right. I stuck with it because I really like the philosophy behind TC (customization and file safety) but if I'd just been looking for a quick Linux experience I may well have moved on too.
-
I'd like this post to be sticky. thx
-
I leave and come back all the time. Being modular and small are valuable in creating bootable CDs and USB Flash drives. So I frequently experiment with TC, and almost used it as the basis for a turnkey "test and clone" system. Almost. Instead, I added my scripts to Patrick Verner's Parted Magic which gave me the preconfigured OS plus a set of related and useful applications in a CD-sized package.
My daily driver for years has been the minimalist CrunchBang. It has evolved with so many customizations that moving to standard Debian Wheezy made more sense when CrunchBang also moved to wheezy. I am still an Openbox/Tint2/Conky fan, and can squeeze my wheezy installation onto 4GB. Lately I am back at TinyCore for the dCore project (small, modular, AND based on Debian) to see if I can recreate my desktop to a smaller USB Flash drive or maybe even a CD.
I have also like Porteus 2.1, and managed to recreate much of my Debian desktop installation in 600MB. But being based on Slackware, there are fewer pre-compiled packages. To get what I want frequently requires building it myself. But I am lazy and only willing to do this for one or two packages. I prefer "off-the-shelf" packages so I don't have to debug the builds or keep up with updated sources. For the moment I have drifted away from Porteus, but recommend it nonetheless. It is compact, modular, can be loaded entirely in RAM, and compatible with the all Slackware (Slackware/Slacky/Salix/Alien) repos.
-
They got on de bus, that fell into the udev on which they floated straight into the systemdhell.
If I want my everyday system to be clean, small, fast-moving, but also stable (this means being able to install the latest shiny crap software without polluting my lean base system) tinycore it is.
Two days ago I set up a wifi repeater on some ARM architecture with debian squeeze. After the actual install all I had to do was add 3 packages and creating two config files. As I will never touch the system again this was the most simple choice for me. On the other hand: If I had to do this install frequently I would use tinycore, because with the gigabytes-big default install it takes AGES to install debian on a flash disk. In this case I had enough time so it didn't matter.
-
I take this opportunity to salute and congratulate you all for 5.0 version... (I still read forum occasionally)
I switched to Alpine Linux a time ago...
Alpine Linux has advantages and disadvantages over TinyCore but the main reason was I like/need a standardized process of building and maintaining extensions (like Arch/pkgbuild).
Either way, I still think that TinyCore is a great distribution.
Regards to all.
Edit: Also, I would like to apologize to Zendrael and manit123 for unread PM.
-
I take this opportunity to salute and congratulate you all for 5.0 version... (I still read forum occasionally)
I switched to Alpine Linux a time ago...
Alpine Linux has advantages and disadvantages over TinyCore but the main reason was I like/need a standardized process of building and maintaining extensions (like Arch/pkgbuild).
Either way, I still think that TinyCore is a great distribution.
Regards to all.
Edit: Also, I would like to apologize to Zendrael and manit123 for unread PM.
Alpine Linux is a community-developed operating system designed for x86 Routers, Firewalls, VPNs, VoIP and servers.
Tinycore is a °normal° distro so why have u changed_
-
As you can read here: http://wiki.alpinelinux.org/wiki/Alpine_Linux:Overview (http://wiki.alpinelinux.org/wiki/Alpine_Linux:Overview)
Note: As the About page says, Alpine is "designed for x86 Routers, Firewalls, VPNs, VoIP and servers." But it's a perfectly workable desktop system, too. The shortcomings just have to do with the small community, and that sometimes you may need to get your hands dirty modifying scripts written with more mainstream desktop distros in mind.
I use openbox but it also has kde, gnome, xfce4, fluxbox, pekwm, awesome... and enlightenment ;)
You can see all packages available here:
- main: http://git.alpinelinux.org/cgit/aports/tree/main?id=8d05ecc84f58e4f5e9b34062fcda4ad35ed58a24 (http://git.alpinelinux.org/cgit/aports/tree/main?id=8d05ecc84f58e4f5e9b34062fcda4ad35ed58a24)
- testing: http://git.alpinelinux.org/cgit/aports/tree/testing?id=8d05ecc84f58e4f5e9b34062fcda4ad35ed58a24 (http://git.alpinelinux.org/cgit/aports/tree/testing?id=8d05ecc84f58e4f5e9b34062fcda4ad35ed58a24)
-
There were two reasons I occasionally bounced off tinycore.
#1 - Kernel version. I frequently wanted to do things with newer kernels. Most recently, proper HDMI support for my graphics card required a newer kernel. It's easier and less troublesome to just switch to say, arch linux than try to build and look after my own custom kernel. (5.0 has a new enough kernel that I doubt this will be an issue again for a while, which made me quite glad :) )
#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)
Oh, and there is actually a #3: it's proven bloody well impossible for me to work out how to get a working Haskell installation.
-
I run on Arch linux 64 bits with Openbox on my PC daily, and have TC 5 as a backup/recovery. (But I am not pleased with Arch direction forward systemd). I like a 64 bits system to run Qemu (and a custom TC 64 version under it), and the new 3.11 kernel provides dynamic power states for my ATI X1400 graphic card, even with some trouble to patch/recompile OSS (open sound system).
Future? Aboriginal linux; it has kernel 3.11, toybox (small/smarter version of busybox) and I hope for musl (instead of glibc).
Why? Because the future is for ARM tablets, PC era is going underway in some (10?) years, Android is linux based (still closed source); And I would love a device with a customisable TC type kernel.
I keep going back here to watch/test the TC advanced ideas, because I dislike bloated/fat systems.
-
Small correction, X1400 is a r500, the DPM is only for newer generations. You won't need the 3.11 kernel for power savings, that work doesn't apply to those older cards.
-
Lubuntu 12.04 non-pae net install (28M image) because it is the only distro that fully supports my video. Still love TC, and I install lubuntu like micro core, then add drivers, X, jwm, and opera. But my real system is the win 7 that came with the netbook. Best version since win98 SE, which is the last one I used.
-
For now I do not know alternatives to tinycore and so do not think I'll change my distro, but the reason to do so would:
* non-optimal package management system (also amat coder sayd)
* development team too small to provide enough support
* sporadic closure on the proposals/requests of community
-
Several hours a day I'm sitting in front of a PCs since more than a decade now but I just recently got caught by Linux. I tryed several distros and kinda ran away from one to another due to bloating installs so I tryed smaller ones. I have also tryed TC some time ago but at that time it seemed to me like a useless proof of concept for nerds.
The Linux I 'would' switch to if I'd leave TC now is probably Puppy.
-
For now I do not know alternatives to tinycore and so do not think I'll change my distro, but the reason to do so would:
* non-optimal package management system (also amat coder sayd)
* development team too small to provide enough support
* sporadic closure on the proposals/requests of community
What do you mean non-optimal?
What kind of support are you missing?
-
@bmarkus
That the package management is sufficient for use but could be better, I think that the best management I've seen is the one used in the arch aur (script-based), allows you to browse/update/edit software better.
Regarding the missed support, I'm not complaining because my English is very bad and I think that is not too pleasant reply to me, but very often I have not had replies to my messages.
-
The best management is no management.
tinycore doesn't put on huge layers of duct tape just to then have to rip it off again and get caught up in the sticky leftovers.
-
@bmarkus
That the package management is sufficient for use but could be better, I think that the best management I've seen is the one used in the arch aur (script-based), allows you to browse/update/edit software better.
Everything can be better.
Edit software via package management? How do you mean?
-
@hiro I do not agree, good organization allow to better solve the problems, let's take a stupid example (also valid to answer bmarkus):
Every time we update the kernel there is the usual problem with programs that lose compatibility (and this round it is exacerbated by the loss of scm).
This is normal administration, but if we had a unified management of the scripts we could better handle the issue.
Let's take a packet at random from aur: https://aur.archlinux.org/packages/vboxgtk/
People can easily vote for it, comment on it, observe the code, download the source, Read the comments, you'll notice several reports.
Simplify access to this information could mean increasing the participation of people.
Also maintain a repository of scripts is to have few limitations of space (and I remember we had this problem in the past) and would also increase the safety of the packages (since the compilation would be just in time, with the code under the eyes).
If we wanted to exaggerate, we could even think to automate the reconstruction of critical packages every time we update a kernel or when a new dependency is updated.
We could make sure that meo have the latest minor version of firefox in complete autonomy, the minute after its release (just kidding but it is a plausible perspective, I hope that meo do not get angry :P )
However, these are not things that I claim, but I'm still stuck to the fourth version of tinycore for missing application and I do not have the ability to solve alone.
Do not take it as a protest, I still consider tinycore as a great gift to the community, and just know that I am sorry to observe the presence of these problems.
-
Two cents: Editing a certain software's behavior has never been so easy for me as it is when using Tiny Core.
Well, to be able to create personal extensions, I always have to look up on the net for correct commands or file/folder access rights, but thats linux - or - thats 'computing'. While tiny core beeing a 'small' distro (less people), it's naturally more unlikely that certain requests can get deepy investigeted because the goal is to create a Tiny base that does work - We, the users have to add the cany if we want but we don't really 'need' to. The rest is still up to us. For me it seems people are getting much help on the forum even if they try to do something 'special'. It's always a hassle for me - competing with computers - with tiny core I'm able to make apps to work as I say whithout having to touch the real system (buried files which might be waste in the future),
-
@vinnie
Automatic compilation wouldn't solve the manpower issue - even if the app compiles, it still needs testing before it can be had there. Mere "does it start" isn't enough really.
-
The fact that they should be tested does not deny that need to be rebuilt :P
-
@vinnie: It's much easier to learn how to compile and create a package than to create, maintain, use, understand and workaround errors in an automated build system.
-
> We could make sure that meo have the latest minor version of firefox in complete autonomy, the minute after its release (just kidding but it is a plausible perspective, I hope that meo do not get angry )
100% autonomy is only useful when the automation works perfectly stable, which it never does. Else why would you need to update at all?
-
I think you're too radicalizing your statements.
No automatic system is 100% perfect, not for this you do not tend to automate things.
I used arch before tinycore and I assure you that I was not able to create any kind of packages or compile source, anyway I used aur to install software.
Nothing is perfect, arch was too bleding edge and stopped working after some time (after some updates).
Subsequently with tinycore and with a lot of efforts I learned how to compile and to package (I started with circuslinux).
I have also managed to create some (ugly) script cloning here, there and everywhere,
I copied a lot from the jason script, but very often when i not knowing well what to do, I copied from aur script.
So what you say is true, the approach of "basic" is better to learn, however automate things is the next step.
I remember back when the .tce packages had not automatic resolving dependencies, someone at the time argued that it was easier to specify all dependencies by hand,
then we know how things went.
-
If we followed your logic and automated more stuff in tinycore then the system would get too complex (like arch) and other people wouldn't be able to learn from the simplicity in tinycore the way you did.
I still prefer manual dependencies. It forces you to keep it small and simple. In the beginning many packages on tinycore got linked only against the bare minimum to get a usefull "app". Now often when I install a program to do something simple I get loads of libraries auto-installed together with it. Sometimes needed because of the package creator's decision, sometimes by accident, sometimes not needed at all.
An example: look at mpd.tcz dependencies, something I wanted to use on a 64MB RAM embedded audio system. Of course I had to recompile it. And I blame the ease of automatic package management.
mpd.tcz
libavahi.tcz
gtk2.tcz
atk.tcz
glib2.tcz
libffi.tcz
libffi.tcz
cairo.tcz
pixman.tcz
fontconfig.tcz
expat2.tcz
pango.tcz
glib2.tcz
libffi.tcz
Xorg-7.6-lib.tcz
libxcb.tcz
gdk-pixbuf2.tcz
glib2.tcz
libffi.tcz
graphics-libs-1.tcz
shared-mime-info.tcz
glib2.tcz
libffi.tcz
libxml2.tcz
liblzma.tcz
Xlibs.tcz
dbus.tcz
expat2.tcz
gcc_libs.tcz
bzip2-lib.tcz
libffado.tcz
expat2.tcz
libiec61883.tcz
libraw1394.tcz
firewire-3.0.21-tinycore.tcz
v4l-dvb-3.0.21-tinycore.tcz
i2c-3.0.21-tinycore.tcz
libxml++.tcz
libxml2.tcz
liblzma.tcz
glibmm.tcz
libsigc++.tcz
glib2.tcz
libffi.tcz
libxml2.tcz
liblzma.tcz
glibmm.tcz
libsigc++.tcz
glib2.tcz
libffi.tcz
glib2.tcz
libffi.tcz
libsigc++.tcz
faad.tcz
libmpcdec.tcz
tcp_wrappers.tcz
sqlite3.tcz
libcdio.tcz
ncurses.tcz
ncurses-common.tcz
zziplib.tcz
curl.tcz
libssh2.tcz
libssl-0.9.8.tcz
libidn.tcz
libiconv.tcz
libavformat52.tcz
libavcodec52.tcz
libavutil50.tcz
libvorbis.tcz
libogg.tcz
libvpx0.tcz
libogg.tcz
libmms.tcz
libid3tag.tcz
flac.tcz
audiofile.tcz
libmikmod.tcz
libmodplug.tcz
libgme-svn.tcz
sidplay2-lib.tcz
fluidsynth.tcz
glib2.tcz
libffi.tcz
flac.tcz
jack-lib.tcz
libasound.tcz
libogg.tcz
libsndfile.tcz
flac.tcz
libvorbis.tcz
libogg.tcz
libvorbis.tcz
libogg.tcz
ncurses.tcz
ncurses-common.tcz
readline.tcz
ncurses.tcz
ncurses-common.tcz
wildmidi.tcz
libasound.tcz
wavpack.tcz
libiconv.tcz
libmad.tcz
mpg123.tcz
libltdl.tcz
libcue.tcz
lame.tcz
ncurses.tcz
ncurses-common.tcz
twolame.tcz
libsndfile.tcz
flac.tcz
libvorbis.tcz
libogg.tcz
flac.tcz
libvorbis.tcz
libogg.tcz
libogg.tcz
libopenal.tcz
libpulseaudio.tcz
Xorg-7.6-lib.tcz
dbus.tcz
expat2.tcz
glib2.tcz
libffi.tcz
libltdl.tcz
libsamplerate.tcz
libsndfile.tcz
flac.tcz
libvorbis.tcz
libogg.tcz
speex.tcz
libogg.tcz
libx11-xcb.tcz
libxcb.tcz
libxcb-util.tcz
libxcb.tcz
libavahi.tcz
gtk2.tcz
atk.tcz
glib2.tcz
libffi.tcz
libffi.tcz
cairo.tcz
pixman.tcz
fontconfig.tcz
expat2.tcz
pango.tcz
glib2.tcz
libffi.tcz
Xorg-7.6-lib.tcz
libxcb.tcz
gdk-pixbuf2.tcz
glib2.tcz
libffi.tcz
graphics-libs-1.tcz
shared-mime-info.tcz
glib2.tcz
libffi.tcz
libxml2.tcz
liblzma.tcz
Xlibs.tcz
dbus.tcz
expat2.tcz
gcc_libs.tcz
json-c.tcz
liborc.tcz
libshout.tcz
libtheora.tcz
libogg.tcz
libvorbis.tcz
libogg.tcz
libogg.tcz
libiec61883.tcz
libraw1394.tcz
firewire-3.0.21-tinycore.tcz
v4l-dvb-3.0.21-tinycore.tcz
i2c-3.0.21-tinycore.tcz
libxml++.tcz
libxml2.tcz
liblzma.tcz
glibmm.tcz
libsigc++.tcz
glib2.tcz
libffi.tcz
And here are my mpd dependencies. Sorry, the dependency-dependencies are not displayed, cause I created this extension myself and it's not up on any tinycore servers (perhaps I forgot to submit it back then?):
vorbis-tools.tcz
faad.tcz
libmpcdec.tcz
libmms.tcz
glib2.tcz
libid3tag.tcz
libmad.tcz
audiofile.tcz
wavpack.tcz
mpg123.tcz
libcue.tcz
lame.tcz
libsamplerate.tcz
-
And yes, I think tinycore itself is already quite radical (some might say *too* radical). But I'm grateful for having an alternative to all the radically complex software.
-
I'm agree with Vinnie.
Another good example is the libpng update issue.
If Tinycore had a standardized build system then to recompile all packages to link new libpng would be trivial.
Sadly some extensions could be lost in 5.x because nobody (excluding creator - maybe missing) knows how it was compiled for TinyCore.
(Also: patches are needed to compile some packages. Information about which patches have been applied is no retained.)
-
there is already a build system: http://forum.tinycorelinux.net/index.php/topic,11972.0.html (http://forum.tinycorelinux.net/index.php/topic,11972.0.html)
-
But it is not official...
I am speaking about an official build system (this means: all extensions must be made mandatorily with it).
-
#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
-
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
-
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.
-
@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.
-
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 :P
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.
-
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.
-
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
-
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.
-
@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.
-
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.
-
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 :P
-
@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! :D
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.
-
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 :)
-
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 :)
-
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.
-
One never leaves TCL You always find a use for special tasks, especially on diskless systems and older PCs.
As a newbee you also can learn a lot by using TCL. If you are looking for a complete system environment, Debian and/or
Mint are your best bets.
-
No, I will NOT leave TinyCoreLinux, it has too many features that make it unique:
- Ease to install it even multiple on the same stick for special purposes,
- Very short time to boot and rundown, even from pendrive, and with persistence
- Ease to update all of its extensions, even with older tc releases
With TinyCore-7.x I am running on Problems. some of them have a workaround but not all, I hope they will be fixed.
I tried Puppy, but was not very happy.
Now I found Slitaz rolling, for both 32bit and 64bit CPU. You get an .iso of a "frozen state" every month.
After booting (very fast) you can update your system with all of the packets newer than the ,iso state.
This can take some minutes and,- the fun of a rolling release,- the packets are usable immediately.
The RAM consumption increases to about 100 MB (on my systems); SWAP partitions will be used.
While updating you can use the onboard midori browser; after finishing the packet update you can add the recent firefox official or -ESR, and there is a huge number of additional software in the repository.
This update has to be done at every reboot. And actually I've only found a narrow way for data persistence, and access to mass memory like hdd or pendrives.
The docu is a bit confusing, so I did not get to the bottom actually.
-
I agree Tinycore is unique and awesome
In my opinion It is the best designed linux distro there is period
and I have tried just about all of them
I don't post much because everything works great for me
but I would like the people that make Tinycore to know I appreciate their work
thanks again
ulfr
-
It turns out that my original copy of puppy was no good so I burnt another and this one boots up on my CF-28 and I have sound :o I can run it in high resolution too. I'm quite chuffed with that. Puppy Linux will now be its main OS if everything goes to plan figures crossed... I installed it to the hard drive but made a mistake when I installed the grub boot loader so I've got to start again, hopefully I'll get lucky the second time. I was mainly just looking for a graphical desktop environment for this specific laptop for basic use.
This doesn't mean I've abandoned Tiny Core I have installed Tiny Core on another laptop as it does interest me and I hope to learn more about as I go along.
-
Sorry posted in the wrong thread ???
-
"posted in the wrong thread"
Not really; it's on topic.
Puppy Linux (actually several versions) was the first distro I got to work when I started trying Linux. It was very encouraging and actually worked better on the old PC I was using than Tiny Core did initially. I moved on to Tiny Core because of its customization features, but had some sound card issues that took a while to resolve and that would have been very frustrating if TC was the first Linux distro I was trying. That said, I'm happy with TC now and hope you'll keep using it too.
-
it may be more interesting why do you come here?
-
I think you are right
-
it may be more interesting why do you come here?
So how about it, folks. Why -do- you come here?
I'll start:
To these forums, because Team Tiny Core and the community overall are just awesome. Knowledgeable, helpful, friendly.
To Tiny Core in general, pretty much as described in the Welcome, Intro and Core Concepts pages:
- I like the design principles
- It's tiny
- It's simple
- It's fast
- It's "clean"
- I don't have to remove a bunch of junk before I start adding my own junk
- Did I mention the team and the community? A huge "Thank you" to all.
-
that's what most people have been concentrating on anyway, me included.
the reasons are obvious: tinycore doesn't startle me.
yesterday i got startled by unity on some ubuntu, and cause i got so stressed out it took me over 10 minutes to apt-get remove it, due to automatic dependency fixings.
-
Hi
just saw this post so add my 2 cents worth. People do not always leave for some kind of software reason. umm the main reasons I have left in past, still haunt me today....my coding skills and communications could improve.
##############
ignoring me can I offer other reasons.
1) Sometimes people are given a work computer and its easier for them to learn it quicker if there other computers are converted to the same distro.
2) specific hardware to software Linux support. On another forum, a person heard of a a fancy laptop sold with Ubuntu variant already pre-installed.......and the drivers (kernel modules) were or are AFAIK some kind of third party and are not forced to be
license GPL MIT etc.....so to use some of the hardware, they are "forced" to use certain software.
I am guessing the hardware was or still is so new, other distros would struggle to install and have all the hardware enabled.
I don't mind if you dispute this claim as long as you could accept such agreements between hardware vendors and software companies can and do occur from time to time.
eg router vendors tend to use a particular type of software altho I lack the skills to know what distro mine is using under it shell.
I have seen a propriety type system.....that showed Linux was booting up before the fancy graphics locked us into a few choices.
3) out of the box experience.
Sorry if this seems obvious but I suspect the main reason why people go to Ubuntu and other such distros is because they may be ex-windows users and just want to click a button and it automagically works. I am pretty sure most of us have seen this before.
---I am not suggesting such users are good bad .....they are entitled to their views....I merely offer it as a reason why people leave.
hope I have not offended anyone.
-
and yet again i'm still using tinycore
but if i wanted something to switch to i made some nice experiences with void linux. can't say that about anything else i've used in the meantime (since starting with tinycore). if you like rolling release and want a simple system installed to disk in the traditional sense and with the common packages most people need it's quite nice. there's even an option to use the musl libc there, which i find marvelous.
-
@aus9: I think anyone who comes from windows to tinycore must have chosen tinycore specifically to avoid the crappy experiences they get out of the box on windows/ubuntu. It's not like tinycore is shiny or does anything to attract the people who are attending those "year of the linux desktop" convetions: So whoever comes here should know pretty well what jobs are easier done on tinycore than some bloated, hard-to-configure, badly working, monolithic enterprise software :P
-
Hi all
I have followed tinycore since it was dsl
It has now matured to the point where I use it as my primary distro
Its true that a lot of people just want something they don't have to (and can't) mess with
but a lot of people still use windows
I'm sure most people don't know tinycore exists or the power and elegance of it
However once you are aware of it no other distro even comes close
That's why its good to try to spread the word
Personally I just really appreciate that tinycore exists
because though I was able to envision it
I didn't have the expertise to make a useful system
Thanks again to all the people who made tinycore
its a masterpiece
ulfr
-
Because of SEVERE lack of easy-to-understand documentation. This OS has been built for nerds and normal users can really feel this. The wiki, the book, no easy step-by-step instructions.
If you want to do something very basic, then tough luck for you, you won't be able to do it If you aren't a developer.
Also, this community doesn't seem to understand that some people are LITERALLY computer illiterate and don't even know what a web browser is. If you don't guide them very carefully, they won't be able to do a damn thing.
Hell, even people who know about computers but are kind of new to this OS can be lost.
No one listen to the community here, a lot of people complained that the captchas were unreadable for instance and no one gives a damn about this.
Also, some members of this community can be very rude at times.
So much wasted potential for this OS.
I will come back to tiny core linux, the day where we will be able to have PROPER documentation that can be read by HUMANS.
In other words: The OS itself/the code is good, the environment surrounding it (documentation, community, support etc) is DISGUSTING.
-
seriously, you specially created a new account just for this junk?
at least it's not some markov chain, that would make more sense.
still coming back to tinycorelinux all the time, bec. i keep on using my good old mydata.tgz everywhere, and no other OS is so easy to use without installation.
been doing some alpine stuff bec. of hipster container stuff.
somebody should probably take tinycorelinux and add musl and alpine packages to it. i always miss tinycorelinux when on alpine :(
i hate that all OS's now have bigger and bigger system layer in between userland and kernel when most frequently all i want is to run one command in one shell script (esp. on containers). and that's what i can do easily with /opt/bootlocal in mydata.tgz.
tinycorelinux is the minimum linux userland that still can support everything i need to easily customize my own system layer.
-
You are either trolling or you never read the documentation.
There is no easy to understand guide to install specific programs that aren't present in the official repo.
In fact, that's exactly one of the problems that happened with damn small linux. An "elite" group of people were the one creating the extensions in the official repos and once they were gone, It was all over and most of the common people didn't know how to create extensions.
No simple documentation to customize the UI.
No simple documentation to support your hardware.
There is no documentation to do REAL everyday stuff!!!!
-
Hi aneverydayhumanuser
Welcome to the forum.
You are right, it takes some work to get Tinycore to where you want it. It is not a turnkey system. It is a small distro that
doesn't have the kind of manpower of Debian or other larger distros to support it. It is all volunteer based. As a result, it
also relies on member contributions for extensions and to provide help to other newcomers.
Information on how extensions are created, among other subjects, can be found here:
http://wiki.tinycorelinux.net/doku.php?id=wiki:start
There is also a very fine book available here:
http://tinycorelinux.net/corebook.pdf
-
TC (or DSL) aren't really aimed at users new to computers. You would be better served by another distro.
-
..humanuser...
I can't resist because it's so over the top to think that TC should be productized to your needs, and demand hand-holding. Like they somehow "owe" you something?
Perhaps the easiest thing to do is change your outlook and become a nerd. Nothing to be ashamed of. :) Or just seek out something else that meets your needs.
Here's the original document from the "Elite Group" that brought all of this fun to us in the first place. People went absolutely bat-crazy over it's simplicity.
Ken and Dennis kind of hand-hold the audience step-by-step over what it's all about:
http://cva.stanford.edu/classes/cs99s/papers/ritchie-thompson-unix-time-sharing-system.pdf
Towards the end, you'll see some really impressive uptimes! Yet they plowed ahead.
Start here. OR boot microcore, do NOT go online, and actually learn what you can do with all that the devs of TC have enabled.
Check it out: a 3rd-edition of "How Linux Works" by Brian Ward is due out later this year, however the 2nd edition from 2015 is still quite relevant.
LEARNing something is soooo much more satisfying that just going down a checklist based on the work of others.
.. I mean c'mon man, you asked for it. :) :)
-
There is no easy to understand guide to install specific programs that aren't present in the official repo.
I wouldn't expect compiling a program and making an TC extension to be task for "an everyday human user". It's one of those tasks that if you have to ask, you shouldn't be doing it IMHO.
People need to understand *their* requirements and pick a solution that matches.
With so many great options available, isn't it a matter of just moving on the the next one. You can even pay for a turnkey solution and pay for support if that is more suitable. If "time is money" it can work out the right solution for you.
-
..humanuser...
I can't resist because it's so over the top to think that TC should be productized to your needs, and demand hand-holding. Like they somehow "owe" you something?
TC doesn't owe me anything and I don't owe anything by using it either.
However, If a software works properly, It should definitely do what It advertise to do (in this case, allowing me to use my computer).
..humanuser...
Perhaps the easiest thing to do is change your outlook and become a nerd. Nothing to be ashamed of. :) Or just seek out something else that meets your needs.
LEARNing something is soooo much more satisfying that just going down a checklist based on the work of others.
.. I mean c'mon man, you asked for it. :) :)
I may look into this again later, thank you for the links, but right now I don't feel like tinkering around to have something working, when I can use things that work out-of-the-box.
Most people don't have the ability, time or even want to read documentation, just to have an OS working where other OS work out-of-the-box.
But fair point.
I wouldn't expect compiling a program and making an TC extension to be task for "an everyday human user". It's one of those tasks that if you have to ask, you shouldn't be doing it IMHO.
Installing apps that aren't present in the official repo is definitely something that most humans need, because the official repo lacks way too many good apps.
-
have you never realised:
software never works (everybody knows that)
the big pathetic error of IT nerds: you help the computer, yet the computer doesn't help you.
-
Ok, since you've been around since the DSL days, you should know the ropes about what it's about.
Have you looked into dCore, which instead of relying on dev AND user contributions for programs like TCE, it relies upon Debian / Ubuntu packages, which get downloaded and converted into "SCE"'s? It might be for this very reason that relying on a major distro repository frees up the dev to improve dCore itself, instead of hand-holding users building endless games taking time away from the main project.
So do you want TC to support all the package formats out there, in addition to every appimage, flatpak, snaps etc etc - making TC some sort of universal app-store. Or are you talking debs and rpm conversions only? Or are you willing to compile from source, and turn those into tcz's, which are simply not plug n play unless you hit the command line. Sorry, but 5 year olds need not apply for tcz's.
Have you considered that the devs and user contributed tcz's could be a major security risk, since we are not security experts? How do you know that the Terminus-font.tcz package I submitted is not a rootkit? Something to think about.
Seriously - since you are a dsl user, have you looked into dCore? What about Puppy? Knoppix? Any other system that will already do what you ask?
At times I just don't get the idea from some who want to turn TC into something it is not. Is it an agenda? Or just a simple misunderstanding about what TC is all about, when other systems that do what they want are already at hand?
It's enough to drive a guy to fully appreciate the no-nonsense ethos of OpenBSD (of which I admire too) that don't waste time in forums whatsoever. :)
-
Hi, PDP-8!
Wonderful article on UNIX, thanks a lot! Just like ancient saga, fairy tale!
"UNIX can run on hardware costing as little as 40,000$"
"UNIX occupies 42K bytes"
"The PDP-11 has a 1M fixed-head disk"
Was this written about something produced by our civilization? No, probably this is space invaders epos, dropped accidentally out the UFO window.
Cheers!
-
Yeah, that paper was the shot heard around the world!
Using mixed-metaphors, imagine us working in some other comp center and coming across it ... we'd be babbling in disbelief ...
"Check it out - it only crashes every other day and one run was up for 2 weeks!
We take uptime for granted these days - back then when you got a mini and placed it up against only ONE wall of a room, uptime for more than a week was rare before having to reboot. And when you bought a mini, you also bought into a service-contract for a team to come and swap boards, fix dying chips, etc on a regular basis. You had to. Imagine if years later when you bought an IBM PC, you also had some techs knocking at your door every 2 weeks to keep it running!
"Hey, these guys are doing system programming a high-level language called C. WHAT? No more assembly? You gotta be kidding. Can't be done."
"Check out that pipe | mechanism. Redirection <> is pretty standard, but check that pipe out!"
"What do you mean you can treat external devices like files? No vendor o/s specific language to manage our files and send/retrieve them from devices? Are you telling me that to print my listings, all I have to do is
cat mythesis > /dev/lpt
Dude, what sorcery is this??? "
Nearly everybody knows about the introduction of unix pipes, but "everything is a file" including things like printers, just exploded your head.
Professor Bob Fabry at Berkeley got wind of this, and immediately brought V4 back to their comp center. Makes sense - Berkeley was Ken's alma-mater, where presumably he was playing with the BTS timesharing system many years before. Well before the "BSD" days.
At this time, MIT and GE/Honeywell, with ATT out of the picture, the rest of the team were trying to work the bugs out of MULTICS and were progressing well. And of course Richard Stallman was working on the ITS timesharing system, also at MIT - programmed in assembly of course, in the AI department of MIT on big-iron like the PDP-10, unlike ATT's "rasberry-pi pdp-11's". ITS being a counter-revolutionary reaction to the Arpa-funded CTSS > Multics project, where ITS was left to the AI hackers to do what they pleased without any commercial / government oversight.
Easily forgotten is Gary Kildall working on CP/M for MICROprocessors at this time. Got it to work, but using paper-tape punch and mechanical teletypes made it far less useful for common consumers. He was trying to figure out how to rattle the disks of the recently introduced 8-inch floppy, where CP/M makes more sense for the 70's consumers.
A ground-breaking time man. That sense of wonder and learning is what keeps me involved with TinyCore today - it seems to espouse some of the same spirit.
Unfortunately, like back then, many view computers as simple app launchers "dude, how do I get super-mario-brothers to play?" Sigh. :)