Slashdot Mirror

BTW - O'Reilly has more books on Java programming than .NET programming, and with quite a few Python books.

And let's not get started on how many Perl books they have published. ;-)

BTW - O'Reilly has more books on Java programming than .NET programming, and with quite a few Python books.

And let's not get started on how many Perl books they have published. ;-)

BTW - O'Reilly has more books on Java programming than .NET programming, and with quite a few Python books.

And let's not get started on how many Perl books they have published. ;-)

Sort of like the Baen free library, which does the same thing with fiction. I don't know if you could do the same with software, but putting the full text of a book online tends to increase sales.

The wonderful thing about standards is that there are so many to choose from. --Admiral Grace Hopper or Andrew Tannenbaum?[A]

[A] It appears the saying even applies to itself! Andrew Tannenbaum wrote this in both editions of Computer Networks, the first of which was published in 1981. However, some evidence indicates that Admiral Hopper first said this in the late 1970s, and the saying is attributed to her by The Unix-Haters Handbook. Tim Salo posed the question on the IETF mailing list in September 1994, and he received a variety of responses, which are summarized at major mailing list archives. (Among many other locations, his summary is archived at this link.)

credit: this link

This is indeed an excellent read and well worth the time - if you want some other online books which discuss the earlier days of computing and hacker culture try these

Free As In Freedom - Sam Williams - A biography of Richard Stallman and an excellent read for those who would like to understand the man a bit more or even understand how GNU and Open Source actually happen. I reccomend this to even people who dislike RMS (as i did) as you will understand the man from a new perspective

The Cathedral and the Bazzar- Eric Raymond - This book has been condemmed and praised by many and provides an intersting look at open source and the different models of software - worth a read

Underground : Hacking, madness and obsession on the electronic frontier - Sulette Dreyfuss - A great look inside the world of the cracker and very intersting and compelling to read

There are heaps more out there - post them as you find them - BTW if you have a bit of cash to spend i reccomend Hackers by Steven Levy and Fire in the Valley by freiburger and swain for 2 more great books on computer and PC history

If you work with a Unix shell: one of the best references that I found: O'Reilly's Unix Power Tools. Some stuff may be outdated, but it's packed to the brim with useful, hands-on info and it's a very good bang for the buck.

Oreilly also has a Mastering Regular Expressions book.

Start with Learning Perl, proceed with Programming Perl and finish off with Mastering Regular Expressions. Your parsing needs will be filled forever.

Start with Learning Perl, proceed with Programming Perl and finish off with Mastering Regular Expressions. Your parsing needs will be filled forever.

Start with Learning Perl, proceed with Programming Perl and finish off with Mastering Regular Expressions. Your parsing needs will be filled forever.

O'Reilly Open Books Project
Bruce Eckel's "Thinking in..." books
Data Structures and Algorithms books
MIT's Structure and Interpretation of Programming Languages
Numerical Recipes series
Handbook of Applied Cryptography
The Art of Assembly Language Programming
Object-Oriented System Development
GTK+/Gnome Application Development
GNU Autoconf, Automake, and Libtool
Effective Perl (partial)
Programming Pearls (partial)

I have one for you - Free as in freedom - Sam williams - great book on RMS (Stallman for those not in the know)and the reasons behind GNU and Open Source - Worth the read (even a RMS hater like me appreciates it)

Soul of a new machine - Tracy Kidder - inside the creation of the data general eagle mini comp - a great look at IT in the late 70's early 80's - considered a classic of tech writing

Fire in the Valley - Frieberger and Swaine - Considered the definitive history of the PC revolution and silicon valley.

Infinite Loop - Micheal S Malone a good look inside Apple computer - real insight into what went on behind the scenes

Hackers - Steven Levy - the classic of computer tech writing - the reality of hackers and an insight into where open source came from

Free as in Freedom - Sam Williams - Fascinating look at RMS and what makes him tick, even someone who often disagrees with him(like me)found a new insight into him and the book is GPL and available in full online

Thats just a few with links for you - PS i also love the following books myself - theyre a great read for many reasons...

-The unix Haters Handbook (dont laugh - its a funny read and so much of this stuff still bugs me)
-Sluggy Freelance Books
-The Bastard Operator from hell books
-Underground - Sulette Davies (great book about hackers and available online if you lookat www.underground.com)
-Insanely Great and Crypto - Newer books by steven levy
-The Cathedral and the Bazzar - Eric Raymonds book on open source
-Takedown - The pursuit of Kevin mitnick (a bit biased but a good read) let me know your favourites ok.

