Well then I disagree with your GF. No big deal

1) you can disable the blinken lights in /sbin/preinit
2) if your USB breaks *and* you brick it, then you cannot enable R&D anymore

To BROWSE the list, not do "manage". You can "manage" (add/remove/update) using apt-get perfectly OK (or do you use some kind "app store" in Linux?! - exactly).

If peterleinchen wants "to have a GUI for looking through" he can use the web browser, or apt-cache. Anyway, installing HAM or FAM could/should be an optional thing.

Currently, if I do:
# apt-get -s remove hildon-application-manager
it tells me it wants to delete:
dbbrowser
fiasco-image-update-ask
hildon-application-manager
kernel-power-flasher
kernel-power-settings
mobilehotspot
recovery-boot
u-boot-flasher

The problem is fiasco-image-update-ask (which kernel-power-flasher and u-boot-flasher require) as well as dbbrowser (why it depends on HAM escapes me, I think I'll remove it because of that..)

When I have time I'll see if I can fix/fake fiasco-image-update-ask (I don't want to lose u-boot or kernel-power) and do:

But before I do that I'll have a look at some stuff in /usr/libexec (ham-after-boot, ham-rescue.sh sound kinda scary)

OK, ham-rescue is run (if exists) from /etc/init.d/rcS. Looking at what it does I feel now 100% sure that I want to get rid of it.

Will report..

I did not know we can disable the kb lights in preinit (could you point me? Do not have at hand right now)!
(could be a good advice, but only to knowledgeable people ...)

Reading full repo in terminal is quite hard (even I am a 'terminalist' )
URl for app browsing?

but the very next line is
(may contain typos as I just typed that by hand)

Meaning you don't even need to patch /sbin/preinit but simply make sure this appears on /etc/pmconfig:

This way the kbd leds (sleep indicator) will be turned on but then immediately turned off.

e.g. http://maemo.org/packages/repository...el_free_armel/

Not very convenient, when we want to search something for keyword in package title, name, or description (long or short). Sure, one can use additional search engine of choice to format that, but then we're depending on two completely unnecessary web interfaces (web interface for repos, and any_random_search_engine, both can go down anytime without notice, with repos still working).

Also, one may want to apt-get update, then browse packages - comfortably - off-line, marking packages for installation as soon as internet is accessible again. I strongly dislike requirement to be constantly on-line.
****

Arien Stokowiec

For some reason this post had the highest density of stuff I wanted to reply to:

There's legitimate reasons to not run R&D mode. Honestly the only reason I've found in the long term to run it is when hardware bugs (the little internal capacity/batter doesn't charge, so if you let the battery discharge it starts to boot loop instead of actually charging when it gets bad enough - turning on R&D mode avoids that), or software bugs (on my first N900 it seemed that the watchdogs or the lifeguard reset killed stuff).

But besides that I happily ran without R&D mode on my N900s for a long while - I used to say everyone should be running it too, but honestly I don't really have strong reasons to advocate either way... but I kinda mellowed out with regard to that position over time.

Did you forget my rdmod utility? That'll turn your R&D mode on for you right on-device. (That said, right now that's only available in source form, possibly outdated source form, because I really suck at following through on my package compiling/uploading-to-repos plans.) Admittedly you need to be able to run commands as root... but now that everyone should have the ability to do on their devices.

Funny enough lots of people do, actually. You know, they're not exactly app stores, but they use the distro-provided GUI wrapper around the actual package managing stack.

Like 'fkdep', perhaps? (Another one of those projects which I need to get around to integrating some improvements on and pushing into the repos, as of a year now, but it's a basic shell script, should work on even a purely stock N900, and it will build 'fake' (empty) .debs for you, which you can then install. Like rdmod, it's in one of the few threads I started, so should be easy to find.)

How did this end up going?

Since I ended up commenting on this thread after it was dead for six months, figured I might as well post again to give it a thorough reply regarding the claimed merits of HAM's unique features:

