The Google user-interface for searching (not the crawling/indexing part, or any of the other Google products) is an exceedingly simple application. There's no e-commerce, very little user-customization, almost no options, very simple layout.
Let's not confuse the size and importance of an application with its implementation complexity.
This part of Google is "heavyweight" in its significance, but it uses what I would call lightweight implementation technologies.
Client-side scripting language, usually JavaScript,
Server-side language,
SQL for database access.
#3 is where there's the most flexibility. Speaking very generally, there are two ways to go:
a. Lightweight scripting systems that depend only on the web server (probably with a loaded module) for support. Typically PHP, Perl, Python, or JSP/ASP using Java or a Microsoft language.
b. Heavyweight systems, of which the two most common are J2EE and.NET. J2EE uses Java as its language, and.NET usually uses C# or VB.
The usability, performance, etc., of the heavyweight systems depend as much on the middleware as the language itself..NET is.NET, but for J2EE there are several choices. In my own experience with heavyweight systems, I found Java to be wonderful, but our J2EE server (Oracle's) very difficult to work with operationaly, and way too complicated for what we needed. So, in my opinion, one has to have much education, experience, and patience if one is to use a heavyweight system.
My conclusion, however, would be that a heavyweight system is the correct choice for a big web application. My bias is towards J2EE because it's more open (and even has open source choices available), but the complexity of J2EE servers is a big concern.
From what I hear,.NET has superior development tools and better support. I don't know whether this is (a) true and (b) worth the disadvantages of using a proprietary system.
In considering whether you need a fireproof safe, and whether such a safe would be OK for media, it's helpful to go back to first principles:
If what you are trying to protect is truly a backup, and not an archive (that is, it is a spare copy, not the only copy), then it is not necessary to protect both the original and the backup from fire (or flood, etc.). It is necessary only to ensure that the hazard doesn't affect both at the same time.
If you want to store both in the same room, or even in the same house, then indeed some sort of fireproof safe would be needed. But it you can store one offsite, then no fireproofing is needed. There's defnitely no need for a safe-deposit box at a bank!
Once I simply rented an additional locker at my athletic club (in the hallway, where they were cheaper, not in the humid locker room). Another time I stored my home backups at the office, and vice versa.
At the offsite location, you may need theft protection. Hiding is the best way, but there are many safes that are very good at this, even if they're not fireproof.
Another reason for not using a safe-deposit box is that you want the storage location to be easily accessible so you will use it often. You don't want your backups sitting on the hall table for two weeks waiting for your next trip to the bank!
As someone who was in the middle of the war, and communicated regularly with the combatants, perhaps I can relate a little history and an opinion or two.
On one side was Sun and AT&T pushing Open Look, and on the other was OSF (backed mainly by DEC, HP, IBM, and a few others). Both sides pretended that the fight was over GUI technology, but it really was pure politics. AT&T, which in those days still had some control over UNIX, had decided that a new version, to become the one and only standard, would be produced mainly by Sun.
I suppose AT&T thought that DEC, HP, and IBM would be happy with this. Somehow AT&T just didn't understand that these companies were all competitors, with four distinct and incompatible hardware lines.
So, the non-Sun companies formed OSF, and OSF then developed Motif to run on top of X.
It was all about control of UNIX. The techies (of which I was one) argued about scroll bars, pinned windows, context menus, and such, as if it mattered.
One might call the UNIX GUI wars stupid and wasteful, but aren't all wars? At the time, the people involved thought the issues were important. That's usually true, I guess.
One additional comment: UNIX has always suffered from different, annoyingly incompatible variants. By "always" I mean since about 1973, when there was the assembler version and the C version. That is, for the first 3 years or so there was only one system, but the chaos has now gone for roughly 32 years. It's not something that afflicts UNIX--it is UNIX!
Actually, I've had an account here for a while, and follow Slashdot actively. But, I thought it more appropriate to sign posts on this particular thread with my real name.
I wondered the same thing, when I found the bug while reviewing the code for the new edition. (You've just proved that my hope that nobody was paying attention was in vain.;-)) This time, I took no chances: Since what that code was doing in 1984 is now handled by a library function, the whole section has been removed.
Interestingly, this is the first comment I've gotten on the matter. I wasn't aware of it myself until about 18 months ago.
Completely agree... the SUS website is a terrific resource. I'm pleased that you're able to come up with an alternative reason to buy the book, of course!
Almost didn't see your post because somebody rated it -1, clearly way too low.
As you say in the 2nd paragraph of the article, "Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system."
My book really is about the kernel API. There's nothing there about commands, shells, compilers, or anything else at the GNU level, except how to implement them. GNU commands are often used as examples, and the reader is pointed to GNU code for research material. (And encouraged not to read it before doing the exercises!)
I suppose we probably disagree about what the term "operating system" refers to. Back when I was at Bell Labs and studying computer science, we didn't think shells and other commands were part of the OS. In fact, removing the shell, the file access methods (e.g., ISAM), and lots of other stuff from the OS was one of the key contributions of UNIX.
The book and its website also strongly support part of your last point, the part about the importance of Free Software. The part about the evils is outside the scope of the book. (All of the code from the book is Open Source under the BSD license.)
Slashdot Mirror
Let's not confuse the size and importance of an application with its implementation complexity.
This part of Google is "heavyweight" in its significance, but it uses what I would call lightweight implementation technologies.
#3 is where there's the most flexibility. Speaking very generally, there are two ways to go:
a. Lightweight scripting systems that depend only on the web server (probably with a loaded module) for support. Typically PHP, Perl, Python, or JSP/ASP using Java or a Microsoft language.
b. Heavyweight systems, of which the two most common are J2EE and .NET. J2EE uses Java as its language, and .NET usually uses C# or VB.
The usability, performance, etc., of the heavyweight systems depend as much on the middleware as the language itself. .NET is .NET, but for J2EE there are several choices. In my own experience with heavyweight systems, I found Java to be wonderful, but our J2EE server (Oracle's) very difficult to work with operationaly, and way too complicated for what we needed. So, in my opinion, one has to have much education, experience, and patience if one is to use a heavyweight system.
My conclusion, however, would be that a heavyweight system is the correct choice for a big web application. My bias is towards J2EE because it's more open (and even has open source choices available), but the complexity of J2EE servers is a big concern.
From what I hear, .NET has superior development tools and better support. I don't know whether this is (a) true and (b) worth the disadvantages of using a proprietary system.
In considering whether you need a fireproof safe, and whether such a safe would be OK for media, it's helpful to go back to first principles:
If what you are trying to protect is truly a backup, and not an archive (that is, it is a spare copy, not the only copy), then it is not necessary to protect both the original and the backup from fire (or flood, etc.). It is necessary only to ensure that the hazard doesn't affect both at the same time.
If you want to store both in the same room, or even in the same house, then indeed some sort of fireproof safe would be needed. But it you can store one offsite, then no fireproofing is needed. There's defnitely no need for a safe-deposit box at a bank!
Once I simply rented an additional locker at my athletic club (in the hallway, where they were cheaper, not in the humid locker room). Another time I stored my home backups at the office, and vice versa.
At the offsite location, you may need theft protection. Hiding is the best way, but there are many safes that are very good at this, even if they're not fireproof.
Another reason for not using a safe-deposit box is that you want the storage location to be easily accessible so you will use it often. You don't want your backups sitting on the hall table for two weeks waiting for your next trip to the bank!
On one side was Sun and AT&T pushing Open Look, and on the other was OSF (backed mainly by DEC, HP, IBM, and a few others). Both sides pretended that the fight was over GUI technology, but it really was pure politics. AT&T, which in those days still had some control over UNIX, had decided that a new version, to become the one and only standard, would be produced mainly by Sun.
I suppose AT&T thought that DEC, HP, and IBM would be happy with this. Somehow AT&T just didn't understand that these companies were all competitors, with four distinct and incompatible hardware lines.
So, the non-Sun companies formed OSF, and OSF then developed Motif to run on top of X.
It was all about control of UNIX. The techies (of which I was one) argued about scroll bars, pinned windows, context menus, and such, as if it mattered.
One might call the UNIX GUI wars stupid and wasteful, but aren't all wars? At the time, the people involved thought the issues were important. That's usually true, I guess.
One additional comment: UNIX has always suffered from different, annoyingly incompatible variants. By "always" I mean since about 1973, when there was the assembler version and the C version. That is, for the first 3 years or so there was only one system, but the chaos has now gone for roughly 32 years. It's not something that afflicts UNIX--it is UNIX!
Actually, I've had an account here for a while, and follow Slashdot actively. But, I thought it more appropriate to sign posts on this particular thread with my real name.
Interestingly, this is the first comment I've gotten on the matter. I wasn't aware of it myself until about 18 months ago.
My thinking is that, since he downloaded Jtux, he could reply to the Jtux email address, which is on the website.
If you're using Jtux in production, I love to hear more! Please email me privately.
Completely agree... the SUS website is a terrific resource. I'm pleased that you're able to come up with an alternative reason to buy the book, of course!
As you say in the 2nd paragraph of the article, "Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system."
My book really is about the kernel API. There's nothing there about commands, shells, compilers, or anything else at the GNU level, except how to implement them. GNU commands are often used as examples, and the reader is pointed to GNU code for research material. (And encouraged not to read it before doing the exercises!)
I suppose we probably disagree about what the term "operating system" refers to. Back when I was at Bell Labs and studying computer science, we didn't think shells and other commands were part of the OS. In fact, removing the shell, the file access methods (e.g., ISAM), and lots of other stuff from the OS was one of the key contributions of UNIX.
The book and its website also strongly support part of your last point, the part about the importance of Free Software. The part about the evils is outside the scope of the book. (All of the code from the book is Open Source under the BSD license.)