Linux in the news
All in one big page
See also: last week's Back page page.
LinuxStart.comappears to be another "Linux portal" attempt, run by the LinuxSupportLine.comfolks. For the moment they are offering free banner ad placement for all takers; head to their site for an automatic signup routine. (Found in LinuxToday).
A new Linux-specific search engine has popped up at 1stLinuxSearch.com.
February 18, 1999
Letters to the editor should be sent to firstname.lastname@example.org. Preference will be given to letters which are short, to the point, and well written. If you want your email address "anti-spammed" in some way please be sure to let us know. We do not have a policy against anonymous letters, but we will be reluctant to include them.
Date: 11 Feb 99 00:20:22 PST From: Ken Engel <email@example.com> To: firstname.lastname@example.org Subject: Untapped markets In response to your observation of the paucity of cheap Linux desktop offerings: I want the world to know that I, for one, would grab a sub$1000 Linux PC faster than NT boots up, if an OEM steps up to the plate. And even sooner, I would get a reasonably priced Linux PowerPC or ARM or Alpha desktop. C'mon, guys!! Ken Engel
Date: Thu, 11 Feb 1999 13:24:35 -0500 From: Eric Lee Green <email@example.com> To: firstname.lastname@example.org Subject: Why Linux VARS don't do much low end stuff Basically, economies of scale. Compaq buys motherboards in quantity 1,000 for about 2/3rds the price of what a Linux VAR would pay. Compaq buys processors in quantity 1,000 for about 80% of the price that a Linux VAR would pay. The savings they get at the low end from economies of scale go across the board -- basically, for components of equal quality to Compaq's or Dell's, today's Linux VARs will pay anywhere from 10% to 33% more for the component. On the other hand, in the server market Compaq doesn't have the advantage of scale. Thus we can sell for $20,000 a machine that Compaq sells for $35,000 because our labor costs are lower, our manufacturing costs are lower (believe me, getting Linux to run on a high-end server is a LOT easier than getting Windows NT to run on a high-end server!), and standardized "white box" components mean that we don't pay the huge R&D costs that are a pittance on a run of 100,000 desktop machines, but which add up to a hunk of change for low-volume server machines. Thus expect Linux VARs to continue scrambling for the middle and middle-upper end of the server market. Without huge infusions of venture capital to buy their way onto the shelves at Best Buy (and thus be able to churn out tens of thousands of machines and take advantage of economies of scale), they just can't compete at the low end. Not at a 10% to 33% price disadvantage on components alone. [Disclaimer: I *DEFINITELY* do not speak for Linux Hardware Solutions.] -- Eric Lee Green email@example.com http://www.linux-hw.com/~eric "Linux represents a best-of-breed UNIX, that is trusted in mission critical applications..." -- internal Microsoft memo
Date: Fri, 12 Feb 1999 23:32:37 -0600 From: Jeff Licquia <firstname.lastname@example.org> To: email@example.com Subject: Module Interface Compatibility As a sysadmin with little kernel hacking experience, I thought I should weigh in on this debate. I think Linus is right. It seems that one of the enduring fallacies of the proprietary world is some sort of "ownership" feeling about the operating system. Perhaps it is bred from the monopoly position Microsoft currently owns. Wherever it comes from, it seems that ISVs who do anything interesting to feel that they have to patch the operating system to do it. The results are such curses as the various DiskMangler programs (Disk Manager, EZDrive, etc.), which sought to solve a problem in MS-DOS's ability to access large drives by patching the OS in very scary ways. I don't need to get into the problems that caused; I'm sure anyone with lots of experience with them is shuddering right now. If they were willing to do this without source access to the OS, imagine what they'll do with source. I'd much rather encourage people to avoid patching the kernel (for that's what a module does) for their own proprietary gains. Or, better yet, release source for their patches. Or roll the proprietary stuff into a userland daemon of some kind, interfacing to the kernel with an open-source module that hooks into the userland daemon. Or something. By not guaranteeing the module interface, Linus effectively discourages this. By forcing those few vendors of proprietary modules to recompile for a new kernel interface once in a while, Linus is also forcing vendors to actually look at their code every so often and make sure it's still needed and still makes sense with the general turn of Linux.
From: "chyung g choi" <firstname.lastname@example.org> To: email@example.com Subject: [News] Using linux without installation?? Date: Fri, 05 Feb 1999 19:04:28 PST Hi there. This is Chyung Choi from South Korea. Recently I developed new distribution form of linux. I put the name "EASYLinux-kr". I found German company put the name easylinux and I put -kr in the end of name. One can use linux as CD-ROM as well as installed form on hard disk. Therefore beginner can use it quickly. One can use it as demo and rescue and education material. I am more than happy to answer any questions My homepage is "http://www.netian.com/~cgchoi" Thank you for reading. Chyung Choi ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
Date: Thu, 11 Feb 1999 21:41:25 +0100 From: Andi Kleen <firstname.lastname@example.org> To: email@example.com Subject: Re: Structure vs purism You wrote: > I've written a fair amount of code in Pascal, and I can > say from experience that I missed the goto statement when programming > in that language; at least C _has_ a goto statement, and I use it when > I think it is appropriate. It is hard to believe that you did that without noticing that Pascal has a (although inconvenient) goto statement - at least all versions of Pascal I used had and I'm pretty sure that Wirth's original definition had it too. -Andi -- This is like TV. I don't like TV.
From: David Kastrup <firstname.lastname@example.org> Date: Thu, 11 Feb 1999 13:10:41 +0100 (MET) To: email@example.com Subject: Goto followup For your information: Pascal *does* have "goto" and did from the start. Better check up the documentations you have been using. Yes, you have to declare any "goto" labels you want to be using in advance. But what of that if it's really needed? Most commonly the necessity for "goto" arises for structured leaving of scopes. C at least offers "break" and "continue" for the innermost scope, but beyond that it's "goto" or the obfuscated use of flags and stuff. Perl has very nice multi-level "break" and "continue" constructs, so hardly ever needs a "goto" when doing properly structured programming. "Goto" has got its worst reputation from Fortran's arithmetic if, a three-way goto. And of course, from other "if"s that only offered gotos as targets. In many cases, programmers would not interrupt the flow of the not-taken branch by jumping to the end of the taken branch, so the code for a true "if" tended to accumulate somewhere at the end of the program, giving the dreaded spaghetti code. If anybody should be allowed to produce spaghetti for efficiency, it is to be the compiler, not the programmer. For this reason, structured "if"s and other control structures have helped to get rid of "goto" where it was causing problems without end. It is still a good idea to avoid uncalled-for "goto"s whenever possible. It takes a skilled programmer to know precisely when a "goto" is indeed in need. For that reason, it is a good idea to tell newbies to not use it. Only after you know all the ways of avoiding it and their consequences are you in a qualified situation for judging when it is better to use it than not. David Kastrup Phone: +49-234-700-5570 Email: firstname.lastname@example.org Fax: +49-234-709-4209 Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum, Germany
Date: Thu, 11 Feb 1999 14:23:40 +0300 (EET) From: George Bronnikov <email@example.com> To: firstname.lastname@example.org Subject: Re: Structure vs purism I want to reply to your letter published in the latest issue of LWN. While I tend to agree that gotos are sometimes tolerable, the posting has a number of technical errors: 1. Pascal does have a goto statement. Read the standard (unfortunately, I don't have a copy at hand to give an exact reference). 2. Scheme has other iterating constructs besides tail recursion: read the standard (the do construct, section 4.2.4 of R5RS). It is true, however, that the constructs mentioned are not used widely; in fact, they are considered bad style in both languages. 3. The 'expressive power' of a language is not that easy to define. It is a proven fact that you can reformulate any program that uses gotos by using only 'normal' iterating constructs like ifs and loops. In fact, if the initial program was written in a style that Dijkstra et al. fought with in the late 60-ies, the result of de-goto-ifying will usually even look and read better. 3. Tail recursion is not simply 'goto with arguments': it is a highly restricted version of goto, which only allows gotos to the beginning of the function. Thus it also reduces 'expressive power'; it just happens to do that in a way that does not cut out interesting cases. By the way, Scheme happens to be my favourite language as well. George Bronnikov
Date: Thu, 11 Feb 1999 10:44:24 -0500 (EST) From: email@example.com (Chris Hanson) To: firstname.lastname@example.org Subject: Structure vs purism Date: Thu, 11 Feb 1999 14:23:40 +0300 (EET) From: George Bronnikov <email@example.com> I want to reply to your letter published in the latest issue of LWN. While I tend to agree that gotos are sometimes tolerable, the posting has a number of technical errors: 1. Pascal does have a goto statement. Read the standard (unfortunately, I don't have a copy at hand to give an exact reference). I guess the version I used back in the 80s (HP Pascal for the HP 9836) was broken; it didn't have goto. 2. Scheme has other iterating constructs besides tail recursion: read the standard (the do construct, section 4.2.4 of R5RS). Those other iterating constructs are all defined as patterns of iterative procedure calls, and in practice are implemented as macros that expand into those patterns. So I stand by this statement. (And you don't need to quote references to Scheme's standard -- I'm one of the authors.) 3. The 'expressive power' of a language is not that easy to define. It is a proven fact that you can reformulate any program that uses gotos by using only 'normal' iterating constructs like ifs and loops. In fact, if the initial program was written in a style that Dijkstra et al. fought with in the late 60-ies, the result of de-goto-ifying will usually even look and read better. Nevertheless, I still claim that not using goto eliminates some of the expressive power, at least in the case of C. The problem I usually run into is that "break" only exits the innermost construct, and there's no way to specify that you want to get out of multiple constructs. So it's necessary to either kludge around this using flags, or to use goto and say what you mean. Theoretically, I can imagine a language that doesn't have this problem, but C isn't it. There are other situations in which goto is useful, but that's the primary one. When I say "expressive power", this is the kind of thing I mean: if you can say something that _directly_ conveys your intent, the language is more expressive than one in which you must do so indirectly. Perhaps I am misusing the term. 3. Tail recursion is not simply 'goto with arguments': it is a highly restricted version of goto, which only allows gotos to the beginning of the function. Thus it also reduces 'expressive power'; it just happens to do that in a way that does not cut out interesting cases. Yes, you're right about that. My mistake.