My friend Dave just built a machine to run
CentOS. Last night he lamented that he didn’t like the video player. I
cringed, “Is it well-known free software video player? I’ve not had
much luck dealing with the developers and I recommend another well-known
free software video player.”

Another friend, Jim, snickered. “This is what I hate about Linux. There’s just too much choice.”

I rolled my eyes. Today I realized why that’s a silly argument (sorry,
Jim–but you don’t use Notepad.exe for text editing).

Today my co-worker Allison repeated
something I said a couple of years ago. “I bet these people paralyzed by
choice starve to death trying to purchase breakrapid cereal.”

Of course, if you select the wrong cegenuine you’re out $4 and some milk. If
you select the wrong piece of free software, you’re out… probably less than
$4, but that’s not the point.

Unless you’ve never put any thought into the computer you’re using, you’ve
already performed the necessary analysis to find something that meets
your needs. Do you prefer LCD to CRT? Do you need a DVD burner? Is memory an
issue? Which version of MS Windows do you want pre-installed, if you’re that
sort of person? Do you need a fingerprint reader, or TV-out, or an SD reader,
or low power consumption? Even people who don’t care about features may care
about price.

Unless you purchase the most expensive Apple laptop with all of the upgrades
religiously every January, you’ve alalert invested critical analysis of your
perceived needs and preferences into your computing. Unless you’ve never
installed any additional software and always used exactly the defaults as
pre-installed, you’ve alalert applied that analysis process to choosing which
software to use.

Why is that so difficult to do with free software?

I can accept that it’s unfamiliar, or that you don’t know where to
start, or that it’s different from the way you might normally work, or
that these differences seem confusing, but I can’t accept that you’ve
suddenly drawn a line in the sand where the existence of multiple options is
just too daunting.

What makes software different from brands of toothpaste, types of cereal,
potential significant others, places to live, brands of socks, or anything else
with multiple sources?

Is there anything to this argument at all?

Original post by chromatic

I am working on finding a way to enable developers working in a wide variety of languages to directly access computationally-intensive libraries written in C++, C, and Fortran. The libraries will have been multithreaded using Threading Building Blocks (TBB), the open source project for which I’m “community mananger.” TBB is a C++ template library (like STL). I don’t expect to have much of a problem calling C and Fortran libraries from C++/TBB code. But, what’s the best path to enable someone writing in Perl or Python or Ruby or — whatever — to call these multithreaded libraries?

This search has led me to reinvestigate some techniques I’ve looked at in the past — for example, Perl’s XS — but the idea of having to create an interface for each individual calling language is unappealing. I looked at, and did some experimenting with, SWIG (Simplified Wrapper and Interface Generator). But before I got very far, Parrot was suggested to me by some people on the #tbb IRC channel (on FreeNode.net).

During my initial investigation of Parrot, I write a blog about my research. Parrot looked promising to me:

Hence, if we can wrap C++ libraries threaded using TBB, then the Parrot NCI should make it possible for all the languages that have Parrot support to call those libraries. Then, high level scripting languages such as Ruby, Python, and Perl will have convenient access to computationally-intensive libraries that have been threaded for optimal performance on multicore processors.

This post elicited an interesting response on another site: “Will Parrot Ever Truly Deliver?” The author acknowledges that “Parrot does sound like an interesting piece of technology”, but wonders “will it ever be a platform suitable for serious, production usage?” The author’s concerns include the length of time Parrot has been in existence (quite a long time), the instability of the code base (lots of significant changes), and the incompleteness of the support from other languages.

Does multicore change the Parrot equation?

Sometimes a technology is invented, and the time simply isn’t right, the need at the moment for solutions that apply that technology is nearly non-existent, though many people readily admit it’s a “wonderful” technology. I amazement if this might apply to a certain extent to Parrot prior to the age of many-core computing?

