Slashdot Mirror

An anonymous reader writes: "The X-box Linux Project at Sourceforge reports today that an anonymous donor will award nearly a quarter of a million dollars to the individuals responsible for the completion of a two-phased effort to run Linux on the Xbox. One can't help but wonder if this will help or hurt the community. On one hand, it is likely to generate additional interest in the project, on the other, some people may be less inclinded to share their discoveries with money on the line. Then again, getting both Money and Glory sounds pretty good."

An unnamed reader writes: "I just noticed that all sites. '*.sourceforge.net' are being blocked by all corporations using SmartFilter including mine. SmartFilter lists all of them as 'MP3' sites. Below is the error I get. How come they do not block Microsoft? I can download an MP3 player from there, too (Media Player does play MP3s)." Here's the error: "Access is restricted to the site (http://www.sourceforge.net/) you requested. Per the firm's Information Security & Privacy Policy, all Internet browsing is monitored and logged. Please contact the Information Security Center at ext 7114 for more information. SmartFilter Control List category MP3 Sites is restricted. " The aptly named SmartFilterWhere tool shows which sites are painted over by SmartFilter's broad brush; in this case, software development site (and Slashdot sister site) SourceForge is blocked by the latest SmartFilter versions -- 3.0, 3.0.1 and 3.1 -- but not version 2. You might also be interested in The Censorware Project's analysis of the efficacy of SmartFilter as applied to Utah schools and libraries, or Peacefire's explanation of how and how well SmartFilter works.

cpfeifer writes with the review below of O'Reilly's 802.11 Wireless Networks: The Definitive Guide; he warns that this is not a book for everyone setting up a casual home wireless network, but says it's excellent for its intended audience. Read on for his complete review. 802.11 Wireless Networks : The Definitive Guide author Matthew S. Gast pages 443 publisher O�Reilly & Associates rating 9/10 reviewer cpfeifer ISBN 0-596-00183-5 summary A thorough survey of the features, issues and potential solutions of deploying 802.11 based wireless networks.

The Scenario

For a lot of folks, implementing an 802.11 network involves selecting and purchasing an access point and adapter cards, and installing or compiling the proper drivers. From there, we are off and running, usually in under an hour. However for the few, the proud, the sysadmins of the world it's a whole different ballgame. Sysadmins need a deeper understanding of network technologies to be able effectively design, deploy and debug them.

What's Bad?

Most of the book is right on the mark when it comes to the sysadmin audience, however chapters 8 (the PCF, for contention free service), 10 (the ISM PHYs) and 11 (802.11a overview) are only of interest to folks who are implementing 802.11 hardware, IMHO. These chapters contain very low-level material about the 802.11 transmission protocol, and will not be generally useful since equipment manufacturers do not provide access to this layer. A dead giveaway that you can skip over chapter 8 is the phrase "The PCF has not been widely implemented." If it's not widely implemented, chances are you won't have the option of using it in a deployment.

After this bellycrawl through the weeds, chapters 12 and 14 give click-by-click instructions for installing two commercially available 802.11 access point/client adapter pairs on your Windows box. The selected products are Nokia's A032 Access Point along with their C110/C111 and Lucent's Orinoco (formerly WaveLan) Access Point and client adapter. It's worth noting that these are two of the most expensive 802.11 solutions available on the market and have enhanced features that are not present in other models. These chapters are simply rehashed vendor installation documentation for these products and provide very little added value. There's nothing that I hate more than paying $30-$50 for a book which repackages documentation that is freely available on the web. Skip these chapters; the rest of the book is excellent.

What's Good?

This book starts off with six strong chapters that cover the 802.11 protocol specification, why WEP is vulnerable, and some upcoming security specifications. The first six chapters are invaluable reading for any sysadmin that is planning (or already responsible) for an 802.11 deployment. This is your ammunition when users come and ask why the wireless network is slower than the wired network with fewer users (preventing contention adds more overhead in wireless) or why they really really should tunnel every wireless connection over SSH (because WEP is fundamentally flawed). The chapter that covers the current WEP implementation demystifies the "40 bit" vs. "64 bit" key-length sleight of hand that some vendors play. The standard WEP key length is 64 bits. However, 24 of those bits are used as WEP's initialization vector for the RC4 cipher. These bits aren't encrypted in an 802.11 packet, so by sniffing 802.11 traffic you can examine the IVs of the packets and see how many distinct keys are in use, and even retrieve the actual key once you have captured enough packets. AirSnort retrieves WEP keys by implementing the Fluhrer/Martin/Shamir attack (orig paper, Stubblefield paper). Chapter 16 covers using tools such as Airsnort and Ethereal to analyze the 802.11 traffic on your network. Remember to use your powers for good and not evil.

The final 3 chapters address deployment, analysis and tuning of 802.11 networks. These chapters, combined with the first six are the heart of this book and the whole motivation for buying the book. The analysis chapter has a particularly wonderful section about gathering user requirements with respect to 802.11 specific issues (security requirements, roaming ...) and a very practical section about physical installation that clearly illustrates the author's mastery of integrating 802.11 technologies into an existing infrastructure.

So What's In It For Me?

If you're an sysadmin and implementing 802.11 technologies is on the horizon, this book is a solid reference of the current state of 802.11 solutions, both good and bad. It pulls no punches in presenting issues and weaknesses with the current solutions and documents forthcoming standards that are being proposed or developed to address them. If you're considering a smaller deployment at home, the security aspects of the text are still applicable, but the design/deployment sections are more rigorous than you will need. There is a bit of starch (repackaged vendor installation documentation) and unnecessary details (knowing that 802.11 frequency hopping uses Gaussian frequency shift keying is good for impressing women at parties, but doesn't really impact the design/deployment of an 802.11 network) but the other chapters redeem themselves and make this a very valuable text.

Table of Contents

1. Preface
2. Introduction to Wireless Networks
3. Overview of 802.11 Networks
4. The 802.11 MAC
5. 802.11 Framing in Detail
6. Wired Equivalent Privacy (WEP)
7. Security, Take 2: 802.1x
8. Management Operations
9. Contention-Free Service with the PCF
10. Physical Layer Overview
11. The ISM PHYs: FH, DS, and HR/DS
12. 802.11a: 5-GHz OFDM PHY
13. Using 802.11 on Windows
14. Using 802.11 on Linux
15. Using 802.11 Access Points
16. 802.11 Network Deployment
17. 802.11 Network Analysis
18. 802.11 Performance Tuning
19. The Future, at Least for 802.11
20. 802.11 MIB
21. 802.11 on the Macintosh
22. Glossary
23. Index

You can purchase 802.11 Wireless Networks : The Definitive Guide from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then visit the submission page.

cpfeifer writes with the review below of O'Reilly's 802.11 Wireless Networks: The Definitive Guide; he warns that this is not a book for everyone setting up a casual home wireless network, but says it's excellent for its intended audience. Read on for his complete review. 802.11 Wireless Networks : The Definitive Guide author Matthew S. Gast pages 443 publisher O�Reilly & Associates rating 9/10 reviewer cpfeifer ISBN 0-596-00183-5 summary A thorough survey of the features, issues and potential solutions of deploying 802.11 based wireless networks.

The Scenario

For a lot of folks, implementing an 802.11 network involves selecting and purchasing an access point and adapter cards, and installing or compiling the proper drivers. From there, we are off and running, usually in under an hour. However for the few, the proud, the sysadmins of the world it's a whole different ballgame. Sysadmins need a deeper understanding of network technologies to be able effectively design, deploy and debug them.

What's Bad?

Most of the book is right on the mark when it comes to the sysadmin audience, however chapters 8 (the PCF, for contention free service), 10 (the ISM PHYs) and 11 (802.11a overview) are only of interest to folks who are implementing 802.11 hardware, IMHO. These chapters contain very low-level material about the 802.11 transmission protocol, and will not be generally useful since equipment manufacturers do not provide access to this layer. A dead giveaway that you can skip over chapter 8 is the phrase "The PCF has not been widely implemented." If it's not widely implemented, chances are you won't have the option of using it in a deployment.

After this bellycrawl through the weeds, chapters 12 and 14 give click-by-click instructions for installing two commercially available 802.11 access point/client adapter pairs on your Windows box. The selected products are Nokia's A032 Access Point along with their C110/C111 and Lucent's Orinoco (formerly WaveLan) Access Point and client adapter. It's worth noting that these are two of the most expensive 802.11 solutions available on the market and have enhanced features that are not present in other models. These chapters are simply rehashed vendor installation documentation for these products and provide very little added value. There's nothing that I hate more than paying $30-$50 for a book which repackages documentation that is freely available on the web. Skip these chapters; the rest of the book is excellent.

What's Good?

This book starts off with six strong chapters that cover the 802.11 protocol specification, why WEP is vulnerable, and some upcoming security specifications. The first six chapters are invaluable reading for any sysadmin that is planning (or already responsible) for an 802.11 deployment. This is your ammunition when users come and ask why the wireless network is slower than the wired network with fewer users (preventing contention adds more overhead in wireless) or why they really really should tunnel every wireless connection over SSH (because WEP is fundamentally flawed). The chapter that covers the current WEP implementation demystifies the "40 bit" vs. "64 bit" key-length sleight of hand that some vendors play. The standard WEP key length is 64 bits. However, 24 of those bits are used as WEP's initialization vector for the RC4 cipher. These bits aren't encrypted in an 802.11 packet, so by sniffing 802.11 traffic you can examine the IVs of the packets and see how many distinct keys are in use, and even retrieve the actual key once you have captured enough packets. AirSnort retrieves WEP keys by implementing the Fluhrer/Martin/Shamir attack (orig paper, Stubblefield paper). Chapter 16 covers using tools such as Airsnort and Ethereal to analyze the 802.11 traffic on your network. Remember to use your powers for good and not evil.

The final 3 chapters address deployment, analysis and tuning of 802.11 networks. These chapters, combined with the first six are the heart of this book and the whole motivation for buying the book. The analysis chapter has a particularly wonderful section about gathering user requirements with respect to 802.11 specific issues (security requirements, roaming ...) and a very practical section about physical installation that clearly illustrates the author's mastery of integrating 802.11 technologies into an existing infrastructure.

So What's In It For Me?

If you're an sysadmin and implementing 802.11 technologies is on the horizon, this book is a solid reference of the current state of 802.11 solutions, both good and bad. It pulls no punches in presenting issues and weaknesses with the current solutions and documents forthcoming standards that are being proposed or developed to address them. If you're considering a smaller deployment at home, the security aspects of the text are still applicable, but the design/deployment sections are more rigorous than you will need. There is a bit of starch (repackaged vendor installation documentation) and unnecessary details (knowing that 802.11 frequency hopping uses Gaussian frequency shift keying is good for impressing women at parties, but doesn't really impact the design/deployment of an 802.11 network) but the other chapters redeem themselves and make this a very valuable text.

Table of Contents

1. Preface
2. Introduction to Wireless Networks
3. Overview of 802.11 Networks
4. The 802.11 MAC
5. 802.11 Framing in Detail
6. Wired Equivalent Privacy (WEP)
7. Security, Take 2: 802.1x
8. Management Operations
9. Contention-Free Service with the PCF
10. Physical Layer Overview
11. The ISM PHYs: FH, DS, and HR/DS
12. 802.11a: 5-GHz OFDM PHY
13. Using 802.11 on Windows
14. Using 802.11 on Linux
15. Using 802.11 Access Points
16. 802.11 Network Deployment
17. 802.11 Network Analysis
18. 802.11 Performance Tuning
19. The Future, at Least for 802.11
20. 802.11 MIB
21. 802.11 on the Macintosh
22. Glossary
23. Index

You can purchase 802.11 Wireless Networks : The Definitive Guide from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then visit the submission page.

Dasein asks: "I am working as a Tech Support Developer, and I had a wonderful idea a few months ago. After stumbling upon Trinux, I modified it so that I could run Linux on any PC with a floppy. By doing this, I was able to backup on our network valuable data on users' computers when their OS failed. This summer I wanted to develop a similar idea but this time with a CD. I was having trouble finding Linux/BSD distributions that could run solely off a CD, and I'm a bit scared to start one from scratch because I wouldn't know where to begin. Does anyone have any suggestions?" nik suggests: On the BSD front, there's the LiveCD project, which seems to do exactly what you want.

Dasein asks: "I am working as a Tech Support Developer, and I had a wonderful idea a few months ago. After stumbling upon Trinux, I modified it so that I could run Linux on any PC with a floppy. By doing this, I was able to backup on our network valuable data on users' computers when their OS failed. This summer I wanted to develop a similar idea but this time with a CD. I was having trouble finding Linux/BSD distributions that could run solely off a CD, and I'm a bit scared to start one from scratch because I wouldn't know where to begin. Does anyone have any suggestions?" nik suggests: On the BSD front, there's the LiveCD project, which seems to do exactly what you want.

millisa asks: "I've been looking into options for inexpensive web based load balancing services for both Apache and IIS based web servers. There are plenty of commercial products out there that claim to do the job, but they are often too pricey, offer too many features, or are unreliable. I have lost the small amount of confidence I had in the MS based NLB services and do not like the idea of running multiple services on the same system anyways. I would like to build one (or more) simple front end load balancing Linux (or BSD) servers to direct traffic to the back-end systems if possible. I have seen mention of implementations based off of the Linux Router Project or the global load balancing oriented Eddie. What approaches are other geeks out there using for their LAN load balancing needs? I am especially interested in implementations that can maintain state (ie, handle sessions) as well as do some form of request inspection (so as to redirect those pesky web spiders to their own playground so a live user has the best web experience)." It's been long enough since the last time this came up, so lets revisit this question and touch upon the new solutions that have come up since 1999.

Anonymous Coward writes: "Seems LucasArts finally noticed ScummVm although they seem to be confused about what it is. ScummVM is a 'virtual machine'(yes like Java) that allows you to play scumm games (Monkey Island, for example) in modern OS (Linux, BSD, err Windows XP) and weird machines like PDAs and the Dreamcast, but Lucas have confused them with an abandonware site."

Jonathan Corbet at LWN has posted a terrific summary of the first Day of the Ottawa Kernel Summit, and you should expect the second day soon. In it he relates the greatest hits of the first day's talks, including the AMD Hammer Port, Block I/O, Modules, and more. For mp3s or oggs of this event, check out the Kernel Summit MP3 Repository on SourceForge. The big news is the desire to feature freeze 2.5 within 4 or 5 months. Halloween. I've posted a very small gallery of the group pictures from the summit on my site.

Jeremy Andrews writes "KernelTrap has spoken with Marc-Christian Petersen, who originated the WOLK project in March of 2002. WOLK is the Working Overloaded Linux Kernel, a large set of nearly 450 useful patches applied against the current stable 2.4 Linux kernel tree. The project has recently expanded to offer a second 'secure' patchset, this one against the older stable 2.2 tree. In this interview, Marc-Christian Petersen tells the history behind WOLK and discusses many of the patches included."

Pivot writes: "With the release of Xine v0.9.11a, it is now possible to play back Quicktime movies encoded with the Sorenson SVQ1 encoding natively. There are still some minor issues with sound, and still no support for SVQ3 encoding, but overall this is a major achievement. Downloads are at xine.sf.net. I wonder what apple will do about this." Note: you may have to cut and paste that "movies" link into a new tab or browser.

Dave Hansen, the IBM programmer who organized this interview (questions were posted on May 28), says, "Perhaps I didn't make this clear enough during the call for questions, but myself and my group are kernel programmers. But, we were able to dredge up some responses for answers that we couldn't do ourselves. We haven't been able to get an answer to the ViaVoice question yet, but if there is real interest, I'll make sure that we do get some kind of answer back to Slashdot. IBM Kernel Hackers:

A note: we answered these questions individually, but in the interests of Slashdot's disk space, we decided to coalesce the answers into a single, unified one. You might say we "became one voice". (the IBMers in the audience will get that one) These were edited by management, but they mostly corrected our spelling mistakes and cleaned up our dirty language :)

Remember, if you're interested in Linux on large systems or if you have more questions, be sure to check out the LSE site, find us on LKML, or look for us at OLS (we're giving lots of talks).

1) Multi-CPU Scalability
by morbid

Now that Linux has been ported to run on high-end machines under virtualization, when will we see a kernel tuned for (e.g.) scalability to 64-128 processors natively?

IBM Kernel Hackers:

Assuming you're talking about single systems running one instance of Linux, we are focusing on 8 way scalability this year, 16-32 scalability next year. After that, we'll do whatever the hardware people can produce ... there aren't many 64-128 processor systems around.

The open source community is tackling the complexities in getting multi-cpu systems to scale well, and with that understanding also comes a realization that sometimes entire subsystems are bottlenecks. Major rewrites of some of these are underway in 2.5 (not just by IBM people mind you). The scheduler is being wrestled to the ground, the I/O subsystem is being dissected, and virtual memory implementations are creating rhetoric worthy of the Cold War. All of these efforts have had contributions from IBM people in Beaverton and other parts of the Linux Technology Center.

2) OS Blending
by 2names

As Linux developers inside IBM, do you get to see the AIX source code? If you do, are you allowed to "steal" some ideas from AIX and implement them in Linux? If not, why not, and what's the IBM official line?

IBM Kernel Hackers:

First of all, before any of us were allowed to contribute to Linux, we were required to take an "Open Source Developers" class. This class gives us the guidelines we need to participate effectively in the open source community - both IBM guidelines and lessons learned about open source from others in IBM.

We are definitely not allowed to cut and paste proprietary code into any open source projects (or vice versa!). There is an IBM committee who can and do approve the release of IBM proprietary or patented technology, like RCU.

That covers "stealing" code, but what about ideas? We might talk to an AIX programmer and comment we're seeing performance issues in Linux in this area or that area and she tells us they discovered that they really needed to profile the network routines when they saw that. Having solved the problem once, our non-Linux peers can help steer us without spelling it out for us, allowing us to still develop solutions that can then be open sourced.

It's a fine line to walk, especially as an engineer who just wants the answer :)

3) The Open Source model
by larry bagina

IBM will be using linux to help sell their hardware. Other companies have tried this (VA Linux, which owns Slashdot, once had linux hackers on their payroll). Obviously, IBM's hardware is in a different league as an x86 clone, but do you have any thoughts on Open Source business models and their validity? Once the kernel is running smoothly, will you be disposable since the "Open Source community" can continue development for free?

IBM Kernel Hackers:

We think the Open Source business model is more than just valid, it is revolutionary. Linux has become a real "killer app"; the ability to run Linux on IBM hardware is increasingly high on customer's lists. Being able to run it doesn't really hurt AIX or VM, but not being able to run it would cost hardware sales.

As far as our disposability: don't get too concerned on our behalf, Linux will always have bugs and there will always be room for improvement.

4) Getting your changes accepted?
by korpiq

Is Linus accepting your changes well? How directly do you submit patches, and what are your experiences on the overall Linux kernel development style?

IBM Kernel Hackers:

Linus himself is wonderful about accepting patches on technical merit alone. He doesn't "grade" them differently if they come from ibm.com or mit.edu. We submit patches the exact same way that everyone else does: append the patch, mail to Linus and CC linux-kernel. If it's good, it gets in. If it sucks, you get flamed.

However, the submission process can be more complicated than first appears. Often, you need to figure out who is maintaining a particular area of code, followed by talking to them to gauge if someone else is already working on the same thing. Once you submit your code to them and the appropriate list, (isn't always lkml..) you may not get a response. This can be discouraging, but you have to find out why, or just simply resubmit, over and over and over. But, once you have a reputation, it does get easier to get quicker responses.

Sometimes it's frustrating when you've put a lot of effort into something that doesn't get accepted, but there's normally a good reason for it. Even work that doesn't get accepted can influence other people's thinking and development in the future. On the flip side you can also just point out problems and other people fix them for you, so in general you win more than you lose ;-)

5)linux on thinkpads
by Olinator

IMHO, IBM makes some of the best mobile hardware out there -- one of the professors I support raves about his ThinkPad 600, that went with him into the Israeli desert for several months and is still running strong, no service required -- but the linux support for that hardware has been, um, erratic at best. Yes, we've been occasionally been able to purchase the odd model with linux preinstalled (usually it's more expensive than the comparable model with MicroSoft preinstalled, grr) but an awful lot of the hardware (mini-pci modems, etc...) is rather difficult to drive with a penguin behind the wheel. Why does IBM's linux enthusiasm fade so quickly at the small (physical) end of the hardware scale? Is there momentum underway to change this?

IBM Kernel Hackers:

All of the people in our group and most in the LTC have Thinkpads for their daily development and run Linux on them (I'm writing this on one as I sit in my apartment). There may not be as much corporate support there as you want, but there is plenty of grass-roots support. We had to learn all the quirks to get Linux installed and get all of the little things working (just like you). I've always wished that we shared more of this information, but there are usually people who are farther ahead than we are. I've uploaded the meager information that we put together during a meeting once. If you're curious, take a look: http://www.sr71.net/slashdot/thinkpad/linux-desktop

People don't buy many small computers just because they will run Linux (the geek population just isn't that large). People do, however, blow large chunks of cash on big machines just to run Linux. Mom-and-Pop can almost always undercut IBM on prices for small machines, and geeks are thrifty. You don't have to sell many million dollar machines to justify being involved in Linux development.

6) Issues with middle management
by Consul

When you were starting out as a group, did you encounter a lot of friction and resistance from middle and/or upper management about your wanting to work on Open Source projects for IBM? If so, what did you do to overcome the objections and become the team you are now? I think the answer to this would help a lot of other people in other companies get mainstream acceptance of the idea of OSS in corporate environments.

IBM Kernel Hackers:

The management chain from engineer up to VP has been surprisingly a non-issue. We believe this is mostly because of the way the Linux Technology Center was founded. You might think the LTC evolved "up" from renegade engineers, but the truth is that our first Linux corporate strategy in 1998 called for the creation of a team, composed of some our best OS engineers, that would join the community to

1. Learn from doing,
2. Grow Linux skills
3. Give back to the community
4. Help make Linux better.

The LTC was founded then with full corporate backing already in place. Boring!! The early funding story for the LTC did involve renegade behavior and a table outside the BOFs at LinuxWorld in 1999, but that's a different story. Our director, Dan Frye, is owed much of the praise for the LTC's existence and smooth operation within IBM. The critical thing here is that engineers shouldn't be fighting corporate political battles, you need management that will go to bat for you on those issues (and win ;-)) We have that, and they do a good job of keeping that stuff off our backs. On the whole, our only work in this arena is to inform the management of what we need, and to feed them with the ammunition they need from a technical standpoint to fight these battles for us.

7) When do you estimate Linux can surpass Solaris?
by wytcld

Solaris 9 is getting great reviews. Between the strengths of the traditional open source community and IBM's resources, do you see a point in the next several years where you expect Linux to surpass Solaris in all of its core strengths? Or does Solaris have some unique values which will allow Sun to continue to position itself to advantage, at least for some applications? Please answer this as a technical rather than marketing question.

IBM Kernel Hackers:

We don't have a Solaris machines to back up any claim we may make, nor do we want to stir up another epic Linux on mainframe battle. It is safe to say, however, that today Linux/x86 is able to outperform¹ Solaris/Sparc in many areas that Sun has a long history of success. If your core business was threatened, wouldn't you make some serious changes?

¹ I know, I know, outperform is a very vague term. Just think price, performance, stability, etc...

8) OS/2 Developers
by reaper20

I'm one of the few people who really enjoyed the OS/2 desktop and its features. Have any of the former OS/2 developers been contributing to Linux?

Specifically, the user interface and accessibility people - OS/2 was very polished - does IBM see a benefit by offering this expertise to the GNOME/KDE projects?

If so, how does this tie into IBM's vision of Linux of the desktop, if you have one? :)

IBM Kernel Hackers:

Yes, there are a number of former OS/2 developers in the LTC including the majority of the teams working on: JFS, EVMS, and Print, as well individuals contributing in the areas of networking, security, RAS, performance and other projects. Remember, OS/2 had JFS support and EVMS supports the OS/2 partitioning scheme.

While IBM is not actively contributing code from the OS/2 user interface, we are supporting and sponsoring both the GNOME and the KDE projects through our involvement in the KDE League and the GNOME Foundation. And as you mentioned, we place a high level of importance on accessibility and so are participating in the community efforts in that area as well.

10) IA64
by sabre ...

Do you think that IPF64 line will see any kind of broad industry adoption? Will it become just like rest of the (non-embedded) processor architectures designed since the x86 -- constantly fighting for 5% of the market? Do you think the AMD Hammer architecture will be a meaningful player in the field?

IBM Kernel Hackers:

Quite possibly, never underestimate the importance of being able to run the huge installed base of ia32 apps natively, and at high speed. But IA64 has lots of industry backing as well. The good news is that Linux runs well on both, so we the community don't have to choose. The market will do that for us.

Additional questions and answers:

