23 November 2008 - Software Engineering is not Computer Science

When I came to college two years ago, I intended to major in Computer Science. I looked forward to learning and being around people who shared my interest in computers. As I quickly found out, (1) there weren't any people here who shared my interest or even anyone who could speak the same language, and (2) the little bit of learning I would be doing in my computer science classes wasn't interesting to me at all. By the end of my first year, after attempting to discuss my feelings (read: disappointments) about the computer science curriculum and one professor specifically with the head of the department, I realized it wasn't going to change anything. If I wanted a computer science degree, I would sit in boring classes, be treated as if I weren't competent enough to possibly know how to program, and I would have to do my assignments in Ada. After a year searching for a silver lining around the Computer Science department, I switched to Physics -- which may have been the best decision possible if I wanted to do anything interesting with computers.

Initially, I entered college as a Pre-engineering major with the intention of later going to an Engineering school for a Computer Engineering degree. I took the same Physics classes as Physics majors, the same Computer Science classes as Computer Science majors, and the same (if not harder) Math classes as Math majors.

I knew from first class sign-up day that the Computer Science faculty expected all incoming students to have no programming experience, and moreover didn't care one bit if you did have any. Normally, you find someone with common interests, in this case programming, and you will talk to them about the common interest. Here, they treated me as if I was a know-nothing outsider.

My computer generated course schedule didn't include the introductory computer science class, which is the prerequisite of all higher level computer science courses. Not taking it meant waiting a full year to take any other computer science classes. It was entitled


It sounded silly, and after reading the course description out of the catalogue, I decided it was: binary arithmetic, how a computer works, and the use of editors and linkers in programming. Yes, editors and linkers. As if they are somehow closely related.

Unfortunately, it conflicted with my schedule entirely. Adding it would require that I drop and find new times to take two other classes.

I attempted to find a way out of taking this class, so I introduced myself to the head of the Computer Science department. I told him that I knew a few programming languages already (at this point, C, PHP, and x86 assembly) and asked if there was any way I could avoid taking this class but still be able to take higher level courses. He replied that he'd give me the final exam and that if I passed, I'd get credit. "OK" I said, "that sounds great." He got a strange look on his face and paused thoughtfully for a moment. He had been trying to call a bluff that wasn't there. He quickly withdrew the offer when he realized I was serious.

I was forced to rearrange my entire schedule before I'd even set foot in class to accommodate this entirely useless class. In this two-hour class, we literally spent eight class periods on binary numbers. It was a thorough waste of my time, and the frustrating part was that wasn't even the slightest acknowledgment from the professor. To him, I was just another idiot who couldn't comprehend zeros and ones. On top of that, there were no other students who felt like I did (To everyone else, this stuff was magic). The final question on the final exam which was the hardest from the entire class was an assignment to write code to add all the even numbers from 1 to 1000. I answered in x86 assembly.

Similar episodes occurred throughout the next two years. I also began to realize that the program wasn't Computer Science but rather Software Engineering. Learning to write fault tolerant, rock solid business applications in Ada, while useful, isn't interesting to the aspiring hardware engineer.

By the end of my freshman year I decided it would be a better use of my time and my parent's money to major in Physics. After all, in the same time it would take to complete the Pre-engineering and Computer Engineering degrees, I could complete a BS in Physics and a Masters of Computer Engineering.

I've been a Physics major for a year now, while still retaining a minor in computer science. In contrast to Computer Science, the Physics professors are helpful and responsive, treat students as intelligent creatures (even if they aren't), and are understanding if there's a course scheduling conflict, which mostly are due to, you guessed it, the Computer Science department not thinking of Physics and upper level Math students.

Best of all, I recently learned that one of my Physics professors has quite an interest in DEC hardware, including Alphas. He's even nice enough to find a cabinet to house my noisy AlphaServer DS20L in the Physics lab in the Science building.

Tags: compsci rant school

30 July 2008 - Licensing Prevents Old Code From Being Freed

As previously reported, it was possible that Compaq's long dead suite of compilers and libraries optimized for the Alpha processor may be released to the Linux community. With hand written and highly optimized code in hand, Alpha developers could improve integral software such as gcc and glibc. Unfortunately, it does not appear that the release of this code will be possible due to licensing issues.