I see that the big differences HAM has (vs. normal apt + dpkg) are:
1. Domains
2. Some recovery if interupted (battery falls out while updating or something)
3. Loose scriptability (independent of the underlying deb package system's preinst/postinst/prerm/postrm scripts)

I must admit, I think that point #2 is a good idea to some extent - though this is something that I think needs to be bounced around until it's well ironed out as an implementation on the upstream apt mailing list(s) or wherever they do their development decision-making, then pulled down from upstream. (I know apt / dpkg CAN try to fix broken packages, but in my experience it often doesn't know what to do when you tell it to: so I hope HAM's stuff is somehow better...)

Point #3 seems to have come from back when Nokia was planning on using Hildon (and Hildon Application Manager) as a more general-purpose tool, not as /only/ a wrapper for our apt/dpkg -based system. From the Hildon wiki page I see that they intended back in the day to use it on Symbian somehow as well. Such limited scriptability might be meritable in that context, but I don't see how it really adds anything of value to our Maemo 5 system - does any package we have even use that scriptability?

Finally, domains. This is a thing that I've seen get argued in-favor-of in this thread, almost as if it really makes things safer. For example:
And I can see that, yes, domains lower the attack surface slightly - this way, the packages that we know are /guaranteed/ to be on people's N900s are also packages that we can't /attack/ by uploading a similarly named package to extras*. Okay, fair enough.

But I don't think that that really gains us a lot. Sure, I can no longer sneak a malicious "hildon-application-manager" package into extras (but if I manage to hack into our infrastructure and just directly plop one of those into the (C)SSU repos, then HAM will still happily download and install it).

But if my modus-operandi is 'make an "updated" version of a package and sneak it into the repos' I am actually NOT realistically any more likely to be succesful if I use any other package name that I know is optional but most/many have installed.

Let's consider how packages get into the extras* repos:
0: We can trivially upload anything into extras-devel - last I checked you didn't even need to be the maintainer of the existing package. This is a pretty egregious security hole looming over everyone who regularly uses extras-devel (yes, you're not supposed to use extras-devel for day to day use, but we know people do, and we know there are legitimate reasons to)
1: Promoting from extras-devel to extras-testing is, last I checked, only the priviledge of the maintainer(s) of that package. Doable, but requires a lot more effort and windup time and preconditions for a would-be attacker.
2: Stuff only gets into extras when ten or so members of the mob that we are vote on it. We /hope/ that within the mob are competent people who /do/ watch the packages carefully, and who will vote down if there is something suspicious.

Obviously, #0 is pretty vulnerable to malicious packages, #1 is pretty easy to hit if you social-engineer right and put in the work (but now we're not in low-hanging-fruit territory), and #2 could certainly be hit if you put in even more work. There are improvements we could make across the board, which is a separate discussion we should really cover sometime soon in community meetings. I have no idea how packages get into the CSSU repos, never seen it written up, so I can't comment on that process.

But my point is that if you look at the above breakdown, sneaking a damaging package /under the name of an existing package/ is really not that easy - if the package exists in the repo already, you have to be its maintainer to get your malicious override of it out of extras-devel. And if we moved all of the system packages into the extras repository too, it would be similarly not easy to pull the same trick with them. It would be easier to sneak some system-library-named package down into extras now, simply because the namespace isn't already taken up. So part of the actual protection that HAM honoring Domains provides is self created by having (C)SSU packages in a separate repo.

Meanwhile, the actual risk of having people sneak malicious packages with the same name as 'updates' into the repos, is a deeper problem - if the chance of such sneakery is high, then the exact details of what package I do it through is irrelevant. It doesn't matter if I manage to get into position to do it with a 'system' package, or with a ubiquitous but not 'system' package, like openssh or bash or python.

In short, I can understand the benefit the HAM Domains thing brings - but I think that it is perhaps somewhat overestimated in value, and that just like having a separate system-packages repo at all, it is the product of Nokia's goals for our N900s as consumer products (to able to provide customer support, warranty, etc, on a stable set of software, rather than necessarily the best possible setup for a libre-ish phone). And I think the technically superior approach we ought to aim for in the future would be to have all the system packages in one main community repo along with all the 'extras' (I imagine using the same 'extras' repos, just renamed to something more general).

And completely independently of that we as a community ought to really try to refine how we secure the extras repos, and make another concerted go at improving the current workflow of getting stuff through the entire process - it could really use more polishing. (By the way, I think if the CSSU packages moved through the same process, especially if we made the process more effective, as the extras packages, then honestly I think that would be better in general: I think it would be nice for the CSSU to have that kind of feedback, but actually, it may even help motivate more of the community to take an active role in helping test software - we've always had a lack of motivation making things pile up at the extras/extras-testing barrier. Maybe is the CSSU moved through the same pipe people would feel more motivated to get involved, and while they did so, test and vote on another piece of software here or there...).

Actually, the number of votes required have been lowered quite some time ago, and now is only 6 "thumb up" votes and a week in testing. Considering, that most people vote for package when asked to - without doing ANY serious testing - it is trivial to sneak whatever you want to extras, if your intentions are malicious..

As for the rest, thanks for elaborately busting another myth about HAM "superiority".

/Estel

I think you will find it's still 10 actually.

Also there is no "myth busting", just a interesting discussion about HAM's superior features.

Really? Let's check out one at random.

"Package karma 10 out of 6".

Or another one:

"Package karma -1 out of 6".

Different voters have different effects on the voting threshold.
It's sort of broken as is much of the stuff around garage.
I believe it should be 10 "normal" votes or 6 votes if a dev or special garage member has voted. Now that most packages are realised by a small cluster of people and instantly voted up by the maintainer packages generally have a 6 threshold.

I have managed to enable promotion on many of the packages stuck in testing due to this.