Re: spatial stuff detail

[Guido Schimmels <guido schimmels freenet de>]

Am 23.09.2003 20:41:46 schrieb(en) George:
> On Tue, Sep 23, 2003 at 05:00:35PM +0200, Guido Schimmels wrote:
> > And security holes almost always only affect commandline tools and
> > popular shared libraries. How does a remote exploit for GIMP look
> like?
>
> Like an obscure library doing a buffer overflow on reading an obscure
> picture

And then what? Please elaborate the remote exploit scenario. Local  
exploits are irrelevant.


> format.  Or some library not handling /tmp correctly.  ANY app can
> have a
> security problem, not just servers or 'command line' tools.  A lot of
> times
> things are found in shared libs and distros update those shared libs,
> not all
> the apps.  It's much faster to update say openssl then all the apps
> that
> might use them.

I'm not talking about openssl. I'm talking about a 300M base system,  
which certainly does include openssl.

Again, 90% of libraries are used by not more than 1-3 apps.
And if you link a 100k library into a 10M executable, if the  
application has a security hole, with 99% probablity it will be inside  
the main executable. Or are libraries somehow magically more prone to  
bugs? Widely used libraries have more eyeballs to watch for security  
holes. But I'm not talking about those.


> You are most definately on crack.  The whole point of the recent
> .desktop
> file hooplah is exactly to make applications easy to find and install
> in the
> right place in the menu without user interaction.  You're putting the
> whole
> categorization back unto the user.

That must be why Gnome users for so long have whined about the state of  
menu-editing, because they have no interest at all to customize the  
menu. But users outside the corporate desktop obviously are irrelevant  
now. Nice sentiment.

> And you have suddenly two ways to
> start
> apps rather then one.

No you have __one__: The file-manager. You obviously never used the  
Finder or ROX-Filer. The start menu is redundant when you do it like  
that. Plain in simple.
And you don't need much categorisation either.
/Applications/Utilities
/Applications/Internet
Applications/Games
and the rest goes flat into /Applications. What's the point of digging  
through submenus all the time?

> Unless you make every app into an appdir,
> which
> will
> make it impossible to make better categorization for distros and will
> be a
> management headache.  It works for proprietary systems because they
> ship with
> didly-squat instead of the piles of apps that free software systems
> ship.

And if a distro ships with 100000 apps, what the hell does it matter  
for christs sake when you won't install them? The time when  
distributors thought it is a good idea to have 20 text-editors in the  
default install are long past, thankfully.

It works for the MacOS, so it can work for Gnome. How arrogant to think  
to know better. When I'm on crack, Apple usability engineers must be  
too. Only Gnome and Sun hackers have seen the light. Yeah right.

Before this turns into a flamewar. I'm getting a bit upside now and I  
really want to apollogize for that.
I'm not suggesting this for Gnome, because I know it is futile and  
reaches far beyond the scope of a X11 DE anyway.
When I joined the thread, I wanted to inform the Gnome community we are  
working on such a system and that it can be done, because I have  
already such an environment right here on my desktop (posting this from  
a relocatable Balsa appdir). That's all.
If we do a good job, we hope to make the Gnome developer platform more  
popular. That's why I'm posting here at all. In Europe, with the  
exception of Extremadura Gnome is pretty much irrelevant at this point.  
We want to change that.


> But lots of actual settings will be in many random places (because
> they have
> to, either you have the system look in all kinds of random places or
> you make
> the apps do it).  If you just whack the app without running some sort
> of
> post-uninstall script this won't be cleaned up.

I think I have explained that already. There are by far more advanced  
ways to handle help files than scrollkeeper.
It is true that registries don't go well along with appdirs. But there  
is no reason to design a system like that. Of course as Gnome over time  
is more and more based on such registry technologies, we have to find  
ways around them. Fortunately in case of scrollkeeper it is easy. Just  
get rid of it, as it serves no purpose anyway in our context.