Rik van Riel has doubled and doubled again the amount of RAM that can be directly addressed in the x86 64-bit architecture. The previous limit had been 244 bytes, or more than 17 terabytes. The new limit is 246 bytes, or more than 70 terabytes.
The Linux Pulse Per Second (LinuxPPS) Project has had to reset and restart, when Udo van den Heuvel asked why the code hadn't been accepted, and neither Andrew Morton nor Alan Cox could remember any of the objections anyone had against it. They both recommended resubmitting the patches, which at the very least would get the folks who still had problems with the code to speak up again. LinuxPPS is a project to provide a character-device-based API for communication between kernel space and userspace. Rudolfo Giometti took Alan and Andrew's advice a couple weeks later, submitting the core LinuxPPS code for inclusion—the idea being to get everyone signed off on the basic features before introducing any code that might be more controversial. He also pointed out that all previous objections had been fixed, or that the objectors already had agreed the fix could wait. So, it looks like a good thing that Udo asked about this initially, or the perfectly good code might be lingering still.
The XCEP motherboards from IskraTel now are supported in Linux, which is cool, because that motherboard is used in many particle accelerators throughout the world. Michael Abbot recently submitted patches adding this architecture, which runs an ARM XScale PXA255 CPU.
DebugFS soon may be configurable in much more powerful ways. Steven Rostedt has added a feature to enable tracing events defined in a whole directory tree. The previous version required that each event be enabled individually in its own directory. The current version recurses through all child directories, but it also allows users to chop off branches of that directory tree easily if they so desire. What's the cost of all this power? It's no longer easy to identify which tracing events are enabled and which are not, because an event may be controlled by configurations elsewhere in the directory tree. But, as Steven said during the discussion, the information is all there, and a script easily could identify all configured events. As far as the debate went, no one seemed to feel the cons outweighed the pros, so this probably will be accepted into the kernel in the near future.
One thing that doesn't happen often is a hardware vendor asking for advice from the Linux community about how to code its drivers. But, Atul Mukker from LSI Corporation recently did exactly that. He said LSI wanted to take a whole new approach to driver writing, in which it had operating-system-independent code at the core, with a thin layer of support for Linux, Windows and so on. And, he just wanted to know if anyone had any advice. Turns out several folks did—one of the main ones being Jeff Garzik. Jeff recommended Intel's networking drivers as excellent examples of good practice. He suggested modularizing the code so that each piece of hardware would have its own codebase, which also could be kept free of any operating-system-specific code. He also recommended keeping general-purpose code out of the driver entirely, where other drivers could use it more easily. The Application Binary Interface (ABI), Jeff said, also should remain consistent with other drivers already in the kernel. Any feature similar to something found elsewhere should imitate that other interface. Any features that were unique, on the other hand, could create whatever interface seemed best.
Moonlight is an open-source implementation of Microsoft's Silverlight. In case you're not familiar with Silverlight, it's a Web browser plugin that runs rich Internet applications. It provides features such as animation, audio/video playback and vector graphics.
Moonlight programming is done with any of the languages compatible with the Mono runtime environment. Among many others, these languages include C#, VB.NET and Python. Mono, of course, is a multiplatform implementation of ECMA's Common Language Infrastructure (CLI), aka the .NET environment.
A technical collaboration deal between Novell and Microsoft has provided Moonlight with access to Silverlight test suites and gives Moonlight users access to licensed media codecs for video and audio. Moonlight currently supplies stable support for Silverlight 1.0 and Alpha support for Silverlight 2.0.
Silverlight Pad Running on Moonlight (from www.mono-project.com)
In two days, I'll be the proud owner of a Kindle DX. That may seem a bit odd, considering how much I despise DRM. The real selling point for me, however, is that it will read PDF files natively, and in full size. As I was looking for the system requirements for the Kindle DX (naively thinking it might sport Linux support), I was amused to see the hardware requirements listed: none.
The Kindle is designed as a self-contained piece of hardware, never needing to connect to a computer. Because it actually mounts as a USB removable device, it will work just fine under Linux. But, more interesting for me is that it never needs to sync at all. And, that got me thinking about my other electronic devices. I have two smartphones that I never connect to a computer. They both have the ability to sync with a computer, but because they're connected to the Internet, I never have had the need to connect them directly to a computer.
Will hardware compatibility fade away into the past? It wouldn't be a bad thing, unless, of course, proprietary hardware drivers are replaced with proprietary network protocols. Luckily, Linux is king on the Internet, so we're much more likely to keep standards in place on-line than in the hands of Windows-savvy developers.
My Kindle DX might have the taint of DRM, but thankfully, it also has support for non-DRM files as well. Although it has support for the non-free Windows operating system, it also supports Linux. And heck, it will run just fine all by itself. I figure that's because it's running Linux as its underlying OS.
1. Percent of all waste that is e-waste: 2
2. Percent of the heavy metals in landfills that come from e-waste: 70
3. Number of separate elements found in e-waste: 38
4. Percent of e-waste bound for recycling that actually gets recycled: 20
5. Average number of electronic items purchased per American household per year: 24
6. Average number of books read per year by adults in the US: 4
7. Percent of adults in the US that read zero books per year: 25
8. Number of hours the average American spends watching TV per day: 4
9. Number of years spent watching TV during a 65-year life: 9
10. Average time someone in the US spends Web surfing each month: 27:38:58
11. Average time someone in France spends Web surfing each month: 19:16:28
12. Average time someone in Spain spends Web surfing each month: 17:52:43
13. Average time someone in the UK spends Web surfing each month: 17:36:55
14. Average time someone in Germany spends Web surfing each month: 17:00:35
15. Average time someone in Italy spends Web surfing each month: 15:02:36
16. Average time someone in Australia spends Web surfing each month: 14:30:16
17. Percent of local advertisers on search engines that choose not to renew: 50
18. Percent of local advertisers on advertising sites that choose not to renew: 60
19. US National Debt as of 06/08/09, 10:51:06am MST: $11,403,815,042,547.90
20. Change in the debt since last month's column: $152,944,501,331.18
1–3: EPA
4: Basel Convention
5: Consumer Electronics Association
6, 7: Washington Post
8: A.C. Nielsen Co.
9, 20: Math
10–16: Telegraph.co.uk
17, 18: The Business Insider
In the past, the Mac OS was a fairly unique entity, not having much in common with other OSes, such as Windows or UNIX, which made cross-platform work a bit convoluted. However, the advent of the latest incarnation of the Mac OS, called OS X or Darwin, provides a very comfortable alternative for Linux geeks. Because Darwin is based on BSD UNIX, it is possible to use POSIX-compliant applications on the Mac.
Apple provides a package called Xcode on its developer site. Xcode has the necessary tools for compiling programs on the Mac, and it includes a nice graphical IDE and lots of examples for developing applications for OS X. Xcode is based on the GNU toolset, providing tools like gcc, libtool, make and so on. That means, with Xcode, most command-line applications can be compiled and run on the Mac. So, a simple little hello world program:
#include <stdio.h>
#include <stdlib.h>
int main (int argc, char **argv) {
printf("Hello World\n");
}
compiles fine with gcc, giving you an executable that prints out “Hello World” on the command line. Basically, anything that is POSIX-compliant should compile and run with no issues.
Getting graphical programs to run can be a bit more involved. Mac OS X does provide an X server and all the standard development libraries you would need for a pure X11 application, like Xlib. However, none of the other standard libraries, like GTK or Qt, are available by default. You have to download, compile and install them yourself, which works fairly well, but you have to choose the correct configuration options and collect all the required dependencies. But, you shouldn't need to go through so much pain. Two projects in active development provide some form of package management for GNU software: Fink and MacPorts. Using these, getting and installing GNU software is as easy to do as it is with most Linux distros.
The Fink Project started in 2001 and is based on the Debian package management system, so you can use the Debian package tools like dpkg, dselect and apt-get, making it familiar for Debian-based distro users. Once the base installation is done, you can start to install packages. If you like a text-based manager, use dselect (Figure 1). If you prefer a graphical manager instead, use the following command to get synaptic (Figure 2):
sudo apt-get install synaptic
Using these applications, you can install many of the packages you are familiar with in Linux. The package count, at the time of this writing, is 10,872.
Figure 1. dselect Package Manager
Figure 2. synaptic Package Manager
However, not all packages are available as a binary install using these tools. For that class of packages, Fink installs them directly from source, compiling and installing on your Mac. So, for example, if you want to install gramps and do some genealogy work, execute the following:
sudo fink install gramps
Even installing from source, Fink deals well with dependency issues, because it still is based on the Debian package management system.
The MacPorts Project started in 2002 and models itself after the BSD port packaging system. Thus, you use the command to manage the packages on your system. Once you have done the base install, you can install other software packages simply by running the command:
sudo port install stellarium
Several graphical interfaces are available as well, such as Porticus. However, those typically are independent projects, as opposed to the Debian tools available in Fink. As such, their development cycle and behavior tend to be a bit more erratic and unstable than the older and more mature Debian tools. But still, they may be exactly what you're looking for if you prefer a graphical interface. Like the Fink Project, both binary packages and source packages are available. There are 5,829 packages available in the MacPorts Project.
Both projects provide access to the full wealth of open-source applications that has been available to Linux users, and the number of packages provided by both projects continues to grow.
Once you have one, or both, of these projects installed (they will coexist on your system), you will have all the tools necessary to do your own code development. I have used anjuta (Figure 3) on my MacBook to develop some small GNOME applications. These compile and run equally well on my MacBook and my Netbook running Ubuntu. Although there isn't binary compatibility between OS X and Linux, with source compatibility, it is (at least in theory) simply a matter of recompiling for the other system.
Figure 3. Anjuta IDE
Running Mac OS X code on Linux is not as easy as running Linux code on Mac OS X. The real stumbling block is the graphical interface called Quartz on the Mac OS. Although the kernel and most of the command-line tools have been released as open-source software, Quartz still is closed. At the time of this writing, I could not find any references to a reverse-engineered, open-source replacement for Quartz. So the only option available is running OS X inside a virtual machine. Although this is not technically running Mac applications on Linux, it does provide the ability to run OS X on a Linux box.
Apple Developer Connection: developer.apple.com
Open-Source Apple: www.opensource.apple.com
Fink Project: www.finkproject.org
MacPorts Project: www.macports.org
We're done with the first 80%, and well into the second 80%.
—Larry Wall, referring to Perl 6
Doing linear scans over an associative array is like trying to club someone to death with a loaded Uzi.
—Larry Wall
Getting information off the Internet is like taking a drink from a fire hydrant.
—Mitchell Kapor
Globalization, as defined by rich people like us, is a very nice thing...you are talking about the Internet, you are talking about cell phones, you are talking about computers. This doesn't affect two-thirds of the people of the world.
—Jimmy Carter
I don't have to write about the future. For most people, the present is enough like the future to be pretty scary.
—William Gibson
In Cyberspace, the First Amendment is a local ordinance.
—John Perry Barlow
On August 10, 2009, I'll be at a conference in Troy, Michigan, put on by the LTSP (Linux Terminal Server Project, www.ltsp.org) crew and their commercial company (www.disklessworkstations.com). The mini-conference is geared toward people considering thin-client computing for their network. My talk will be targeting education, as that's where I have the most experience.
One of the issues network administrators need to sort out is whether a decent thin client, which costs around $350, is worth the money when full-blown desktops can be purchased for a similar investment. As with most good questions, there's really not only one answer. Thankfully, LTSP is very flexible with the clients it supports, so whatever avenue is chosen, it usually works well. Some of the advantages of actual thin-client devices are:
Setup time is almost zero. The thin clients are designed to be unboxed and turned on.
Because modern thin clients have no moving parts, they very seldom break down and tend to use much less electricity compared to desktop machines.
Top-of-the-line thin clients have sufficient specs to support locally running applications, which takes load off the server without sacrificing ease of installation.
They look great.
There are some advantages to using full desktop machines as thin clients too, and it's possible they will be the better solution for a given install:
Older desktops often can be revitalized as thin clients. Although a 500MHz computer is too slow to be a decent workstation, it can make a very viable thin client.
Netbooks like the Eee PC can be used as thin clients and then used as notebook computers on the go. It makes for a slightly inconvenient desktop setup, but if mobility is important, it might be ideal for some situations.
It's easy to get older computers for free. Even with the disadvantages that come with using old hardware, it's hard to beat free.
Thankfully, with the flexibility of LTSP, any combination of thin clients can coexist in the same network. If you're looking for a great way to manage lots of client computers, the Linux Terminal Server Project might be exactly what you need. I know I couldn't do my job without it.
A few months back, Linux Journal had a live streaming show called, “Linux Journal Live”. It aired once a week and streamed via ustream.tv. One of the frustrating things about running the show was that it was very difficult to get the “studio” feel using Linux. As it happened, we ended up using a Macintosh computer and the freeware CamTwist in order to embed graphics, guest hosts and text.
If we ever resurrect the live show, now we'll be able to stream from our dearly beloved Linux, thanks to the open-source project, WebcamStudio (webcamstudio.sourceforge.net). WebcamStudio allows Linux users to stream Webcams, graphics, text and much more to sites like ustream.tv. If you've ever wanted to try your hand at a live show, be sure to check it out.
As we read this month's coverage of cross-platform development, I thought I'd weigh in on the Web development end of things. While I work toward a new-and-improved iteration of LinuxJournal.com, I must constantly consider the needs of users with widely varying operating system and browser configurations. LinuxJournal.com visitors are a technologically diverse bunch. As you might expect, the majority of our Web visitors view LinuxJournal.com with Firefox, but what may surprise you is that a slight majority of those Firefox users are browsing from a Windows machine. Linux and Firefox users are nipping at their heels though. What also may surprise you is the percentage of visitors browsing with some version of Internet Explorer. Granted, that percentage has decreased during the last couple years, but the most recent numbers show about 20% of traffic coming from IE users, down from around 30% a year ago. Other browsers like Chrome, Opera and Safari have a small but important constituent as well, which makes my job just a little more interesting. So, to all of you visiting us from a less-used browser, I am doing my very best to give you the same great experience as the Firefox majority, and to all of those using IE, well, you may drive me to drink. I still welcome you though, and I will do my best to accommodate!