What features do you find linux most lacking in? (If we don't examine our weaknesses, we will be crippled)

Linux on the desktop still doesn't really cut it for some of us (though we do use it). Applications are not nearly as robust as they should be, and though we are perfectly capable of configuring X, we'd rather spend the time coding. Though it's fun to throw stones at Windows and the Linux OS is more stable than the Windows OS, as a whole desktop package with the apps, installation, usability and everything rolled together, Linux is not always preferable.

There are thorns in our side daily because of the lack of debugging and profiling ability in the kernel. We're always patching kernels for kernprof or lockmeter and porting them around to new kernel versions. Although Linus has pretty much said that debuggers are for sissies, the built-in facilities are much better than they were during the old days (think readprofile). So, there are advances being made.

...I'm not surprised that your responses have to be vetted by management. But, I'd love to know what guidelines IBM has for hackers' interaction with the rest of the GNU/Linux/Internet community. Are you allowed to criticize IBM management, or other IBM products, for example?

This is the Internet. We are hackers. Our management has been great allowing us to resolve many of our own problems involving certain email systems and desktop OS rules. Working in the kernel group of the LTC we have free reign to do our work on the kernel in the Open Source community.

There's no day-to-day vetting of anything we post or say, they trust us to be sensible. We would not say "IBM product X sucks, and you should buy competitor's product Y instead" in a public forum, but if we don't think something works well, I'm not going to endorse it either. We're engineers who get paid to work on Linux by IBM, not IBM corporate drones ;-)

From the brief bios, and Sequent pedigree, it looks like there is a lot of focus on high-end features like NUMA, async I/O and the like. Other commercial organizations, notably SGI, are also putting forth effort in those areas. There is actually quite a bit of overlap.

Since these are "open source" projects, do you collaborate with your traditional "enemies" such as SGI and Sun on Linux? What is your management's attitude toward that type of collaboration? If not, do you "look" at the work \ the others are doing in comparison to what you are doing?

We have been working smoothly with engineers from HP, Intel, SGI and many other companies through the Linux Scalability Effort Open Source Project. Whatever legal issues there might be within each company, it appears to me that the engineers who are working on open source are allowed to do their work with no problems. Hanna runs the bi-weekly LSE Conference Call and can say the biggest percentage of attendees are from either IBM, SGI or Intel every time. This is nice, but we want more members from the Open Source community to join: (http://lse.sf.net/mtg).

Management doesn't really care too much who actually writes the patch at the end of the day, they want to see Linux work well in their focus areas. Persuading other (external) developers of the correct approach or solution to a problem is just as important a part of our jobs as writing code.

Why isn't IBM making more of an effort to recruit developers directly from the Linux community, as opposed to hiring people who have very little if any working familiarity with the platform?

IBM has hired lots of existing Linux developers such as Rusty Russell, Greg Kroah-Hartman, and Ted Ts'o. There are also others that post to LKML and don't even use their IBM email addresses because they were firmly established community members (with those email addresses) before they were hired. We do have a site where you can view many of our patches, or a list of developers. Keep in mind that there are still developers who don't submit patches here.

What are your opinions regarding the shrinking number of women in the industry? (actually I believe the numbers are rising again in schools)

This is a tough field and many young women are discouraged from sticking it out through all of the math and science classes, as are many young men. Companies, like IBM, help by hiring bright women who move up the technical chain. This shows the less experienced that there is a future for women in engineering.

Shrinking? The numbers seem to be increasing based on what we see at work every day. IBM is active in programs that introduce young women to engineering in an attempt to get them interested in pursing careers in engineering. An example of these programs is Camp EXITE, check this site out for more info: http://www.ibm.com/ibm/ibmgives/grant/education/camp.shtml

An interesting interview regarding the number of women in industry is available at: http://www.nspe.org/etweb/16-02viewpoint.asp

Questions Rick Lindsley liked that didn't make the top 10, plus answers:

Best way into the Professional Linux world?

As many people here, I am a huge Linux fan, but I am so much so that I am trying to figure out how to get into the professional Linux world when I graduate.

I attend Clemson University and am in the Computer Information System (CS + business) program (and doubled in Political Science). My goal is to become a Linux sys admin, or perhaps some other Linux guru type job. The work that IBM is doing with Linux is also very appealing to me.

So, how did you get your job, and what would you recommend as the path to follow for us geeks just getting started in the professional world as to how to get into Linux? How can I become as entrenched with Linux as the professionals at IBM? I have had two internships (not with IBM, nor with Linux, but with other CS stuff), but how can I get an entry-level job in a Linux intensive environment like IBM? How can said job lead me into a career where I can be deeply involved in the Linux world?

Rick:

First: I've done recruiting at a "significant Big 10 university whose mascot's name is Bucky" so let me tell you what I look for in a college candidate.

Knowledgable -- your resume should reflect what you know, but don't puff it. Just because they make me dress up when I'm on campus doesn't mean I can't tell perl from shell scripting. Accentuate your strong points. You gain points for knowledge, but you lose them for lying or "overstating."

Communicative -- a person who cannot talk about what they know might as well know nothing. Seriously consider taking a public speaking course your junior or senior year. Also: it's ok to say "I don't know."

Grade point -- Personally, I really don't care so much about your GPA as you might think. Unfortunately, you will be judged by it by far too many people, right or wrong. So if you're not 3.9 or 4.0, you might be ready to spin it a bit. "Yes, it's 3.2, but I've buckled down and have 3.84 in the last three semesters." "Yes it's 3.1, but you'll note it's 3.6 on courses in my major." Don't get surreal but make that number say something good about you.

Work experience -- you get a big edge for doing something other than a teaching assistant. Internships, co-ops, and summer jobs can help you more than you think in the end.

Second, how did I get my job at IBM? Luck, in part. Right place, right time. Sometimes it really does work for you. Along with that luck, though, was the fact that I'd established a reputation as a smart coder and a fast learner. While I knew far less about Linux then than I know now, that reputation made managers believe that "coming up to speed" would not be a problem, and they judged right. Your reputation, as reported by your colleagues and not yourself, will be your greatest ally (or enemy.) This is never more true than in the Linux community.

Third, advancing? Once you get your foot in the door, work at interacting. Nobody really advances very far without interaction. At first this is with your cubie neighbor or office mate, but pretty soon it's chatting with people down the hall, and then in other projects. Eventually, you have opportunities to help organize informal seminars with the local user's group, and then it's helping out with conferences, and then you're writing papers, and chairing sessions, and before you know it you're standing puzzled in front of a thousand people, wondering how troubled their life must be that they would want to listen to <em>you</em> speak.

Dave Hansen's answer -

Purdue University's Computer Science program. I went to one of the CS job fairs where someone in the large IBM booth saw "Linux" on my resume. I handed my resume off, had a nice chat, and got a sit-down interview a couple of days later. That was followed soon by a plant trip and a job offer. The moral of the story: if you want a Linux job, put Linux on your resume! Make it bold. Make it half the page if that is really want you want to do. Most importantly, you have to learn to walk the walk before you can talk the talk. Engineers usually have better BS detectors than most people and you won't fool them for long.

Advancing - This is probably evident to anyone who has gone through an engineering program at a large school, but the most successful engineers are those who can teach others. You'll notice that there are lots of brilliant engineers and lots of teachers, but those who can do both are a rarity. Learn as much as you can from your colleagues then share as much as you can. The more people who know your name and come to you for help, the more visible you are. There is probably a fine line between getting noticed and being annoying and I have the feeling that a Slashdot interview may be WAY beyond the line :)

Dave Hansen, the IBM programmer who organized this interview (questions were posted on May 28), says, "Perhaps I didn't make this clear enough during the call for questions, but myself and my group are kernel programmers. But, we were able to dredge up some responses for answers that we couldn't do ourselves. We haven't been able to get an answer to the ViaVoice question yet, but if there is real interest, I'll make sure that we do get some kind of answer back to Slashdot. IBM Kernel Hackers:

A note: we answered these questions individually, but in the interests of Slashdot's disk space, we decided to coalesce the answers into a single, unified one. You might say we "became one voice". (the IBMers in the audience will get that one) These were edited by management, but they mostly corrected our spelling mistakes and cleaned up our dirty language :)

Remember, if you're interested in Linux on large systems or if you have more questions, be sure to check out the LSE site, find us on LKML, or look for us at OLS (we're giving lots of talks).

1) Multi-CPU Scalability
by morbid

Now that Linux has been ported to run on high-end machines under virtualization, when will we see a kernel tuned for (e.g.) scalability to 64-128 processors natively?

IBM Kernel Hackers:

Assuming you're talking about single systems running one instance of Linux, we are focusing on 8 way scalability this year, 16-32 scalability next year. After that, we'll do whatever the hardware people can produce ... there aren't many 64-128 processor systems around.

The open source community is tackling the complexities in getting multi-cpu systems to scale well, and with that understanding also comes a realization that sometimes entire subsystems are bottlenecks. Major rewrites of some of these are underway in 2.5 (not just by IBM people mind you). The scheduler is being wrestled to the ground, the I/O subsystem is being dissected, and virtual memory implementations are creating rhetoric worthy of the Cold War. All of these efforts have had contributions from IBM people in Beaverton and other parts of the Linux Technology Center.

2) OS Blending
by 2names

As Linux developers inside IBM, do you get to see the AIX source code? If you do, are you allowed to "steal" some ideas from AIX and implement them in Linux? If not, why not, and what's the IBM official line?

IBM Kernel Hackers:

First of all, before any of us were allowed to contribute to Linux, we were required to take an "Open Source Developers" class. This class gives us the guidelines we need to participate effectively in the open source community - both IBM guidelines and lessons learned about open source from others in IBM.

We are definitely not allowed to cut and paste proprietary code into any open source projects (or vice versa!). There is an IBM committee who can and do approve the release of IBM proprietary or patented technology, like RCU.

That covers "stealing" code, but what about ideas? We might talk to an AIX programmer and comment we're seeing performance issues in Linux in this area or that area and she tells us they discovered that they really needed to profile the network routines when they saw that. Having solved the problem once, our non-Linux peers can help steer us without spelling it out for us, allowing us to still develop solutions that can then be open sourced.

It's a fine line to walk, especially as an engineer who just wants the answer :)

3) The Open Source model
by larry bagina

IBM will be using linux to help sell their hardware. Other companies have tried this (VA Linux, which owns Slashdot, once had linux hackers on their payroll). Obviously, IBM's hardware is in a different league as an x86 clone, but do you have any thoughts on Open Source business models and their validity? Once the kernel is running smoothly, will you be disposable since the "Open Source community" can continue development for free?

IBM Kernel Hackers:

We think the Open Source business model is more than just valid, it is revolutionary. Linux has become a real "killer app"; the ability to run Linux on IBM hardware is increasingly high on customer's lists. Being able to run it doesn't really hurt AIX or VM, but not being able to run it would cost hardware sales.

As far as our disposability: don't get too concerned on our behalf, Linux will always have bugs and there will always be room for improvement.

4) Getting your changes accepted?
by korpiq

Is Linus accepting your changes well? How directly do you submit patches, and what are your experiences on the overall Linux kernel development style?

IBM Kernel Hackers:

Linus himself is wonderful about accepting patches on technical merit alone. He doesn't "grade" them differently if they come from ibm.com or mit.edu. We submit patches the exact same way that everyone else does: append the patch, mail to Linus and CC linux-kernel. If it's good, it gets in. If it sucks, you get flamed.

However, the submission process can be more complicated than first appears. Often, you need to figure out who is maintaining a particular area of code, followed by talking to them to gauge if someone else is already working on the same thing. Once you submit your code to them and the appropriate list, (isn't always lkml..) you may not get a response. This can be discouraging, but you have to find out why, or just simply resubmit, over and over and over. But, once you have a reputation, it does get easier to get quicker responses.

Sometimes it's frustrating when you've put a lot of effort into something that doesn't get accepted, but there's normally a good reason for it. Even work that doesn't get accepted can influence other people's thinking and development in the future. On the flip side you can also just point out problems and other people fix them for you, so in general you win more than you lose ;-)

5)linux on thinkpads
by Olinator

IMHO, IBM makes some of the best mobile hardware out there -- one of the professors I support raves about his ThinkPad 600, that went with him into the Israeli desert for several months and is still running strong, no service required -- but the linux support for that hardware has been, um, erratic at best. Yes, we've been occasionally been able to purchase the odd model with linux preinstalled (usually it's more expensive than the comparable model with MicroSoft preinstalled, grr) but an awful lot of the hardware (mini-pci modems, etc...) is rather difficult to drive with a penguin behind the wheel. Why does IBM's linux enthusiasm fade so quickly at the small (physical) end of the hardware scale? Is there momentum underway to change this?

IBM Kernel Hackers:

All of the people in our group and most in the LTC have Thinkpads for their daily development and run Linux on them (I'm writing this on one as I sit in my apartment). There may not be as much corporate support there as you want, but there is plenty of grass-roots support. We had to learn all the quirks to get Linux installed and get all of the little things working (just like you). I've always wished that we shared more of this information, but there are usually people who are farther ahead than we are. I've uploaded the meager information that we put together during a meeting once. If you're curious, take a look: http://www.sr71.net/slashdot/thinkpad/linux-desktop

People don't buy many small computers just because they will run Linux (the geek population just isn't that large). People do, however, blow large chunks of cash on big machines just to run Linux. Mom-and-Pop can almost always undercut IBM on prices for small machines, and geeks are thrifty. You don't have to sell many million dollar machines to justify being involved in Linux development.

6) Issues with middle management
by Consul

When you were starting out as a group, did you encounter a lot of friction and resistance from middle and/or upper management about your wanting to work on Open Source projects for IBM? If so, what did you do to overcome the objections and become the team you are now? I think the answer to this would help a lot of other people in other companies get mainstream acceptance of the idea of OSS in corporate environments.

IBM Kernel Hackers:

The management chain from engineer up to VP has been surprisingly a non-issue. We believe this is mostly because of the way the Linux Technology Center was founded. You might think the LTC evolved "up" from renegade engineers, but the truth is that our first Linux corporate strategy in 1998 called for the creation of a team, composed of some our best OS engineers, that would join the community to

1. Learn from doing,
2. Grow Linux skills
3. Give back to the community
4. Help make Linux better.

The LTC was founded then with full corporate backing already in place. Boring!! The early funding story for the LTC did involve renegade behavior and a table outside the BOFs at LinuxWorld in 1999, but that's a different story. Our director, Dan Frye, is owed much of the praise for the LTC's existence and smooth operation within IBM. The critical thing here is that engineers shouldn't be fighting corporate political battles, you need management that will go to bat for you on those issues (and win ;-)) We have that, and they do a good job of keeping that stuff off our backs. On the whole, our only work in this arena is to inform the management of what we need, and to feed them with the ammunition they need from a technical standpoint to fight these battles for us.

7) When do you estimate Linux can surpass Solaris?
by wytcld

Solaris 9 is getting great reviews. Between the strengths of the traditional open source community and IBM's resources, do you see a point in the next several years where you expect Linux to surpass Solaris in all of its core strengths? Or does Solaris have some unique values which will allow Sun to continue to position itself to advantage, at least for some applications? Please answer this as a technical rather than marketing question.

IBM Kernel Hackers:

We don't have a Solaris machines to back up any claim we may make, nor do we want to stir up another epic Linux on mainframe battle. It is safe to say, however, that today Linux/x86 is able to outperform¹ Solaris/Sparc in many areas that Sun has a long history of success. If your core business was threatened, wouldn't you make some serious changes?

¹ I know, I know, outperform is a very vague term. Just think price, performance, stability, etc...

8) OS/2 Developers
by reaper20

I'm one of the few people who really enjoyed the OS/2 desktop and its features. Have any of the former OS/2 developers been contributing to Linux?

Specifically, the user interface and accessibility people - OS/2 was very polished - does IBM see a benefit by offering this expertise to the GNOME/KDE projects?

If so, how does this tie into IBM's vision of Linux of the desktop, if you have one? :)

IBM Kernel Hackers:

Yes, there are a number of former OS/2 developers in the LTC including the majority of the teams working on: JFS, EVMS, and Print, as well individuals contributing in the areas of networking, security, RAS, performance and other projects. Remember, OS/2 had JFS support and EVMS supports the OS/2 partitioning scheme.

While IBM is not actively contributing code from the OS/2 user interface, we are supporting and sponsoring both the GNOME and the KDE projects through our involvement in the KDE League and the GNOME Foundation. And as you mentioned, we place a high level of importance on accessibility and so are participating in the community efforts in that area as well.

10) IA64
by sabre ...

Do you think that IPF64 line will see any kind of broad industry adoption? Will it become just like rest of the (non-embedded) processor architectures designed since the x86 -- constantly fighting for 5% of the market? Do you think the AMD Hammer architecture will be a meaningful player in the field?

IBM Kernel Hackers:

Quite possibly, never underestimate the importance of being able to run the huge installed base of ia32 apps natively, and at high speed. But IA64 has lots of industry backing as well. The good news is that Linux runs well on both, so we the community don't have to choose. The market will do that for us.

Additional questions and answers:

