Hi,

Quite off-topic, but here goes. I'm currently rewriting my CentOS-based book on Linux administration. This second edition is based on Slackware. My editor has asked me to add a "History of Linux" chapter.

There's one detail I can't seem to find on the Internet. A few years after Dennis Ritchie and Ken Thompson created Unix at Bell Labs, Unix was licensed by AT & T, in the sense that AT & T more or less self-righteously proclaimed that the Unix code belonged to their company. Which caused a lot of bad blood at the time.

Does anybody remember what year (even approximately) that was? I once had a Unix & Linux guru tell me the whole story a few years back, but unfortunately I can't contact him, and the only information I have is what I could remember from his story.

Cheers,

Niki

https://en.wikipedia.org/wiki/Unix ?

Of course, this was my first search. But the exact info can't be found there. Only roughly that it happened somewhere between 1972 and 1980.

Unix always belonged to AT & T, as this was Bell Labs' parent organization: you can find more details in (from the wikipedia article)

http://www.faqs.org/docs/artu/ch02s01.html
http://cm.bell-labs.com/cm/cs/who/dmr/hist.html

the thing was that Unix couldn't be a product, so it had to be distributed freely, this until 1983, as explained in the first link above

Ah, now I get it. Thanks very much !!!

Something you may want to mention as you go along is the invention, by M(alcolm) Douglas McIlroy, of pipes. UNIX (we're talking the AT&T UNIX, not other Unix) consisted, in addition to the kernel, of a large number of small programs that worked together to perform useful work and pipes made that possible; e.g., cat some_file | sed | awk | whatever (that's pretty simplified but that's essentially what you're doing). It's that "write programs that do one thing an do it well, write programs that work together" part of the UNIX Philosophy (proposed by McIlroy).

Some years ago I taught a course, the UNIX/C Program, developed by William C. Holliker (between 1987 and 1994 and distributed nationally mostly to educational institutions along with some commercial organizations) at Marygrove College in Detroit. The course was aimed at people already in the business -- folks familiar with computers and software on some platform -- to broaden their skills; 8 weeks, 40 hours per week. Starting with the basic utilities (such as vi, ed, cat) and proceeding though shell programming (KornShell), to C programming to system administration the course proved quite valuable both to the students and, frankly, to me -- you learn a heckuva lot teaching. The entire emphasis was on putting McIlory's ideas into practice, using pipes, filters and other tools. I taught from spring 1994 into 1996 and it was one of the most rewarding experiences I've ever had in this business.

Over and over again, students spoke up about how easy it was to perform useful work with just a few tools working together; some came from DOS, some came from mainframes, some came from lord knows what but the pretty much universally were pretty happy campers when they finished and went on to put what they'd learned into practice (I still hear from a couple of guys).

Linus Torvalds, in brief, had used UNIX at school, loved it, couldn't afford a license, so he rolled his own kernel, gave it away and the rest is history -- the contributions of Richard Stallman and crew, the contributions of distribution developers (in our case, Patrick Volkerding, thank you Pat and crew) and the contributions of... what, millions? ...and we've got all the tools you could ever imagine at hand to do whatever you need to.

Dang, we do owe a debt to quite a few people (and quite a few corporate entities, too).

Niki, Google translate does a nice job from French to English and you've done a day's work there, well done.

2 members found this post helpful.

Hi,

Niki, some of these links may help you when it comes to Slackware;Hope this helps!

1 members found this post helpful.

Here's a "work in progress" preview. Excuse my French

Imaginez que votre voiture tombe en panne un jour. Vous avez en gros deux possibilités pour la faire réparer.

• Vous la faites remorquer au garage Lapeau & Descouilles en ville : un endroit très high tech avec beaucoup de chrome et de carrelage blanc, sans la moindre trace de cambouis ni de poussière. Les mécaniciens ressemblent à des ingénieurs en blouse blanche. Ils sont armés jusqu’aux dents d’ordinateurs portables et ne répondent à personne. Votre voiture est le seul objet sale dans cet endroit étincelant de propreté. L’ingénieur en chef dissimule à peine son dégoût, ouvre le capot et branche un câble dans une prise dont vous ignoriez l’existence jusque-là. Il retourne devant l’écran de son portable, clique sur une série de boutons dans son logiciel de diagnostic et vous annonce qu’il ne peut pas vous fixer un rendez-vous avant le début du mois prochain, mais qu’on peut déjà établir un devis.
• Vous décidez d’aller voir Tony, le mécanicien du village. En guise de bonjour, Tony vous présente son avant-bras à peine moins maculé de cambouis que ses mains. Il propose de s’occuper tout de suite de votre voiture, l’objet le plus propre dans tout le garage. Il ouvre le capot et contemple le moteur en sifflotant le refrain qui vient de passer à la radio. Puis il fouille dans sa boîte à outils et en extrait une clé tubulaire, un tournevis et une pince. À peine deux minutes plus tard, il vous annonce qu’il fallait juste changer les bougies et refixer une durite qui s’était défaite. Il refuse de se faire payer malgré vos protestations réitérées.

Les commandes que nous venons d’apprendre sont certes aussi peu spectaculaires qu’une clé tubulaire, un tournevis ou une clé de douze. Vous serez d’ailleurs probablement surpris d’apprendre que ce sont des commandes Unix, le système d’exploitation le plus éprouvé de la planète, qui a fêté ses vingt ans un an avant la sortie de Windows 3.0. Les principes de base d’Unix sont restés les mêmes pendant près de quarante ans. Douglas McIlroy, l’un des fondateurs d’Unix, a résumé la philosophie Unix en une série de trois impératifs catégoriques*:

1. écrivez des programmes qui font une seule chose, et qui la font bien*;
2. écrivez des programmes qui se combinent les uns avec les autres*;
3. écrivez des programmes pour gérer des flux de texte, car c’est une interface universelle.

Même si vous n’avez pas l’intention d’écrire des programmes Unix (ou Linux), ces trois règles sont d’une importance capitale pour tout utilisateur de systèmes de cette famille. À partir du moment où vous maîtrisez ne serait-ce qu’une poignée de commandes Unix, vous apprendrez à les combiner pour résoudre les problèmes de manière efficace. Gardez ce principe à l’esprit lors de votre apprentissage, car nous verrons bientôt comment les tâches les plus complexes peuvent être décomposées en une série d’opérations simples.

Nice analogy! My Tony is Jim down the road -- goes by Rusty's Nuts, works out of his pole barn, is meticulous, leaves nothing to chance, doesn't charge enough, great guy. I do love living in the country.

I've never been able to find a better way than McIlory's summary, started doing things that way in the 80's and haven't stopped.

Good piece, keep going.

To translate
"Write programs to work together"
instead of
"écrivez des programmes qui se combinent les uns avec les autres"
may I suggest
"écrivez des programmes qui coopèrent"

Just my 0.5 cent

I know this article on Wikipedia isn't the best information, but the references it cites are stuffed full of useful tidbits:

http://en.wikipedia.org/wiki/History_of_Linux

here's a good article:

http://coe.berkeley.edu/labnotes/history_unix.html

1 members found this post helpful.