I happen to be one of the lead investigators on the CitySense project. It's cool to be slashdotted; and funny to read the comments from people who jump to incorrect conclusions based only on reading this fairly high-level and (admittedly not very good) article. If you want to know more check out our web page: http://www.citysense.net/. One of the big problems with popular press is that it is not targeted at folks who read Slashdot and crave the technical details.
CitySense is intended to be the first (to our knowledge) wireless _sensor_ network to span an entire city. The goal is not to provide public WiFi access; as many others have noted, there are other projects afoot focusing on that. We hope to leverage existing wireless mesh routing from projects like Roofnet and CUWin rather than reinvent the wheel there.
The main focus on CitySense is to provide an open testbed to support wireless sensor research - which means that the CitySense nodes (Linux PCs using 802.11a/b/g an various sensors) will be programmable. We plan to open up CitySense allowing anyone (even the l33t h4x0rs who read Slashdot...) to upload and run custom programs on the testbed. We envision researchers using CitySense to study wireless routing and MAC protocols; to better understand how 802.11 works in a dense urban setting with a great deal of interference and existing wireless networks; to implement new distributed services and systems; and to support domain scientists gathering data from the various sensors to understand things like how weather and wind patterns affect air pollution and particulate transport in the atmosphere. If you have other ideas of what CitySense might be useful for I'd encourage you to drop me an email.
There are plenty of research challenges to address here. The major difference between CitySense and most of the public WiFi networks is that it will be programmable by external users; so reliability is of upmost concern. We'll need to develop some form of sandboxing to prevent users from hogging resources; and come up with appropriate policies for controlling access to the radios and sensors. Another major effort is developing an appropriate distributed programming model to make application development easier, to deal with failuree gracefully, and to automate software updates across the testbed. We think it's pretty cool stuff to be working on. Thanks for your comments.
I work on this area of wireless sensors (see www.tinyos.net for lots of cool stuff). These are certainly NOT "nanotechnology". In my experience, PR people like to tack on the "nano-" prefix to anything that is small. At my research group at Harvard, we did a press release on our use of wireless sensors for monitoring volcanoes, and the PR guys used the term "nanotechnology" in the same way. I pointed out to them that this was not technically correct...
Gee, that's sweet. Time to upgrade that PC I think...
Actually, I was just a small part of this. Michael K. Johnson and Lars Wirzenius did a huge amount to get this project off the ground. I am still amazed at how much Linux has taken off. You can now go to Barnes and Noble and see a whole rack full of Linux books. Who knew?
One of the reasons why information on this subject is not widespread is that the answer is really very complex. Most Web sites simply code their stuff and hope that it can deal with the traffic they get to their site --- in most cases this is not going to be a problem. But take a site like Slashdot, for example. Undoubtedly there are things about the way it is built (using Perl, some files or databases for state storage, etc.) which make it less efficient than it couuld be. What can you do?
In most cases the easiest thing to do is simply buy more hardware and replicate. This is easy to do if you're serving up static (or even dymamic) web pages that don't need to share any state across multiple web servers. This is feasible because in many situations the bottleneck of the site is the web server and dynamic page generation itself, not access to the back-end database. For really large sites, a replicated/clustered database is going to be needed, not just a single machine running MySQL.
The Application Server industry has started to provide some solutions for building scalable web sites -- for example, IBM WebSphere, BEA WebLogic, and other systems provide a platform for building web-based applications, which generally consist as a middleware layer between an HTML/presentation 'front end' (i.e., a web server) and a database 'back end'. These middleware systems support replication and clustering to increase efficiency. Replicating the front-end web servers is easy, and many products support this. You can even buy fancy network switches which load-balance HTTP requests across multiple web servers. Replicating the back-end database is much harder, but that's how companies like Oracle earn their money.
Not surprisingly nearly all heavily-loaded Web sites have to do a huge amount of work to get all of this working right. One thing you might ask is whether the process of building a scalable Web site could be made simpler. That's the goal of the research project I work on at UC Berkeley, called Ninja.
I just watched the Slashdot Beanie Awards on thesync; after wading through Rob and Jeff's endless banter and lame jokes, I finally got all of the winners:
Hemos Award: Hemos Cluestick Award for ?? Journalism: Microsoft Big Dumb Domain Name Bully: EToys Big Dumb Patents Bully: Amazon Best Slashdot Story of 1999: The Quickies Favorite Slashdot Comment Poster: AC Favorite Slashdot Author: CmdrTaco Best Dressed: Tux Best Designed Interface in Non-Graphical App: Pine Best Designed Interface in a Graphical App: Gimp Most Deserving of $2000: Debian Best Open Source Text Editor: VIM Best Apache Module: ModPerl Best Perl Module: CGI Best Open Source Book: Programming Perl Best Desktop Theme: Brushed Metal Best UNIX Ear Candy: XMMS Best UNIX Desktop Candy: Enlightenment Best Open Source Advocate: Linus Torvalds Most Deserving Open Source Charity: GNU/FSF Best Newbie Helper: Tom Christiansen Unsung Hero: Alan Cox Most Improved Kernel Module: USB Most Improved Open Source Project: GNOME Best Merger: VA and Andover.Net
What did I do for Linux newbies? Seems like more than I can remember...
Well, I:
Started the Linux Documentation Project
Started the HOWTO project
Wrote the first free book about Linux: "Linux Installation and Getting Started"
Wrote the first published general-purpose book about Linux: "Running Linux" (O'Reilly and Associates)
Developed the first Linux website - the Linux Documentation Site at sunsite.unc.edu
Maintained the Linux documentation FTP archives at sunsite
Wrote a number of HOWTOs
Maintained several sections of the original Linux FAQ
Wrote numerous magazine articles, for Linux Journal, Linux Magazine, Dr. Dobb's, etc.
Moderated both comp.os.linux.announce and comp.os.linux.answers (the FAQ/HOWTO newsgroup)
Developed the Linuxdoc-SGML tools suite (now called SGML-Tools) for writing free documentation
Answered approximately 50-75 e-mails a day from Linux users for a period of almost 3 years
Gave Linux tutorials and talks at several conferences and trade shows -- before there was such thing as a Linux conference
Organized several Linux events, including last summer's O'Reilly Linux Conference
Was a founding member of the Debian project and Linux International
Okay, so a lot of my contributions might be "ancient history", but I would only hope that they were instrumental in making Linux as popular as it is today. Helping newbies was my top priority for longer than I can remember. Maybe that deserves a vote.
First off, remember that IBM's JDK includes one of the fastest (if not the fastest) JIT compilers available for Java -- on any platform. It's really impressive.
Secondly, I wanted to point out that TowerJ is not the only "static" Java compiler for Linux. Another very good system is GCJ, a Java front-end for GCC, which is entirely open source, based on EGCS, and has pretty impressive performance!
One reason why Win98 and variants are so popular in Japan (as well as other places in Asia) is because of the very good Asian language support, both in the O/S and the applications. I have worked in both Japan and Korea and I can tell you that in terms of full-featured applications which support these languages, Linux and other UNIX systems have a long way to go.
This is fantastic, but what would be really great is if Sun could release a stable, working JDK 1.2 for Linux. Unfortunately the Blackdown port of the Sun JDK is far from production quality -- it is rife with problems, especially with respect to native threading.
This isn't to knock the Blackdown team -- they have done a terrific job. But doing such a port really is a lot of work, maybe too much for a closed porting team. If we could open up the porting process and let those of us with different systems really bang on it, I'm sure things would be progressing much more rapidly.
I just saw a great talk by Ted Schlien, a partner at Kleiner Perkins Caufield & Byers, a top VC firm which has launched such juggernauts as Sun and Excite. Note that Ted is also on the board of LinuxCare. This was at the Second Jini Community Meeting (www.jini.org) and I believe that his slides will be online in a few days. I don't have my notes with me but I will write down what I can remember:
Ted's advice was very straightforward. First, you e-mail a VC partner a 2-3 page executive summary. If you are then asked for one, you present a business plan. The shorter the business plan, the better. The first meeting will consist of about an hour -- 15-20 slides MAX! -- where you try to sell your idea. He suggested that if the VC asks about what percentage in the company you are willing to sell for VC help, you say something vague like "we'll let the market determine that".
Pitching your idea to multiple VCs is good as you can get them to compete for what percentage of your company they will own -- and of course you should be shopping around for VCs that will actually contribute value to your venture rather than add value. Ted's main point was that firms like KP put a lot of work into helping you launch the company, recruit executives, strategize, and so forth. Other VC firms only "manage portfolios" of companies and may not be there for you if you start to run into trouble.
I wouldn't worry about your idea being stolen in this way. It belongs to you. You can't get VC money unless you can put all of your cards on the table, and I believe that you retain all rights to the IP even after delivering the pitch. It sounds like you are at the perfect stage to approach VCs -- not too far along with your ideas, but not totally green either.
I took the opportunity to ask Ted what he thought of the Linux market, since he's funding LinuxCare. His comment was that Linux looks great for the server market and even better for embedded systems -- but he personally doesn't see it making a lot of impact on the desktop. It's up to us to prove him wrong, of course, but what this means is that there's a lot of good opportunity to push Linux into the server and embedded space. Note also that Ted doesn't think that selling Linux distributions is going to be as important as services based on Linux -- which is what LinuxCare is providing.
I think it's important to realize what Tim's point is here: that Linux versus Windows versus anybody else isn't the point here. It's all about building an open platform upon which to deploy the next generation of Internet applications.
In ten years, desktop operating systems will be an endangered species. We won't care about GNOME versus KDE, or even Linux versus Windows. We'll be far too busy connecting to the universal information applications with wireless appliances, handhelds, and other "pervasive" forms of computing. Everybody's going to have a different "net widget" in their hands or on their desks. We're already seeing this today -- can't everyone use the Web regardless of whether they use Linux, Windows, or an iMac?
The question is this: In such a heterogeneous computing landscape, how can we deploy services which are universally accessible?
Tim's point is a very good one: That we sure can't get there if everything's closed and proprietary. We need an open platform on which to base the next generation of networked information access. Windows ain't gonna do it. Linux (alone) ain't gonna do it, either. So it's important to chart out the space of platforms which will support the new applications. And Open Source is a fantastic way to ensure that the platform remains open itself.
For those who don't believe it, go read up on some technologies like Jini, Ninja, and e-Speak. The wave is coming.
First of all, I really appreciate all of the good reviews here on Slashdot, and I'm glad that folks find Running Linux to be useful. I wanted it to be a book that Slashdot readers would appreciate:-)
I'd just like to point out that if you do find any mistakes or incorrect information in the book, please feel free to send corrections my way: mdw@metalab.unc.edu. Usually we can correct small things in subsequent printings without waiting for the next edition to be released. In a book of this size, sometimes things slip through the cracks, but we do our best.
Also, feel free to send me any suggestions or ideas for future editions. We really depend upon readers to help us to shape the direction of the book's content, since it's often hard to tell which topics are important to cover and which are not. Now that Linux has grown so much this task is even more difficult than in previous editions.
It is true that our bias towards KDE was due to Kalle being on-board for this edition, but we did our best to talk about GNOME (albeit in an appendix). I hope that the next edition will have a bona fide section on GNOME incorporated into the book, but unfortunately we ran out of time to include it in this one.
I'm sure that the interview on NPR yesterday could have gone better, that much is true. But please bear in mind that this was done entirely unrehearsed, on the spot, and live. Unlike a magazine or newspaper article, or even a talk in front of an audience, neither Alan nor myself had a chance to carefully think through our responses to the questions -- we simply spoke off the top of our heads. As such some of our responses may have been blundered a bit, but that's the best you can do on live radio.
I regret that some people are so narrow-minded as to flame Alan and myself for getting out there and simply trying to promote Linux to the masses in the best way we know how. Would you have rather had guests who were eloquent speakers but knew nothing about the system? I doubt that you could have found two people qualified to talk about Linux who would have done much better under the circumstances.
Please, folks, have some patience. Whether you loved it or not, the point was that Linux got an hour of airtime on NPR.
In a nutshell: Ninja is dealing with several problems which Jini is not addressing. We care a great deal about security, scalability (millions of simultaneous users), fault-tolerance, and deployment of wide-area services -- Jini is more focused on the local area and "workgroup" issues. We hope that there will be a Ninja-Jini bridge so that the two can talk to each other. I will be at the Jini Community Meeting in Annapolis next month to discuss these issues with the Jini folks and get a better handle on them.
I would love to see a whitepaper on this. I have spoken a couple of times with Stephen Tweedie about his ideas, and he certainly has a lot of experience (he worked on VMS clusters for a while). However there are many smart people all over the world working on this same set of problems -- Microsoft, IBM, Oracle, Compaq, etc. all spring to mind. A large number of university research projects are working on things that most commercial vendors aren't even thinking of yet -- my own research project at Berkeley being one of them.
For those who want some background on the important issues, I highly recommend Gregory Pfister's book In Search of Clusters. Clustering is a lot harder than most people realize, and people should not ignore the work that's been done before in this area. The important question for LCC is what is fundamentally new in their design. I doubt that the lack of kernel locks is really it.
The thing that remains to be seen is what set of applications they target, and what tradeoffs they make to support those applications. The fundamental issues in clustering have been addressed by a large number of research projects and products, and I'd like to know what's new about LCC.
That being said, I'm happy that some smart people are going after this problem!
Actually, we decided to use the "Wild West" theme for the O'Reilly Linux books before the penguin had been adopted as the official Linux mascot. Back then, the only real animal representing Linux was a seagull (anyone remember that?) but the folks at O'Reilly thought the connotation wasn't what we wanted (seagulls tend to be found near large heaps of trash, for example).
I suggested the use of antique motorcycles as the Linux cover design motif (after Pirsig's "Zen and the Art of Motorcycle Maintenance") but again the possible negative connotations (i.e. Hell's Angels and the rest) outweighed that idea. My coauthor on Running Linux, Lar Kaufman, came up with the idea of the wild west -- seeing as how using Linux was a lot like the exploration of the American frontier. Never mind the negative connotations with that approach!
With the amount of e-mail I receive, it is impossible to reply to everything. Also, I placed my documents under the GPL so that people could work with them without my explicit permission. You should have run with it anyway!
I'd like to respond to many of the postings here as a group, rather than individually.
First of all, please don't send new HOWTOs or proposals directly to me; this won't help, since I am no longer the LDP maintainer. A good place to discuss this is the Open Source Writer's Group mailing list, found here. It is my understanding that the current LDP leadership is being generally unresponsive to the needs of the community. The OSWG seems to have the community's best interests in mind.
Clearly the LDP needs a maintainer who can allow new people to contribute to HOWTOs which have gone out of date. Maintenance of LDP documents should be considered a lease: if the current owner does not update or maintain the document after a certain time, somebody new should be allowed to step in. I don't think that's happening now, judging from what I've heard.
In response to the people noting that various HOWTOs are out of date: true, but you can't really complain unless you're willing to do something about it yourself. The LDP is a volunteer effort; nobody is being paid to write and maintain these documents. If you're tired of running into out-of-date HOWTOs, do whatever you can to revise the information and send it to the original author, or failing that, to the LDP maintainers. My hope is that the LDP maintainer will allow these kinds of "third-party" updates if it's clear that the current maintainer isn't doing an adequate job.
I have noticed a few people comment that the LDP is sparse and out-of-date. That may indeed be true, but consider this: the LDP was the original (and is still the only) volunteer-run documentation effort for Linux. As it turns out, it is very difficult to get volunteers to write complete documentation for a system the size of Linux and keep it up-to-date; anybody who doesn't believe me is welcome to provide me with a counterexample. (Note that the FSF documentation is very incomplete and often mismatches the version of the software which it is packaged with.)
The original LDP planned to write a small set of long manuals (such as the Linux Network Administrator's Guide or my own Linux Installation and Getting Started). What we found was that Linux moved too fast, and there was too much to cover, to keep these manuals recent. The HOWTO project was a shift towards letting people write short documents on their favorite topic of interest -- somebody might write the Net-HOWTO while somebody else wrote the Serial-Cheese-Grater-HOWTO. This was a fantastic success, judging by the number of HOWTOs and mini-HOWTOs we have now. But this doesn't solve the problem of keeping the material up-to-date.
I don't see any way to force volunteers to maintain documentation; all you can hope for is to get writers who care to maintain their docs and have some incentive to do so. Perhaps there is now a niche market for professional writers and publication companies to step in and help maintain Linux docs, but that's not the scope of the LDP. The benefits of the LDP are that it's free, vendor-neutral, and anybody can contribute. So, you get what you pay for.
I just (at 2:42pm EDT) called E*Trade's IPO line at 888-707-8680 x4263 and asked about the status of my order. I was connected to a broker who had me reconfirm my original order -- but he had no new information about the allocation of shares.
To top it off, right now I can't access my account information on E*Trade's web site -- the servers seem to be down.
My guess is that the change in the IPO price coupled with the huge interest in Red Hat shares has overwhelmed the poor servers at E*Trade and that any information we have about share allocations (or lack thereof) is incorrect and out-of-date. So I'm taking a wait-and-see approach. I just hope it didn't hurt to have the broker re-confirm my order!
Okay, folks. So we have a bit of egg on our face for this one, because nobody (to my knowledge) has really stepped forward with large-server Linux benchmarks which demonstrate anything differently. It may be that Mindcraft royally screwed up, or it might be that Linux really is slower than NT for a certain set of benchmarks -- the truth is more likely a combination of these factors.
If Linux is going to be treated as a serious operating system by the majority of the IT community, it's going to have to step up to the plate and demonstrate scalability and performance which does rival NT server in this area. Most of our knowledge about Linux-vs-NT performance is somewhat anecdotal -- we haven't really "put our money where our mouth is" and shown objectively that Linux can outperform NT in these areas.
Rather than dismissing this study as FUD, I think we could learn a few valuable lessons from this study. We should seek to understand why the benchmark results weren't as great as we would have liked. We should fix any obvious bugs or misfeatures in Samba, Apache, and the Linux kernel which stood in the way of higher performance. And we should stive to improve the entire system to make it be a true NT rival.
We have a lot going for us. First of all, we can innovate at a much more rapid pace than Microsoft -- so hopefully within just a few short months (and I'm being pessimistic!) we could demonstrate a high-performance Linux file and Web server which kicks NT's butt all over the place.
Nobody said building a high-performance, scalable Internet server operating system was easy. Let's get to it!
Slashdot Mirror
I happen to be one of the lead investigators on the CitySense project. It's cool to be slashdotted; and funny to read the comments from people who jump to incorrect conclusions based only on reading this fairly high-level and (admittedly not very good) article. If you want to know more check out our web page: http://www.citysense.net/. One of the big problems with popular press is that it is not targeted at folks who read Slashdot and crave the technical details.
CitySense is intended to be the first (to our knowledge) wireless _sensor_ network to span an entire city. The goal is not to provide public WiFi access; as many others have noted, there are other projects afoot focusing on that. We hope to leverage existing wireless mesh routing from projects like Roofnet and CUWin rather than reinvent the wheel there.
The main focus on CitySense is to provide an open testbed to support wireless sensor research - which means that the CitySense nodes (Linux PCs using 802.11a/b/g an various sensors) will be programmable. We plan to open up CitySense allowing anyone (even the l33t h4x0rs who read Slashdot...) to upload and run custom programs on the testbed. We envision researchers using CitySense to study wireless routing and MAC protocols; to better understand how 802.11 works in a dense urban setting with a great deal of interference and existing wireless networks; to implement new distributed services and systems; and to support domain scientists gathering data from the various sensors to understand things like how weather and wind patterns affect air pollution and particulate transport in the atmosphere. If you have other ideas of what CitySense might be useful for I'd encourage you to drop me an email.
There are plenty of research challenges to address here. The major difference between CitySense and most of the public WiFi networks is that it will be programmable by external users; so reliability is of upmost concern. We'll need to develop some form of sandboxing to prevent users from hogging resources; and come up with appropriate policies for controlling access to the radios and sensors. Another major effort is developing an appropriate distributed programming model to make application development easier, to deal with failuree gracefully, and to automate software updates across the testbed. We think it's pretty cool stuff to be working on. Thanks for your comments.
I work on this area of wireless sensors (see www.tinyos.net for lots of cool stuff).
These are certainly NOT "nanotechnology". In my experience, PR people like to tack on the "nano-" prefix to anything that is small.
At my research group at Harvard, we did a press release on our use of wireless sensors for monitoring volcanoes, and the PR guys
used the term "nanotechnology" in the same way. I pointed out to them that this was not technically correct...
It turns out I was the one who said that, although I'm not a student.
Gee, that's sweet. Time to upgrade that PC I think...
Actually, I was just a small part of this. Michael K. Johnson and Lars Wirzenius did a huge amount to get this project off the ground. I am still amazed at how much Linux has taken off. You can now go to Barnes and Noble and see a whole rack full of Linux books. Who knew?
In most cases the easiest thing to do is simply buy more hardware and replicate. This is easy to do if you're serving up static (or even dymamic) web pages that don't need to share any state across multiple web servers. This is feasible because in many situations the bottleneck of the site is the web server and dynamic page generation itself, not access to the back-end database. For really large sites, a replicated/clustered database is going to be needed, not just a single machine running MySQL.
The Application Server industry has started to provide some solutions for building scalable web sites -- for example, IBM WebSphere, BEA WebLogic, and other systems provide a platform for building web-based applications, which generally consist as a middleware layer between an HTML/presentation 'front end' (i.e., a web server) and a database 'back end'. These middleware systems support replication and clustering to increase efficiency. Replicating the front-end web servers is easy, and many products support this. You can even buy fancy network switches which load-balance HTTP requests across multiple web servers. Replicating the back-end database is much harder, but that's how companies like Oracle earn their money.
Not surprisingly nearly all heavily-loaded Web sites have to do a huge amount of work to get all of this working right. One thing you might ask is whether the process of building a scalable Web site could be made simpler. That's the goal of the research project I work on at UC Berkeley, called Ninja.
Matt Welsh, mdw@cs.berkeley.edu
I just watched the Slashdot Beanie Awards on thesync; after wading through Rob and Jeff's endless banter and lame jokes, I finally got all of the winners:
Hemos Award: Hemos
Cluestick Award for ?? Journalism: Microsoft
Big Dumb Domain Name Bully: EToys
Big Dumb Patents Bully: Amazon
Best Slashdot Story of 1999: The Quickies
Favorite Slashdot Comment Poster: AC
Favorite Slashdot Author: CmdrTaco
Best Dressed: Tux
Best Designed Interface in Non-Graphical App: Pine
Best Designed Interface in a Graphical App: Gimp
Most Deserving of $2000: Debian
Best Open Source Text Editor: VIM
Best Apache Module: ModPerl
Best Perl Module: CGI
Best Open Source Book: Programming Perl
Best Desktop Theme: Brushed Metal
Best UNIX Ear Candy: XMMS
Best UNIX Desktop Candy: Enlightenment
Best Open Source Advocate: Linus Torvalds
Most Deserving Open Source Charity: GNU/FSF
Best Newbie Helper: Tom Christiansen
Unsung Hero: Alan Cox
Most Improved Kernel Module: USB
Most Improved Open Source Project: GNOME
Best Merger: VA and Andover.Net
Congratulations to all of the winners!
Matt Welsh
Well, I:
Okay, so a lot of my contributions might be "ancient history", but I would only hope that they were instrumental in making Linux as popular as it is today. Helping newbies was my top priority for longer than I can remember. Maybe that deserves a vote.
Cheers,
Matt Welsh
First off, remember that IBM's JDK includes one of the fastest (if not the fastest) JIT compilers available for Java -- on any platform. It's really impressive.
Secondly, I wanted to point out that TowerJ is not the only "static" Java compiler for Linux. Another very good system is GCJ, a Java front-end for GCC, which is entirely open source, based on EGCS, and has pretty impressive performance!
Matt Welsh
One reason why Win98 and variants are so popular in Japan (as well as other places in Asia) is because of the very good Asian language support, both in the O/S and the applications. I have worked in both Japan and Korea and I can tell you that in terms of full-featured applications which support these languages, Linux and other UNIX systems have a long way to go.
Matt Welsh
This isn't to knock the Blackdown team -- they have done a terrific job. But doing such a port really is a lot of work, maybe too much for a closed porting team. If we could open up the porting process and let those of us with different systems really bang on it, I'm sure things would be progressing much more rapidly.
Matt Welsh
I just saw a great talk by Ted Schlien, a partner at Kleiner Perkins Caufield & Byers, a top VC firm which has launched such juggernauts as Sun and Excite. Note that Ted is also on the board of LinuxCare. This was at the Second Jini Community Meeting (www.jini.org) and I believe that his slides will be online in a few days. I don't have my notes with me but I will write down what I can remember:
Ted's advice was very straightforward. First, you e-mail a VC partner a 2-3 page executive summary. If you are then asked for one, you present a business plan. The shorter the business plan, the better. The first meeting will consist of about an hour -- 15-20 slides MAX! -- where you try to sell your idea. He suggested that if the VC asks about what percentage in the company you are willing to sell for VC help, you say something vague like "we'll let the market determine that".
Pitching your idea to multiple VCs is good as you can get them to compete for what percentage of your company they will own -- and of course you should be shopping around for VCs that will actually contribute value to your venture rather than add value. Ted's main point was that firms like KP put a lot of work into helping you launch the company, recruit executives, strategize, and so forth. Other VC firms only "manage portfolios" of companies and may not be there for you if you start to run into trouble.
I wouldn't worry about your idea being stolen in this way. It belongs to you. You can't get VC money unless you can put all of your cards on the table, and I believe that you retain all rights to the IP even after delivering the pitch. It sounds like you are at the perfect stage to approach VCs -- not too far along with your ideas, but not totally green either.
I took the opportunity to ask Ted what he thought of the Linux market, since he's funding LinuxCare. His comment was that Linux looks great for the server market and even better for embedded systems -- but he personally doesn't see it making a lot of impact on the desktop. It's up to us to prove him wrong, of course, but what this means is that there's a lot of good opportunity to push Linux into the server and embedded space. Note also that Ted doesn't think that selling Linux distributions is going to be as important as services based on Linux -- which is what LinuxCare is providing.
Good luck!
Matt Welsh, UC Berkeley
I think it's important to realize what Tim's point is here: that Linux versus Windows versus anybody else isn't the point here. It's all about building an open platform upon which to deploy the next generation of Internet applications.
In ten years, desktop operating systems will be an endangered species. We won't care about GNOME versus KDE, or even Linux versus Windows. We'll be far too busy connecting to the universal information applications with wireless appliances, handhelds, and other "pervasive" forms of computing. Everybody's going to have a different "net widget" in their hands or on their desks. We're already seeing this today -- can't everyone use the Web regardless of whether they use Linux, Windows, or an iMac?
The question is this: In such a heterogeneous computing landscape, how can we deploy services which are universally accessible?
Tim's point is a very good one: That we sure can't get there if everything's closed and proprietary. We need an open platform on which to base the next generation of networked information access. Windows ain't gonna do it. Linux (alone) ain't gonna do it, either. So it's important to chart out the space of platforms which will support the new applications. And Open Source is a fantastic way to ensure that the platform remains open itself.
For those who don't believe it, go read up on some technologies like Jini, Ninja, and e-Speak. The wave is coming.
Matt Welsh
First of all, I really appreciate all of the good reviews here on Slashdot, and I'm glad that folks find Running Linux to be useful. I wanted it to be a book that Slashdot readers would appreciate :-)
I'd just like to point out that if you do find any mistakes or incorrect information in the book, please feel free to send corrections my way: mdw@metalab.unc.edu. Usually we can correct small things in subsequent printings without waiting for the next edition to be released. In a book of this size, sometimes things slip through the cracks, but we do our best.
Also, feel free to send me any suggestions or ideas for future editions. We really depend upon readers to help us to shape the direction of the book's content, since it's often hard to tell which topics are important to cover and which are not. Now that Linux has grown so much this task is even more difficult than in previous editions.
It is true that our bias towards KDE was due to Kalle being on-board for this edition, but we did our best to talk about GNOME (albeit in an appendix). I hope that the next edition will have a bona fide section on GNOME incorporated into the book, but unfortunately we ran out of time to include it in this one.
Thanks everyone!
Matt Welsh
I regret that some people are so narrow-minded as to flame Alan and myself for getting out there and simply trying to promote Linux to the masses in the best way we know how. Would you have rather had guests who were eloquent speakers but knew nothing about the system? I doubt that you could have found two people qualified to talk about Linux who would have done much better under the circumstances.
Please, folks, have some patience. Whether you loved it or not, the point was that Linux got an hour of airtime on NPR.
Matt Welsh
In a nutshell: Ninja is dealing with several problems which Jini is not addressing. We care a great deal about security, scalability (millions of simultaneous users), fault-tolerance, and deployment of wide-area services -- Jini is more focused on the local area and "workgroup" issues. We hope that there will be a Ninja-Jini bridge so that the two can talk to each other. I will be at the Jini Community Meeting in Annapolis next month to discuss these issues with the Jini folks and get a better handle on them.
For those who want some background on the important issues, I highly recommend Gregory Pfister's book In Search of Clusters . Clustering is a lot harder than most people realize, and people should not ignore the work that's been done before in this area. The important question for LCC is what is fundamentally new in their design. I doubt that the lack of kernel locks is really it.
The thing that remains to be seen is what set of applications they target, and what tradeoffs they make to support those applications. The fundamental issues in clustering have been addressed by a large number of research projects and products, and I'd like to know what's new about LCC.
That being said, I'm happy that some smart people are going after this problem!
Actually, we decided to use the "Wild West" theme for the O'Reilly Linux books before the penguin had been adopted as the official Linux mascot. Back then, the only real animal representing Linux was a seagull (anyone remember that?) but the folks at O'Reilly thought the connotation wasn't what we wanted (seagulls tend to be found near large heaps of trash, for example).
I suggested the use of antique motorcycles as the Linux cover design motif (after Pirsig's "Zen and the Art of Motorcycle Maintenance") but again the possible negative connotations (i.e. Hell's Angels and the rest) outweighed that idea. My coauthor on Running Linux, Lar Kaufman, came up with the idea of the wild west -- seeing as how using Linux was a lot like the exploration of the American frontier. Never mind the negative connotations with that approach!
Matt Welsh
With the amount of e-mail I receive, it is impossible to reply to everything. Also, I placed my documents under the GPL so that people could work with them without my explicit permission. You should have run with it anyway!
First of all, please don't send new HOWTOs or proposals directly to me; this won't help, since I am no longer the LDP maintainer. A good place to discuss this is the Open Source Writer's Group mailing list, found here. It is my understanding that the current LDP leadership is being generally unresponsive to the needs of the community. The OSWG seems to have the community's best interests in mind.
Clearly the LDP needs a maintainer who can allow new people to contribute to HOWTOs which have gone out of date. Maintenance of LDP documents should be considered a lease: if the current owner does not update or maintain the document after a certain time, somebody new should be allowed to step in. I don't think that's happening now, judging from what I've heard.
In response to the people noting that various HOWTOs are out of date: true, but you can't really complain unless you're willing to do something about it yourself. The LDP is a volunteer effort; nobody is being paid to write and maintain these documents. If you're tired of running into out-of-date HOWTOs, do whatever you can to revise the information and send it to the original author, or failing that, to the LDP maintainers. My hope is that the LDP maintainer will allow these kinds of "third-party" updates if it's clear that the current maintainer isn't doing an adequate job.
Matt Welsh
The original LDP planned to write a small set of long manuals (such as the Linux Network Administrator's Guide or my own Linux Installation and Getting Started). What we found was that Linux moved too fast, and there was too much to cover, to keep these manuals recent. The HOWTO project was a shift towards letting people write short documents on their favorite topic of interest -- somebody might write the Net-HOWTO while somebody else wrote the Serial-Cheese-Grater-HOWTO. This was a fantastic success, judging by the number of HOWTOs and mini-HOWTOs we have now. But this doesn't solve the problem of keeping the material up-to-date.
I don't see any way to force volunteers to maintain documentation; all you can hope for is to get writers who care to maintain their docs and have some incentive to do so. Perhaps there is now a niche market for professional writers and publication companies to step in and help maintain Linux docs, but that's not the scope of the LDP.
The benefits of the LDP are that it's free, vendor-neutral, and anybody can contribute. So, you get what you pay for.
Matt Welsh
I just (at 2:42pm EDT) called E*Trade's IPO line at 888-707-8680 x4263 and asked about the status of my order. I was connected to a broker who had me reconfirm my original order -- but he had no new information about the allocation of shares.
To top it off, right now I can't access my account information on E*Trade's web site -- the servers seem to be down.
My guess is that the change in the IPO price coupled with the huge interest in Red Hat shares has overwhelmed the poor servers at E*Trade and that any information we have about share allocations (or lack thereof) is incorrect and out-of-date. So I'm taking a wait-and-see approach. I just hope it didn't hurt to have the broker re-confirm my order!
Okay, folks. So we have a bit of egg on our face for this one, because nobody (to my knowledge) has really stepped forward with large-server Linux benchmarks which demonstrate anything differently. It may be that Mindcraft royally screwed up, or it might be that Linux really is slower than NT for a certain set of benchmarks -- the truth is more likely a combination of these factors.
If Linux is going to be treated as a serious operating system by the majority of the IT community, it's going to have to step up to the plate and demonstrate scalability and performance which does rival NT server in this area. Most of our knowledge about Linux-vs-NT performance is somewhat anecdotal -- we haven't really "put our money where our mouth is" and shown objectively that Linux can outperform NT in these areas.
Rather than dismissing this study as FUD, I think we could learn a few valuable lessons from this study. We should seek to understand why the benchmark results weren't as great as we would have liked. We should fix any obvious bugs or misfeatures in Samba, Apache, and the Linux kernel which stood in the way of higher performance. And we should stive to improve the entire system to make it be a true NT rival.
We have a lot going for us. First of all, we can innovate at a much more rapid pace than Microsoft -- so hopefully within just a few short months (and I'm being pessimistic!) we could demonstrate a high-performance Linux file and Web server which kicks NT's butt all over the place.
Nobody said building a high-performance, scalable Internet server operating system was easy. Let's get to it!
Matt Welsh, mdw@metalab.unc.edu