What features do you find linux most lacking in? (If we don't examine our weaknesses, we will be crippled)

Linux on the desktop still doesn't really cut it for some of us (though we do use it). Applications are not nearly as robust as they should be, and though we are perfectly capable of configuring X, we'd rather spend the time coding. Though it's fun to throw stones at Windows and the Linux OS is more stable than the Windows OS, as a whole desktop package with the apps, installation, usability and everything rolled together, Linux is not always preferable.

There are thorns in our side daily because of the lack of debugging and profiling ability in the kernel. We're always patching kernels for kernprof or lockmeter and porting them around to new kernel versions. Although Linus has pretty much said that debuggers are for sissies, the built-in facilities are much better than they were during the old days (think readprofile). So, there are advances being made.

...I'm not surprised that your responses have to be vetted by management. But, I'd love to know what guidelines IBM has for hackers' interaction with the rest of the GNU/Linux/Internet community. Are you allowed to criticize IBM management, or other IBM products, for example?

This is the Internet. We are hackers. Our management has been great allowing us to resolve many of our own problems involving certain email systems and desktop OS rules. Working in the kernel group of the LTC we have free reign to do our work on the kernel in the Open Source community.

There's no day-to-day vetting of anything we post or say, they trust us to be sensible. We would not say "IBM product X sucks, and you should buy competitor's product Y instead" in a public forum, but if we don't think something works well, I'm not going to endorse it either. We're engineers who get paid to work on Linux by IBM, not IBM corporate drones ;-)

From the brief bios, and Sequent pedigree, it looks like there is a lot of focus on high-end features like NUMA, async I/O and the like. Other commercial organizations, notably SGI, are also putting forth effort in those areas. There is actually quite a bit of overlap.

Since these are "open source" projects, do you collaborate with your traditional "enemies" such as SGI and Sun on Linux? What is your management's attitude toward that type of collaboration? If not, do you "look" at the work \ the others are doing in comparison to what you are doing?

We have been working smoothly with engineers from HP, Intel, SGI and many other companies through the Linux Scalability Effort Open Source Project. Whatever legal issues there might be within each company, it appears to me that the engineers who are working on open source are allowed to do their work with no problems. Hanna runs the bi-weekly LSE Conference Call and can say the biggest percentage of attendees are from either IBM, SGI or Intel every time. This is nice, but we want more members from the Open Source community to join: (http://lse.sf.net/mtg).

Management doesn't really care too much who actually writes the patch at the end of the day, they want to see Linux work well in their focus areas. Persuading other (external) developers of the correct approach or solution to a problem is just as important a part of our jobs as writing code.

Why isn't IBM making more of an effort to recruit developers directly from the Linux community, as opposed to hiring people who have very little if any working familiarity with the platform?

IBM has hired lots of existing Linux developers such as Rusty Russell, Greg Kroah-Hartman, and Ted Ts'o. There are also others that post to LKML and don't even use their IBM email addresses because they were firmly established community members (with those email addresses) before they were hired. We do have a site where you can view many of our patches, or a list of developers. Keep in mind that there are still developers who don't submit patches here.

What are your opinions regarding the shrinking number of women in the industry? (actually I believe the numbers are rising again in schools)

This is a tough field and many young women are discouraged from sticking it out through all of the math and science classes, as are many young men. Companies, like IBM, help by hiring bright women who move up the technical chain. This shows the less experienced that there is a future for women in engineering.

Shrinking? The numbers seem to be increasing based on what we see at work every day. IBM is active in programs that introduce young women to engineering in an attempt to get them interested in pursing careers in engineering. An example of these programs is Camp EXITE, check this site out for more info: http://www.ibm.com/ibm/ibmgives/grant/education/camp.shtml

An interesting interview regarding the number of women in industry is available at: http://www.nspe.org/etweb/16-02viewpoint.asp

Questions Rick Lindsley liked that didn't make the top 10, plus answers:

Best way into the Professional Linux world?

As many people here, I am a huge Linux fan, but I am so much so that I am trying to figure out how to get into the professional Linux world when I graduate.

I attend Clemson University and am in the Computer Information System (CS + business) program (and doubled in Political Science). My goal is to become a Linux sys admin, or perhaps some other Linux guru type job. The work that IBM is doing with Linux is also very appealing to me.

So, how did you get your job, and what would you recommend as the path to follow for us geeks just getting started in the professional world as to how to get into Linux? How can I become as entrenched with Linux as the professionals at IBM? I have had two internships (not with IBM, nor with Linux, but with other CS stuff), but how can I get an entry-level job in a Linux intensive environment like IBM? How can said job lead me into a career where I can be deeply involved in the Linux world?

Rick:

First: I've done recruiting at a "significant Big 10 university whose mascot's name is Bucky" so let me tell you what I look for in a college candidate.

Knowledgable -- your resume should reflect what you know, but don't puff it. Just because they make me dress up when I'm on campus doesn't mean I can't tell perl from shell scripting. Accentuate your strong points. You gain points for knowledge, but you lose them for lying or "overstating."

Communicative -- a person who cannot talk about what they know might as well know nothing. Seriously consider taking a public speaking course your junior or senior year. Also: it's ok to say "I don't know."

Grade point -- Personally, I really don't care so much about your GPA as you might think. Unfortunately, you will be judged by it by far too many people, right or wrong. So if you're not 3.9 or 4.0, you might be ready to spin it a bit. "Yes, it's 3.2, but I've buckled down and have 3.84 in the last three semesters." "Yes it's 3.1, but you'll note it's 3.6 on courses in my major." Don't get surreal but make that number say something good about you.

Work experience -- you get a big edge for doing something other than a teaching assistant. Internships, co-ops, and summer jobs can help you more than you think in the end.

Second, how did I get my job at IBM? Luck, in part. Right place, right time. Sometimes it really does work for you. Along with that luck, though, was the fact that I'd established a reputation as a smart coder and a fast learner. While I knew far less about Linux then than I know now, that reputation made managers believe that "coming up to speed" would not be a problem, and they judged right. Your reputation, as reported by your colleagues and not yourself, will be your greatest ally (or enemy.) This is never more true than in the Linux community.

Third, advancing? Once you get your foot in the door, work at interacting. Nobody really advances very far without interaction. At first this is with your cubie neighbor or office mate, but pretty soon it's chatting with people down the hall, and then in other projects. Eventually, you have opportunities to help organize informal seminars with the local user's group, and then it's helping out with conferences, and then you're writing papers, and chairing sessions, and before you know it you're standing puzzled in front of a thousand people, wondering how troubled their life must be that they would want to listen to <em>you</em> speak.

Dave Hansen's answer -

Purdue University's Computer Science program. I went to one of the CS job fairs where someone in the large IBM booth saw "Linux" on my resume. I handed my resume off, had a nice chat, and got a sit-down interview a couple of days later. That was followed soon by a plant trip and a job offer. The moral of the story: if you want a Linux job, put Linux on your resume! Make it bold. Make it half the page if that is really want you want to do. Most importantly, you have to learn to walk the walk before you can talk the talk. Engineers usually have better BS detectors than most people and you won't fool them for long.

Advancing - This is probably evident to anyone who has gone through an engineering program at a large school, but the most successful engineers are those who can teach others. You'll notice that there are lots of brilliant engineers and lots of teachers, but those who can do both are a rarity. Learn as much as you can from your colleagues then share as much as you can. The more people who know your name and come to you for help, the more visible you are. There is probably a fine line between getting noticed and being annoying and I have the feeling that a Slashdot interview may be WAY beyond the line :)

Anonymous Coward writes "Ryan du Bois, from genbukan security (aka red0x), has created a chassis intrusion detection system for your computer box: the actual physical case. He also wrote a paper describing three separate implementations of this CIDS system: Contacts, Pressure switchs, and a PLA (programmable microchip). Included in his paper are complete designs for the first two and a promise for the last to come soon. Definitely worth a read. The paper is available in many formats including OpenOffice 1.0, HTML , TEXT and a Tarball of them all. You can also obtain the signatures as well as his Automated Security Tools Project, of which this is a member."

Anonymous Coward writes "Ryan du Bois, from genbukan security (aka red0x), has created a chassis intrusion detection system for your computer box: the actual physical case. He also wrote a paper describing three separate implementations of this CIDS system: Contacts, Pressure switchs, and a PLA (programmable microchip). Included in his paper are complete designs for the first two and a promise for the last to come soon. Definitely worth a read. The paper is available in many formats including OpenOffice 1.0, HTML , TEXT and a Tarball of them all. You can also obtain the signatures as well as his Automated Security Tools Project, of which this is a member."

Anonymous Coward writes "Ryan du Bois, from genbukan security (aka red0x), has created a chassis intrusion detection system for your computer box: the actual physical case. He also wrote a paper describing three separate implementations of this CIDS system: Contacts, Pressure switchs, and a PLA (programmable microchip). Included in his paper are complete designs for the first two and a promise for the last to come soon. Definitely worth a read. The paper is available in many formats including OpenOffice 1.0, HTML , TEXT and a Tarball of them all. You can also obtain the signatures as well as his Automated Security Tools Project, of which this is a member."

Anonymous Coward writes "Ryan du Bois, from genbukan security (aka red0x), has created a chassis intrusion detection system for your computer box: the actual physical case. He also wrote a paper describing three separate implementations of this CIDS system: Contacts, Pressure switchs, and a PLA (programmable microchip). Included in his paper are complete designs for the first two and a promise for the last to come soon. Definitely worth a read. The paper is available in many formats including OpenOffice 1.0, HTML , TEXT and a Tarball of them all. You can also obtain the signatures as well as his Automated Security Tools Project, of which this is a member."

Anonymous Coward writes "Ryan du Bois, from genbukan security (aka red0x), has created a chassis intrusion detection system for your computer box: the actual physical case. He also wrote a paper describing three separate implementations of this CIDS system: Contacts, Pressure switchs, and a PLA (programmable microchip). Included in his paper are complete designs for the first two and a promise for the last to come soon. Definitely worth a read. The paper is available in many formats including OpenOffice 1.0, HTML , TEXT and a Tarball of them all. You can also obtain the signatures as well as his Automated Security Tools Project, of which this is a member."

Anonymous Coward writes "Ryan du Bois, from genbukan security (aka red0x), has created a chassis intrusion detection system for your computer box: the actual physical case. He also wrote a paper describing three separate implementations of this CIDS system: Contacts, Pressure switchs, and a PLA (programmable microchip). Included in his paper are complete designs for the first two and a promise for the last to come soon. Definitely worth a read. The paper is available in many formats including OpenOffice 1.0, HTML , TEXT and a Tarball of them all. You can also obtain the signatures as well as his Automated Security Tools Project, of which this is a member."

Peter Wayner writes: "In a world where Ali had to meet Frazier and Luke had to meet his father, it was only a matter of time before buzzwords like Java and eXtreme Programming found themselves together on the same marquee. A pair of new books examines some open source Java development tools and outlines how they can be put to use by those trying to master their workload by adopting the techniques of eXtreme programming." Read on for his latest review, which is really two reviews in one. (see each) author (see each) pages (see each) publisher (see each) rating (see each) reviewer Peter Wayner ISBN (see each) summary Two books which explore the use of Ant in Java software development

The two books are excellent examples of how the book industry organizes and disciplines the often crazy explosion of new tools, approaches, structures and metaphors developed by the software industry. Ant: The Definitive Guide by Jesse Tilly and Eric Burke comes from O'Reilly, the masters of producing missing manuals for open source projects. The other, Java Tools for eXtreme Programming: Mastering Open Source Tools including Ant, JUnit, and Cactus by Richard Hightower and Nicholas Lesiecki was published by John Wiley and Sons. Both provide a clear, example-driven exploration of the tools at hand.

The books are probably driven by the success of Kent Beck's Extreme Programming Explained: Embrace Change , a manifesto that outlined Beck's belief that the best way to develop code was with small teams of programmers and users who constantly reworked the software. His most controversial and attention grabbing notion demanded that the programmers work in pairs sharing one computer, one mouse and one keyboard. The constant interaction forced everyone to actually communicate with each other without sending emails and that, more than anything else, may be responsible for the success of his vision. His book spawned a few others on how programmers can plan to apply his vision.

Meanwhile, on the other side of the buzzword galaxy, the Apache group was quietly creating some of the coolest Java development and deployment tools around. Ant was and still is one of the most revolutionary, even though it was just a simple reworking of the classic UNIX make command. Its creator, James Davidson, grew so frustrated with the shell interface of the make command that he wrote a Java-centric version that moved all of the compilation, compression, and distribution inside one Java process. Now, no one has to wait for another Java Virtual Machine to start up to compile each class file independently.

While Davidson's Ant isn't much different than make at first glance, it's hard to overestimate the power of giving programmers a clever tool with plenty of hooks into the development process. Anyone can write new tasks for Ant, and some clever folks have built great new widgets that do things like enforce style guidelines or grab new code from a CVS tree. The structure of Ant lets the programmer dig deeply into the build process. The organic growth and dynamic flexibility shows how close Java can be to Lisp.

Tilly and Burke do a good job capturing the spirit of the tool. Their book follows O'Reilly's time-tested and market-proven simple-examples technique to illustrate how to use Ant for your projects. The chapters in the first half of the book outline how to use and extend Ant for your project. The strength of the book may be the way the authors casually include practical advice about the bugs and idiosyncracies of the tool. While Ant is quite capable, there are a number of little limitations to the XML parser that can drive new users a bit nuts. The second half of the book is a detailed description of the API, the data types and the other practical documentation.

In one sense, it's not really fair to lump this book in with all of this gloss about Extreme Programming. because it's just another methodical O'Reilly book with Dover artwork on the cover. It's important to realize that these tools aren't directly tied to the extreme programming movement. Ant was just created by a Java programmer who hated to wait. Everything else came afterwards when he opened the API.

Ant: The Definitive Guide author Jesse Tilly & Eric M. Burke pages 260 publisher O'Reilly rating 7 ISBN 0-597-00184-3 summary A methodical, in-depth look at the Java tool.

The other book, however, explicitly illustrates how some popular open source tools can help the process of extreme programming. Hightower and Lesiecki's book is much broader than Tilly and Burke's because they want to tackle so much more. They don't want to just provide a missing manual for the tool-- they want to give the world a road map on how they use Ant and its cousins JUnit, HTTPUnit, and Cactus to build better applications. It should be noted that Hightower and Lesiecki work for a consulting group called eBlox and a number of other eBlox programmers are listed as contributors to the book. I think it's fair to say that anyone who hires eBlox will get eXtreme Programming results built with this methodology.

The best part about this book is the wide scope. Ant remains the central taskmaster responsible for building the software, but the book explains how to incorporate other tools for testing the software. The authors embrace one of the extreme programming central beliefs that programmers should define how to test their code before it is actually written. The book explains how to use JUnit, Cactus, and HTTPUnit to set up rules to test every class file. After ANT fires up the compiler, it turns around and runs the tests on the code.

Java Tools for eXtreme Programming author Richard Hightower and Nicholas Lesiecki pages 513 publisher John Wiley and Sons rating 7 ISBN 0-471-20708-X summary How to use some Java tools to transform extreme programming theory into reality.

I don't think that eXtreme Programming or any of these tools is the last word on the subject. The biggest problem is that testing a piece of code is guaranteed to be fairly rudimentary. No programmer can come up with test cases to push all of buttons in all possible combinations. The structure and discipline provided by this approach can help, but the book makes it clear that no amount of pairs programming or extremism will remove the need for the guidance of good programmers.

If anything these tools and the books about them should serve as inspiration for the next round of tools even more focused on extreme programming. The tools are impressive, but there is plenty of room for more innovation. None of them is aimed at explicitly coordinating the work of multiple developers and none of them is designed to provide much structure to the refactoring process. These areas are still very much arts, but there's no reason why tool suites like Ant can't evolve some rational approach to solving them. Perhaps the Slashdot audience can provide some informative postings with pointers to the next generation of cool tools.

Hightower and Lesiecki's book feels a bit more rudimentary and basic than Tilly and Burke's, in part because they cover so much more ground. Although their book is broader, it doesn't go into as much depth about Ant as Tilly and Burke's. The examples are simpler, too, and Hightower and Liesiecki seem mainly interested in getting you excited about building and testing software with the tools. There just isn't as much room for details. If you're interested in learning as much as you can about Ant, choose the book devoted to it. If you want to learn how to use a diverse set of tools to build and test your program in an extreme way, go for that book.

Peter Wayner blends the buzzwords of security, privacy, and data warehousing together in his latest book, Translucent Databases. It shows how to ensure that only the right people see the right information and the wrong people get nothing. His other new book, Disappearing Cryptography, mixes the buzzwords of being, nothingness, steganography, and cryptography. You can purchase both Ant: The Definitive Guide and Java Tools for eXtreme Programming from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then hit the submission page.

Peter Wayner writes: "In a world where Ali had to meet Frazier and Luke had to meet his father, it was only a matter of time before buzzwords like Java and eXtreme Programming found themselves together on the same marquee. A pair of new books examines some open source Java development tools and outlines how they can be put to use by those trying to master their workload by adopting the techniques of eXtreme programming." Read on for his latest review, which is really two reviews in one. (see each) author (see each) pages (see each) publisher (see each) rating (see each) reviewer Peter Wayner ISBN (see each) summary Two books which explore the use of Ant in Java software development

The two books are excellent examples of how the book industry organizes and disciplines the often crazy explosion of new tools, approaches, structures and metaphors developed by the software industry. Ant: The Definitive Guide by Jesse Tilly and Eric Burke comes from O'Reilly, the masters of producing missing manuals for open source projects. The other, Java Tools for eXtreme Programming: Mastering Open Source Tools including Ant, JUnit, and Cactus by Richard Hightower and Nicholas Lesiecki was published by John Wiley and Sons. Both provide a clear, example-driven exploration of the tools at hand.

The books are probably driven by the success of Kent Beck's Extreme Programming Explained: Embrace Change , a manifesto that outlined Beck's belief that the best way to develop code was with small teams of programmers and users who constantly reworked the software. His most controversial and attention grabbing notion demanded that the programmers work in pairs sharing one computer, one mouse and one keyboard. The constant interaction forced everyone to actually communicate with each other without sending emails and that, more than anything else, may be responsible for the success of his vision. His book spawned a few others on how programmers can plan to apply his vision.

Meanwhile, on the other side of the buzzword galaxy, the Apache group was quietly creating some of the coolest Java development and deployment tools around. Ant was and still is one of the most revolutionary, even though it was just a simple reworking of the classic UNIX make command. Its creator, James Davidson, grew so frustrated with the shell interface of the make command that he wrote a Java-centric version that moved all of the compilation, compression, and distribution inside one Java process. Now, no one has to wait for another Java Virtual Machine to start up to compile each class file independently.

While Davidson's Ant isn't much different than make at first glance, it's hard to overestimate the power of giving programmers a clever tool with plenty of hooks into the development process. Anyone can write new tasks for Ant, and some clever folks have built great new widgets that do things like enforce style guidelines or grab new code from a CVS tree. The structure of Ant lets the programmer dig deeply into the build process. The organic growth and dynamic flexibility shows how close Java can be to Lisp.

Tilly and Burke do a good job capturing the spirit of the tool. Their book follows O'Reilly's time-tested and market-proven simple-examples technique to illustrate how to use Ant for your projects. The chapters in the first half of the book outline how to use and extend Ant for your project. The strength of the book may be the way the authors casually include practical advice about the bugs and idiosyncracies of the tool. While Ant is quite capable, there are a number of little limitations to the XML parser that can drive new users a bit nuts. The second half of the book is a detailed description of the API, the data types and the other practical documentation.

In one sense, it's not really fair to lump this book in with all of this gloss about Extreme Programming. because it's just another methodical O'Reilly book with Dover artwork on the cover. It's important to realize that these tools aren't directly tied to the extreme programming movement. Ant was just created by a Java programmer who hated to wait. Everything else came afterwards when he opened the API.

Ant: The Definitive Guide author Jesse Tilly & Eric M. Burke pages 260 publisher O'Reilly rating 7 ISBN 0-597-00184-3 summary A methodical, in-depth look at the Java tool.

The other book, however, explicitly illustrates how some popular open source tools can help the process of extreme programming. Hightower and Lesiecki's book is much broader than Tilly and Burke's because they want to tackle so much more. They don't want to just provide a missing manual for the tool-- they want to give the world a road map on how they use Ant and its cousins JUnit, HTTPUnit, and Cactus to build better applications. It should be noted that Hightower and Lesiecki work for a consulting group called eBlox and a number of other eBlox programmers are listed as contributors to the book. I think it's fair to say that anyone who hires eBlox will get eXtreme Programming results built with this methodology.

The best part about this book is the wide scope. Ant remains the central taskmaster responsible for building the software, but the book explains how to incorporate other tools for testing the software. The authors embrace one of the extreme programming central beliefs that programmers should define how to test their code before it is actually written. The book explains how to use JUnit, Cactus, and HTTPUnit to set up rules to test every class file. After ANT fires up the compiler, it turns around and runs the tests on the code.

Java Tools for eXtreme Programming author Richard Hightower and Nicholas Lesiecki pages 513 publisher John Wiley and Sons rating 7 ISBN 0-471-20708-X summary How to use some Java tools to transform extreme programming theory into reality.

I don't think that eXtreme Programming or any of these tools is the last word on the subject. The biggest problem is that testing a piece of code is guaranteed to be fairly rudimentary. No programmer can come up with test cases to push all of buttons in all possible combinations. The structure and discipline provided by this approach can help, but the book makes it clear that no amount of pairs programming or extremism will remove the need for the guidance of good programmers.

If anything these tools and the books about them should serve as inspiration for the next round of tools even more focused on extreme programming. The tools are impressive, but there is plenty of room for more innovation. None of them is aimed at explicitly coordinating the work of multiple developers and none of them is designed to provide much structure to the refactoring process. These areas are still very much arts, but there's no reason why tool suites like Ant can't evolve some rational approach to solving them. Perhaps the Slashdot audience can provide some informative postings with pointers to the next generation of cool tools.

Hightower and Lesiecki's book feels a bit more rudimentary and basic than Tilly and Burke's, in part because they cover so much more ground. Although their book is broader, it doesn't go into as much depth about Ant as Tilly and Burke's. The examples are simpler, too, and Hightower and Liesiecki seem mainly interested in getting you excited about building and testing software with the tools. There just isn't as much room for details. If you're interested in learning as much as you can about Ant, choose the book devoted to it. If you want to learn how to use a diverse set of tools to build and test your program in an extreme way, go for that book.

Peter Wayner blends the buzzwords of security, privacy, and data warehousing together in his latest book, Translucent Databases. It shows how to ensure that only the right people see the right information and the wrong people get nothing. His other new book, Disappearing Cryptography, mixes the buzzwords of being, nothingness, steganography, and cryptography. You can purchase both Ant: The Definitive Guide and Java Tools for eXtreme Programming from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then hit the submission page.

Peter Wayner writes: "In a world where Ali had to meet Frazier and Luke had to meet his father, it was only a matter of time before buzzwords like Java and eXtreme Programming found themselves together on the same marquee. A pair of new books examines some open source Java development tools and outlines how they can be put to use by those trying to master their workload by adopting the techniques of eXtreme programming." Read on for his latest review, which is really two reviews in one. (see each) author (see each) pages (see each) publisher (see each) rating (see each) reviewer Peter Wayner ISBN (see each) summary Two books which explore the use of Ant in Java software development

The two books are excellent examples of how the book industry organizes and disciplines the often crazy explosion of new tools, approaches, structures and metaphors developed by the software industry. Ant: The Definitive Guide by Jesse Tilly and Eric Burke comes from O'Reilly, the masters of producing missing manuals for open source projects. The other, Java Tools for eXtreme Programming: Mastering Open Source Tools including Ant, JUnit, and Cactus by Richard Hightower and Nicholas Lesiecki was published by John Wiley and Sons. Both provide a clear, example-driven exploration of the tools at hand.

The books are probably driven by the success of Kent Beck's Extreme Programming Explained: Embrace Change , a manifesto that outlined Beck's belief that the best way to develop code was with small teams of programmers and users who constantly reworked the software. His most controversial and attention grabbing notion demanded that the programmers work in pairs sharing one computer, one mouse and one keyboard. The constant interaction forced everyone to actually communicate with each other without sending emails and that, more than anything else, may be responsible for the success of his vision. His book spawned a few others on how programmers can plan to apply his vision.

Meanwhile, on the other side of the buzzword galaxy, the Apache group was quietly creating some of the coolest Java development and deployment tools around. Ant was and still is one of the most revolutionary, even though it was just a simple reworking of the classic UNIX make command. Its creator, James Davidson, grew so frustrated with the shell interface of the make command that he wrote a Java-centric version that moved all of the compilation, compression, and distribution inside one Java process. Now, no one has to wait for another Java Virtual Machine to start up to compile each class file independently.

While Davidson's Ant isn't much different than make at first glance, it's hard to overestimate the power of giving programmers a clever tool with plenty of hooks into the development process. Anyone can write new tasks for Ant, and some clever folks have built great new widgets that do things like enforce style guidelines or grab new code from a CVS tree. The structure of Ant lets the programmer dig deeply into the build process. The organic growth and dynamic flexibility shows how close Java can be to Lisp.

Tilly and Burke do a good job capturing the spirit of the tool. Their book follows O'Reilly's time-tested and market-proven simple-examples technique to illustrate how to use Ant for your projects. The chapters in the first half of the book outline how to use and extend Ant for your project. The strength of the book may be the way the authors casually include practical advice about the bugs and idiosyncracies of the tool. While Ant is quite capable, there are a number of little limitations to the XML parser that can drive new users a bit nuts. The second half of the book is a detailed description of the API, the data types and the other practical documentation.

In one sense, it's not really fair to lump this book in with all of this gloss about Extreme Programming. because it's just another methodical O'Reilly book with Dover artwork on the cover. It's important to realize that these tools aren't directly tied to the extreme programming movement. Ant was just created by a Java programmer who hated to wait. Everything else came afterwards when he opened the API.

Ant: The Definitive Guide author Jesse Tilly & Eric M. Burke pages 260 publisher O'Reilly rating 7 ISBN 0-597-00184-3 summary A methodical, in-depth look at the Java tool.

The other book, however, explicitly illustrates how some popular open source tools can help the process of extreme programming. Hightower and Lesiecki's book is much broader than Tilly and Burke's because they want to tackle so much more. They don't want to just provide a missing manual for the tool-- they want to give the world a road map on how they use Ant and its cousins JUnit, HTTPUnit, and Cactus to build better applications. It should be noted that Hightower and Lesiecki work for a consulting group called eBlox and a number of other eBlox programmers are listed as contributors to the book. I think it's fair to say that anyone who hires eBlox will get eXtreme Programming results built with this methodology.

The best part about this book is the wide scope. Ant remains the central taskmaster responsible for building the software, but the book explains how to incorporate other tools for testing the software. The authors embrace one of the extreme programming central beliefs that programmers should define how to test their code before it is actually written. The book explains how to use JUnit, Cactus, and HTTPUnit to set up rules to test every class file. After ANT fires up the compiler, it turns around and runs the tests on the code.

Java Tools for eXtreme Programming author Richard Hightower and Nicholas Lesiecki pages 513 publisher John Wiley and Sons rating 7 ISBN 0-471-20708-X summary How to use some Java tools to transform extreme programming theory into reality.

I don't think that eXtreme Programming or any of these tools is the last word on the subject. The biggest problem is that testing a piece of code is guaranteed to be fairly rudimentary. No programmer can come up with test cases to push all of buttons in all possible combinations. The structure and discipline provided by this approach can help, but the book makes it clear that no amount of pairs programming or extremism will remove the need for the guidance of good programmers.

If anything these tools and the books about them should serve as inspiration for the next round of tools even more focused on extreme programming. The tools are impressive, but there is plenty of room for more innovation. None of them is aimed at explicitly coordinating the work of multiple developers and none of them is designed to provide much structure to the refactoring process. These areas are still very much arts, but there's no reason why tool suites like Ant can't evolve some rational approach to solving them. Perhaps the Slashdot audience can provide some informative postings with pointers to the next generation of cool tools.

Hightower and Lesiecki's book feels a bit more rudimentary and basic than Tilly and Burke's, in part because they cover so much more ground. Although their book is broader, it doesn't go into as much depth about Ant as Tilly and Burke's. The examples are simpler, too, and Hightower and Liesiecki seem mainly interested in getting you excited about building and testing software with the tools. There just isn't as much room for details. If you're interested in learning as much as you can about Ant, choose the book devoted to it. If you want to learn how to use a diverse set of tools to build and test your program in an extreme way, go for that book.

Peter Wayner blends the buzzwords of security, privacy, and data warehousing together in his latest book, Translucent Databases. It shows how to ensure that only the right people see the right information and the wrong people get nothing. His other new book, Disappearing Cryptography, mixes the buzzwords of being, nothingness, steganography, and cryptography. You can purchase both Ant: The Definitive Guide and Java Tools for eXtreme Programming from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then hit the submission page.

Brian Donovan contributes this review of Web Database Applications with PHP & MySQL, the most recent of several books geared toward helping people use the common Linux, Apache, MySQL and PHP combination to produce database-backed websites. Read on for the review. Web Database Applications with PHP & MySQL author Hugh E. Williams and David Lane pages 563 publisher O'Reilly rating 9 reviewer Brian Donovan ISBN 0596000413 summary A comprehensive, tutorial-style roadmap for building data-driven web applications with PHP and MySQL.

PHP's speed of execution, gentle learning curve, and ease of development have contributed to its popularity, especially when teamed with MySQL, as a tool for building dynamic sites. Williams and Lane have written a thorough step-by-step guide to building web database applications with PHP and MySQL.

The Meat of the Book

Part I (Chpts 1-3) of Web Database Applications with PHP & MySQL (Web DB Apps) introduces the "Hugh and Dave's Online Wines" case study that's used to highlight the points made throughout the text and treats readers to the fundamentals of PHP, MySQL, and SQL - appropriate since the book assumes only some prior programming experience (not necessarily in PHP) and a general familiarity with HTML.

Chapters 4-9 (Part II) deal with the aspects of web application logic common to practically all data-driven sites : querying and writing to databases, maintaining state, and security. Chapter 4, "Querying Web Databases", includes a good explanation (Ex. 4-1) of the mechanics of connecting to and querying a MySQL db via PHP - numbered blocks of the example script correspond to sections in the accompanying text detailing what's happening at each point in the process (connect, query, retrieve results, process results, and close connection- unless you're using persistent db connections).

Chapter 5, "User-Driven Querying", explains how to pass data to PHP scripts using HTTP GET and POST. Although readers are initially shown parameters and parameter values being passed directly (as they are when register_globals is turned on in php.ini), the authors later explain why the same param:value pairs should instead be accessed through the global associative arrays $HTTP_GET_VARS and $HTTP_POST_VARS (the book was completed before the switch to $_GET and $_POST respectively with PHP 4.2.0) for security reasons. What the authors refer to as "combined scripts" (where the same script performs different functions depending on which, if any, variables in the GET or POST arrays, have been set, for example) are introduced and the reader is walked through the oft-used "next and previous links for query results" scenario.

In Chapter 6, "Writing to Web Databases", in addition to inserts, updates, and deletes, the authors explain one solution to the reload problem - i.e. where reloading a results page after some operation that alters the contents of the database has been performed (or even accessing a bookmarked url if HTTP GET was used to initiate the action) can potentially result in the operation being silently repeated or, if HTTP POST was used, the user being confronted with a big ugly "would you like to repost the data?" dialog. Locking (mostly how to make the best use of table-level locking) is also discussed in all of its glory. Chapter 7 deals with the validation of user input. The authors recommend and give an example implementation of dual server and client side validation (with JavaScript). Chapter 8 covers sessions (with and without cookies).

The chapter on security (Chapter 9, "Authentication and Security") mostly concerns user authentication. HTTP Authentication, managed HTTP Authentication (using PHP to validate encoded credentials from the HTTP Authorized header field), and handling your own authentication are considered, along with the security concerns inherent in stateful web apps - i.e., third party sites maliciously tricking browsers into coughing up cookies with login or session information for your site, session hijacking by feeding random session ids to the scripts until one corresponds to an existing session, etc. SSL is explained briefly.

The third and final section of Web DB Apps (Chpts 10-13) consists of a detailed examination of the guts of the wine store case study. Readers who find the commingling of application logic and html in the snippets of the wine store application discussed in the book distasteful will be gratified to know that, since publication, the authors have released a modified version of the "Hugh and Dave's Online Wines" code that uses the Xtemplate class (http://sourceforge.net/projects/xtpl/) to separate code from markup. Both versions are available in their entirety for download from the book website.

The five appendices, in turn, cover the installation and configuration of PHP, MySQL, and Apache on a Linux system, the architecture and workings of the Internet and Web, designing relational databases using entity-relationship modeling, how to define your own session handler prototypes and store session data in a database instead of files (the default), and provide an annotated list of PHP and MySQL resources (books, web sites, etc.).

The Good and the Bad

While it's clear that Web Database Applications with PHP & MySQL was written with the goal in mind of providing novice coders with a solid foundation for continued growth (or filling the niche of "handy reference" on the shelf of intermediate/advanced developers), the book manages to be comprehensive without patronizing the reader. I admit that I wouldn't have felt cheated if the authors had skipped the obligatory coverage of the history of the Internet, TCP/IP, and HTTP (Appendix B) in favor of, for instance, a discussion of web caching with an eye towards building cache-friendly apps, an important subject that all too gets short shrift from authors of web dev books. Also, some readers may be disappointed to find that the chapter on security doesn't relate to battening down your site against script kiddies and exploits, but that's really the sort of information that you should be getting from sites like PHP Advisory and Securiteam anyway.

For seasoned developers, this could be the book that you wish you'd had when you started out building web database apps and data-driven sites. Keeping a copy around for reference, especially if you frequently jump back and forth between projects in different languages/environments, also might be helpful - for those occasions when you need of a quick refresher in PHP/MySQL dev. Moreover, if you find yourself in the position of having to mentor junior developers (or helping non-coder friends) tasked with building or maintaining PHP/MySQL-based sites or apps, then lending them your copy or recommending that they buy their own could save you quite a bit of time and frustration.

Table of Contents

• Preface
• Part I
• • Chapter 1. Database Applications and the Web
  • Chapter 2. PHP
  • Chapter 3. MySQL and SQL
• Part II
• • Chapter 4. Querying Web Databases
  • Chapter 5. User-Driven Querying
  • Chapter 6. Writing to Web Databases
  • Chapter 7. Validation on the Server and Client
  • Chapter 8. Sessions
  • Chapter 9. Authentication and Security
• Part III
• • Chapter 10. Winestore Customer Management
  • Chapter 11. The Winestore Shopping Cart
  • Chapter 12. Ordering and Shipping at the Winestore
  • Chapter 13. Related Topics
• Appendix A. Installation Guide
• Appendix B. Internet and Web Protocols
• Appendix C. Modeling and Designing Relational Databases
• Appendix D. Managing Sessions in the Database Tier
• Appendix E. Resources
• Index

You can purchase Web Database Applications with PHP & MySQL from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then hit the submission page.

chill writes: "A while ago Heroine Virtual had a video editing program out called Broadcast 2000. Then something weird happened and the program was pulled from release with the homepage saying it was too dangerous legally to put out. Something about liability. Anyway, the successor to that program, called Cinelerra, is now available in beta form. Give it a shot and see what is what." And Dominic Mazzoni writes: "Talk about a tough act to follow. On the same day that Mozilla 1.0 was released last week, we released version 1.0.0 of Audacity, our GPL cross-platform audio editor that has been under development for nearly three years. It is based on wxWindows and runs natively on Linux (of course!), Windows, Mac OS (both 9 and X), and some other POSIX systems. Version 1.0.0 just adds a couple of minor features and bug fixes, but it is basically stable and quite useful, though it has some limitations. In addition, we also released a snapshot of our unstable development branch as Audacity 1.1.0. This version adds support for 24-bit and 32-bit samples, automatic resampling, LADSPA plug-ins, and internationalization, plus it has many nifty new UI enhancements."

Steve Streeting writes "Version 0.99b of OGRE (Object-oriented Graphics Rendering Engine) has been released! OGRE is a well designed, flexible and easy to use 3D engine released under the GNU Public License. This version adds highly customisable, scriptable particle systems, generic billboard support, compatibility with VC.Net, performance improvements and various bug fixes."

Steve Streeting writes "Version 0.99b of OGRE (Object-oriented Graphics Rendering Engine) has been released! OGRE is a well designed, flexible and easy to use 3D engine released under the GNU Public License. This version adds highly customisable, scriptable particle systems, generic billboard support, compatibility with VC.Net, performance improvements and various bug fixes."

Moshe Bar is (pick one) 1. A Linux kernel developer; 2. A motorcycle enthusiast; 3. The primary openMosix maintainer; 4. A respected Linux device driver writer; 5. Author of several books and many articles about Linux; 6. Newly married. 7. A Talmudic scholar; 8. All of the above. The correct answer is 8, and since in addition to (or perhaps because of) all this Moshe is a popular guy, this interview is here by reader request. (Yes, we take interview requests; send them to robin@roblimo.com.) Ask Moshe whatever you wish, one question per post. We'll send him 10 of the highest moderated questions and post his answers as soon as he gets them back to us.

plluke writes "I'm a Teaching Assistant for a course named CS148: Building Intelligent Robots offered by the CS Department at Brown University. Our robots were made/programmed/run on Lego MindStorms (with LegOS). Tres funky results include probabilistic sonar mappers, a bipedal walker, and a bartender. The final exhibition page is here and contains the aforementioned funky results."

benh57 writes "KDE has finally been ported to Mac OS X, by the Fink team. Source packages and pre-built binaries are now available. Read the announcement and instructions for installing. Woohoo!"

josephfeller writes: "'Meeting Challenges and Surviving Success: The 2nd Workshop on Open Source Software Engineering' was held last week at the 24th International Conference on Software Engineering (ICSE 2002), in Orlando, FL. The 15 workshop position papers and the workshop introduction are available for free download."

Slashback with a load of updates for you tonight on modchips for Xbox, Nigerian spam-scams, missing Mozilla hackers, Guillaume Laurent on Murray on Guillaume Laurent, and more. Read on for the details.

Sun giveth and taketh away. axehind writes: "This ZDNet article tells us StarOffice will no longer be free. The decision completes the transition of the StarOffice suite back to being a paid product, as it was when Sun bought the software along with its maker, Germany's Star Division, in 1999. Sun says it will stop free downloads of StarOffice 5.2 at midnight on Wednesday night."

On the other hand, The Pi-Guy writes: "It has been confirmed by Sun that Solaris 9 will be on Intel platforms - you can get it for free on DVD here. Quite surprising considering that a few months ago they were saying 'No S9 at all on x86!'"

Update: 05/29 03:03 GMT by T : As several readers have noticed, the page no longer indicates Solaris 9 once you've chosen x86 as your platform of choice -- looks like a case of mistaken identity.

Strong opinions tend to draw answers. Guillaume Laurent writes "Given that Murray mentions me in his interview, and that I disagree with most of what he says, I felt the need to reply. Enjoy."

Six seems a tad low. supafly613 writes: "Six people were arrested in South Africa over the weekend on suspicion of being involved in the infamous 'Nigerian' e-mail and letter fraud. Four of those detained were Nigerian, one was Cameroonian and the sixth was South African. Police in South Africa believe that the six are part of an international fraud and drug-dealing cartel, sending out thousands of e-mail and letters in an attempt to defraud."

Lost in cyberspace ... Mindphunk writes "Six hackers remain to be found so that Mozilla can be relicensed under the LGPL and GPL as well as the MPL original license. This is really important if Mozilla is going to interoperate readily with all kinds of free software. Perhaps the power of Slashdot can find them in time for the 1.0 release?? The missing hackers are:

• David Nebinger
• 'Uncle George'
• Sanjay Gupta
• Makoto Kato
• Thierry LeBouiland
• Jiwei Wang"

This is a followup to our earlier mention of the missing hackers.

Still waiting for NetBSD :) llordsmiff writes: "According to this, the world's first Xtender Xbox modchip preorders were shipped today (24 May). There are installation pictures also. "It plays back all import and backups on all worldwide sold Xbox machines." It's also supposed to play any DVD, regardless of region."

Wonder if this will be 'content protected.' neema writes: "Just a bit of an update to an older post, but Revolution OS will apparently be released on DVD (region free) in September for 20 dollars. Trailer and first 8 minutes can be found here. I, for one, welcome the chance to see it."

fdsa writes "After a heated debate, and under some pressure by TransGaming, an 'intent to package' WineX from sourceforge CVS for (non-free) Debian has been withdrawn. The message provides a good summary of the recent Wine chaos, and notes how WineX is effectively under a different license than stated. Here's a mail from their CEO Gavriel State on the issue."

We've all heard plenty about IBM's investment in Linux, but we don't hear much from -- or about -- the actual Linux developers at IBM. This interview is not with one person, but with a number of IBM Linux people spearheaded by Dave Hansen, who volunteered to help us with this interview. Of the group responding to your questions, Dave says, "There are more people, but the majority of the group's skills are represented. No surprise that we'll have our responses reviewed before we send them back to you, but we'll try to expedite that. "A little background: The group's experience is pretty broad. Most members were Sequent employees who worked on Dynix/PTX before IBM acquired Sequent (we are still mostly based in Beaverton, OR). Not everyone was with Sequent; Matt Dobson and Dave Hansen came into the group last summer, right out of college. A few of our Austin colleagues are long time IBM employees who worked on the AIX kernel before moving to Linux. Ask about anything from the rmap VM, to PTX's crashdump facilities, to life in Portland :)

• Martin Bligh - Large IA32 system VM scalability, Specweb, NUMA
• Dave Hansen - Big Kernel Lock, SMP locking, Specweb99
• Matt Dobson - NUMA API/ Documentation
• Rick Lindsley - SMP/NUMA Locking, Performance Tuning
• Patricia Gaughen - Discontiguous Memory for NUMA
• Bill Irwin - VM/rmap hacker
• Hanna Linder - dcache_lock scalability
• Janet Morgan - I/O Scalability
• Ruth Forrester - database/performance/scalability"

As usual, please ask only one question per post. We'll forward 10 of the highest moderated questions to Dave, and run all the answers, verbatim, as soon as we get them back.

We've all heard plenty about IBM's investment in Linux, but we don't hear much from -- or about -- the actual Linux developers at IBM. This interview is not with one person, but with a number of IBM Linux people spearheaded by Dave Hansen, who volunteered to help us with this interview. Of the group responding to your questions, Dave says, "There are more people, but the majority of the group's skills are represented. No surprise that we'll have our responses reviewed before we send them back to you, but we'll try to expedite that. "A little background: The group's experience is pretty broad. Most members were Sequent employees who worked on Dynix/PTX before IBM acquired Sequent (we are still mostly based in Beaverton, OR). Not everyone was with Sequent; Matt Dobson and Dave Hansen came into the group last summer, right out of college. A few of our Austin colleagues are long time IBM employees who worked on the AIX kernel before moving to Linux. Ask about anything from the rmap VM, to PTX's crashdump facilities, to life in Portland :)

• Martin Bligh - Large IA32 system VM scalability, Specweb, NUMA
• Dave Hansen - Big Kernel Lock, SMP locking, Specweb99
• Matt Dobson - NUMA API/ Documentation
• Rick Lindsley - SMP/NUMA Locking, Performance Tuning
• Patricia Gaughen - Discontiguous Memory for NUMA
• Bill Irwin - VM/rmap hacker
• Hanna Linder - dcache_lock scalability
• Janet Morgan - I/O Scalability
• Ruth Forrester - database/performance/scalability"

As usual, please ask only one question per post. We'll forward 10 of the highest moderated questions to Dave, and run all the answers, verbatim, as soon as we get them back.

We've all heard plenty about IBM's investment in Linux, but we don't hear much from -- or about -- the actual Linux developers at IBM. This interview is not with one person, but with a number of IBM Linux people spearheaded by Dave Hansen, who volunteered to help us with this interview. Of the group responding to your questions, Dave says, "There are more people, but the majority of the group's skills are represented. No surprise that we'll have our responses reviewed before we send them back to you, but we'll try to expedite that. "A little background: The group's experience is pretty broad. Most members were Sequent employees who worked on Dynix/PTX before IBM acquired Sequent (we are still mostly based in Beaverton, OR). Not everyone was with Sequent; Matt Dobson and Dave Hansen came into the group last summer, right out of college. A few of our Austin colleagues are long time IBM employees who worked on the AIX kernel before moving to Linux. Ask about anything from the rmap VM, to PTX's crashdump facilities, to life in Portland :)

• Martin Bligh - Large IA32 system VM scalability, Specweb, NUMA
• Dave Hansen - Big Kernel Lock, SMP locking, Specweb99
• Matt Dobson - NUMA API/ Documentation
• Rick Lindsley - SMP/NUMA Locking, Performance Tuning
• Patricia Gaughen - Discontiguous Memory for NUMA
• Bill Irwin - VM/rmap hacker
• Hanna Linder - dcache_lock scalability
• Janet Morgan - I/O Scalability
• Ruth Forrester - database/performance/scalability"

As usual, please ask only one question per post. We'll forward 10 of the highest moderated questions to Dave, and run all the answers, verbatim, as soon as we get them back.

We've all heard plenty about IBM's investment in Linux, but we don't hear much from -- or about -- the actual Linux developers at IBM. This interview is not with one person, but with a number of IBM Linux people spearheaded by Dave Hansen, who volunteered to help us with this interview. Of the group responding to your questions, Dave says, "There are more people, but the majority of the group's skills are represented. No surprise that we'll have our responses reviewed before we send them back to you, but we'll try to expedite that. "A little background: The group's experience is pretty broad. Most members were Sequent employees who worked on Dynix/PTX before IBM acquired Sequent (we are still mostly based in Beaverton, OR). Not everyone was with Sequent; Matt Dobson and Dave Hansen came into the group last summer, right out of college. A few of our Austin colleagues are long time IBM employees who worked on the AIX kernel before moving to Linux. Ask about anything from the rmap VM, to PTX's crashdump facilities, to life in Portland :)

• Martin Bligh - Large IA32 system VM scalability, Specweb, NUMA
• Dave Hansen - Big Kernel Lock, SMP locking, Specweb99
• Matt Dobson - NUMA API/ Documentation
• Rick Lindsley - SMP/NUMA Locking, Performance Tuning
• Patricia Gaughen - Discontiguous Memory for NUMA
• Bill Irwin - VM/rmap hacker
• Hanna Linder - dcache_lock scalability
• Janet Morgan - I/O Scalability
• Ruth Forrester - database/performance/scalability"

As usual, please ask only one question per post. We'll forward 10 of the highest moderated questions to Dave, and run all the answers, verbatim, as soon as we get them back.

We've all heard plenty about IBM's investment in Linux, but we don't hear much from -- or about -- the actual Linux developers at IBM. This interview is not with one person, but with a number of IBM Linux people spearheaded by Dave Hansen, who volunteered to help us with this interview. Of the group responding to your questions, Dave says, "There are more people, but the majority of the group's skills are represented. No surprise that we'll have our responses reviewed before we send them back to you, but we'll try to expedite that. "A little background: The group's experience is pretty broad. Most members were Sequent employees who worked on Dynix/PTX before IBM acquired Sequent (we are still mostly based in Beaverton, OR). Not everyone was with Sequent; Matt Dobson and Dave Hansen came into the group last summer, right out of college. A few of our Austin colleagues are long time IBM employees who worked on the AIX kernel before moving to Linux. Ask about anything from the rmap VM, to PTX's crashdump facilities, to life in Portland :)

• Martin Bligh - Large IA32 system VM scalability, Specweb, NUMA
• Dave Hansen - Big Kernel Lock, SMP locking, Specweb99
• Matt Dobson - NUMA API/ Documentation
• Rick Lindsley - SMP/NUMA Locking, Performance Tuning
• Patricia Gaughen - Discontiguous Memory for NUMA
• Bill Irwin - VM/rmap hacker
• Hanna Linder - dcache_lock scalability
• Janet Morgan - I/O Scalability
• Ruth Forrester - database/performance/scalability"

As usual, please ask only one question per post. We'll forward 10 of the highest moderated questions to Dave, and run all the answers, verbatim, as soon as we get them back.

We've all heard plenty about IBM's investment in Linux, but we don't hear much from -- or about -- the actual Linux developers at IBM. This interview is not with one person, but with a number of IBM Linux people spearheaded by Dave Hansen, who volunteered to help us with this interview. Of the group responding to your questions, Dave says, "There are more people, but the majority of the group's skills are represented. No surprise that we'll have our responses reviewed before we send them back to you, but we'll try to expedite that. "A little background: The group's experience is pretty broad. Most members were Sequent employees who worked on Dynix/PTX before IBM acquired Sequent (we are still mostly based in Beaverton, OR). Not everyone was with Sequent; Matt Dobson and Dave Hansen came into the group last summer, right out of college. A few of our Austin colleagues are long time IBM employees who worked on the AIX kernel before moving to Linux. Ask about anything from the rmap VM, to PTX's crashdump facilities, to life in Portland :)

• Martin Bligh - Large IA32 system VM scalability, Specweb, NUMA
• Dave Hansen - Big Kernel Lock, SMP locking, Specweb99
• Matt Dobson - NUMA API/ Documentation
• Rick Lindsley - SMP/NUMA Locking, Performance Tuning
• Patricia Gaughen - Discontiguous Memory for NUMA
• Bill Irwin - VM/rmap hacker
• Hanna Linder - dcache_lock scalability
• Janet Morgan - I/O Scalability
• Ruth Forrester - database/performance/scalability"

As usual, please ask only one question per post. We'll forward 10 of the highest moderated questions to Dave, and run all the answers, verbatim, as soon as we get them back.

jimmcq writes: "After two years of active development the long awaited stable release of FreeCraft is available. FreeCraft is a free cross-platform real-time strategy gaming engine. It is possible to play against human opponents over LAN, internet, or against the computer. The engine can be used to build C&C, WC2, SC and AOE-like real-time strategy (RTS) games. It successfully runs under Linux, BSD, BeOS, MacOS/X, MacOS/Darwin and MS Windows. Souce code and binaries are available from SourceForge."

An Anonymous Coward writes: "Palm Info Center reports that POSE (the Palm Os Emulator) has been ported to the Sharp Zaurus using the QTopia palmtop environment. See the QPOSE homepage for more information." This could make a Zaurus a much more attractive device to those of us with lots of important info on Palm Os devices, but according to other readers' submissions it does require a Palm ROM image to function.

Last week, you posted your questions to SomaFM's General Manger, Rusty, and today he delivers. In this interview: answers about CARP (which was wisely rejected by the Library of Congress, this week), the RIAA, the workings of an internet radio station, and of course, Big URL.

1) how much does the recording industry really care?
by Laplace