Open source software is changing the nature and the very future of the software industry. To help you figure out how everything fits together, we recently updated our Open Source Bibliography. The collection of books described in this third edition represents what we consider the best resources available on open source technologies. (Don't worry, we didn't just select our own publications.) Check it out at: http://opensource.oreilly.com/news/biblio_0502.htm l

The Camel Book.

According to what I read in Free as in Freedom, one of the (major?) influences that drove RMS to originate the Free Software Foundation and the GNU project was Xerox's reluctance to share the source for their laser printer software.
First that and now this? Boy do they love free software :).

Bioinformatics.

Just north of Washington DC area there are almost 200 companies that are working in the bioinformatics area s. Subject knowledge is good of course but even better is knowledge of Perl. O'Reilly even has 2 books Beginning Perl for Bioinformatics and Developing Bioinformatics Computer Skills

Then there are companies that are doing lots of work regarding facial recognition.

Hope this helps.

Bioinformatics.

Just north of Washington DC area there are almost 200 companies that are working in the bioinformatics area s. Subject knowledge is good of course but even better is knowledge of Perl. O'Reilly even has 2 books Beginning Perl for Bioinformatics and Developing Bioinformatics Computer Skills

Then there are companies that are doing lots of work regarding facial recognition.

Hope this helps.

When WalMart starts selling volumes 3 and 8 of the O'Reilly X Window Systems Guide, I'll start hoping there's an inkling of a chance you're right.

Hell, barely anybody at all anywhere has those essential references.

When WalMart starts selling volumes 3 and 8 of the O'Reilly X Window Systems Guide, I'll start hoping there's an inkling of a chance you're right.

Hell, barely anybody at all anywhere has those essential references.

I just finished reading Programming PHP, Rasmus Lerdorf's latest co-authored book.

It's by far the most concise, useful, and down-and-dirty books I've ever read on PHP. Even the usually-useless PHP function reference in this books is a step above the norm.

The book talks about important things like PDF creation, the GD library, and how to extend PHP. Setting up and connecting to a DB is kept to a minimum. Kudos to the man.

S

I'd agree that the mod_perl Developer's Cookbook is really good, and you'll have to prise it from my dead hands before I'll give up my copy.

I agree -- the mouse book rocks! The part on CGI debugging is particularly good. Not only that but the first edition is free in digital form.

• It looks like a nice thick book, but it's very padded. The font is huge (12 to 14 points), there's a lot of padding (most code samples listed twice, 40 pages of appendix material that could have been 8 URLs), the margins are huge, and there's an awful lot of repetition (the 10 lines justifying -wT are repeated nearly every time it's used in a program). I bet that the Mouse book squeezes twice as much content into 450 pages as this one does in 525.
• Some chapters belong better in a Perl book ("Tied Variables").
• Some inclusions/exclusions and focus choices are very odd. There's a very detailed chapter for Mason, but no mention of templates (literally - not even in the index).
• Their style is very choppy. They'll present a couple lines of code, then a paragraph talking about it, repeat. It's very difficult to get a cohesive view of the program this way - it's spoon-fed to you rather than presented whole. (Undoubtedly this is why they repeat all the code at the end of each chapter, but I prefer longer chunks of unbroken code).

And their "Safari" product is neat. I use it as a try-before-you-buy for O'Reilly technical books.

Colliding billiard balls. Missile trajectories. Cornering dynamics in speeding cars. By applying the laws of physics, you can realistically model nearly everything in games that bounces around, flies, rolls, slides, or isn't sitting still, to create compelling, believable content for computer games, simulations, and animation. Physics for Game Developers serves as the starting point for enriching games with physics-based realism.

Colliding billiard balls. Missile trajectories. Cornering dynamics in speeding cars. By applying the laws of physics, you can realistically model nearly everything in games that bounces around, flies, rolls, slides, or isn't sitting still, to create compelling, believable content for computer games, simulations, and animation. Physics for Game Developers serves as the starting point for enriching games with physics-based realism.

One more crippling bombshell hit the already beleaguered Emacs community when FSF confirmed that the Emacs market share has dropped yet again, with yet more users switching to the highly praised vi product line. Coming on the heels of a recent user survey which plainly states that Emacs is continuing to lose market share, this news serves to reinforce what we've known all along. Emacs is collapsing in complete disarray, as has had so many releases it's current version number is greater than 21, a clear sign of crappily maintained software.

You don't need to be a Kreskin to predict the Emacs future. The writing is on the wall: Emacs faces a bleak future. In fact there won't be any future at all for Emacs because Emacs is dying. Things are looking very bad for Emacs. As many of us are already aware, Emacs continues to lose market share to vi. The red ink flows like a river of blood.

Let's keep to the facts and look at some numbers.

Tim O'Reilly, of O'Reilly and Associates Publishing (ya know, the books with the animals on the cover), told folks on his Ask Tim forum that he is among those that have made the switch from Emacs to vi. In his message, he tells his followers that O'Reilly sells almost double the number of vi books when compared to sales of Emacs books. Likewise, an O'Reilly sponsored Linux Expo vi/Emacs paintball match shows a similar 2:1 advantage to team vi.

All major surveys show that Emacs has steadily declined in market share. Emacs is very sick and its long term survival prospects are very dim. If Emacs is to survive at all it will be among text editor dilettante dabblers. Emacs continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes...

Emacs is DEAD

It is official, FSF confirms: Emacs is dying

One more crippling bombshell hit the already beleaguered Emacs community when FSF
confirmed that the Emacs market share has dropped yet again, with yet more users
switching to the highly praised vi product line. Coming on the heels of a
recent user survey which plainly states that Emacs is continuing to lose market
share, this news serves to reinforce what we've known all along. Emacs is
collapsing in complete disarray, as has had so many releases it's current version
number is greater than 21, a clear sign of crappily maintained software.

You don't need to be a Kreskin to predict the Emacs future. The writing is on the
wall: Emacs faces a bleak future. In fact there won't be any future at all for
Emacs because Emacs is dying. Things are looking very bad for Emacs. As
many of us are already aware, Emacs continues to lose market share to vi.
The red ink flows like a river of blood.

Let's keep to the facts and look at some numbers.

Tim O'Reilly, of O'Reilly and Associates Publishing (ya know, the books with the
animals on the cover), told folks on his Ask Tim forum that he is among those that
have made the switch from Emacs to vi. In
his message, he tells
his followers that O'Reilly sells almost double the number of vi books when
compared to sales of Emacs books. Likewise, an O'Reilly sponsored Linux Expo vi/Emacs
paintball match shows a similar 2:1 advantage to team vi.

All major surveys show that Emacs has steadily declined in market share. Emacs is very
sick and its long term survival prospects are very dim. If Emacs is to survive at all
it will be among text editor dilettante dabblers. Emacs continues to decay. Nothing short
of a miracle could save it at this point in time. For all practical purposes...

Emacs is DEAD

It is official, FSF confirms: Emacs is dying

One more crippling bombshell hit the already beleaguered Emacs community when FSF confirmed that the Emacs market share has dropped yet again, with yet more users switching to the highly praised vi product line. Coming on the heels of a recent user survey which plainly states that Emacs is continuing to lose market share, this news serves to reinforce what we've known all along. Emacs is collapsing in complete disarray, as has had so many releases it's current version number is greater than 21, a clear sign of crappily maintained software.

You don't need to be a Kreskin to predict the Emacs future. The writing is on the wall: Emacs faces a bleak future. In fact there won't be any future at all for Emacs because Emacs is dying. Things are looking very bad for Emacs. As many of us are already aware, Emacs continues to lose market share to vi. The red ink flows like a river of blood.

Let's keep to the facts and look at some numbers.

Tim O'Reilly, of O'Reilly and Associates Publishing (ya know, the books with the animals on the cover), told folks on his Ask Tim forum that he is among those that have made the switch to Emacs from vi. In his message, he tells his followers that O'Reilly sells almost double the number of vi books when compared to sales of Emacs books. Likewise, an O'Reilly sponsored Linux Expo vi/Emacs paintball match shows a similar 2:1 advantage to team vi.

All major surveys show that Emacs has steadily declined in market share. Emacs is very sick and its long term survival prospects are very dim. If Emacs is to survive at all it will be among text editor dilettante dabblers. Emacs continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes...

