Poll: Comodo Internet Security Suite [Closed]

General Category Which Product do you want Comodo to develop next?
61

I actually think that fear of bloatware is valid in this discussion. That is the general experience users have had; from a user standpoint, why would Comodo’s suite be any different? Not saying it would be a bloat, but at this point, we don’t know… If it was a big ugly beast and no option was given, then we’d all be very upset.

I don’t think that any suite-ware has to be bloated, but that is pretty much the status quo these days, especially as it applies to security applications.

I’ve used a number of suites that control/interface all aspects/applications thru one gui. I gotta say I really don’t care for that. I prefer individual access. However, I like the idea of (provided it could be done well, with stability) of shared resources. Of course, as has been noted, in that scenario, if one crashes, they all go down - definitely not good. And I’ve seen that happen many times before.

I’d be happy to try the suite if:

It was modular all the way around. Thus, if I didn’t want it, I don’t have to DL the whole package, but just the individual apps. Or select the suite and selected apps for inclusion. If I can install the suite to try it full package, but then deselect it (ie, unpack the modules back into individual units) without re-DLing everything and starting over, that’d be nice.

Another thought I just had (which in the moment I think is neat; later on, I may trash it as absurd) is a drag-n-drop integrated suite/gui. So let’s say we can DL the modular applications, and the suite/integrated gui. Then install each item. Then we can drag-n-drop modules onto the gui for integrated control. If later we decide we don’t want that module in there, just drag it back out. While any module was in the suite’s gui, it would share resources/components. Drag it back out, it uses its own. Perhaps this could be done in such a way that if a particular module caused a fault in shared componentry, other modules sharing that component would revert to their own (original) version of that component, rather than faulting as well. Only the guilty module would crash.

LM

62

A simple way, that i think should be the way:
You download individual applications, or the suite.

This is the simplest way, and no confusion arises. We download one by one. Or the suite.

Downloading the suite, on install we choose what we want, and the security center is installed anyway.

Downloads page: CPF; CAVS; BOClean; …; Suite.

EDIT: i edited an irrelevant part lol

63

Resources could be shared using dlls in usermode, and the interface can be loaded only when needed saving system resources.

The only interface that could be always loaded (consuming system resources) would be the tray icon(s).

Under the hood there should be a number of services sharing resources by means of dll.
But It is possible (but slower) load resources only when an interface is needed (eg alerts).

BUT if a shared dll crashes It will affect every service referencing it.
I don’t know if it is possible to fallback safely to a private dll, maybe it would be possible only in a limited number of cases.

But I would assume that interface resources dlls will be safe from crashing bugs…

The drag&drop modules GUI integration mechanism is possible expecially if the control center has one tab per module. I saw it in one application where drag&droping the tab out the application window created a new child window.

But I won’t bet on this being in the cpf version 3.

64

Nope. That’ll be all firewall, and firewall only (but with HIPS).

LM

65

Oops (:TNG) I forgot that… I was too carried away ;D

66

Yeah, if it was like Melih said, configurable.

67

KISS- keep it simple st*pid.
one download, one installation, one dashboard, one one one simple.
nuff said.
ok more. i have had to do 4 download, 4 installations, try to figure out 4 new softwares.

68

It’s sort of been said.

Yes, but…
No, but…

My ideal solution would be a small (1Mb) download which then lets you choose which components to d/l and install. All components to be related (so the “suite” would be smaller than the individual components combined), but not dependant (i.e. you can choose a different anti-spam, for example, without messing up the whole system).

That said, it didn’t work with Mozilla, so what do I know?

69

I think a suite is a good idea if every single component can be downloaded and installed standalone. I like the idea of a security center for people wanting to use a few or all of the components from the suite, but think that it should be optional as well.

70

Kind of like Yahoo!Messenger, right?

I hate that approach.

I much rather prefer downloading a BIG installer which contains all components, and choose which one(s) I want.

Why?

Internet connection of my country is waaaaay agley. If I can download only the stub, I’ll be forced to waste unbelievable time for each workstation I install the ComodoSecureKit on. I’d rather waste my time once, i.e. downloading the monolithic installer.