Linda Knippers of HP replied to my follow-up email today and told me that due to a couple things, it would be very difficult to release the Alpha tools so that they would be of any use to Linux developers. Firstly, some of the code in the compiler suite is encumbered by a MIPS license. I can only speculate that this goes back to the days of the MIPS-powered DECstation. With licensing comes lawyers, and we know how expensive they can be. It's just not worth HP's time and money to figure out how to free this code, especially for little or no gain on their part.

Secondly, the compilers are written in BLISS. Yes. BLISS. Even if the code were freely available, it would be in a language virtually no one is familiar with. As an side note, BLISS was developed at Carnegie Mellon University, the same place that developed the Mach kernel upon which Digital's/Compaq's/HP's Tru64 is based.

On top of all this, it appears to the current HP developers that all the Alpha tools for Linux were built on OpenVMS, making it ever more difficult for Linux developers to build the code assuming they could (1) find a way around the licensing issues, and (2) find a BLISS compiler.

Long story short, it doesn't appear that Compaq's Alpha tools will ever be released. Rest in peace, proprietary code.

I'm unsure if Alpha optimized libraries such as libots or libcpml contain license encumbered code. I will certainly make an attempt to find out. If they do not, there may still be a chance that HP will release their source codes.

Tags: alpha linux

22 July 2008 - Alpha Linux's New Wiki Unveiled

When I bought a DS20L from eBay, I struggled to find helpful information. I sifted through Google search results, searched HP's website, read hundreds of posts on mailing lists, looked at Linux and BSD release notes, and searched everywhere I could think of. In the process, the one thing I discovered was that there was not a definitive spot for information on Alpha based computers, Alpha/Linux support, SRM versions, Alpha assembly and optimization, or Alpha software. Hopefully this new Alpha Linux Wiki will be that definitive spot.

I have been working behind the scenes with AlphaLinux.org's Peter Petrakis for the last two to three months to create a wiki to house the wealth of knowledge about the aforementioned topics in a central location. As you can see by the TODO page, there is quite a bit of content to be created. The wiki is in place, and I have written only a small fraction of what is needed. This is where we need you, the Alpha enthusiast, to add content and help make the wiki grow.

There are some things that I cannot add to the wiki even with an immense amount of research. In particular:

I sincerely hope that the Alpha community finds this resource helpful and makes good use of it.

On a related note, as many Alpha users know, this is the first time that AlphaLinux.org has been updated in years. We hope to change this by adding a forum and migrating the main site to a content management system. Peter Petrakis would like to use a Ruby based CMS, and I have no preference. If you have any suggestions, please let me know. Also, if you have suggestions of ideas for other ways to improve AlphaLinux.org I'm all ears.

Tags: alpha linux

18 July 2008 - Radeon X1550 in an SGI O2?

In a thread on the SGI Enthusiast site, Nekochan.net, about Linux compatibility with SGI's MIPS based line of workstations, a user, tillin9, suggested the possibility of installing modern, off the shelf graphics cards in the SGI O2 under Linux. The O2 is equipped with a single PCI slot for expansion, so physically installing a new graphics card is no problem. Unfortunately, graphics cards require special initialization code, stored in the card's ROM, to be run at boot time. Since the Radeon's initialization routine has to be able to execute on the processor architecture in the computer in which it's installed, different code is required for x86, PowerPC, PA-RISC, SPARC, and MIPS. Since there weren't any PCI Radeon's made for MIPS powered workstations, surely ten years later, a modern Radeon would never work in an old SGI workstation...

Linux support for SGI's MIPS systems isn't on par with other architectures such as AMD64 or even Alpha currently, mainly due to the lack of man power and programming documentation. For instance, SGI has never released any programming documentation on their IP35 line of workstations which includes the Fuel and Tezro. On top of this, there's the problem of being unable to initialize the Radeon. Given this information, I incorrectly thought this meant there was no chance of installing a PCI Radeon in an old O2.

tillin9 seemed to mention that the inclusion of Radeon kernel modesetting would alleviate the problem of initializing the card. I was skeptical, so I asked around on the #dri-devel and #xorg-devel channels on Freenode about the status of the Radeon kernel modesetting code. Davie Airlie of Red Hat, one of the developers responsible for R500 support among many other things, responded quickly.