I was curious to know how much the recording industry cares about small stations. Do you think that the Recording Industry Association of America is going to come after these tiny internet broadcasters, some of which are run out of someone's bedroom, and actually try to enforce this legislation? Given the bandwidth small stations operate on, their lack of mainstream exposure, and the tiny bang for the (litigious) buck, it seems that the record industry can spend their resources elsewhere with greater effect.

Rusty:

I think the RIAA is very concerned with small broadcasters, and that they will go after them the same way they've gone after small web sites that post MP3 files. Just like the movie companies were sending cease and desist letters to all the fan sites out there.

Think about it, just in the last few months we've been hearing about how the RIAA's been suing companies who have MP3s on company fileservers.

If you can stay under the radar, more power to you. But once you start getting more than 50 concurrent listeners, you'll start getting their attention. Small stations have been getting letters from ASCAP and BMI for a long time, and the RIAA stands to gain much higher revenues than they do. With the proposed rates of 0.14 cents per song per listener, that works out to roughly $0.50 a day per concurrent listener, or $180 a year per concurrent listener. You can see that even a small station with 10 average concurrent listeners could owe them a decent amount of money each year.

I think they'll come after anyone listed in a popular listing directory, be that Shoutcast.com or the Icecast YP.

This whole CARP thing also seems more about control by the record companies rather than just pure monetary greed. The major labels only want to push their superstars. They're not interested in a diverse marketplace. CARP isn't just about money, it also includes some overly burdensome reporting requirements (including stupid things like each listeners time zone!). To me, it's pretty obvious that the major labels want to control what the public is listening to. That's why they're paying huge amounts in "legal payola" to the big broadcast chains. They don't want independent programmers fragmenting their potential audience.