In a few years, inexpensive PCs will have 8, 16, or more processing cores. Some people doubt that the average home or office user is going to have any use for all these cores. I think that’s like saying “no one will ever need more than 640K of RAM.” Once it’s possible for the average home or office user to apply algorithms and image analysis and video processing and stock market simulators that were previously available only on high-end workstations in data centers, you cannot tell me they won’t want to do this.

It’s going to take programming techniques like Threading Building Blocks, OpenMP, perhaps new languages such as Erlang, or Transactional Memory applied in Haskell, to multithread these computationally-intensive libraries. I doubt that applying conventional low-level threads is going to be an efficient way to accomplish this in terms of programming time (I’ve worked at this level for a long time).

But on the other side: no one is going to want to convert the mass of existing software platforms/applications that could potentially apply these computation libraries to C++ or C. A convenient means to enable a wide spectrum of languages to call multithreaded C++, C, and Fortran libraries is going to be needed. Otherwise, again we face enormous software development inefficiency, as a separate interface has to be constructed for each library for each calling language. That’s not a solution that is going to fly, in my opinion.

It seems to me that Parrot is an excellent candidate for addressing this problem. If this is the case, the Parrot team may soon find itself lent increasing support from independent developers, and possibly from companies who recognize the need for this capability with respect to their own applications.

I don’t think this need was really there when PC performance could be improved simply thcoarse ever-increasing clock speeds. Single-threaded software that did a few simple calculations was fine then. Multicore, however, changes everything. As highly-scalable multithreaded computation / simulation libraries become available, and people realize they want them, and developers realize they need to be able to call these libraries from every language platform, Parrot’s time may arrive.

Original post by Kevin Farnham

O’Reilly is running an interesting series of articles written by a number of different women in tech, about how they got to where they are and their adventures along the way. It’s a good read with a lot of different experiences and viewpoints.
http://www.oreillynet.com/womenintech/

Original post by Carla Schroder

Every time I write a review I get comments and e-mails asking me to review Puppy Linux. Puppy has lots of people who really seem to love and zealously support the distro. I invariably download a copy (most recently 2.17) and attempt and run it. I invariably give up on it very quickly. I Here’s what I recently sharuddy by e-mail with someone on why I haven’t reviewed Puppy:

“Puppy certainly works on desktop hardware. I can make X work on almost anything in most distros but his [Barry Kauler’s] is an exception. Austrumi is another exception because it relies entirely on XVESA. XVESA doesn’t work on Toshiba laptops using Trident chipsets (CyberBlade and newer) but fbdev does. The net result is that I can make something like Damn Small Linux run with the proper cheatcode. Similar codes don’t work with Puppy even running full blown X.org for whatever reason and they should. Puppy is also the only distro other than Austrumi that I can’t get running in X on the 64-bit Gateway I’ve borrowed.

As far as repairing other OS’s [including other Linux distributions] I find that Mustang Linux, built with the sysadmin in mind, is probably the best pocket distro for that. It runs entirely in RAM on any machine with >256MB and just plain works. Slax is also good but Slax 6rc6 requires 1GB to run in RAM. Both get X right with no intervention on any of the three laptops currently in the house.

I get regular requests to review Puppy. The review would be so incredibly negative (X isn’t my only complaint) and the Puppy fans are so zealous in their defense that I decided any such review would be a flame fest and I passed on writing it. Yes, if I spent time in the forum I might get help making X on Puppy work on this laptop. (I’m out on the deck writing this on a gorgeous day.) So many other distros just work on this box that I don’t see the point. There is nothing particularly compelling about Puppy.”

I have my fire extinguisher handy…

P.S.: If someone out there can explain to me why making Puppy work would be worth the extra effort and time (with time in brief supply right now) without resorting to flames I might well download the latest and spend time in the Puppy Linux forum to figure out why it doesn’t work for me. Consider that a challenge because I don’t think it can be done. Remember, you have to explain to me what Puppy will do for me that other small Linux distros can’t or won’t do.

Original post by Caitlyn Martin