<airlied> mattst88: we haven't got radeon modeseting written yet..
<airlied> it might make .28, but it more likely will be Fedora first.
<airlied> I'm writing it as fast as I can.

So, the code's not done. It is obviously a high priority from his response. I've never seen a developer say anything similar to I'm writing it as fast as I can. Hopefully it'll be included in the kernel for the 2.6.28 release which should be about 6 months away. If not, it should be included in 2.6.29 a few months later.

Now, this code isn't being written in order to allow alternative architecture enthusiasts to use nice 3D graphics cards in SGI workstations. It certainly would be a great side-effect though. Again, I asked on the appropriate IRC channels. Alex Deucher of AMD, one of the main developers of X.org's xf86-video-ati driver responded quickly to my query.

<mattst88> will radeon kernel modesetting allow the usage of a x86 PCI radeon in a sparc, hppa, or mips box even without a special ROM?
<agd5f> mattst88: it should

What an excellent unintended benefit of Radeon kernel modesetting. I mailed the xorg mailing list just to be sure. From this, Alex Deucher responded to me again and clarified. In short:

This feature, whose main purpose is to remove an unnecessary obstacle and provide a flicker-free boot up, will also allow many users of SPARC, PA-RISC, and MIPS computers to enjoy the features provided by a modern Radeon graphics card.

To tillin9: I'm sorry for doubting you. Thanks a lot for bringing the possibility of a Radeon X1550 equipped SGI O2 workstation to my attention.

Tags: kms linux mips radeon sgi xorg

16 July 2008 - Open Sourcing Compaq's Alpha Tools for Linux

I'm in the (long and arduous) process of becoming a Gentoo/Alpha developer. This involves, firstly, becoming an Architecture Tester. This in turn, requires that I complete a quiz, mail it to the head of the Alpha team and wait. The developer who manages the alpha arch testers, of which there are none, currently, has been missing in action for 18 days.

Once I prove myself worthy, or whatnot, I'll then complete a longer version of the arch tester quiz. Once my quiz has been reviewed, I'll be mentored for 30 days. After this 30 day period, I'll officially be a Gentoo/Alpha developer.

At this point, I'll try to get Compaq's alpha compilers and libraries back into portage in one fashion or another. libots is already in portage. The math library, libcpml, whose value I showed will be next on my agenda. Compaq's C, C++, and FORTRAN compilers, having been unmaintained for years now, have quite a few incompatibilities with modern Linux distributions. I think the best course of action for these is to get them into a portage overlay.

Compaq's alpha optimized compilers, unmaintained and bit rotting, still hold a wealth of knowledge. Compaq's cc still produces code much better than gcc in certain cases. libcpml and libots have incredibly optimized routines for all sorts of common functions. It's such a shame for them to rot as they're doing now.

With this attitude, I emailed Linda Knippers of HP, who in some capacity orcestrated the AdvFS code release under the GPL.

Hi Linda,

There are a few tools and libraries Compaq/HP has provided for Alpha Linux in the past that have been totally unmaintained in the last few years but still hold great value and knowledge to the open source community. I'm emailing to (1) see if there's any possibility that they may be open sourced in the future, or (2) be directed to contact someone more appropriate.

The tools and libraries in question are Compaq's Alpha-Optimized C, C++, and FORTRAN compilers, libots, libcpml, libcxml, and ladebug. Other Tru64 tools that we Alpha Linux users would love to use include spike and pixie.

Do you know of any plans to release any code for any (hopefully all) of these products? It seems a shame to have them bit rot when GNU Compiler Developers could learn a thing or two from ccc, and when the GNU libc Developers could incorporate libcpml routines into their math library and so forth.

Thank you for your time,

Matt Turner

She kindly responded (9 minutes later!) and told me that although she didn't know of any plans to open source these products, that it may be something HP would consider. She forwarded my mail to a former Tru64 developer to get his thoughts.

While I don't have code in hand (yet), it appears that they are at minimum receptive to this idea. Hopefully in the near future we'll be reading through Digital/Compaq's code, learning more about alpha optimization, and implementing what we learn in gcc and glibc.

I'll definitely post back any new information I find out.

Tags: alpha gentoo linux

Previous 1 2 3 4 5