so it becomes something I have been saying for a whileAny Human Being who is willing to work has a God given right to work and to reap the benefits of their labors.
Agreement, disagreement, comments, questions?
well you'd get disagreement from atheists and agnostics. but a handy retort is to make "god" a placeholder for "the innate nature of being..."or the nature of the unverse, or simply "we hold these truths to be self-evident!" (my favorite.) these are functional replacements for the use of the word "god" in a non-religious context. (i don't think s/he'll be offended.)
more importantly than whether your argument is true or not (i think it is) or rather what's more likely to create disagreement (i think everyone can agree with you on some level) is not the argument itself but what constitutes "the benefits." here there is the greatest diversity of opinion. someone from the recording industry association of america or microsoft would say that the benefits are a royality for each use, or a fee for each copy on each device.
that definition would make all software not-libre, or "free software" impossible. but you can charge for libre software, provided that you do not restrict its modification and redistribution. so "the benefits" are still very different from one group to another, even in a commercial context.
From the 60's comes the concept of complicated vs complex. complicated means just that. complex means that the developer has gone to great lenghts to make a complex task simple to understand and use.
if only it was that simple, it's not just a matter of complicated vs. not complicated. it's matter of obfuscation/abstraction vs. a lack of these things. it can go either way.
for example, i can make some things very simple by just doing them in assembler. there are very few tasks today that cannot be made easier for both programmer and user by using a higher level language, but provided i'm already familiar with assembler, it is very good for some very simple tasks.
if i want to print to the screen and compile an executable, all i have to say in BASIC is PRINT "hello world!"
now not many languages make it much easier to write a hello world program, not even pascal. with pascal you must create a structure to put the "print" (what is it, echo?) statement in. either one can be made into an executable binary very easily.
if you want to sort a large array of files, it will be easier to do in javascript than in basic. you won't even need to create the array. you can derive it from a string using variable.split() and the array will be created automatically, regardless of how many elements it has. javascript is not always that "simple" but sometimes it is more simple than basic.
a learning curve is a factor in simplicity. i insist that some things make more sense to someone that has never seen them than others. (otherwise, all things are equally easy to learn. i do not believe this.) it follows that some things will require more fighting of intuition, mroe open-mindedness to get used to doing, regardless of which "way" is learned first.
a common retort to "linux has a larger learning curve" is "that's because you're used to windows." there's truth to that, because learning windows first didn't necessarily make things any easier. but if you have someone who's never seen either, many things are going to be easier in windows for someone who has never seen either.
that list is getting smaller as linux is used by a more diverse group of people, and is developed by a more diverse group of people.
one wonderful debate is that of interface, you would never think to enter:
sudo pump -i eth0
to connect to the net if you're used to clicking a button that says "connect to the internet"
or if you're used to not doing anything at all! (dhcp...)
you'd wonder why you couldn't just click a button, or just type:
netconnect
but if you created "netconnect" yourself, you'd think being in the same folder it's in, you wouldn't need a path, right? WRONG. the current folder is not in the path. therefore it's actually:
./netconnect
(as a non-linux user this once annoyed me greatly.)
./ is not much to type, but it feels like a lot when you didn't have to before (you get used to it.)
every little thing like that is a complication for the user. BUT! we must assume that not everything automated will run the way it's intended in every situation people find themselves in.
for example, half the apps i use in 2.x can't resolve dns. why? no one knows. they're very very simple for other people, for me this is infinitely complicated because i have NO IDEA. my years of linux experience (little of which has anything to do with networking i admit) have not helped.
in fact it's even complicated for people that know much more than i do to figure out.
now getting back to our netconnect script, it's easy to say:
echo \#\!/bin/sh > netconnect
chmod +x netconnect
echo sudo pump -i eth0 >> netconnect
and now you have the magical command "netconnect" that does exactly what you want. (probably)
i'm using the example of pump from dsl because it's less complicated than udhcpc (just typing pump is easier to remember, i'm only mostly sure that udhcpc is the command tc uses...)
but suppose i'm one of the interesting cases where eth1 is needed instead of eth0?
obviously our script just got more complicated. there are lots of ways to do it. you could make it so that it just took an argument:
netconnect eth0
netconnect eth1
and thats the easiest modification to a script- it will use the same number of lines, just add a variable.
but now eth0 users must type TWO arguments, not just the name of the script to get online.
so we choose to make it easy on the typical eth0 user, it defaults eth0 unless you type the eth1 argument.
this is a good use of defaults, it keeps it just as easy for most users, and ask very little of eth1 users. it simply introduces one decision making block. that's about as simple as any script gets.
but it's not as simple as just typing netconnect for everyone!
to do that we have to add some kind of detection. it may be very easy to do so, but it complicates the script. but it makes things easy for both eth0 and eth1 users.
note that all this decision making for the script-writer is about a VERY unsophisticated script this far, about as unsophisticated as any script.
but up to this point when we tried to make it automatic, it was very easy for a total noob (and i use the term affectionately) to learn how our script works. really any primary schooler could figure it out just looking at it, not just the really smart ones.
now to make it automatic we'll double the complexity of the script. we're not doubling much! so it will still be pretty straightforward, even though it's twice as complicated.
but you know how binary is, double here, 2 double there, 4, you get to 512 very quickly, which is more than 100 times our original doubling!
and this is how complexity works practically.
to make everything easy for the user, you make everything more complicated for the author.
a stop-gap measure for development of such things in linux, is that "the author" is not one person. it's a team of as many people THAT ARE INTERESTED.
that makes it easier to maintain things of complexity, linus's law is that given enough eyes, all bugs are shallow.
but once you have this open source dynamic putting a stop to bugs, you ALSO HAVE personal dynamics, POLITICS! and greater politics than you would have top-down.
so that's another level of complexity. the more eyeballs you have, the more it takes to keep them working together.
now getting back to our very simple little script, it theoretically has doubled in complexity over the past few months. no problem so far, everything is working the way it ought to, this is open source/free software (and one might argue, any kind of software development, because i think open source/free software is best) at its best!
but sooner or later,
http://en.wikipedia.org/wiki/Feature_creep comes in.
by the time a distro suffers feature creep, its doubled in complexity past the point where the eyes of the people stlil interested can or want to deal with it. at this point people just want to start over and create a new distro, or find a different one.
tc actually has a stopgap against feature creep! it makes everything an extension. thus the mess of a "distro" is based on a very simple, very tiny little core. the features are not fully integrated, so each new version of tc is HIGHLY RESISTANT to feature creep.
but not immune. it's impossible to make a distro of nothing but extensions, there is always a core.
now the "non complex" solution to the eth0 / eth1 solution earlier is just tell people how to figure out which they have. then make a script accordingly. or export it to a variable. or use a bootcode. there are lots of ways that keep the script very simple. and "simple" is often a matter of opinion, but i think not completely a matter of opinion.
the little netconnect script will reach a point of complexity where a smaller number of people looking at it can tell what's wrong with it if and when it doesn't work. and if a little netconnect script can get so complicated, so can the base of tc. it can double in complexity over time, and you expect it to when it's new.
but nothing is immune to feature creep, just like anyone that lives on a diet of 100% sugar for years is going to die young. a diet of 50% sugar and he may live longer, 25%, etc...
regardless of all the stop gaps, the best measure against feature creep is vigilance. bugfixes are not fun, but other distros may focus too much on adding features, like microsoft does.
there's nothing wrong with features, a few at a time, you can add them, see what they do, see how they integrate. over time they will accumulate, but if your first priority is to make things work, then your work will reflect that.
if your first priority is to add features, and you let the existing features suffer or stop working as you add things, then your work will reflect that.
now one of the reasons i loved dsl was its modularity. and indeed, that modularity itself was a feature (and an ingenius one) and also added complexity. but it added it in a way that had a positive effect and helped control complexity. also note that a distro with no complexity is a distro that doesn't DO anything.
the modularity is so helpful, i would consider it a NECESSARY feature of any distro i would want to use. it makes a huge difference.
but that is not the only reason i liked dsl, and like tc which is more modular.
the other reason that tc and dsl have always been so good, is that vigilance i mentioned. robert shingledecker has always been very grown-up, experienced, and responsible with his work. he fixes bugs. diligently. they're a priority. that's just as important as modularization.
if he lived 1000 years (and i rather wish he would,) he would sooner or later, one of these decades, add too many features to tc and then it would get to a point where he wanted to start over with a new distro.
that will never be a problem. only we're a community, and a community can push a distro in any direction. so if tc someday becomes a distro that is so overly complicated it becomes unusable, it will not be robert's fault. if it ever does that it will be because a community cared more about features than maintenance.
the dsl community (which is essentially this community) knew better than that. maybe we do too.
but tc is for most tasks, the simplest and least complicated distro FOR ITS FEATURE SET, which includes its size.
every other distro in the mini cd range is more complicated. so tc has a simple genius to it.
it will continue along those lines of simplicity as long as we allow it to. and tc is just an extreme example of simplicity. what i'm saying goes for any software project, floss or apple or microsoft.
remember that sometimes adding complexity adds to the balance of simplicity/complexity. the modprobe thing, i think it will soon be very simple, and for some people (me...) it will probably be easier the new way than modprobing everything, manually adding everything to bootlocal. for others, maybe.
one complexity that made everything more simple was, you used to have to modprobe your nic to get online. i don't believe in automount, i don't believe in lots of automatic things, but i'm glad all i have to do to get the network running in cloud is just put the cd in, and boot.
that's simple. it's also complex, but the cost is nil.
other forms of simplicity/complexity have great costs, so it's misleading to even talk about simplicity and complexity, what we really ought to talk about is "pros" and "cons." they are easier for everyone to grasp and easier to quantify. and they are NOT "black" and "white," they are all shades of gray.
that's good design! it's complicated, but if it's good it's never too complicated, the pros always outweigh the cons in good design. most people simply never weigh them.
if that sounds too artsy fartsy, just thing of most distros as big fluffy colorful gardens, full of beauty but also very expensive to maintain- requiring great resources from the user. that's ubuntu.
then think of a small zen rock garden. it probably took less labor to create, more thought, and was just as peaceful to assemble as it is to enjoy. big resources are not as important, you can create as much beauty with a square yard as an american gardener could with seven. you can do it without digging.
that's tc, and i think any other small modular distro at its best. the philosophy is completely different, it's a philosophy based on simplicity.
now, getting my wireless running may take some time and frustration... in ubuntu that was simple. but i cannot figure out how it works because of the countless layers of abstraction they added. switching from xfce to jwm and still having wireless, you would not believe what i had to do. ubuntu is not made for that! it tied the abstraction directly to the heavier wm.
it doesn't matter, i'm tired of ubuntu. i want tc 1.x. i want it so much i will sacrifice wireless, for now. it's that much of a difference. i used ubuntu 7, it was very good. it's just too damned heavy and feature-rich now to stand doing anything, it's unlikely i will ever use ubuntu again.
my experience with lighter gui distros is broad and painful, but dsl was excellent, and tc 1.x is just about everything i ever wanted in a distro. i haven't been happier using anything since win3.1 or dos boot disks in the 80's. now they were simple. tc is maybe as simple as 20 years ago, plus usb and dhcp, and ff and gimp. creating a bootable cd has arguably gotten simpler over time. if only the distros on those cd's could do the same. 32bit memory access is another move to simplicity... for coders and users.
then again, it's all more simple than using a typewriter. just imagine trying to get your typewriter on the internet! (i know that's often what they did in the early days...)
Welcome
FAQ
Downloads
Wiki
