- On the Web
- Might Be Just Right
- diff -u: What's New in Kernel Development
- 100 Million X $100 Linux Laptops
- Proprietary Device Drivers?
- They Said It
On the Web
We at LinuxJournal.com have been fortunate over the years to receive all sorts of how-to and DIY articles. Our authors love to write about their cool projects—you know, the stuff you guys are piecing together in basements and workshops with soldering guns, breadboards, microcontrollers and a few lines of C written in vi. And LinuxJournal.com readers love to read about what other people are doing so they can hack a project for their own needs. Well, we want more of this exchange. So, we're asking our readers to tell us what they're building, hacking and conjuring. Send your project outlines and article proposals to email@example.com.
In the meantime, LinuxJournal.com offers these project articles to hold you over:
“A Beginning Look at MythTV” (/article/8558) by Colin McGregor starts by explaining what MythTV is and when it's a good idea to build your own personal video recorder and then moves on to explore MythTV plugins for DVDs, photo galleries, games and more.
Although not a basement project, the FreeNX Project is both cool and useful. Kurt Pfeifle, a member of the FreeNX Development Team, offers a seven-part series that introduces NX technology and explains how it lets you run remote X11 sessions across slow or low-bandwidth network connections. In Part 5 (www.linuxjournal.com/article/8538), Kurt provides step-by-step instructions for maneuvering your way though the NX interfaces.
We recently posted the 2006 Editorial Calendar on LinuxJournal.com; it's available at www.linuxjournal.com/xstatic/author/topicsdue. It lists the focus topic we have planned for each issue in 2006. Take a look at the topics—ranging from “Home Projects” to “Building Dynamic Web Sites”—and send a proposal to firstname.lastname@example.org if you have an idea for an article.
Might Be Just Right
At LinuxWorld in Boston earlier this year, I got together with an old Swedish friend. She's a nurse, not a technologist, but she was curious about my work and the conference that brought me to town. Somewhere in the midst of my explanation of Linux and its virtues, she said, “Ah, Linux is lagom”. She explained that lagom is a Swedish term that conveys a sense of balance, proportion and appropriateness. “Not too much, not too little...just right.”
When I told her that Linus Torvalds' first language and surname were both Swedish, she said, “Well of course. There you go.” (I'm half-Swedish myself, though I'm not sure that matters.)
So I put the question “Is Linux logom?” to The Man Himself in an e-mail. He debugged my spelling and declined to commit:
Lagom, with an “a”.
And yes, it means “just right”, in the sense of “not too much, not too little”. See en.wikipedia.org/wiki/Lagom
Then he added, in a following e-mail:
They still end up confusing “lagom” with finding the “optimal” amount. That's pretty much missing the point. It's not that something is “lagom” because it's the best possible or “optimal”. Quite the reverse. Something being “lagom” very much involves not caring too much about what the optimal amount even is. Or possibly questions where “optimal” simply doesn't make sense.
So I began checking other sources. The best I found was from “In Other Words”, published in AskOxford, published by the Oxford English Dictionary (www.askoxford.com/worldofwords/wordfrom/otherwords). It lists lagom among a handful of “the most insightful, intriguing, and satisfying expressions on the planet—for which there are no English equivalents”. It says:
Swedish commentator Dr Bengt Gustavsson argued that the lagom mentality can be seen as the trait that gives Swedish society its characteristic stability and yet an openness to external influences. The word alludes subconsciously to the avoidance of both conspicuous success and humiliating failure, which is deeply ingrained in the Swedish psyche. It is the inclination among Swedes to shun ostentation, accept modest rewards, be good team players—to fly beneath the radar.
Beneath the Radar was also the title of Bob Young's book about starting and guiding Red Hat to success. Coincidence?
Perhaps characteristically, Linus adds these final words to the matter: “but whether that applies to Linux I have no idea.”
diff -u: What's New in Kernel Development
SMBFS has been orphaned. Urban Widmark, the official maintainer, has stopped responding to e-mail about the filesystem, and Adrian Bunk has put out the call for someone to step up and maintain this code. The situation is colored by the fact that CIFS, a potential replacement, does not yet support the full array of Windows variants covered by SMBFS. Apparently Red Hat discovered this when they tried to remove SMBFS in Fedora and had to re-enable it fairly quickly. With the CIFS developers working to extend the number of supported systems, the situation of SMBFS is even more uncertain. Should a new maintainer come forward? Should the code just sit quietly until it can be replaced by CIFS? The future of this corner of the kernel seems yet to be decided.
The linux-kernel mailing list has received an infusion of life. Dell recently donated a powerful computer to host the list, and the result has been much better latency between the time a user posts to the list, and the time readers receive that post. Over the years, as the number of silent readers and active posters has gone up and up and up, the hardware running linux-kernel (and the rest of the vger mailing lists) has occasionally been overwhelmed. Various companies always have offered generous donations when speed or bandwidth has gotten tight to keep these lists running properly. Dell's gift, and Red Hat's donation of a 1 gigabit network connection, should ensure linux-kernel's smooth operation for the near-to-mid future.
Michael S. Tsirkin has gone through the kernel sources, identifying and documenting the basic stylistic standards for whitespace usage. He started this project as a way to help his coworkers get started with kernel development, but published the results when he realized they might actually have a wider appeal. A set of kernel coding standards already exists in the Documentation/CodingStyle file distributed with the official sources, but that file neglects to cover much of the intricate details of whitespace usage. Michael's document is a first. As soon as he posted it, a bunch of other developers offered detailed suggestions and refinements, so the latest version is probably quite reliable.
Andrea Arcangeli has written a tool to help track how many people actually test each new kernel. This tool, called klive, runs in user space on the computers of willing participants and reports various system statistics to Andrea's server at klive.cpushare.com, where the results are aggregated and displayed. So far, more than 100 users are participating in the effort. One problem various kernel developers have with this project is the possibility that users might think of it as a tool to spy on them. As a result, it is less likely that Andrea will be able to migrate his tool to a full-kernel feature. Probably, klive will remain just a user program, unless developers' concerns can be clearly assuaged.
Adrian Bunk, always on the lookout for ways to clear out kernel deadwood, has been pushing a patch to remove support for older GCC versions. According to Adrian, newer compilers are perfectly able to compile the kernel, and continuing to support the older compilers results in a lot of conditional code that makes the kernel uglier, larger and harder to maintain in some areas. Nevertheless, it seems that many kernel developers feel quite strongly that at the very least, GCC 2.95 must continue to be supported. GCC 2.95 is blazingly fast compared to recent compilers, and anyone compiling multiple kernels per day (as kernel developers are wont to do) saves considerable time by relying on GCC 2.95 instead of the more recent compilers. So it looks as though Adrian's patch may have to wait until newer compilers can better compete for speed.
Chris Wedgwood recommends boycotting NVIDIA until they start releasing the specifications needed to write open-source drivers for their hardware. This came up recently when Michael Thonke asked whether Linux would implement NCQ support for NVIDIA NForce4 (CK804) SATAII-based chipsets. Jeff Garzik's reply was that there were no plans to implement this because there was no documentation from NVIDIA. He also said, “They are the only company that gives me zero information on their SATA controllers.” With NVIDIA apparently so hostile to free software, Chris argues, it's up to the rest of us to send them a message by not purchasing their hardware until they change their tune.
100 Million X $100 Linux Laptops
MIT's Media Lab is developing a $100 US Linux-based laptop that will “be able to do most everything except store huge amounts of data”. The units will have color displays, Wi-Fi, mesh networking, cell-phone connectivity and “USB ports galore”.
Nicholas Negroponte, chairman and co-founder of the Media Lab, announced the initiative in January 2005 at the World Economic Forum in Davos, Switzerland. Details of the initiative were published in August 2005.
In a Q&A that ran with the August 2005 announcement, Negroponte said, “...we will market the laptops in very large numbers (millions), directly to ministries of education, which can distribute them like textbooks.” He also calls the project “One Laptop Per Child”. The plan is to have units ready for shipment by late 2006 or early 2007. The goal is to produce and distribute 100 million of them.
Tom Limoncelli, co-author of The Practice of System and Network Administration, said, “The thought of laptops distributed like textbooks could be as revolutionary for spreading hardware as Linux was for spreading UNIX-like systems.”
Proprietary Device Drivers?
If you've been reading Linux Journal for a while, you'll notice that everyone here tells you to stay away from proprietary device drivers. Video cards, wireless network hardware and Fibre Channel hardware have been especially problematic.
By releasing a proprietary driver, not only does a vendor shut itself out of the non-x86 embedded market and pass up free driver testing and optimization from the experts on the linux-kernel mailing list, it's also hurting itself with regular Linux customers too.
Here's what readers said in a survey (numbers rounded):
We don't use proprietary drivers on Linux: 20
We'll use a proprietary driver only if there's no competing hardware with a GPL driver: 14
A proprietary driver tends to make us less likely to buy a piece of hardware, but doesn't rule it out: 35
We'll use proprietary drivers only if our Linux hardware vendor or distribution vendor commits to supporting them: 8
Whether the driver is GPL or proprietary doesn't matter in our hardware buying decisions: 20
We prefer proprietary drivers to GPL drivers: 0
That last one is there for the marketing guy at an “enterprise” hardware vendor who told me that the company's enterprise customers would never want GPL drivers for their GPL OS. Sounds like you need to get out and talk to the customers a little more, dude.
One support engineer at a popular enterprise distribution told me that his group has to support some proprietary drivers, but that when those drivers lead to support calls, the customers ask about alternative hardware with GPL drivers. With the Linux hardware market at more than $4 billion a year, letting your lawyers slap a restrictive license on your drivers could be an expensive mistake.
They Said It
At Parrs Wood OSS is seen not as merely a way of saving money, but rather of spending it more effectively.
—BBC News: news.bbc.co.uk/1/hi/education/4642461.stm
When I switched from Windows to GNU/Linux (Red Hat/Fedora/Debian mostly) about five years ago, I found a vast developer's playground. It was like the old days of Compuserve, which was a candy aisle of freeware. Free software is still like that for me; there's a lot of it to explore, and I can see the source code without significant restriction. I can use the source, and I can share the source...which is something geeks love to do. The Windows world by the mid-1990s was very closed (still is mostly), something that's really restrictive as a developer.
—Anonymous, on IT Garage: www.itgarage.com/?q=node/617#comment
You have reached the pinnacle of success as soon as you become uninterested in money, compliments or publicity.
—Thomas Wolfe, The Sun, July 2005
There is no such thing as a “personal” blog if you are employed.
Money can't buy happiness, but it can buy a Linux box.
—Jon Watson, www.jonwatson.ca/blog
If AOL ruled the world, they would slap training wheels on skateboards and charge kids $20/month to go slower and to be able to do fewer things.
—Tony Pierce, www.tonypierce.com/blog/2003_07_13_blogarc.htm
Today's laptops have become obese. Two-thirds of their software is used to manage the other third, which mostly does the same functions nine different ways.
—Nicolas Negroponte, laptop.media.mit.edu
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Interview with Patrick Volkerding
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide