Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Bundabrg

Pages: [1] 2 3 ... 13
Zaurus - pdaXrom / Swap Security Issues
« on: January 09, 2007, 08:47:19 pm »
I'd have to say that considering your Z, which is used by you alone and not a multi-user system, it is probably fairly safe from this sort of attack.

Perhaps an option is to have a script so that when the password app is run, swap is disabled (swapoff -a).

Most password managers will decrypt a single password (unless you select to view them all) and to 'forget' the decrypted password after a few seconds inactivity.

I've got an APM.d script that when I suspend, it will kill all password programs first.

 - Bundabrg

Zaurus - pdaXrom / "ghosting" Caused By R121?
« on: November 01, 2006, 02:43:20 am »
I've got a thread somewhere about this. Definately try adjust those values. One of the steps of installing was to do a NAND erase, which resets these values.

Zaurus - pdaXrom / Gtodo2
« on: August 23, 2006, 12:43:07 am »
Nicely done Chero.

Anything special you needed to do to get it compiled? I might just package it as a BB as well.

Zaurus - pdaXrom / Pdax And Gps Navigation
« on: August 18, 2006, 10:39:07 am »
I've been toying with gpsdrive, and admittedly I'm extremely new to GPS and equiv software ;-). However I have to admit that gpsdrive is limited in some ways, but the fact I can use googlemaps to download sat images, gov_au to download much closer detail images means I have good images even outside of town (ok, sat images are not great to navigate by but it looks cool).

I suspect though that anything called 'qpe'-blah requires qtopia or opie which may be difficult if not impossible to run under X.

Zaurus - pdaXrom / Qtopia Programs On Pdaxrom?
« on: August 17, 2006, 08:12:19 pm »
You would need to recompile it (if possible) for X. The sharp binary and indeed any gui app for Cacko or sharp uses QTopia or Opie to display.
My understanding is that QTopia/Opie apps can not display under X and vice versa.

Zaurus - pdaXrom / Trying To Reflash My Zaurus
« on: August 10, 2006, 05:57:39 pm »
Burned inside the Zaurus.

Does this simply mean it won't charge, or it won't even detect a charger? When I reversed the polarity on my Z, it wouldn't charge, but I could still plug in a charger to flash it (It still detected a charger).

 - Bundabrg

Zaurus - pdaXrom / Pdaxrom Development
« on: July 23, 2006, 10:46:28 pm »
Dear Bundabrg, koen, knopsis and papercrane,

I found it AMUSING that you guys are always hanging around in Pdaxrom
discussion talking about how great OZ is. OZ is no doubt, great, but why
would you guys try to push it so much around here ??

And you guys, when given a chance, always bashs pdaxrom.

It seemed that OZ is so well developed that you guys have so much time ??



