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

Re: 'IT Security' in comps?

Till Maas (opensource till name) said: 
> I considered IT might be redundant information, too, when
> I created the groups, but also both the terms "Forensics" or "Wireless"
> are not IT specific, therefore I put the IT-security explanation into
> the description. There can be wireless analysis that is not security
> related, e.g. to find sources of disturbance and there are a lot of
> forensics tasks that are not IT-security related, but still could be
> assisted via software.

Rather than going back and forth about concepts, I might as well just
describe how I would organize what you have now:

- Network Analysis Tools
- Tools for analyzing and securing computer networks.

(This would include the packages from both your proposed 'reconnaissance'
and 'wireless' groups, as well as some other tools currently in 'System

- Computer Forensic Tools
- Tools for performing computer forensics and data recovery.

(I'd move the password tools here, as well. Not sure how clamav fits here;
I think its current placement at the mail server level makes more sense.)

The intrusion detection group looks OK as a concept. As for the code
analysis group, I'd argue that should be moved into the development

Is this something you'd find usable?

> > Additional groups under Base System, not sub-sub-groups.
> This is no solution to grouping the packages together and still be able
> to know which packages are for which sub group of tasks.
> Btw. these tools to also not build a base system or at least what I
> would think of a base system, because their use case is for certain
> special tasks and does not form a base for other tools to build on, e.g.
> cron performs a base set of features that can be used by other packages.
> But this might not the criteria for packages in the base system
> category.

Right now our toplevel groups are:

- Language support (self explanatory)
- Desktops (fairly self explanatory)
- Applications (End-user desktop applications)
- Development (tools for software development)
- Servers (various system services)
- Base system (administration tools, and other components)

Perhaps a better solution is a new toplevel category of 'System
Administration' (where most of your new groups would fall under); this
widens the scope of it from just 'IT Security' to a larger scope
that fits the existing categories. That might be a larger reorganization,
though, as the group changes would have to filter down to the various spins.

> > - the 'all packages are default' paradigm
> I could accept to make packages not default that are e.g. already meant
> to be deprecated by upstream, like airsnort. But I do not think that the
> audience of these tools would only want to be presented some random
> password cracker like it is a guideline to have only one IM client on
> the Fedora Desktop live image. This is also reflected with the package
> set of the security live image, which also contains all these tools and
> not only selected ones.

Sure, but the live spin can do %group --optional to pull those in. To
expand on what I said before, we have three main concepts for applying defaults
in comps:

- Lots of tools that occupy the same usage case (office tools, etc.)

  Pick one best-of-breed default, the rest are optional.

- Lots of tools that occupy the same space, but are not interchangable. (games)

  Everything's optional. Pick what you want.

- A basic usage case, with various add-ons and similar tools. (many of
  the server groups, 'system tools', etc.)

  A base set that's default; other tools are optional.


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