Re: spatial stuff detail

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
have a
security problem, not just servers or 'command line' tools.  A lot of
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
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
in the
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
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

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
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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]