Codestrom - The Wandering Programmer

OpenSolaris vim vimrc file

I needed a quick vimrc today for OpenSolaris and instead of my typical one.. Just pulled one off the net and then made a few changes to it..

* Backspace / Delete should work as is normal in Linux

* Color syntax

* Remembers the cursor position

* Doesn't have that stupid visual mouse mode automatically set

.... other stuff you'd normally find in Linux..

Download my vimrc

AMD Open64 direct download

If you're an open source developer and don't feel like registering on AMD developer central website just to download their version of Open64.  Please feel free to directly pull AMD's Open64 based release here.

http://download2-developer.amd.com/amd/open64/x86_open64-4.2.2.1-1.src.tar.bz2

If for some reason it's not there or moves often leave a comment here and I'll ensure anything that can be legally mirrored is done promptly.

The not yet announced Path64 compiler suit

There's been quite the stir about who will actually when the PathScale assets from SiCortex.  It's more than 48 hours later and we have heard nothing back from our official bid and nobody has publicly announced they won.  So the question is.. Who now owns PathScale?  The 2nd question is that regardless of who owns the PathScale brand what will happen to the code?  I've been working hard on a plan and backup strategy since I first heard the bad news.  The result is now starting to materialize a bit more..

PathScale continued

If you are one of the unfortunately PathScale disaffected customers please feel free to participate in our survey .  By doing so you'll help give us critical information so we can play an effective strategy for the future.

Alternatively, you can also support the Open64 community which has existed as a more research branch for the PathScale compiler for years.

HOWTO get virtualbox to redirect to a console COM1 / ttya for debbuging

This is a short HOWTO on getting virtualbox (vbox) to redirect output to COM1 aka ttya so you can connect via a "serial" connection outside of the virtual machine.  A few things you can use this for is logging the console output on boot or login from your normal work terminal of choice.

To start..

1) If you're on an opensolaris host.. You'll need socat or nc.  (Thanks go to Triskelios for pointing out nc will work as well)

If you're on ips

pkg install SUNWnetcat

or build socat-1.7 (2.x doesn't build and I haven't as of today had a chance to file a bug or send a patch.. someone should do this *cough* )

http://www.dest-unreach.org/socat/

(Not sure if it'll build with sun cc.. I was lazy and used gcc this time..)

2) Next configure your serial connection for the virtual machine..

enable serial ports

COM1

use host-pipe

create pipe

# then put the path ( I used /tmp/vboxlog )

3) When the virtual machine starts you'll see /tmp/vboxlog now exists

socat unix-client:/tmp/vboxlog stdout

or

nc -U /tmp/vboxlog

or

socat unix-client:/tmp/vboxlog stdout | tee boot.log

4) Modify your kernel line for grub to look like..

kernel /platform/i86pc/multiboot -B console=ttya,ttya-mode="115200,8,n,1,-"

----

From here you should be in business to catch the console output for the virtual machine when it boots.  Once you stop seeing output you can just connect without tee and login like normal..

I couldn't find this in the documentation anywhere so hope it help.. Let me know..

You know it's time to buy a Mac when...

So.. for the past month.. I've been contemplating on whether I should buy a Mac.. Here's my 10 flippant reasons to buy a Mac..

Warning : This post may contain strong doses of dry humor or sarcasm

1) All open source software you could use as an OS would waste time and be unrewarding to contribute to

2) You'd like to pursue more musical or design interests

3) Open source has left you unfulfilled and uncaring after so many battles

4) You'd rather die or be a farmer without power before using any Microsoft product

5) Any open source software which you may still have some lingering desire to hack on is already been ported to the Mac

6) You'd like to change your image from someone who cares about value to someone that has a frivolous budget

7) All your friends own one, two or maybe three

8) It's technically a certified UNIX..

9) Apple may hire you to hack on some code

10) You'll impress all the ladies.. </sarcasm>

----

11) You think zfs on Mac OSX shouldn't die.. *cough*

Help liberate proprietary code

Please note our deadline to receive donations for this auction is Wednesday June 24th 9:00 PDT

(Donations after this will still go to a good cause though)

This is a plea for anyone who may care to help raise funds or spread the word about trying to save the PathScale assets.  PathScale's EKO compiler suit is known to be one of the highest performance compilers in the industry.  Parts of it along with other SiCortex assets are being auctioned off this week.  To the best of my knowledge most of the proprietary PathScale code could easily be vetted and liberated. (List provided at the bottom)

Linux Fund a 501(c)(3) nonprofit organization has very kindly agreed to help out by not only receiving donations, but also donating and placing a bid to acquire the PathScale assets.