[div align=\"right\"][a href=\"index.php?act=findpost&pid=136203\"][{POST_SNAPBACK}][/a][/div]

Hi Felix,

I actually run pdaXrom so theres a good reason I'm in this forum ;-)

 - Bundabrg

Zaurus - pdaXrom / Pdaxrom Development
« on: July 23, 2006, 10:45:30 pm »
i think pdaxrom-builder is much easier to hack than OE..
[div align=\"right\"][a href=\"index.php?act=findpost&pid=136021\"][{POST_SNAPBACK}][/a][/div]

It probably is ... but serious software devs don't want hacks. If I hack up something to build in that environment, how much confidence do I have that it will build in the next version? How easy is it for me to get it committed to the software baseline so that it will be automatically built by someone other than me every time a new ROM version is released? How much do I have to tweak my "hacks" when a new upstream release comes out?

[div align=\"right\"][a href=\"index.php?act=findpost&pid=136199\"][{POST_SNAPBACK}][/a][/div]

I think you hit it right on the head with this part of the quote: -
How easy is it for me to get it committed to the software baseline so that it will be automatically built by someone other than me every time a new ROM version is released?

Having a package compiled, by someone else who is not necesarilly familiar with the package, or automatically on each new release is very important. As I mention in my first post, it means that as a developer I'm more inclined to package it in the first place since I know it will live longer and if I get sick of the whole thing, someone else doesn't have to go through what I did to create the package in the first place.

 - Bundabrg

Zaurus - pdaXrom / Pdaxrom Development
« on: July 23, 2006, 10:41:33 pm »
I think that post is one of the most rational and balanced I've read here for a while. It correctly sums up the issues and position and puts things very well - nice one!

ehe, just a little fact is missing though, that sashz do use a tool to build pdaxrom
[div align=\"right\"][a href=\"index.php?act=findpost&pid=136019\"][{POST_SNAPBACK}][/a][/div]

I wasn't aware of that tool. I'll investigate further. If it mitigates the risks I've posted then thats great, and if it allows one to create package creation dependencies etc, then excellent.

I just assumed everyone just used the native or the cross-tool-chain to create packages, which loses how the package was created, what patches, the source code etc...

 - Bundabrg

Zaurus - pdaXrom / Pdaxrom Development
« on: July 23, 2006, 10:37:45 pm »
What do other developers and users think? This is NOT a flame starter and NOT a this-rom is better than that-rom thread! It is simply my concern that I wish to express!
[div align=\"right\"][a href=\"index.php?act=findpost&pid=135929\"][{POST_SNAPBACK}][/a][/div]


-------- snip 8< ---------------

I agree that it could be beneficial for pdaXrom to switch to the OE build system. But I find myself asking a more fundamental question as a software developer: why do I still want pdaXrom? That may sound like a troll, but it's not meant to be. When I left the Cacko ROM I chose pdaXrom over OZ for some specific reasons: mainly that the kernel was compatible (mostly) with the Sharp ROM kernel and the development tools (gcc) were compatible with Sharp SDK versions. But lately pdaXrom has been going down the OZ path ... first with soft-float that broke binary compatibility with Sharp ROMs and now with a completely custom 2.6 kernel.

Now, there are very good justifications for adopting those technologies, but it doesn't change the fact that if I'm going to run something that breaks all compatibility with the Sharp ROM, why not just run OZ/GPE? With OZ/GPE I get basically the same functionality plus a bigger developer community, a very sophisticated software build system, and a (relatively) consistant stable release across all Zaurus models.

------- snip 8< --------------------

[div align=\"right\"][a href=\"index.php?act=findpost&pid=136018\"][{POST_SNAPBACK}][/a][/div]

I don't wish to debate OS's in this thread, and I know you are not either. One could say why 'Debian' and 'Ubuntu'? Why Redhat and Fedora? Why slackware?
The simple fact is that there ARE lots of people using pdaXrom, and lots of people using OZ/GPE. And whilst both projects are active (using whatever builder), there always will be.

As a developer, it really doesn't matter what OS you run. The users will choose their OS _they_ like, and by god they will defend it to the death ;-) And I respect that!

However, what it boils down to really is, as a developer, when I add a package, I would prefer that same package to ultimately be useful for more OS's than less. It shouldn't matter what OS I use, but if I create a package, sure it's not going to necessarily be binary compatible on different OS's (Try ubuntu debs versus debian debs. You reach dependency hell quite quickly), BUT how the package is created being standard would be extremely useful. Thats why I advocate OE as the .bb recipe files could VERY easily be used with minor-to-no modifications between dists, BUT the dists themselves could be quite seperate. It also means MUCH less duplication of work so BOTH (or more if anyone creates a new) dists can grow faster.

I do wish to add though that though I mention OE, my main aim is to raise awareness of getting rid of the risks in the first post. I myself don't know the politics of OE itself and that may be a factor, but it seems to me that it would be relatively simple to create a new branch or if there is politics in creating the new branch (I don't know who hands out the keys to where it is currently hosted ;-) then it seems that it would be relatively simple to duplicate OE to a different server and build the branch there.

 - Bundabrg

Zaurus - pdaXrom / Pdaxrom Development
« on: July 20, 2006, 10:34:50 pm »
Hi All,

I'd like to discuss a few things that I think are basically some inherent weaknesses in pdaXrom, or rather its development philosophy. Please don't get me wrong as I actually quite like pdaXrom and I think there’s been an exceptional amount of good work put into it by the developer(s), and I must also applaud those who package and contribute applications. You just need to look at to see the amount of good work put in.

However my concern is that the design of pdaXrom currently prohibits its expansibility and has some pretty big risks.

What are some of the big questions that are always asked in the forums? They are things like this: -
  - Where do I find the feed for (some older version)?
  - Please could someone port app from (newer/older) feed to (older/newer) feed?
  - Where can I find (appname)? It used to be here, but its not here any more.

Currently, from my perspective, an image of a version of pdaXrom is released periodically through the efforts of sashz and Laze. These may or may not work with existing feeds (including contributed ones), and generally kind developers on the forums scramble to ensure that packages they've released still work and still have the proper dependencies etc..

My worry is that this process has the following flaws: -
  - The 'hit by the bus' issue - What if a core developer disappears/gets sick of the project. What happens to the project? Is it capable of surviving? What happens if sashz is burned out and feels that he is obligated now to keep developing since everyone is depending on him? That’s quite a bit of stress!
  - Effort to create a package - There seems to be a lot of effort needed to generate packages. Once generated, people are reluctant to necessarily update these packages unless they are actively using them as they need to almost reproduce the effort to create it in the first place unless they're smart enough to keep good logs or have a good make script.
  - Effort to create a public package - Due to the above point, it’s possible that people who could package something for the public may decide against doing it as the effort may only work for the current release of the 'rom'.
  - Lost Compiling Information/Source code - How someone packaged something (including patches) seems to be lost. This actually breaks GPL. It also means that should this person be 'hit by a bus' etc.. someone else has to re-work out how to package the app.
  - Old Version Maintenance - Old versions. Most distributions will 'backport' fixes to old versions for a period of time. Currently as soon as a release is made in pdaXrom, the old feed is 'frozen' and it used to be lost. I'm talking about non-core feeds here as well (i.e. contributed ones that may/may not with other versions of pdaXrom). No back porting is really done.
  - Dependancy Change Issue - If a major library changes (IE, say libc, glibc or something everything depends on), too many contributed packages will break! Same old story, who will go through the steps to repackage them (talking about contributed as well as core feeds)? In fact, it may take a while before someone realises the package doesn't work if it’s not too popular a package.

I really don't wish to see a project like this die because of one of these flaws. Something that most distributions have is the following: -
  - Version control with full logging and accessible access to the code. All of it!
  - A method of generating a new feed (by compiling everything based on rules/recipes) when new versions that may break old feeds come out

The advantages, especially of the latter point are: -
  - Rule based packaging - If I want to package something, I create a recipe/rule for it safe in the knowledge that most likely this same rule/recipe will work to recompile the package for future versions. I can submit this somewhere and know that someone else can run the 'rule' and get a package. This takes lots of things out of the equation
  - Effort expended only once - Because I only really have to use the effort once to create the rule/recipe I'm more likely to create packages. If I'm bored, I'll just randomly pick one and create it. Then forever more that package (possibly with minor tweaks to the rule/recipe) will be available.

What I'm describing as most of you may already know is already provided in the OpenEmbedded framework. I realise there has also be friendly (and some unfriendly) rivalry between OpenZaurus and pdaXrom, but I think that no one can disagree that OpenEmbedded does a pretty good job and takes a lot of risk away. I'm not saying this is the only way, but a lot of the work is already done here.

I decided the other day to backup my pdaXrom installation, install OZ/GPE and try out OpenEmbedded to compile things. I haven’t before because its scary learning something new and I'd heard that OpenEmbedded was a bit difficult. I took my time tracking app (Gtimer) that I use (and normally use in a debian chroot) as my challenge to package. It’s a bit of a complicated package in that debian provides quite a big patch for it (the author no longer maintains it), it’s still packaged for the older debian system (IE, the original_tar is a tar of a tar.bz2) and uses libgtk1.2. It took me 30 minutes to work out how to use OpenEmbedded (to compile nano as an example...), then 1 hour to muddle my way through to create a recipe that downloads, extracts, patches, compiles and packages gtimer (and the end recipe is only 14 lines long!!). I can submit this and know that gtimer will always be around now (since the whole feed is compiled for each version), and if I get 'hit by a bus', someone else surely can fix a 14 line file. And someone will KNOW it breaks because the WHOLE feed is compiled every version and non-compiling packages will be flagged. I also don't have to figure out how to create a tool-chain or any of the dependency libraries as they are compiled by OE automatically as part of creating my package.

What I would like to ask is if pdaXrom developers please (please!) could seriously consider using this valuable tool (or an equivalent if it exists). You can (and probably should) have a totally separate 'branch' from OpenZaurus dedicated to the pdaXrom style that people could contribute recipes to... and it also means that probably with minimal tweaking, rules can be take from the '.dev' and '.oz354x' branches and vice versa. It means that you're still 'separate' but that everyone can contribute and maintain what is a very good OS.

What do other developers and users think? This is NOT a flame starter and NOT a this-rom is better than that-rom thread! It is simply my concern that I wish to express!

 - Bundabrg

Angstrom & OpenZaurus / Keylaunch And Keylaunchrc
« on: July 18, 2006, 12:46:04 am »
(Presumably some if not most of the things keylauncher does can be done by matchbox itself... Any way to map the Fn in matchbox?)

Mine is currently: -
Code: [Select]
# keylaunchrc - Created 2006, BundaBRG (slc860)

# Format: -
#  key={flag}[{option} ]{key}[ {key2}][:-]:[~]{command}

# Brightness Control (fn+3, fn+4)
key=...* down
key=...* up

# Virtual Terminals (ctrl+alt+#) (doesnt work)
key=*.*.1:~chvt 1
key=*.*.2:~chvt 2
key=*.*.3:~chvt 3
key=*.*.4:~chvt 4
key=*.*.5:~chvt 5
key=*.*.6:~chvt 6
key=*.*.7:~chvt 7
key=*.*.8:~chvt 8
key=*.*.9:~chvt 9
key=*.*.0:~chvt 10

# Calendar Hotkey

# Address Hotkey

# Email Hotkey

# Home Hotkey

# Menu Hotkey
key=....F11:~matchbox-remote -menu
key=...*F11:~matchbox-remote -panel-toggle

# Above Home Silkscreen

# Home Silkscreen up

# Between Home/Email Silkscreen

# Email Silkscreen down

# Between Email/Contacts Silkscreen

# Contacts Silkscreen

# Between Contacts/Calendar Silkscreen

# Calendar Silkscreen

# Between Calendar/EJ
# don't know

# E/J Silkscreen
key=....F19:~matchbox-remote -panel-toggle

# Below E/J Silkscreen
# don't know

Angstrom & OpenZaurus / Keylaunch And Keylaunchrc
« on: July 17, 2006, 05:18:52 am »
Ok, I've searched everywhere and simply can't find documentation on keylaunch. So I've pulled apart the code and worked it out. To save someone else the same frustration, here are my notes.

Firstly, for those who don't know, keylaunch is used to bind 'commands' to hotkeys. For example, pressing 'Calendar' can load Calendar, and pressing 'Fn 3' can lower the brightness.

Keylaunch uses /etc/keylaunchrc, and can also be (overridden? in addition?) by ~/.keylaunchrc.

A typical keylaunchrc may look like this: -
Code: [Select]
# Comment

key=...*1:chvt 1
key=....Released F9:anothercommand

Each line has the following format ([]'s means optional. {} means its a variable):
Code: [Select]
key={flag}[{option} ]{keyname}[ {combinekeyname}][:-]:[~]{command}

Lets look at each bit seperately: -
key= - This is always the same.

{flag} - 4 characters, normally ....
 - Each character corresponds to a modifier. If the modifier is pressed at the same time, then this key will be triggered. IE, Control + 1 can give a chvt 1.
 - If the FIRST character is '?', then all the flags are ignored, and it will trigger on ANY modifier
 - OTHERWISE, each character can be '.' (not selected) or '*' (selected), and the modifiers are as follows: -
*... - Control
.*.. - Shift
..*. - Alt
...* - Fn
 - I'm pretty sure you can have more than one modifier.

[{option} ] - Optional Option. Note the SPACE afterwards if used!
  - This dictates on what event the key must trigger. If you don't specify an option it assumes when the key is pressed.
  - The events can be one of the following: -
Pressed - Occurs when the key is pressed
Released - Occurs when the key is released
Held - Occurs if the key is held for a bit
Combine - Occurs when you press TWO keys (IE Calendar+AddressBook} You MUST provide {combinekeyname}.
  - Don't forget the space!!!

{keyname} - The name of the key to trigger on
  - The names are defined in /etc/

[ {combinekeyname}] - Iff (if and only if) the Combine option is used you specify a second key here.
  - Don't forget the space BEFORE this (ie, between key and combinekeyname}

[:-] - Try to raise an existing window
  - If this exists then when the key is triggered keylaunch will first see if there is already a running instance of the command, and if so, just bring it into focus.
  - If it is omitted, then it will load a new instance every time.

[~] - Disable startup notify
  - If this exists (IE, a tilda before the commandname), then startup notify will not be used. I think this means that you won't see the hourglass in the corner.

{command} - Command to run
  - What command to run.

Feel free to post your changes you've made to your keylaunchrc files. I'd be interested in getting some ideas.

 - Bundabrg

Angstrom & OpenZaurus / Opie/gpe
« on: July 09, 2006, 09:38:55 am »
Sorry, slightly more difficult than I thought. There is a 'queryvt' program around that I'm trying to compile for ARM that is supposed to tell you what VT you are on now. Once thats available hopefully it should be simple enough to script this up a bit...

 - Bundabrg

Pages: [1] 2 3 ... 13