71

I still think this should prevent any discontent:

Download options:
CPF
CAVS
BOClean
…
Suite

Everything is the same, except Comodo now offers a complete package for those who want it.

If i only want CPF, i really don’t want no other interface.
And i could want to add CAVS to it, and still no Security Center.

72

Everyone has his own preferences based on his specific needs…
One install solution doesn’t exclude another though…

we should consider two kind of users with two bandwidth requirements.

  1. low bandwidth
  2. high bandwidth
    then we should consider two kind of users with two installation requirements.
  3. all-in-one
  4. modular
    then we should consider bandwidth efficiency too.

low bandwidth users need to download the minimum amout of data possible.
The best solution would be a standalone installer provided on a magazine data-cd.

high bandwidth users prefer to have their software updated.
The best soultion would be a internet based tiny installer.

all-in-one users prefer one installation for many apps.

modular installation users prefer to choose which app to install.

Bandwidth efficiency would be a common requirements, nobody would want to download the same data again and again…

So what have we got?
An internet-aware & module-aware installer that let the use choose what to install, looks for modules to install in its current path (or in a subdirectory), checks if an updated version of the needed modules is present and ask user permission to download them.
Updated/missing needed modules are downloaded in the current path (or in a subdirectory) and then installed.

It is possible a one file installer that extract the internet-aware installer and the modules subdirectory. This onefile installer would be better suited for magazines.

The internetet/module-aware installer could generate the onefile installer.
Many installation systems better than this could be made available

73

Gibran:
low bandwidth user wants CPF only. Why not simply download CPF?
low bandwidth user wants all. Well, he’s going to download everything anyway, so…
;D

74

A Tiny installer could download CPF only. you choose and if the needed modules are not available locally it’ll download them

low bandwidth user wants all. Well, he's going to download everything anyway, so..
this would be possible too... But with low bandwidth I mean 56k dialups... I hope they'll get the suite buying a magazine...
75

Sounds like Windows Updates (website) to me, or very similar…

LM

76

I mean…

What about an installer that checks locally available installation modules and lists them enabling the user to choose If they want to install them all and if they want to download missing apps.

install.exe localdir: cpf install modules cavs install modules boclean install modules

in this case the install will show a default suite installation dialog and a custom installation option to let users choose which modules to install…

install.exe
localdir:
cpf install modules

in this case the install will show a default cpf installation dialog and a custom installation option to let users choose if they want to download missing apps…

install.exe localdir: cpf install modules cavs install modules

in this case the install will show a default installation dialog and a custom installation option to let users choose which modules to install and if they want to download missing apps…

install.exe localdir: no install modules

in this case the install will show a default suite intallation dialog that will download & install all apps and a custom installation option to let users choose which modules to download & install…

77

Do you have screenshots for me to look at? I’d really love to see some screenies…

That way I could know better if I like it or not… ;D

78

;D

We could bet that bloatware developing companies are very skilled in deployment…
But this metod is used also in competing opensource alternatives…

79

Ahem, you see how that’s already raising confusion?

Note: it’s not like it’s a bad idea, infact it seems to envolve more gray matter into it :), but simple solution, and traditional is usually… simpler ;D

80

Hmmm…
Dunno, the logic should be staightforward.

The default dialog should be a wellcome screen saying if it is a suite (all apps provided in the package) or e.g. CPF (only CPF provided in the package) or a “mix”.

Choosing “custom installation” in the dropdown shows a dialog like this where all apps provided in the package are enumerated and missing apps can be downloaded if selected.

Options provided would be

  • check for updates before installation.
  • create a one file installation package for subsequent installations

This pic is a DIALOG for Diaperware Diapers App Custom Installation.

If all Apps were provided in the package there would have been install checkboxes only.
If no App was provided in the package there would have been download & install checkboxes only.

This way one install system would handle all common scenarios.

In this case many type of install and downloads would be possible.

For the Diaperware products case the minimum amount of install packages would be five… ;D

[attachment deleted by admin]