Emacs is DEAD

"(And for those interested in writing Perl applications for this new platform [OS X], watch for Programming Cocoa Applications with Perl, also coming soon from O'Reilly.)"

"(And for those interested in writing Perl applications for this new platform [OS X], watch for Programming Cocoa Applications with Perl, also coming soon from O'Reilly.)"

This book chapter from O'Reilly's OpenSources book captures the spirit of Mozilla really well:

Freeing the Source: The Story of Mozilla

Here is a sample chapter from Learning Perl

Give them gm crops that work in drought conditions, defeats local varmints, etc.

Or how about stopping the promotion of global agri-monoculture and helping them bring back the native crops that work in drought conditions, defeats local varmints, etcetera.

GM crops are not only an environmental disaster waiting to happen (since plants and their pollen have this annoying habit of spreading outside where your plant them), and a corporate bastards' wet dream of controlling global food supplies, they are a solution in search of a problem.

Take this "golden rice" bullshit. The areas they're hyping to grow this stuff already have native crops that provide plenty of vitamin A - but these crops are being squeezed out by globalized agriculture.

Regular expressions aren't so much either a trick or a tool exactly, but you can use them with all the "good" tools.

Get the book "Mastering Regular Expressions," by Jeffrey E. F. Friedl. http://www.oreilly.com/catalog/regex2/

Read it slowly, a couple of pages every day. I didn't understand much of what he was trying to say until I read the book the second time.

But why make up my own clever things to say... From http://www.oreilly.com/catalog/regex/desc.html "There can be certain subtle, but valuable, ways to think when you're using regular expressions, and these can be taught."

I find that books that teach you how to think about problems and solutions are few and far between, and books that do it well are almost impossible to find. This books is one of those.

Once learned regular expressions are one of those things that can profoundly effect the way you work. And once your there "you wonder how they [other people] use UNIX w/o them".

Regular expressions aren't so much either a trick or a tool exactly, but you can use them with all the "good" tools.

Get the book "Mastering Regular Expressions," by Jeffrey E. F. Friedl. http://www.oreilly.com/catalog/regex2/

Read it slowly, a couple of pages every day. I didn't understand much of what he was trying to say until I read the book the second time.

But why make up my own clever things to say... From http://www.oreilly.com/catalog/regex/desc.html "There can be certain subtle, but valuable, ways to think when you're using regular expressions, and these can be taught."

I find that books that teach you how to think about problems and solutions are few and far between, and books that do it well are almost impossible to find. This books is one of those.

Once learned regular expressions are one of those things that can profoundly effect the way you work. And once your there "you wonder how they [other people] use UNIX w/o them".

All the tricks you can cram into one of those big books, and more: Unix Power Tools -- O'Reilly's best book, IMHO.

An even cheaper way to get it (or the information in it) is from O'Reilly's Safari electronic book site. Less than $10 per month for several books, and it is searchable, etc. and you can print out key sections if you want... Safari Books Online

O'Reilly's Safari lets you read books online. It's a lot cheaper than buying the books, and for things you don't absolutely need on your shelf, it's a good deal.

It's really easy to use basic SSH, but managing keys and using the more advanced forms of authentication is more of a hassle. You can read the docs, search the web for tutorials, or you can spend a safari point (a couple of bucks) to get full access to the book online.

I haven't read the book, but I imagine that it would be helpful for people who want to do things like run automatic backups over the network through a SSH tunnel.

Actually, the book has been out for over a year now, as can be seen on the O'Reilly site.

No, sorry, this time you've got it wrong. BSD was distributed as a complete system, even if most of that was AT&T code and even if it was based on the original Unix system created by AT&T. See (for example) this:
"Over the next year, Joy, acting in the capacity of distribution secretary, sent out about thirty free copies of the system." Not patches, the whole system.

The difference was that GNU was to be a completely free system from the begining, but this is not germane to the basic premise. Actually, all of this is hair splitting anyway. Even if it had been distributed as patches, BSD clearly never refered to a single component the way Linux did and does.

Anyone who wants to understand RMS should read Free as In Freedom first. It's free as in beer and free as in speech.

The most chilling part of the whole book is a reference to Bill Gates' Open Letter to Hobbyists. It's chilling really, to think of young Bill, writing this letter, unaware of where he will be in 25 some-odd years.

