LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   History of Unix, Linux & Slackware : in search of info about AT & T and Unix (https://www.linuxquestions.org/questions/slackware-14/history-of-unix-linux-and-slackware-in-search-of-info-about-at-and-t-and-unix-4175470184/)

kikinovak 07-19-2013 05:43 AM

History of Unix, Linux & Slackware : in search of info about AT & T and Unix
 
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

ponce 07-19-2013 05:55 AM

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

kikinovak 07-19-2013 06:04 AM

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.

ponce 07-19-2013 06:28 AM

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
Quote:

in 1983, the U.S. Department of Justice won its second antitrust case against AT&T and broke up the Bell System. This relieved AT&T from the 1958 consent decree that had prevented them from turning Unix into a product. AT&T promptly rushed to commercialize Unix System V—a move that nearly killed Unix.

kikinovak 07-19-2013 07:19 AM

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

tronayne 07-19-2013 07:22 AM

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.

onebuck 07-19-2013 07:41 AM

Member Response
 
Hi,

Niki, some of these links may help you when it comes to Slackware;
Quote:

From Slackware General

Miscellany:
The Slack World
Slackware® Miscellany
alt.os.linux.slackware FAQ <- Help Slackware® Linux users
Slackware® Linux-resources <- Good reference, links

History:
Patrick Volkerding <- '(born October 20, 1966) is the founder and maintainer of the Slackware® Linux distribution' + Informational + Load of external links
Get Slack History <- You gotta read this!
Church of the SubGenius <- SlackMasters Place
Interview with Patrick Volkerding <- April 1st, 1994 by Phil Hughes
LQ Interview with Patrick Volkerding of Slackware <- 'LQ Members question(s) June 7, 2012
Historic Slackware®:
Historic Slackware Alien_Bob's Pipe <- 'Versions 1.01 through '-current'
Historic GNU/Linux Slackware® <- 'Versions 1.1.2, 2.1, 3.0, 3.1, 3.9'
University of Oslo(Lars Strand) <- 'Version 1.1.2 through -current'
Hope this helps!

kikinovak 07-19-2013 08:18 AM

Quote:

Originally Posted by tronayne (Post 4993157)
Something you may want to mention as you go along is the invention, by M(alcolm) Douglas McIlroy, of pipes.

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.

tronayne 07-19-2013 08:37 AM

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.

Didier Spaier 07-19-2013 10:10 AM

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 ;)

ReaperX7 07-19-2013 03:59 PM

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


All times are GMT -5. The time now is 03:55 AM.