5:46 p.m.
For the single end user that manages his /her own computer, it
doesn't matter how the add-on is deployed. In fact, there are
advantages to the way Firefox handles it. In an environment that is
managed by a "professional" , using the distribution package manager
for add-ons has many advantages.
As an administrator, I would prefer to control what Firefox and
Thunderbird add-ons my users have access to, and allow the system-
wide management tools to tell me what add-ons are installed and what
are the exact versions of those add-ons. Some add-on versions are
locked to a specific Firefox version. An administrator would take
that into account when rolling out updates. yum /rpm could bark if an
update to Firefox was attempted before an updated add-on was
available ( as long as the correct version requires were in the add-
on package ).
Code for self-application updates ( and add-on updates ) is IMHO
wasted effort since the code and infrastructure already exists in the
distro platform ( yum, rpm ). Only in the proprietary OS world do
applications need to re-invent the update wheel because the OS update
mechanism is closed to most application developers and is only
available to the OS vendor for its own applications. Having Firefox
update itself and its add-ons is a consequence of its deployment on
Windows. It is not necessarily the best way on Linux.
Charles Dostale
6:30 p.m.
New subject: sense of packaging firefox' addons?
chasd wrote:
For the single end user that manages his /her own computer, it
doesn't
matter how the add-on is deployed. In fact, there are advantages to the
way Firefox handles it. In an environment that is managed by a
"professional" , using the distribution package manager for add-ons has
many advantages.
As an administrator, I would prefer to control what Firefox and
Thunderbird add-ons my users have access to, and allow the system-wide
management tools to tell me what add-ons are installed and what are the
exact versions of those add-ons.
And most users would rather not wait for their administrator to get around to
their station to deploy a new addon they found out about, which is supposed to
make them more effective at doing their job rather than waste time trying to get
the IT guy to handle it. Most admins don't want to have the excess work of
building custom packages for those addons just to let the user test the addon..
only to find it is inadequate for their needs. You will not find an adequate
solution based only on system-wide installation for these addons unless the
users are simply denied any other option (i.e. not an effective way to deal with
the desktop user).
Some add-on versions are locked to a
specific Firefox version. An administrator would take that into account
when rolling out updates. yum /rpm could bark if an update to Firefox
was attempted before an updated add-on was available ( as long as the
correct version requires were in the add-on package ).
And if you updated firefox by its own update system it would warn you that the
update would break your extensions before it let you apply the update. I'm not
suggesting we do that, but the fact is that upstream has done that work so it is
not wasted effort (it already exists). The extra work is in fact creating
packages for all these addons (a rapidly changing group of small code bits).
Code for self-application updates ( and add-on updates ) is IMHO
wasted
effort since the code and infrastructure already exists in the distro
platform ( yum, rpm ). Only in the proprietary OS world do applications
need to re-invent the update wheel because the OS update mechanism is
closed to most application developers and is only available to the OS
vendor for its own applications. Having Firefox update itself and its
add-ons is a consequence of its deployment on Windows. It is not
necessarily the best way on Linux.
I would agree with that last statement, partially, but the fact that
self-updates is not necessarily the best option does not mean that system-wide
updates are the best option either. There are systems for deploying windows
updates through IT administrators as well.. but that is inadequate to solve the
problem of firefox addons (which is the real reason why the self-update system
exists for them, not because there was no other option in the windows world).
There are many use cases where the system-wide package management is nothing
more than overhead and in the way of getting the job done. Creating an RPM spec
is additional work to be done and takes the time and effort of someone which
causes more delay in deployment. It is also a heavy amount of work to package,
build, and distribute a very rarely used addon for a small group of users. It
does not make sense to remove or block the user's ability to install extensions
through the provided firefox interface, unless that is for very specific
security reasons within a managed IT infrastructure.
I could see their being an advantage in pushing out a set of system-wide firefox
extensions to a group of lab machines, but is it really worth the effort it will
take on an continual basis to keep these small extensions updated?
--
Andrew Farris <lordmorgul(a)gmail.com> www.lordmorgul.net
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
7:26 p.m.
New subject: sense of packaging firefox' addons?
On Wed, Feb 27, 2008 at 04:30:49PM -0800, Andrew Farris wrote:
And most users would rather not wait for their administrator to get
around
to their station to deploy a new addon they found out about, which is
Why would the administrator have to go anywhere to do this?
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
7:37 p.m.
New subject: sense of packaging firefox' addons?
Matthew Miller wrote:
On Wed, Feb 27, 2008 at 04:30:49PM -0800, Andrew Farris wrote:
> And most users would rather not wait for their administrator to get around
> to their station to deploy a new addon they found out about, which is
Why would the administrator have to go anywhere to do this?
My point was that it will take *much longer* to get done than if the user can
simply click an .xpi and restart their browser. Frankly, if you set aside
security or stability concerns, it seems like a *major waste* to go to the
effort of packaging extensions. The existing framework for their deployment
works very well.
--
Andrew Farris <lordmorgul(a)gmail.com> www.lordmorgul.net
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
7:52 p.m.
New subject: sense of packaging firefox' addons?
On Wed, Feb 27, 2008 at 4:37 PM, Andrew Farris <lordmorgul(a)gmail.com> wrote:
My point was that it will take *much longer* to get done than if the
user can
simply click an .xpi and restart their browser. Frankly, if you set aside
security or stability concerns, it seems like a *major waste* to go to the
effort of packaging extensions. The existing framework for their deployment
works very well.
Even if there is utility for some individual sites to have packages
and to lockdown firefox's plugin ability.. it might not make sense for
Fedora to provide those packages.
-jef
11:47 p.m.
New subject: sense of packaging firefox' addons?
Jeff Spaleta pisze:
On Wed, Feb 27, 2008 at 4:37 PM, Andrew
Farris<lordmorgul(a)gmail.com> wrote:
> My point was that it will take *much longer* to get done than if the user can
> simply click an .xpi and restart their browser. Frankly, if you set aside
> security or stability concerns, it seems like a *major waste* to go to the
> effort of packaging extensions. The existing framework for their deployment
> works very well.
Even if there is utility for some individual sites to have packages
and to lockdown firefox's plugin ability.. it might not make sense for
Fedora to provide those packages.
Agree.
9:09 p.m.
New subject: sense of packaging firefox' addons?
On Wed, Feb 27, 2008 at 05:37:35PM -0800, Andrew Farris wrote:
can simply click an .xpi and restart their browser. Frankly, if you
set
aside security or stability concerns, it seems like a *major waste* to go
to the effort of packaging extensions. The existing framework for their
deployment works very well.
Heh. "Frankly, if we set aside eight million dollars, eight million and one
dollars isn't very much money."
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
9:24 p.m.
New subject: sense of packaging firefox' addons?
Matthew Miller wrote:
On Wed, Feb 27, 2008 at 05:37:35PM -0800, Andrew Farris wrote:
> can simply click an .xpi and restart their browser. Frankly, if you set
> aside security or stability concerns, it seems like a *major waste* to go
> to the effort of packaging extensions. The existing framework for their
> deployment works very well.
All,
Look at the number of updates for certain critical extensions such as
NoScript, and then judge about security versus maintainability. Quite
Often, the update within Firefox doesn't contain the latest version. I
would much rather the users take a suggestion about which updates should
be included if a popup appears when they start their browser.
And I keep a running log of the latest and greatest software which they
have learned through extreme coercive techniques to consult before
installing something willy-nilly
Randy
9:54 p.m.
New subject: sense of packaging firefox' addons?
Randy Wyatt wrote:
Matthew Miller wrote:
> On Wed, Feb 27, 2008 at 05:37:35PM -0800, Andrew Farris wrote:
>> can simply click an .xpi and restart their browser. Frankly, if you
>> set aside security or stability concerns, it seems like a *major
>> waste* to go to the effort of packaging extensions. The existing
>> framework for their deployment works very well.
>
All,
Look at the number of updates for certain critical extensions such as
NoScript, and then judge about security versus maintainability. Quite
Often, the update within Firefox doesn't contain the latest version. I
would much rather the users take a suggestion about which updates should
be included if a popup appears when they start their browser.
And I keep a running log of the latest and greatest software which they
have learned through extreme coercive techniques to consult before
installing something willy-nilly
Bravo, afterall.. no security policy is 100% adequate to prevent a user from
doing something very stupid. Not updating adblock plus or noscript frequently
makes them ineffective, and if you're only providing the very first version via
system-wide install and then permitting the user's profile to update a local
extension version that seems a little silly to me.
--
Andrew Farris <lordmorgul(a)gmail.com> www.lordmorgul.net
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
5916
days inactive
5917
days old
8 comments
6 participants
participants (6)
-
Andrew Farris -
chasd -
Jakub 'Livio' Rusinek -
Jef Spaleta -
Matthew Miller -
Randy Wyatt