This is one of the biggest Open Source events around. It’s really exciting to be part of this conference.
I plan on talking about how we at Etelos support and advocate open standards, open source developers, and the impact that is having on the industry.
So far, Vimeo looks awesome. Let’s see how far these people will go. I like them because they are much cleaner that YouTube, and they seem to be quality driven. Here is a sample.
I talked about the potential of Adobe Flex before, now the doors are open.
With the Flex SDK released as Open Source get ready to see the Flex OS. The underlaying OS will not matter, Flex will be it. It will take a long time, but people will eventually wake up to it.
Why am I so certain? the market will correct itself. Now Flex is the most appropriate thing to build a cross platform UI. It is as close as possible to the sexiness of OS X (close enough), and fully internet aware.
There is one person that I can think of who should be thanked for this, there maybe more folks but the most visible sane person at Adobe is Duane Nickull.
Last week Etelos rocked the planet and introduced Apps On a Plane (here is a video, check it out). We got so much press 
Every one we talked to was excited. Imagine, building a desktop application with PHP + a DB + Security
More to come from the Web 2.0 Expo, recovering still.
Maybe someone will create us a very good AOP Icon thx
Back in 2003, I wrote an article for Linux.com (or NewsForge.com, I forgot which, but they are the same outfit anyway). The article was titled, “Is RHN the right choice for your business?”. I basically questioned the sanity of paying 10 times more for a product that essentially was broken.
The article made it to the front page of Google News and many other sites. So at first I was pleased, and on virtually all sites, the comments were supportive and it seemed I hit a nerve.
Then I turned to Linux.com and NewsForge.com’s comments. And I was shocked, the comments were awful. My competence was questioned and I was virtually crucified. No rebuttals to what I was pointing out, just a “well if you don’t like it you are an idiot”-type of comments. That was a turn off.
It was to my delight (sorry ESR) that yesterday I came upon this gem titled “ESR gives up on Fedora”. I thought it was interesting that 4 years later, ESR comes to the same conclusion. But what’s more interesting, are the comments that followed. And some of these bozos didn’t even know who ESR was!
I should mark this post as Humor even though its real, but its just way too funny.
Thank you ESR for speaking up!
I believe this is one of the most destructive and under estimated bugs that inhibit devs (not code, but developers).
The outcome of over-engineering is heartbreaking on so many levels. Not only is the product destroyed, but resources are wasted, careers are ruined, and egos get crushed, in this case needlessly. But worst of all, this disease goes on undiagnosed decimating project after project.
I know I will get lambasted for saying this, but I honestly see this most (not all, most) with devs coming from a specific discipline. One that mainly uses a technology that starts with J and ends with AVA, referred to as J*** from here on.
Consider the following diagram to better understand what I’m noticing.
As I said, this behavior appears to manifest itself mainly within the J*** community. It is already an established fact (if it isn’t, I’m establishing it now) that computer languages and the characters of the devs using them are tightly woven and intertwined. To know a dev is to know his languages.
Case and point, I indirectly got involved in a project that had been in the works for about 8 months already. The requirement was the classical multi-data-sources that needed a single merged view. The solution that was proposed and worked on by your friendly neighborhood J*** dev was a central data warehouse that collects data from many sources into a single Mega-DB. Then that DB would provide that data by merging it chronologically.
In 8 months, work on plug-ins that connect to many different kinds of sources and protocols was about 50% done (to my knowledge). The client was very unhappy, after all that time there wan nothing to show yet.
I cannot take credit for this one, so I must give credit where credit is due. Danny (our CEO) was asked to look at the problem and suggest a solution. Three (3) days later, the site was up and the client was pleased to see data flowing.
So how did he do it? the answer was RSS!
It was very easy for any data source to provide the data in XML. Not just any XML, but RSS XML. Then using any plain RSS aggregator, data would be merged chronologically. No Mega-DB to build and maintain, no periodical data dumps, no plug-ins, and almost no code involved at all.
We did spend some time fixing up a PHP RSS aggregator and adding a search facility, but the solution was dripping of simplicity and elegance, it was art.
I have no idea why all those protocols were used before, I don’t know why they didn’t ask for a standard form of data from all sources, or if a Mega-DB was actually part of the requirement. Maybe there was more to it than what I was told, but it remains an example in my mind of how devastating over-engineering is.
I would advise that you at least be aware of the possibility that you may be committing over-engineering at any time. And be brave enough to re-evaluate your decision (another Agile Software Development principle).
I finally found the fix for the blue tint you get when using QCRenderer and QuickTime to export frames to a file.
On Intel Macs, you have to use
GL_UNSIGNED_INT_8_8_8_8
instead of
GL_UNSIGNED_INT_8_8_8_8_REV
In all of your OpenGL functions.
It makes sense since the the processor was switched from PPC to Intel. I would have thought Apple already took care of all these minor endian annoyances. Oh well, as long as I know what’s going on.
Some of these are not so cool, but some are way funny.
See more here.
If you try to install the latest UB Python + UB wxPython + UB py2app then build an app and package it, will break. The error I get is a couple of missing wxPython libraries in /usr/local/lib/wxPython*. Which is freaky because py2app should have taken care of that. Anyway, I’m doing this fix manually now. I added the following two lines to my build scripts for EDE4
install_name_tool -change /usr/local/lib/wxPython-unicode-2.6.3.3/lib/libwx_macud-2.6.0.dylib @executable_path/../Frameworks/libwx_macud-2.6.0.dylib "dist/Etelos Development Environment.app/Contents/Frameworks/libwx_macud_gizmos-2.6.0.dylib"
install_name_tool -change /usr/local/lib/wxPython-unicode-2.6.3.3/lib/libwx_macud-2.6.0.dylib @executable_path/../Frameworks/libwx_macud-2.6.0.dylib "dist/Etelos Development Environment.app/Contents/Frameworks/libwx_macud_stc-2.6.0.dylib"
A while ago I actually got this combination to work. I re-did the whole setup once, so I wanted to put some details up here.
I must say the only pain I got was from the DishNetwork receivers. I got them to hand over two 301 receivers. They were pushing real hard for their own PVR which I did not want. So they actually charged me $5 extra everymonth because I had an extra receiver.
As you may know, I’m a big Gentoo fan so what else would I be running. Nothing special here, just compiled the kernel 2.6.15-gentoo-r1 with the following options (I also have a pcHDTV3000 in there, so some options are for that also).
Device Drivers->
Multimedia devices->
[*]Video For Linux
Video For Linux->
<*> BT848 Video For Linux
<*> Conexant 2388x (bt878 successor) support
<*> DVB/ATSC Support for cx2388x based TV cards
[*] Build all supported frontends for cx2388x based TV cards
<*> Add support for additional audio chipsets
<*> Add support for additional video chipsets
Digital Video Broadcasting Devices --->
[*] DVB For Linux
<*> DVB Core Support
<*> BT8xx based PCI cards
Here is my kernel config file if you need more details.
This is probably the simplist thing I had to do,
emerge ivtv ivtv-ptune
It gave me media-tv/ivtv-0.4.2 media-tv/ivtv-ptune-0.2.0_rc3. They still work out of the box.
If everything went Ok, you should have these two devices up and running.
/dev/v4l/video1
/dev/v4l/video2
Then I used ptune-ui.pl to adjust the input to S-Video. In MythTV-Setup when you add the Capture Card, add two cards both of type “MPEG2 Encoder card…”. Set the Video Device to each one of the above. Then set the Default Input to S-Video 0 for both cards. Nothing to it.
In the MythTV-Setup (4. Input) map your data feed to S-Video 0 on both cards. If you are not using S-Video, then all you have to do is select Tuner instead.
The hardware was simple, but getting the codes to work correctly with DishNetwork’s receivers was not cool. I’ll save you the trouble, go to this page to get the details. Follow the instructions to get mythtv-ledxmit working. Our only fix is for the multi-tuner-with-one-irblaster. So here goes.
After much trial and error and google searching, I got the perfect ledxmit.conf file. I set tuners in a stack, in the config file I created two remotes, TOP_TUNER and BOTTOM_TUNER. I think I set the top tuner to personality 9 and the bottom to 5. I honestly don’t remember. That just means you get to do some trial-and-error too
Next, I needed a script named /usr/local/bin/tune_dish_tuner that MythTV can use to change the channels. Here it is
#!/bin/sh
TS=`date +"%a %b %H:%M:%S"`
HN=`hostname`
echo "$TS $HN $TUNER_NAME: changing to channel $1" >> /var/log/ledxmitd.log
for digit in $(echo $1 | sed -e 's/./& /g'); do
/usr/local/lirc-ledxmit/bin/ledxmit-irsend SEND_ONCE $TUNER_NAME $digit
sleep 0.2
done
TS=`date +"%a %b %H:%M:%S"`
echo "$TS $HN $TUNER_NAME: sending select" >> /var/log/ledxmitd.log
/usr/local/lirc-ledxmit/bin/ledxmit-irsend SEND_ONCE $TUNER_NAME select
sleep 0.2
/usr/local/lirc-ledxmit/bin/ledxmit-irsend SEND_ONCE $TUNER_NAME cancel
It dumps logs to /var/log/ledxmitd.log just so you know what its doing.
Then I created two scripts also, one for each tuner that call tune_dish_tuner. Here is /usr/local/bin/top_tuner
#!/bin/bash
export PATH=/usr/local/bin:$PATH
export TUNER_NAME=TOP_TUNER
tune_dish_tuner $1
And the /usr/local/bin/bottom_tuner
#!/bin/bash
export PATH=/usr/local/bin:$PATH
export TUNER_NAME=BOTTOM_TUNER
tune_dish_tuner $1
I ordered the IR Blaster, its really a very simple thingy. It worked with no problems. But, with a single transmitter LED, it was a probem.
I had some very nice dual LED transmitters from an old Sony-T60 Tivo (the best Tivo).
So this was a no brainer, I solderd the Tivo LEDs to the IR Blaster and it worked like a charm. Here are the pics.
Changing the channels is slow and choppy, you will feel every digit as it’s being sent to the receiver and it sucks.
For a remote control, I used an IR keyboard I found at the office and a $19 learning remote. No lircd mess for me.
Well, that’s it, I hope this helps. I must say I switched over to plain non-digital cable and used the PVR-500 tuners instead, it works MUCH better. The only reason I wanted DishNetwork was because they had Bridges-TV and no one else did. But I couldn’t take it anymore.