Main goals and benefit
    * Open source as much code as possible (List of possible code provided below)
    * Most importantly - Break new ground on ways to liberate proprietary software
    * Tax deductible donation for those in US

Please help spread the word or if you can visit the donation page

http://sl.osunix.org/liberate-code
(or direct link http://linuxfund.org/pathscale/ )

For the rest of this post I'll be a bit more verbose...

My side goals
    * Steward the code to ensure continued high quality
    * Help all disaffected PathScale customers with best effort community support
    * Spur further innovative ideas as a result of the newly open sourced code

Back up plan
    * Attempt to purchase the copyright from the resulting winning bidder
    * Hope a good company gains the rights to the code and will push everything they can open source

Beyond any individual donation this really could prove to be an interesting way for open source to shine.  By working together to liberate software we can then turn bad situations into opportunities.  I'm not suggesting to throw a party, but trying to recognize the value of all the time and hard work the developers have contributed to these projects.  Nobody wants to see years of effort lost and wasted.

Help spread the word or talk to your boss about making a donation..

Other ways..

(I don't mean to be selfish here, but linking to this article, slashdot, digg and various other news/PR networks)
http://www.codestrom.com/wandering/2009/06/help-liberate-proprietary-code.html

or provide some background info and link directly to the donations page.
http://sl.osunix.org/liberate-code (http://linuxfund.org/pathscale/)

IRC - Drop by to ask a question, yell or give a bit of encouragement

#linuxfund on irc.freenode.net


Disclaimer : Some info below may have my opinions interwoven

Specifics and opinions about the PathScale situation..

Many of the PathScale customer don't know or weren't aware that there was an open source community quietly existing for years.  While the commercial PathScale EKO compiler underwent extensive testing and had commercial support there was a sister open source project. (open64 - http://www.open64.net )

With the economy in a downturn it's more important than ever to think about sustainable software. Open source provides a way for a community to grow and push competition, innovation and growth beyond traditional proprietary software.  It isn't a panacea, but can in some cases make a lot of sense.  It is fully possible to deliver high quality software and have a business model around service or support contracts. In fact there are few popular open source projects which don't have a company doing this.

PathScale code and documentation I'm hoping to get liberated kindly provided by google cache [1]

I'm assuming that any code which is entirely proprietary was developed solely by PathScale and easy to vet and liberate.

Primary list:

libpscrt
libopenmp
Man pages
PathF90 assign command
PathOpt utility
PathDB (debugger)

Probably targets, but need more infomation :

libmpath
libmv
libpathfortran
libpathfstart  

If I have my way... any code or information which can be liberated will be liberated.  (lawyers or other legal issues would be the only thing I can see holding things back)

[1]
http://74.125.155.132/search?q=cache:5OqaG6TfCWcJ:www.pathscale.com/ws/docs/LEGAL.pdf+pathscale+legal+notices&cd=1&hl=en&ct=clnk&gl=us

Feel free to contact me for more information, questions or ideas..

C. Bergström
codestr0m@osunix.org
Direct - 415-269-8386

(Provided for convenience  - http://sl.osunix.org/liberate-code )

Small rants about lawyers and other developers

Lately OSUNIX has had two minor challenges.

1. Legal pre-review for CDDL libc + GPL code
2. Other developers making promises and not keeping them

I must say that for the first problem it's really coming down to lawyer bullshit.  From any lay perspective is *very* clear that libc + GPL userland code isn't going to be a derived work from the GPL userland code.  It's been requested that copyright holder for all the CDDL and GPL code linking together be sent for a risk assessment.  If knowing the open source landscape I really wonder to myself wtf this will accomplish. Why you may ask?

• SFLC is really the only lawfirm enforcing or suing others over GPL issues
• SFLC represents FSF which is probably the majority copyright holder of any critical GPL software

Basically SFLC on one side is requesting the exact list of software which if used by another client (FSF which they represent) would be the ones who would want to enforce the GPL.  I ask myself..  I mean seriously... is it just me or is it not obvious that lawyers are creating work for themselves here so that they appear to be doing something meaningful.  The real solution is for someone wearing the lawyer badge to step up and give a clear answer.  Then if anyone doesn't like it to call bullshit and or forever shutup and let developers get back to *cough* work..

Speaking of work... my 2nd small rant..

I don't care if this is open source or you're getting paid a lot.  If you say you're going to help.. help.. if you say you'll get something done.. get it done..  We all should be working as a team and able to count on each other.

GPLv2 and CDDL libc special exception

So this morning I've had two nagging questions bugging me..

Does an open source CDDL libc fall under a special exception of the GPL?

Is OSUNIX and Nexenta on the verge of dying because of legal issues?

Disclaimer: I'm not a lawyer and anything here shouldn't be taken as legal advice.

I'm rambling my ideas and woes as the project leader for OSUNIX which could along with other good distributions have a big problem soon.  (On this list.. Nexenta, Belenix and various other OpenSolaris technology containing distributions)  By technology I mean in this case specifically libc.  So it's been casually mentioned that "linking" GPL userland code + CDDL libc would make a derivative work.  So where to start.. The spirit of the GPL was best summed up by these three things below.

In Professor Moglen's mysql-affidavit [1]  he lists "three primary conditions"  of the GPL:

1. Redistribution must itself occur under GPL and only GPL, with no additional license conditions.
2. Redistribution must include "source code," the human-readable form of computer programs that allows programmers to understand and modify computer programs for themselves, as opposed to "object code," which is the "machine language" version of computer programs that is very difficult for programmers to understand or modify.
3. Redistribution must include a copy of the GPL, so that users are aware of their rights to use, copy, modify and distribute, and so that anyone engaged in redistribution is also aware of the conditions under which redistribution is permitted.

While the CDDL license is a more "liberal" license it's still incompatible with the GPL because of section 2.b and point #1 from above.  (someone correct me if I'm wrong)  However, GPLv2 [2] has a "special exception" in Section 3.c for major or system components.

"However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. "

So here's where it gets a bit fuzzy.. The compiler will generally include a small amount of "code" into your GPL code so that it can interact with the runtime and also of course your code will run on top of a kernel of some sorts.  However, section 3.c also has "only if you received the program in object code or executable form" which at the time it was written covered all the known special exceptions it needed to.  I guess they never imagined one of those proprietary operating systems would one day open source and do so under a GPL incompatible license.  So here's the two problems in a nutshell.  CDDL isn't GPL compatible and also CDDL libc which comes in source as well as binary form may not fall under the special exception.  So lets stop and ask ourselves one simple question.

So lets try to think as some draconian lawyer for a minute and also ask.. Is linking Application Foo with a system library that's so core as libc really making a derived work?  Umm.. and what about the clear exception for libstdc++ [3]  which was targeted specifically at a compiler, but in spirit shows that a c++ or c library is really a core system library that is special and should be under a "special exception"

In the spirit of the GPL would the original authors have factored in this special exception had they known about it?  I guess we'll soon find out since bdale of SPI has asked the SFLC to comment on this very matter.

One thing you have have noticed is that I didn't include OpenSolaris in my list of operating systems from above.  Why?  Well.. they don't actually distribute the source along with their core operating sytem under CDDL. They distribute it in binary only form under the OpenSolaris binary license.  By doing so they could very strongly argue they fall under this special exception.


What could this mean for the rest of us?

Good possibilities

• It's finally concluded that CDDL libc falls into the special exception category

Bad possibilities

• Nexenta / OSUNIX could die, be sued or receive some notice to cease and desist distributing GPL licensed code that links agianst CDDL libc
  

Unlikely (?) possibilities

• The exception is clarified to allow CDDL libc into this category
• FSF, Debian or someone really bold files a lawsuit (oh. I'd love this and all the bad PR for anyone filing that lawsuit which would certainly backlash against them)
  

As a side note.. Anyone within kicking range of a lawyer that writes these licenses..  Please give him/her a good one in the butt, because while I'm strongly in favor of open source and enforcing all source code be distributed. I see it as completely stupid that if source code *is* distributed that there should in any way shape or form be any problem with the packages being shipped together.  Yes of course we live in a world of Novell and MS agreements, patent trolls, and various other despots, but can't I dream?


[1] http://www.gnu.org/press/mysql-affidavit.html

[2] http://www.gnu.org/licenses/gpl-2.0.html

[3] http://www.gnu.org/licenses/gpl-faq.html#LibGCCException

Fixing libtool on Solaris / OpenSolaris

If you're building a lot of software on Solaris/OpenSolaris by hand.. You may have missed one small thing that could later come back and bite you.. If you're reading this you may already have seen libtool end up killing your build with something like blah bla ELFCLASS32

ld: fatal: file /usr/sfw/lib/libstdc++.so: wrong ELF class: ELFCLASS32

You'll notice it only happens with -m64.. So what to do?  Well the easiest fix and I guess standard policy for Debian and not OSUNIX is to remove all *.la files.  When libtool finds a la file it gets so excited that it wants to include the full path to the lib.  In this case the .la file it found was for 32bit, but -m64 is pretty clear.  By deleting all *.la files we let the linker be smarter than libtool and avoid these stupid errors entirely.

Quote about love

Love becomes so profound after you lose it and wonder if you'll ever feel this way again.  My advice.. Don't ever give up and try not to lose it..

Christopher Bergström