'IT Security' in comps?

[Till Maas]

On Thu, Aug 06, 2009 at 01:24:24PM -0400, Bill Nottingham wrote:
> Till Maas (opensource at till.name) said: 
> > The IT prefix is only used in the group id, which is afaik not visible
> > to the used and not translated.
> 
> No, it's not just in the description.
> 
> "These tools can be used to perform IT security related wireless auditing."
> 
> In this example, "IT security related" (aside from missing a hyphen
> or two) is completely superfluous.

1) It is not a prefix in the description
2) It does not allow easy selection of the packages, which was the
feature you said that it allows to have and which is the necessary
context you removed:

| I'm not sure they need to be bundled. Especially with 'IT' as a
| prefix;

3) The description will be translated / meant to be human readable and
not to be a machine readible property.


> > I don't understand what you want to say
> > with "password recovery" is "password recovery". There is nothing to
> > argue about, but nevertheles the groups are related to each other,
> 
> How so? aide is not really related to password recovery at all,
> at least not in any generally describable way.

So the assignement of tools to the groups can be improved. Does this
make the groups useless? I say no, there I don't see how this does
belong to this general discussion about whether or not there should be
these groups in comps.

> > already expresses itself that they are all on the security spin. Also it
> > allows other people to easier ignore them, instead of cluttering other
> > categories.
> 
> Put it this way:
> 
> - These packages are all in other groups under 'Base System'
> - Ergo, if they're being grouped together, the resulting group
>   should still be under 'Base System'

It is not technically possible to have subgroups, as you can see in the
answer from Jesse Keating.

> > > Tagging would help with this; as it stands now, 'yum search wireless'
> > > or 'yum search wireless sniffer' would return the packages in your
> > > wireless group.
> > 
> > Probably, but this cannot be done right now afaik.
> 
> yum search certainly can be done now.

Yes, but is there an easy search expression that will result with the
groups that I added? Afaik no. Does 'yum search wireless' returns 43
lines of packages, so it does not qualify.

 
> > > Moreover, what's the usage case in that you really need all three
> > > tools (which is the default if you install the group you mentioned)?
> > 
> > Everyone on a multi user system can use the tool of his preference.
> 
> ...
> 
> So, the goal of this is for a multi-user forensic system, where
> you have multiple users working on the same system su-ing to root
> and running the tools of their choice? That's an odd usage case
> to design for by default.

Afaics I did not mention the forensics group. I can't answer your
questions if you refer to different groups with "the group" and then
argue against the answer using some other group. The forensics group had
15 packages in it if I counted correclty and e.g. pdfresurect and
chkrootkit are completely different applications. But how does searching
for good or bad examples help here?

> > Also
> > there may be a feature in one application, that is missing in another.
> 
> Then fix one app so that it's reasonable enough. To quote Adam Jackson:

In reality, one does not very often have the time to first fix a bug,
before a task can be completed. So this does not help me right now if I
need to perform a task. Nevertheles the fixing can still be done later.

> "Choice is not the goal. We have many interesting problems to solve and
> forcing the user to care about their choice of solutions is both bad UI
> and actively detracts from the real goal, which is making it work out
> of the box and enabling people to work on the really cool stuff at the
> edges."

I do not know users who prefer to wait several days to months to perform
a task with one application instead of doing it with another
application. Especially not if the need to perform the task right now.

> In comps, in most any group, the default item is the best-of-breed app;
> other implementations are optional.

I see, comps is not the right place to implement the feature that
fulfills my need.

> > Btw. I fail to understand what trouble this is causing you. Thanks to
> > bundling all together into one category, it will even disturb you less
> > than six (or more) groups in some other category, where the stuff you
> > are interested is.
> 
> It's about not presenting bad UI and bad groups to our users - it's 
> a design thing.

I do not agree that my groups are bad or that they are bad by their
nature. Nevertheless, I do not see that this discussion is leading
anywhere, that will allow to fulfill my needs (Easy installation of the
software, easy finding of the software, allowing many people to do this
and not maintaining the same information in several places) and your
requests. Also it looks for me that you do not want these groups at any
cost, because of the way you argue.

In conclusion I have reverted the IT-security related changes to the
comps-f12.xml.in file.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090806/e75c044a/attachment.bin