Re: spatial stuff detail
- From: Guido Schimmels <guido schimmels freenet de>
- To: desktop-devel-list gnome org
- Subject: Re: spatial stuff detail
- Date: Tue, 23 Sep 2003 23:08:00 +0200
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 an obscure library doing a buffer overflow on reading an obscure
And then what? Please elaborate the remote exploit scenario. Local
exploits are irrelevant.
format. Or some library not handling /tmp correctly. ANY app can
security problem, not just servers or 'command line' tools. A lot of
things are found in shared libs and distros update those shared libs,
the apps. It's much faster to update say openssl then all the apps
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
file hooplah is exactly to make applications easy to find and install
right place in the menu without user interaction. You're putting the
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
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.
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,
make it impossible to make better categorization for distros and will
management headache. It works for proprietary systems because they
didly-squat instead of the piles of apps that free software systems
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
to, either you have the system look in all kinds of random places or
the apps do it). If you just whack the app without running some sort
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.
] [Thread Prev