And the way they'll enforce it is by going after the ISPs. The DMCA has some pretty clear methods for dealing with that. So it will be simple for the RIAA to use provisions of the DMCA to shut down the ones that aren't worth suing.

2) Thoughts about Digital Rights Management?
by SPYvSPY

Given the availability of programs like streamripper (and others like it, I guess), do you have any plans to accomodate the myriad of digital rights management schemes in the pipeline? Which, if any, do you support or intend to implement? Do you think that you have an obligation to do so? BTW, keep up the good work. I can say with total sincerity that your stations have introduced me music that I would otherwise never have heard. I thank you, (and so does my iPod). ;)

Rusty:

The bottom line is that DRM doesn't work. It's like a speed bump, not a barrier. You can always use something like Total Recorder to record the bits going to the sound drivers. You can always plug a minidisc recorder into the audio outs on your computer. And you can always make a cassette off of the radio.

That being said we're not big fans of streamrippers. Bandwidth costs real money, and we have licensing fees (ASCAP/BMI) that are based on numbers of listeners and revenue. If someone is streamripping all day long, and they're not listening, they're costing us money. The latest versions of the Shoutcast server as well as the Shoutcast YP are not too friendly to streamrippers but again, that's just another speedbump.

Streamrippers do have their place for time-shifting, and taking a program with you in the car or on your iPod. But in those cases, you'd be ripping a continuous chunk of audio, not trying to split it up into discrete audio tracks. After all, we want people to listen to our full presentation. We may implement things to make it harder to split the tracks automatically.