Two quotes from this letter are very interesting:

Nothing would please me more than being able to hire ten programmers and deluge the hobby market with good software.

I think he succeeded in the hiring and deluging, but some might want to qualify "good".

But ultimately, he got one thing terribly wrong...

What hobbyist can put 3-man years into programming, finding all bugs, documenting his product and distribute for free?

It turns out that the Internet makes that thing possible. A math whiz at MIT, a graduate student in Finland, a couple hundred thousand computer hobbyists all over the world can do this.

Before you attack RMS for his wacky views, remember that he has committed his life to his views. He's committed his life to proving Gates' letter wrong.

Of course, you can buy tools from someone, and IMHO, that's okay. I can't grow bananas in my back yard, so I pay money for them. I suppose RMS would do without bananas.

But the GNU project is all about making the quality tools for free. The GPL enforces that notion with our own crazy copyright law. To extend my analogy, I do grow basil in a window box. You're welcome to some of my basil, but if you want to a whole lot of it, please give me some of your fine pesto sauce. You don't want to share, OK, then get your mitts off my plants.

More than many other modern occupations, programming is a craft: like gardening, or woodworking. Many people do it for fun. Some are lucky enough to get paid. The freedom RMS is fighting for is the freedom to share your code openly. You get my basil, I get your pesto, and everyone can get bananas. The conventional rules of scarcity don't apply with code. As we share, our tools get better, we become better craftsmen and perhaps we get our $208 back.

LPI Linux Certification in a Nutshell is very good, since it is preping you to certify for LPI 101 and LPI 102 it contains excersies and questions.

For Electronic references start here:
O'Reilly Open Books Project

Learn it, live it, love it.
Let me say it one more time, O'Reilly.

As an academic myself, a few different issues spring to mind. I'll try to organize them in a somewhat coherent fashion.

First, I would ask if you really need textbooks? While most professors still use textbooks, a lot of people do fine without using any textbooks at all. Yes, it requires more effort on the part of the professor to research all of the sources themself; however, in my experience, the results are certainly worth it. Rather than teaching a politically-correct, watered-down course, you can tailor it to precisely what you feel is important. And shouldn't that be a professor's obligation anyhow?

For sources, I would start with the LDP, the FSF, O'Reilly, and Addison-Wesley. These guys easily make up over 95% of my tech bookshelf.

Addison-Wesley also does textbooks. I don't know how good they are but if they pay as much attention to their textbooks as they do to their IT texts, they'll be excellent.

On another matter, if you're going to consider rolling your own textbooks, don't reinvent the wheel. Much, if not most, of the documenation out there is under a free-as-in-speech license. Use it. Also, I don't think that you need to start your own website. I can't speak for the LDP but it seems to me that they would be delighted to assist you in developing the texts that you need.

Finally, if you go to the effort of developing all of this content, please do the right thing and share it with the community. Ideally, this would through a free-as-in-speech license.

• LPI (ORA) - more course-like coverage of basic Linux
  
• Rebel Code - fantastic history
  
• Free as in Freedom - RMS bio, a good read and also available under the GFDL
  
• Cathedral and the Bazaar
  
• In the Beginning was the Command Line - nostalgia
  
• Learning the Bash Shell
  
• Sed & Awk
  
• The Linux Documentation Project
  

Quite useful and handy.

D

The keyboard has hiragana on it, which is the Japanese syllabic writing system for native works. Shift (I think) outputs the equivilant katakana, which is the syllabic writing system for borrowed (foreign) words. An input system on the computer automatically replaces the kana with the kanji for words that can be written in kanji as you go.

There are actually dozens of systems for inputting Chinese and Japanese in computers. That is the most common for Japanese today to my knowledge. In China the most common is to have a keyboard with special characters that represent the sounds in Chinese using a system called BoPoMoFo. Unlike the Japanese Kana, the BoPoMoFo characters are never used when writing; only for typing.There actually are Chinese keyboards with large arrays of Hanji (same as Kanji, but how the Chinese say it). Watch the James Bond movie Tomorrow Never Dies to see Bond be intimidated by one :)

If anyone cares to know more I'd recomend this book published by Oreilly.

Oh, and PinYin is the romanization system for Chinese endorsed by the government of the PRC. The BoPoMoFo keyboard symbols represent PinYin sounds.