MobileRead Forums - View Single Post - Scripts to move comics to Iliad e-ink reader

scotty1024 · 10-03-2006, 04:38 PM

What if iRex had hired scotty1024 to develop the iLiad via OSS, what would be different?

First off, my #1 priority would have been patches to X to produce an iLiad simulator. Right number of pixels X and Y, correct PPI if people cared, and the same API provided on the iLiad to trigger updates to the X display (think about it, how do they push the changes to the e-ink panel, somewhere in your code you call something that says "Update e-ink now" right???) A skin in the window with buttons to push with a mouse that produced the same events as the buttons on the iLiad.

Second, participation in Kernel/Minimo/xpdf development communities. I'd have developers assigned to participate in all those forums and get iLiad source checked in. No freakin' iLiad tar ball, but iLiad build paths that could be checked out and built by developers and used under the X simulator.

When people had feedback, and there would be far more people than just those with iLiads. After all, people could build the X code and run the iLiadian xpdf et al... My developers would work through the existing communities to process those suggestions into the code bases.

Instead of developers fruit-lessly bashing their skulls into desks and eeking out 5% to 10% improvements in power? I'd be kicking their metaphorical asses to get into the developer community and ask for help: "I'm trying to power down a XXXX but YYY is happening. Any one else seen that?"

I would have been leveraging the OSS community for as many man hours as I could mooch to help get the iLiad up to speed as quickly as possible. Bugzilla, Wiki, Subversion and a PHPBoard for my public developers... along with iLiad t-shirts, coasters, mugs and any other thing I could beg, borrow or steal out of the marketing department as a seducement for contributed code. Contribute enough significant items, I'd be going to management to ask for a free or subsidized iLiad for you.

I would have had maybe one kernel developer on ICE with the actual hardware. Application developers would have soft developer iLiad's with ROMulators and Desktops with the X simulator.

So no, no bugs for iRex, and I don't feel bad about that, I feel bad about what iRex could have done, and where we could have been today.

And I really don't feel they are the best people to be fixing other people's code at this point. After all, most of the code in the iLiad doesn't belong to iRex.

What I'd rather do when I find a bug is just check out the X simulator, the minimo code, and fix/submit the bug to the minimo project. Let iRex collect the new sources once every 2 or 3 months and push out a new OS release.

If you want to submit bugs to iRex, that's your choice.

10-03-2006, 04:38 PM	#19
scotty1024 Banned Posts: 1,300 Karma: 1479 Join Date: Jul 2006 Location: Peoples Republic of Washington Device: Reader / iPhone / Librie / Kindle	What if iRex had hired scotty1024 to develop the iLiad via OSS, what would be different? First off, my #1 priority would have been patches to X to produce an iLiad simulator. Right number of pixels X and Y, correct PPI if people cared, and the same API provided on the iLiad to trigger updates to the X display (think about it, how do they push the changes to the e-ink panel, somewhere in your code you call something that says "Update e-ink now" right???) A skin in the window with buttons to push with a mouse that produced the same events as the buttons on the iLiad. Second, participation in Kernel/Minimo/xpdf development communities. I'd have developers assigned to participate in all those forums and get iLiad source checked in. No freakin' iLiad tar ball, but iLiad build paths that could be checked out and built by developers and used under the X simulator. When people had feedback, and there would be far more people than just those with iLiads. After all, people could build the X code and run the iLiadian xpdf et al... My developers would work through the existing communities to process those suggestions into the code bases. Instead of developers fruit-lessly bashing their skulls into desks and eeking out 5% to 10% improvements in power? I'd be kicking their metaphorical asses to get into the developer community and ask for help: "I'm trying to power down a XXXX but YYY is happening. Any one else seen that?" I would have been leveraging the OSS community for as many man hours as I could mooch to help get the iLiad up to speed as quickly as possible. Bugzilla, Wiki, Subversion and a PHPBoard for my public developers... along with iLiad t-shirts, coasters, mugs and any other thing I could beg, borrow or steal out of the marketing department as a seducement for contributed code. Contribute enough significant items, I'd be going to management to ask for a free or subsidized iLiad for you. I would have had maybe one kernel developer on ICE with the actual hardware. Application developers would have soft developer iLiad's with ROMulators and Desktops with the X simulator. So no, no bugs for iRex, and I don't feel bad about that, I feel bad about what iRex could have done, and where we could have been today. And I really don't feel they are the best people to be fixing other people's code at this point. After all, most of the code in the iLiad doesn't belong to iRex. What I'd rather do when I find a bug is just check out the X simulator, the minimo code, and fix/submit the bug to the minimo project. Let iRex collect the new sources once every 2 or 3 months and push out a new OS release. If you want to submit bugs to iRex, that's your choice.