As for an obligation to implement other forms of DRM, I guess I would have to see what that DRM was. And since our music is segued and we talk over the intros, when people do streamrip us they're not getting cleanly split versions of the tracks we're playing anyway!

3) Pirate Mythology
by tcd004

Right now Internet Radio enjoys a sort of "pirate" image, which I think endears it to many people because they feel like they're supporting independent media.

However, my guess is that as it grows and becomes more profitable, most Internet radio is bound to end up owned by 2-5 big players, as is the case with most other media. Do you expect internet radio to get bought up like the movie studios, local TV stations and radio stations, or do you think it will be able to stay independent?

Would mergers and consolidation ruin internet radio, or would it help it?

Rusty:

I'm not sure I agree with the "pirate" terminology, but I get your drift. We're independent, we're not mainstream, we're an alternative, we're indie, we're not part of the system.

I disagree that internet radio will be owned by several big players. Remember, net radio doesn't have the limitations that over the air broadcast stations do. There are a limited number of over the air stations in each city. This is because broadcast radio spectrum is limited (the FM band is twenty whole megahertz wide, the AM bandwidth is just over one megahertz wide!) However, the net is different, while not infinite there is a whole lot of room out there for content. There are over 3,000 stations listed in Shoutcast.com right now, and I'm sure there is an equal number of stations in other formats. There are less than 13,000 FCC licensed AM and FM stations in the United States. In all major metro markets, there is no more room for additional AM/FM stations. There is plenty of room for more stations in the 'net.

Will there be mergers and consolidation? Probably. Will this ruin it? Probably not. Here's how I see it: I think you'll see lots of stations join together into "groups". Maybe they'll be ad supported, and sell ads across the group. Maybe they'll be subscription based, and by subscribing to the group, you'll have access to all the member stations.

I'm sure a lot of stations will "sell out" to big media companies. And then their programming will get just as boring as the programming from the big media companies. Which in turn will mean that people who are tired of the same old shit will look for something different, the kind of programming only being played on the stations that didn't sell out.

I see it as a continual flow, a cycle almost. Would we sell out? Right now we are running purely on donations and donated bandwidth, so if someone offered us a way to keep running it like it is now with guaranteed bandwidth and actually pay me a salary, that would be great. There is also a lot of things we'd like to do to improve the quality of our streams but they'd all cost money. Same with our plans for additional channels. We've got plans for 6 more niche channels in the works but we can't afford to get them going at this time.

SomaFM could even go away tomorrow not due to CARP, but if everyone suddenly pulled their bandwidth. Donations aren't going to come close to covering the potential bandwidth bill of $12,000-20,000 a month. That really isn't control.

4) Cutting out RIAA music
by mcc

Something that has been brought up a couple times in other threads, and that I am kind of curious about:

The CARP is something the RIAA is imposing, correct?

Does this or does this not mean that if an internet radio station were certain to only play music by non-RIAA artists, it could stay in business? It would not be terribly easy to find material for a net radio station that only played independent music, but it would be possible, i think, and at the least i'd listen to it.

But am i just confused? Would that be feasible from a royalties standpoint? What exactly is the royalties relationship between independent record labels and internet radio, before or after CARP?

One more small question: the page on CARP on your site says that non-US broadcasters would not be subject to the CARP fees. How would this work out? Would this just mean that anyone in Canada would be able to netcast worldwide without having to pay any fees other than the ones imposed by their government? Or would stations outside the U.S. be barred from netcasting to U.S. citizens? If stations outside the U.S. are allowed to run free, what would the regulations say about a server in the U.S. that is just repeating what is being broadcast by an internet streaming radio station located outside the U.S.-- so that the lag created by the internet links that go across the atlantic ocean are minimized. Could a repeater of this sort be classified as just another router, or would the repeater be subject to the CARP payments?

Thanks for clarifying things.. just curious. Hopefully, the LoC will see through this blatant attempt by the RIAA to silence internet radio and none of the above questions will ever become an issue. I wish you luck..

Rusty:

The CARP is the outcome of a provision of the DMCA known as the compulsory license. What that means, is that an internet broadcaster can get a license to broadcast any recorded works without getting prior permission from the copyright holder. The compulsory part means that the copyright owners must give it to you. In return the CARP set a royalty fee that would be paid to Sound Exchange, an unincorporated division of the RIAA. Sound Exchange is then obligated to distribute that money to the copyright owners and the performance artists, after keeping a cut for their efforts.

If a radio station was to get permission from the holder of the copyright of the sound recording - they could broadcast it without being subject to the DMCA compulsory license. It would not be easy to do this, and would require a lot of paperwork, but it could be done. The biggest issues that arise is what happens when the copyright is sold? This has happened with many electronica artists. They created the recording, they gave us permission to play it. But then they sold it to a record label who no longer gives us permission to play it. So the only way in that case we can play it is through the compulsory license.

This is what is hurting SomaFM the most. When we started back in 1999, we were playing unknown obscure ambient music. Labels would contact us after finding their tracks in the playlists and thank us for playing them. But as ambient electronica became more and more popular, big labels started buying the rights. Now those big labels won't even return our emails... and we're the people who did so much to expose and popularize their artists.

As for non-US broadcasters, the CARP fees don't apply to them, but similar, albeit substantially lesser, fees do. European stations have to pay a "Phonographic Performance License". My understanding is that this is a 3-6% of revenue fee. Stations outside the US won't run free, they'll just run at an affordable, reasonable rate.

As to the question of whether repeaters would be considered a "source of broadcast", we are not sure and it will probably take a court challenge to clarify it.

5) Royalties loophole?
by Dan Crash

The statutory royalty rate for Internet simulcasts of FM radio broadcasts is only half that of Internet-only broadcasts. So couldn't any web station cut their royalties in half by spending $34.95 (plus shipping) to buy a micro-FM transmitter?

Here's what the law says in Title 17, ? 114. Scope of exclusive rights in sound recordings:

The performance of a sound recording publicly by means of a digital audio transmission, other than as a part of an interactive service, is not an infringement of section 106(6) if the performance is part of ...a nonsubscription broadcast transmission.

It doesn't require you to be a licensed or noncommercial broadcaster, simply that your performance is broadcast freely over the airwaves.

Has the webcasting industry looked into this loophole at all? Seems to me that cutting your operating expenses roughly in half could be the difference between economic life and death for most companies.

Rusty:

You are correct that the compulsory rate for Internet simulcasts of FM radio broadcasts is only half that of Internet-only broadcasts. However, that is still a huge amount of money. For SomaFM, that would still amount to over $150,000 for the next year, or about 6-7 times our estimated revenues.

But buying a micro FM transmitter doesn't help. If you read further on, you'll note that Section 114 of Title 17 defines a "broadcast" transmission a transmission made by a terrestrial broadcast station licensed as such by the Federal Communications Commission.

Remember, in the US, you can't broadcast freely over the airwaves except in certain designated bands, and then only within certain limits.

6) Fraunhofer, and OGG Vorbis
by E1ven

What amount do you currently pay in MP3 liscensing, in order to stream SomaFM over the internet?

With all the threats and attacks to MP3 streaming by Fraunhofer, have you considered moving to streaming OGG Vorbis files?

As Winamp is now shipping with native support, this could be a good way of shaving down some of the fees regarding your business.

Rusty:

We are not paying licensing fees to Fraunhofer, although we do own a licensed copy of their encoder. We currently use LAME for all Mp3 streams.

We are intrigued with OGG Vorbis compression, and would like to start experimenting with it soon. We've been kind of kind of busy with all the politicking lately to spend time on technical experiments.

There are a few problems we face: all our music is currently stored as high bit rate MP3 files. (192-320kb). From what I've seen, OGG does not do a good job recompressing MP3 files. Our broadcast playback software plays back and segues music files, does some audio processing (automatic gain control and some light dynamics compression), sends the bit stream to the LAME encoder and then onto the server. This sounds pretty good even though in the end, the listener is getting a file that has been double MP3 compressed. But add OGG to that equation, and the recompression could sound pretty bad. We still have to experiment with this more. OGG is in our future. As storage gets cheaper, we'll re-encode our music in a non-lossy format.

And as soon as Tag and Tom ship a version of the Shoutcast DSP with OGG codec support that is stable, we'll start running an experimental stream.

7) Popular (internet) music on the Radio?
by Traa

As much as I love internet radio and hope to see it stay I have been wondering why some of the more popular music themes on the internet are not available on commercial radio. I am talking about the sounds of SomaFM's Groove Salad, Digitally Imported and other internet radio stations playing Ambient, Trance or any of the other more mellow versions of Electronic House. What in your opinion is the reason we can't find these styles on commercial radio?

Best of luck and keep up the good work!

Rusty:

The audience isn't big enough to make it worthwhile to advertisers. The broadcast band isn't big enough to hold fringe formats. Formats succeed on internet radio because the audience is NOT limited to a geographical area. I think the place you'll see these formats first is satellite radio. We've talked a bit to XM, but they are still under the impression that electronic music = dance music. They don't realize how broad the genre is, and lumping them all together would be like mixing Dixieland jazz and blues and smooth jazz together on the same channel. XM is starting to come around and we've been told that they're actively considering some type of "Chill Out / Downtempo" channel.

8) Will CARP (crap) affect overseas operators?
by an Anonymous Coward

The beauty of the Internet is that no single government (or stupid government person) could stop an entire class of service - look at Internet gambling. That said, why not relocate to a co/lo service in India?

Or, better yet, just run amok of the law? Last I heard, the Library of Congress is a library, not an authorized body to create policy. Since they are attempting to do so, why not block them on the grounds that they are exceeding their charter, and therefore, acting against the constitution?

Also, the fact that internet based transmissions are treated differently than FM based transmissions is ridiculous. This is the foundation of the "separate but equal" crap that CARP is funnelling.

128k MP3 (and less) is not a perfect reproduction of sound, as the LoC contends. It is no more perfect than FM, and no less perfect. Both formats mangle stereo separation, both add audio artifacts, and both deduct from clarity and depth of the source's timbre. The only real difference is one is digital, and the other analog.

And both formats HELP drive record sales. The big difference to the RIAA is that they don't control the channels of distribution for MP3 servers. All SomaFM, or any other internet broadcaster needs is a music library, a fast connection to the net and powerful servers. In order to broadcast on the air, you need to give some slimy FCC official a kickback, and/or be owned by TimeWarnerAOL, Vivendi, or Viacom.

I can't help but see the future of the RIAA - all the offices burned to the ground and the leadership decapitated. This another one of those infuriating instances where their feeble attempts at limiting distribution channels so that everyone listens to the same, soulless crap that record producers are puking at us.

Rusty:

Why not set up in India? Well, I like living in San Francisco and can't afford to move to India (I have to have a day job to pay my bills, SomaFM loses money). So we'd have to "virtually" run out of India and control things from here. That's a pretty lose loophole and won't protect us. It sounds good in theory but when you dive into it you realize that we would still be a target for the RIAA. Unless we were buying the CDs here and mailing them over there to be digitized and loaded into playback systems over there, we would still be breaking copyright law. Not to mention we could never do any more live broadcasts from the US. So that option is out.

While the Library of Congress is only setting the royalty rate, they're not charged with enforcing the law. The law is set in place by the DMCA. And as I get older, it's scary enough for me when I get a letter from the IRS, let alone a knock on the door from the FBI.

If we were rich enough, and had enough money or a bunch of lawyer friends, we would form a LLC and challenge them. But just to give you an idea of what it would cost- the costs associated with being a part of the original CARP hearings came out to $300,000 per each participant. Yahoo and MTV can afford that, but we can't.

Keep in mind that CARP only sets the fees that are required by the DMCA. We can't change provisions of the DMCA by going after the Library of Congress, or complaining about CARP. We can only hope to get a fee basis from CARP that will not bankrupt internet stations.

9) Business Model
by Everach

How does SomaFM compare fiscally to a traditional FM or AM business?

Specifically, are there any fiscal advantages to using an internet-only format to outweight the disadvanges (like a lack of big-name advertising)?

Rusty:

The fiscal advantages to being internet-only:

Massively lower startup costs. We were able to get started almost immediately. Even if we could have gotten a license and construction permit to build a new FM station, it would have taken a year with all the regulations you have to go through. Not to mention the ongoing regulations that over the air stations have to deal with (FCC licenses bring with them lots of FCC mandated record keeping and such).

The disadvantages:

Incremental costs increase as audience increases (bandwidth mostly). Can't reach people in cars, which are a huge potential audience. We don't get respect from record companies (e.g. we have to call and beg just to get copies of CDs, they rarely automatically send them to us), nor do we get the legalized payola known as indie promotion to play their music.

But to me, the most important thing is the global reach we get by being internet only. We can now get decent sized audiences for extremely niche music genres and formats.

10) Big Earl [spelled 'Big URL' actually] by hitchhacker

Hi Rusty, thanks for the beautiful music!

I wanted to know what you use for Big Earl's voice synthesis. It sounds awfully similar to Dr. Sbaitso from the early 90's.

Also, I noticed that there are many songs that have disapeared from Groove Salad's playlist from around last year. (GOOD songs). I wanted to know if this is because you were forced to remove them, and how many other artists/labels are being held back this way. This music is so good it gives me goose-bumps, and I can't stand the thought that there is more that I am missing.

my letter is off to my controllers^H^H^H^H^Hrepresentatives.

Rusty:

Big Url's voice is driven by an old bell labs text to speech demonstration site. He's the "Big Man" voice. Google for Bell Labs TTS and you'll find it. Sadly, the site crashes from time to time - I'm not sure but I get the feeling it's one old timer who keeps the site working. We're glad whoever keeps it up does, because we'd miss his voice otherwise.

The only songs that have disappeared are songs that we only had in MP2 format and have lost the original CDs for them. We try and re-encode them as we re-discover them. The reason for this is that the playback automation software we now use (from OtsJuke.com) only handles MP3 compression. But there were less than 50 songs that way. I don't think there are any others we are missing, we generally don't completely remove songs, we just play them a lot less frequently. In the last year, we've removed less than 20 songs from the playlist. There are probably close to 15,000 tracks that we play on the air.

babbage writes "There has been some talk recently on various mailing lists about getting a Mac OS X version of Ximian Connector extension to Evolution, which allows Evolution to interact with Microsoft Exchange 2000 servers much as Microsoft Outlook can. It is already possible to build and run Gnome and Evolution on Mac OS X, thanks largely to projects such as Fink. Ximian is aware of this interest, and has indicated that if enough users expressed a serious interest in buying the product -- the target number was 500 paying users -- they would be willing to produce a Mac OS X port of Connector. To that end, I've set up an petition to help gauge user interest."

The Griller writes "Gordon Bell, one of the creators of VAX, and Linus Torvalds were at the launch of a new supercomputing platform at the Los Alamos National Laboratory. Based on Crusoe processors from Transmeta and running a version of linux, it is aimed at being cheaper than conventional supercomputers by requiring no cooling and lower maintenance. " Basically, it's blade clustering, using Beowulf.

axehind writes "In this Byte.com article, Dr Moshe Bar explains some of the differences between IA32 and IA64. He also explains some things to watch out for when porting applications to the IA64 architecture."

Anonymous Chris writes: "I was reading up at LinuxArtist.org and saw mention that Crystal Space is running a contest, with first, second, and third prizes of $500, $250, and $200. This is how the developers decided to distribute a $1000 grant from the Linux Fund. The deadline for your game/demo/tool is August 2002. At least there's still good news in some parts of the Linux Gaming front."

jayed_99 writes "mod_snake has been abandoned by its creater Jon Travis. He cites a lack of 'time or motivation.' Like mod_python, it embedds the Python interpreter into Apache. Unlike mod_python, it includes support for HTML-embedded python (a very nifty feature). It's still available here. Wouldn't you know this would happen two days after I decide to switch from mod_python to mod_snake?"

jayed_99 writes "mod_snake has been abandoned by its creater Jon Travis. He cites a lack of 'time or motivation.' Like mod_python, it embedds the Python interpreter into Apache. Unlike mod_python, it includes support for HTML-embedded python (a very nifty feature). It's still available here. Wouldn't you know this would happen two days after I decide to switch from mod_python to mod_snake?"

mtve writes: "Have you ever seen source code that is valid on four languages: Perl, C, Befunge, and BrainF*ck? During last Perlgolf season famous Perl hacker Jérôme Quelin submit such inconceivable masterpiece and now he published expanded explanation of his solution. Caution: that text can hurt your mental health. Play Perlgolf!"

mtve writes: "Have you ever seen source code that is valid on four languages: Perl, C, Befunge, and BrainF*ck? During last Perlgolf season famous Perl hacker Jérôme Quelin submit such inconceivable masterpiece and now he published expanded explanation of his solution. Caution: that text can hurt your mental health. Play Perlgolf!"

jgrr asks: "I'd like to be able to take a DVI file and convert it to some less palatable format, like MS Word. Some journals I want to submit papers to accept electronic copies as either MS Word or WordPerfect documents, not as TeX. (These are in ecology and zoology, not math journals). People I ask to look at papers don't use TeX either, and like to make the changes to the text itself, so PDF won't work. I know about latex2rtf, but I use some different packages and BiBTeX, and I'd rather not have to re-write the paper in Word after converting it. It seems like the DVI level is better than the TeX level for this, but I can't seem to find any existing software that does it. Any ideas?"