How do *you* use Fedora?

[Pete Travis]

Hello,

The docs team has begun assembling release notes for Fedora 19, and I've
been thinking over hardware requirements.

Historically, we have cited the CPU, storage, and especially memory
requirements for the default installation - a basic GNOME desktop.  I'd
like to reexamine that practice, with input from the development community.
Fedora is too versatile a product to document so narrowly.

A few considerations come immediately to mind, but please don't limit
yourself to the examples:
Modern composited desktops like GNOME and KDE need better graphics hardware
than XFCE or MATE.  Headless servers would benefit from better NICs or
storage controllers, but not require them. Purpose driven virtual machines
clearly need fewer resources than the machine that hosts them.

I'm considering system specs at this point, but establishing the roles
deployed might aid in targeting more comprehensive documentation. Beyond a
basic desktop, what use cases would you like to see us represent?

-- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
- immanetize at fedoraproject.org

[DJ Delorie]

I'm WAY out on the bell curve...

I have two PCs.  One of them, the one I sit in front of, has four
monitors (on one Radeon HD card), video capture and playback, digital
and analog audio (digital goes to a surround system receiver, analog
to gaming headphones), an SSD plus a dual-3Tb raid1 all in a hot-swap
bay, and a bunch of other stuff (mostly usb - lab equipment, scanner,
two android devices, etc).  It's a six-core i7 with 24 GB of RAM, and
typically about half the RAM is in active use (the rest is for cache).
I have some guest OSs but don't run them unless I need to, but the PC
itself is up 24/7.

I run fvwm2 across all monitors as one giant screen (the main screen
is not the leftmost screen, and eventually won't be the topmost one
either), and assign two virtual desktops to the local PC.  I tried
gaming under a composited desktop but the FPS dropped so compositing
was dropped too.

The other two virtual desktops are assigned to my other PC, which sits
in the basement and only talks over X and ssh.

I do *not* use any ramdisks or tmpfs.  I also remove abrt as it takes
too long to run if anything crashes (they tend to be BIG crashes).

This setup is used for software development, gaming, EDA, email (10
mailboxes to monitor), web, and as a home (er, office :) theater.

[Matthew Miller]

On Tue, Apr 02, 2013 at 01:47:48PM -0600, Pete Travis wrote:
> I'm considering system specs at this point, but establishing the roles
> deployed might aid in targeting more comprehensive documentation. Beyond a
> basic desktop, what use cases would you like to see us represent?

Cloud guest, please.

[Adam Williamson]

On 02/04/13 02:26 PM, Matthew Miller wrote:
> On Tue, Apr 02, 2013 at 01:47:48PM -0600, Pete Travis wrote:
> > I'm considering system specs at this point, but establishing the roles
> > deployed might aid in targeting more comprehensive documentation. Beyond a
> > basic desktop, what use cases would you like to see us represent?
>
> Cloud guest, please.

What kind of cloud? What kind of guest?

I'm worried that this will turn into a very large and amorphous effort. 
Trying to pin down 'typical Fedora use cases' seems rather like trying 
to box a cloud.

[Matthew Miller]

On Tue, Apr 02, 2013 at 03:28:21PM -0700, Adam Williamson wrote:
> > > I'm considering system specs at this point, but establishing the roles
> > > deployed might aid in targeting more comprehensive documentation. Beyond a
> > > basic desktop, what use cases would you like to see us represent?
> >
> > Cloud guest, please.
>
> What kind of cloud? What kind of guest?
> I'm worried that this will turn into a very large and amorphous
> effort.

Sure; let's start concrete -- Amazon EC2, starting at M1 Small. If we can
make it run nicely on Micro instances (and I don't see why not), so much the
better.
> Trying to pin down 'typical Fedora use cases' seems rather like trying to
> box a cloud.

Maybe we could at least try to describe the cloud a bit, though? That one
looks like a fluffy bunny....

[Pete Travis]

On Tue, Apr 2, 2013 at 5:56 PM, Matthew Miller wrote:
> On Tue, Apr 02, 2013 at 03:28:21PM -0700, Adam Williamson wrote:
> > > > I'm considering system specs at this point, but establishing the roles
> > > > deployed might aid in targeting more comprehensive documentation.
>
> Beyond a
> > > > basic desktop, what use cases would you like to see us represent?
> > >
> > > Cloud guest, please.
> >
> > What kind of cloud? What kind of guest?
> > I'm worried that this will turn into a very large and amorphous
> > effort.
>
> Sure; let's start concrete -- Amazon EC2, starting at M1 Small. If we can
> make it run nicely on Micro instances (and I don't see why not), so much
> the
> better.
> > Trying to pin down 'typical Fedora use cases' seems rather like trying to
> > box a cloud.
>
> Maybe we could at least try to describe the cloud a bit, though? That one
> looks like a fluffy bunny....
>
> --
> Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <
> [e-mail]>

--

I'm not sure we need to get too specific - at least, we can't make specific
claims unless someone can validate function, which I can't personally do
for cloud guests - but it would be nice to claim function on a certain
class of node. Once we clear the installer hurdle, a minimal system doesn't
need much.

Clearly, the memory requirements of the installation environment can't be
equated to the memory requirements for the running environment, especially
for cloud guests. @minimal requires less memory to install than a full
desktop - but does anyone want to run Fedora with less memory than that, or
is doing so venturing out of reasonable guidelines and into
proof-of-concept adventureland?

-- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
- immanetize at fedoraproject.org

[Adam Williamson]

On 03/04/13 07:29 AM, Pete Travis wrote:
> Clearly, the memory requirements of the installation environment can't
> be equated to the memory requirements for the running environment,
> especially for cloud guests. @minimal requires less memory to install
> than a full desktop - but does anyone want to run Fedora with less
> memory than that, or is doing so venturing out of reasonable guidelines
> and into proof-of-concept adventureland?

I ran my IRC proxy VM for some long time with 256MB of RAM. It never 
needs any more. Now it has 2GB just because the host has tons of RAM and 
'why not', but it still doesn't _need_ it. I've never seen top go north 
of 150MB on that box, and it's not a particularly exotic config, and 
it's doing obviously useful work (it's basically a minimal install with 
bip and bitlbee on top, doing what they're meant to do).

[Matthew Miller]

On Wed, Apr 03, 2013 at 08:29:21AM -0600, Pete Travis wrote:
> equated to the memory requirements for the running environment, especially
> for cloud guests. @minimal requires less memory to install than a full
> desktop - but does anyone want to run Fedora with less memory than that, or
> is doing so venturing out of reasonable guidelines and into
> proof-of-concept adventureland?

Yes, people want to run Fedora in VMs with less memory than that. (Key
demographic: large computer science classes.)

[David Lehman]

On Thu, 2013-04-04 at 08:59 -0400, Matthew Miller wrote:
> On Wed, Apr 03, 2013 at 08:29:21AM -0600, Pete Travis wrote:
> > equated to the memory requirements for the running environment, especially
> > for cloud guests. @minimal requires less memory to install than a full
> > desktop - but does anyone want to run Fedora with less memory than that, or
> > is doing so venturing out of reasonable guidelines and into
> > proof-of-concept adventureland?
>
> Yes, people want to run Fedora in VMs with less memory than that. (Key
> demographic: large computer science classes.)

Would those classes be installing the VMs themselves, or would the
instructor/assistant do that beforehand? If the latter, this is a
perfect case for anaconda's install-to-a-disk-image-file capability and
makes little sense to handle by doing dozens of interactive
installations.

Dave

[Matthew Miller]

On Thu, Apr 04, 2013 at 10:55:39AM -0500, David Lehman wrote:
> Would those classes be installing the VMs themselves, or would the
> instructor/assistant do that beforehand? If the latter, this is a
> perfect case for anaconda's install-to-a-disk-image-file capability and
> makes little sense to handle by doing dozens of interactive
> installations.

Installed to an image. Not concerned at all about interactive
installations.

[Pete Travis]

On Thu, Apr 4, 2013 at 9:55 AM, David Lehman  wrote:
> On Thu, 2013-04-04 at 08:59 -0400, Matthew Miller wrote:
> > On Wed, Apr 03, 2013 at 08:29:21AM -0600, Pete Travis wrote:
> > > equated to the memory requirements for the running environment,
>
> especially
> > > for cloud guests. @minimal requires less memory to install than a full
> > > desktop - but does anyone want to run Fedora with less memory than
>
> that, or
> > > is doing so venturing out of reasonable guidelines and into
> > > proof-of-concept adventureland?
> >
> > Yes, people want to run Fedora in VMs with less memory than that. (Key
> > demographic: large computer science classes.)
>
> Would those classes be installing the VMs themselves, or would the
> instructor/assistant do that beforehand? If the latter, this is a
> perfect case for anaconda's install-to-a-disk-image-file capability and
> makes little sense to handle by doing dozens of interactive
> installations.
>
> Dave

I wasn't aware of this compelling capability. I experimented with it a bit;
encouragingly, I can create an image with qcow-create that anaconda
recognizes, but I haven't sorted out how to run anaconda from the command
line without it taking over the system that runs it, with varying degrees
of success. The functionality seems... inconsistent. Is this the way I'm
using it[1] ?

[1] ssh to a guest to I don't kill my workstation
# ssh targetvm anaconda --kickstart=http://host/ks.cfg--image=/root/anaconda.img

-- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
- immanetize at fedoraproject.org

[David Lehman]

On Fri, 2013-04-05 at 08:59 -0600, Pete Travis wrote:
> On Thu, Apr 4, 2013 at 9:55 AM, David Lehman 
> wrote:
>         On Thu, 2013-04-04 at 08:59 -0400, Matthew Miller wrote:
>         > On Wed, Apr 03, 2013 at 08:29:21AM -0600, Pete Travis wrote:
>         > > equated to the memory requirements for the running
>         environment, especially
>         > > for cloud guests. @minimal requires less memory to install
>         than a full
>         > > desktop - but does anyone want to run Fedora with less
>         memory than that, or
>         > > is doing so venturing out of reasonable guidelines and
>         into
>         > > proof-of-concept adventureland?
>         >
>         > Yes, people want to run Fedora in VMs with less memory than
>         that. (Key
>         > demographic: large computer science classes.)
>     Would those classes be installing the VMs themselves, or would
>     the
>     instructor/assistant do that beforehand? If the latter, this
>     is a
>     perfect case for anaconda's install-to-a-disk-image-file
>     capability and
>     makes little sense to handle by doing dozens of interactive
>     installations.
>
>     Dave
>
>
>
>
> I wasn't aware of this compelling capability. I experimented with it a
> bit; encouragingly, I can create an image with qcow-create that
> anaconda recognizes, but I haven't sorted out how to run anaconda from
> the command line without it taking over the system that runs it, with
> varying degrees of success. The functionality seems... inconsistent.
> Is this the way I'm using it[1] ?
>
> [1] ssh to a guest to I don't kill my workstation
> # ssh targetvm anaconda --kickstart=http://host/ks.cfg
> --image=/root/anaconda.img

I found a bug just a few minutes ago that would prevent disk image
installs from working as expected [1]. There may be other issues lurking
as this is an under-used piece of functionality. Your usage seems fine.

[1] When disk images are specified they automatically become the
exclusive set of usable disks. The bug I found earlier marks all disks,
including the disk image, as unusable.

[Pete Travis]

On Apr 5, 2013 2:23 PM, "David Lehman"  wrote:
> On Fri, 2013-04-05 at 08:59 -0600, Pete Travis wrote:
> > On Thu, Apr 4, 2013 at 9:55 AM, David Lehman 
> > wrote:
> >         On Thu, 2013-04-04 at 08:59 -0400, Matthew Miller wrote:
> >         > On Wed, Apr 03, 2013 at 08:29:21AM -0600, Pete Travis wrote:
> >         > > equated to the memory requirements for the running
> >         environment, especially
> >         > > for cloud guests. @minimal requires less memory to install
> >         than a full
> >         > > desktop - but does anyone want to run Fedora with less
> >         memory than that, or
> >         > > is doing so venturing out of reasonable guidelines and
> >         into
> >         > > proof-of-concept adventureland?
> >         >
> >         > Yes, people want to run Fedora in VMs with less memory than
> >         that. (Key
> >         > demographic: large computer science classes.)
> >     Would those classes be installing the VMs themselves, or would
> >     the
> >     instructor/assistant do that beforehand? If the latter, this
> >     is a
> >     perfect case for anaconda's install-to-a-disk-image-file
> >     capability and
> >     makes little sense to handle by doing dozens of interactive
> >     installations.
> >
> >     Dave
> >
> >
> >
> >
> > I wasn't aware of this compelling capability. I experimented with it a
> > bit; encouragingly, I can create an image with qcow-create that
> > anaconda recognizes, but I haven't sorted out how to run anaconda from
> > the command line without it taking over the system that runs it, with
> > varying degrees of success. The functionality seems... inconsistent.
> > Is this the way I'm using it[1] ?
> >
> > [1] ssh to a guest to I don't kill my workstation
> > # ssh targetvm anaconda --kickstart=http://host/ks.cfg
> > --image=/root/anaconda.img
>
> I found a bug just a few minutes ago that would prevent disk image
> installs from working as expected [1]. There may be other issues lurking
> as this is an under-used piece of functionality. Your usage seems fine.
>
> [1] When disk images are specified they automatically become the
> exclusive set of usable disks. The bug I found earlier marks all disks,
> including the disk image, as unusable.
>
> --

I thought this exclusivity was the expected behavior, although I only did
quick glance over the code.  The problem seems to stem from running
anaconda on an existing system rather than booting into anaconda.

I'll play around with this some more, and follow up with bug reports, or a
thread on anaconda-devel@ if you'd prefer. This thread is giving me a lot
to ponder...

--Pete

[John5342]

On 2 Apr 2013 20:48, "Pete Travis"  wrote:
> Hello,
>
> The docs team has begun assembling release notes for Fedora 19, and I've

been thinking over hardware requirements.
> Historically, we have cited the CPU, storage, and especially memory

requirements for the default installation - a basic GNOME desktop.  I'd
like to reexamine that practice, with input from the development community.
Fedora is too versatile a product to document so narrowly.

One important spec that should be listed regardless of the use case is the
minimum requirements for the installer. Not necessarily a big issue with
live disks but I remember a time when KDE (once installed) would do quite
well enough on 512MB of ram but the DVD install would fail with less than
1GB.

[Máirín Duffy]

On 04/02/2013 03:47 PM, Pete Travis wrote:
> I'm considering system specs at this point, but establishing the roles
> deployed might aid in targeting more comprehensive documentation. Beyond
> a basic desktop, what use cases would you like to see us represent?

FWIW I primarily use Fedora as a creative workstation, for both vector &
bitmap graphic manipulation as well as non-linear video editing and
occasional audio editing. I recently had one of my two 4 GB RAM DIMMs
die, and noticed a big difference in how quickly Gimp was able to
process images... it really slowed down. On my i7 system with full 8 GB
of RAM Fedora performs quite well with what I work on though.

Hope this helps,
~m

[M. Edward (Ed) Borasky]

My use cases fall into two broad categories - algorithmic music
composition and computational journalism. The former is almost exactly
the Fedora Jam audio spin, augmented by packages from Planet CCRMA.
The latter is a mix of Design Suite and Science and Engineering spins
and other packages, and can be rather neatly summarized by browsing
all the scripts in
https://github.com/znmeb/Computational-Journalism-Publsihers-Workbench
of the form 'yum-*.bash'. ;-)

On Wed, Apr 3, 2013 at 10:07 AM, Máirín Duffy  wrote:
> On 04/02/2013 03:47 PM, Pete Travis wrote:
> > I'm considering system specs at this point, but establishing the roles
> > deployed might aid in targeting more comprehensive documentation. Beyond
> > a basic desktop, what use cases would you like to see us represent?
>
> FWIW I primarily use Fedora as a creative workstation, for both vector &
> bitmap graphic manipulation as well as non-linear video editing and
> occasional audio editing. I recently had one of my two 4 GB RAM DIMMs
> die, and noticed a big difference in how quickly Gimp was able to
> process images... it really slowed down. On my i7 system with full 8 GB
> of RAM Fedora performs quite well with what I work on though.
>
> Hope this helps,
> ~m
> --
> devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/devel

[Howard Howell]

I do experimental design, prototyping, writing and  commercial design of
electronic projects.

The tools I employ are:
LO calc
LO writer
OpenSCAD
ngspice
gschem
gedit
emacs
MPLABX (from microchip)
GIMP
eclipse
Firefox
Evolution
PCB (just learning)

Languages include
C
Basic
Assembly
Clisp

[Dan Mashal]

On Tue, Apr 2, 2013 at 12:47 PM, Pete Travis  wrote:
> Hello,
>
> The docs team has begun assembling release notes for Fedora 19, and I've
> been thinking over hardware requirements.
>
> Historically, we have cited the CPU, storage, and especially memory
> requirements for the default installation - a basic GNOME desktop.  I'd
> like to reexamine that practice, with input from the development community.
> Fedora is too versatile a product to document so narrowly.
>
> A few considerations come immediately to mind, but please don't limit
> yourself to the examples:
> Modern composited desktops like GNOME and KDE need better graphics
> hardware than XFCE or MATE.  Headless servers would benefit from better
> NICs or storage controllers, but not require them. Purpose driven virtual
> machines clearly need fewer resources than the machine that hosts them.
>
> I'm considering system specs at this point, but establishing the roles
> deployed might aid in targeting more comprehensive documentation. Beyond a
> basic desktop, what use cases would you like to see us represent?
>
> -- Pete Travis
> Fedora Docs Project Leader
> 'randomuser' on freenode
> immanetize at fedoraproject.org
>
> --
> devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/devel

Differently over the years.

I used to run Fedora on servers at one point.

I then started contributing.

I now use it to stay up to date with "Distro X" upstream, learn new things,
and help other people, and I have come in to contact with some amazing
people along the way.

Thanks,
Dan

[Nicolas Mailhot]

Hi,

I use Fedora rawhide daily as an all-purpose desktop: administrative tasks
(budgets, taxes, etc), mail, web browsing (online stores, news, etc).

I am pretty agnostic in what I call desktop but over the years I've slowly
moved from fat clients to local web clients plugged on local 'server' apps
(postfix, amavisd-new, dovecot, squirrelmail…). In part to get the ability
to access my desktop remotely and in part due to GNOME's long-term failure
in providing apps with stable behaviour, complete feature-sets and robust
data handling (I used for example to launch evolution when at home. Now I
don't bother and open squirrelmail directly. Both evo and thundermail
never bothered with correct handling of shared maildir stores). I don't
care about the continuous chrome rewrites and experimentations when basic
functionnality does not work (for the same reasons I use the terminal all
the time instead of desktop helpers). The web apps have no fancy UI but
they get the job done reliably day after day. (OTOH OpenOffice then
LibreOffice I continue to use, so I'm not wed to web apps I just want
working no-surprise dekstop apps). IMHO there is a severe lack of
understanding FLOSS desktop-side that pretty demos win reviews and
two-weeks user tests but long-term adoption relies on long-term stability
and lack of UI surprises.

Once upon a time I wanted to explore adding entertainment media PC
functions to the desktop (I have all the required hardware, including
video capture card) but I gave up on it for pretty much the same reasons I
gave up on GNOME apps (the last straw was the killing of background
audio/video tasks by laptop-oriented developpers).

Printing robustness is a long-term sore point (when you fill admin
documents, invoices, taxes it must work now not the next day after lots of
debuging).

Due to limited free time my Fedora testing has slowly devolved into
filling abrt and selinux reports (there are enough crashes in Fedora apps
handling them does not leave any time for more in-depth reporting, which
is ignored too often anyway).

I've used Fedora and other FLOSS projects in the past to push changes i
wanted upstream, and I still use it to get an idea about the changes that
will eventually land in distro derivatives that I will see used at work
for example (I'm pretty pessimistic about Fedora adoption. RHL then Fedora
used to be in the same class than other desktop systems like windows, but
other desktop producers made huge stability efforts while Fedora moved the
other way for unfathomable reasons. Once upon a time a Linux desktop was
the solution if you wanted to avoid data loss (at the cost of being a bit
bare) now it's even more bare but completely outclassed by the competition
on the stability front.

Lately I've noticed the Games SIG packaged some interesting bits in
Fedora, and so far those bits to not fail in strange and misterious ways
and I can continue months-old games after multiple updates without strange
and mysterious time-consuming behaviour changes.

Regards,

[Nicu Buculei]

Being in the middle of a career change, I use Fedora as a basic desktop
with MATE. As productivity I do a lot of photo editing with GIMP and the
occasional tools like custom-made ImageMagick scripts, illustration with
Inkscape, DTP with a GIMP and Inkscape combo and web development with
Pluma. On the server side, I run only an Apache instance on the same
machine for testing the web stuff. All the other services are externally
hosted.

The machine is shared with my life partner, who also do photo editing, but
as she refuses to even try Linux alternatives, is set-up for dual boot
with Window 7.

[Reindl Harald]

Am 02.04.2013 21:47, schrieb Pete Travis:
> The docs team has begun assembling release notes for Fedora 19, and I've been thinking over hardware requirements.
>
> Historically, we have cited the CPU, storage, and especially memory requirements for the default installation - a
> basic GNOME desktop.  I'd like to reexamine that practice, with input from the development community. Fedora is too
> versatile a product to document so narrowly.
>
> A few considerations come immediately to mind, but please don't limit yourself to the examples:
> Modern composited desktops like GNOME and KDE need better graphics hardware than XFCE or MATE.  Headless servers
> would benefit from better NICs or storage controllers, but not require them. Purpose driven virtual machines
> clearly need fewer resources than the machine that hosts them.
>
> I'm considering system specs at this point, but establishing the roles deployed might aid in targeting more
> comprehensive documentation. Beyond a basic desktop, what use cases would you like to see us represent?

i have two uses-cases for Fedora

private:

* homerouter / firewall / VPN-gateway / WLAN-AP (hostapd)
* fileserver for all sorts of data
* music server (MPD)
* KDE desktop
* web-develoment (Eclipse)
* all sort of servers like for business in VMware Workstation

_______________________

business:

* software development
  * web-applications / web-services / cms-systems
  * admin backends for different services like mail/web/ftp/sftp/EPP
  * deployment-tools (shell/php-scripts)
* router / firewall / VPN-gateway for small offices
* http-server / load-balancer (httpd / apache trafficserver)
* ftp-server
* mailserver (dbmail, dovecot, postfix, mysql)
* database servers (for web-sites as well for admin-backends)
* fileserver (smb / netatalk)
* dns-servers (authoritative for hosting and internal resolvers
* dhcpd
* sftp-servers with nss-mysql in case of many virtual users
* voip / fax (asterisk, hylafax, iaxmodem)
* openvpn

in summary: any network-service for internal usage as well as for
customer services based on self-written admin- and deployment tools
on top of VMware vSphere and running all on Fedora since many years
and any dist-upgrade online with YUM all the time

[Lokesh Mandvekar]

I mostly use cli programs (apart from web browsing, pdf readers and
the ocassional gimp). My netbook has just 1G RAM, so I try to use the
lightest programs wherever I can, and given the tools I've gotten used to, I don't even
feel the need for more RAM (except when I'm forced to use Firefox). Here's my
list:

* Desktop environment: spectrwm - a tiling window manager (nothing else)
* terminal emulator: urxvt
* ssh
* pdf reader: zathura
* web browser: luakit(mostly), Firefox(if luakit doesn't behave well)
* chat: irssi, bitlbee
* email: mutt
* editor: vim
* Document/slideshow creation: LaTeX, beamer :)
* SCM: git, gitolite
* Tor \m/

I also have an installation of NetBSD's pkgsrc package manager on my machine.
Coexists happily with yum.

On Thu, Apr 04, 2013 at 01:17:17AM +0200, Reindl Harald wrote:
> Am 02.04.2013 21:47, schrieb Pete Travis:
> > The docs team has begun assembling release notes for Fedora 19, and I've been thinking over hardware requirements.
> >
> > Historically, we have cited the CPU, storage, and especially memory requirements for the default installation - a
> > basic GNOME desktop.  I'd like to reexamine that practice, with input from the development community. Fedora is too
> > versatile a product to document so narrowly.
> >
> > A few considerations come immediately to mind, but please don't limit yourself to the examples:
> > Modern composited desktops like GNOME and KDE need better graphics hardware than XFCE or MATE.  Headless servers
> > would benefit from better NICs or storage controllers, but not require them. Purpose driven virtual machines
> > clearly need fewer resources than the machine that hosts them.
> >
> > I'm considering system specs at this point, but establishing the roles deployed might aid in targeting more
> > comprehensive documentation. Beyond a basic desktop, what use cases would you like to see us represent?
>
> i have two uses-cases for Fedora
>
> private:
> homerouter / firewall / VPN-gateway / WLAN-AP (hostapd)
> fileserver for all sorts of data
> music server (MPD)
> KDE desktop
> web-develoment (Eclipse)
> all sort of servers like for business in VMware Workstation
>
> business:
> software development
> web-applications / web-services / cms-systems
> admin backends for different services like mail/web/ftp/sftp/EPP
> deployment-tools (shell/php-scripts)
> router / firewall / VPN-gateway for small offices
> http-server / load-balancer (httpd / apache trafficserver)
> ftp-server
> mailserver (dbmail, dovecot, postfix, mysql)
> database servers (for web-sites as well for admin-backends)
> fileserver (smb / netatalk)
> dns-servers (authoritative for hosting and internal resolvers
> dhcpd
> sftp-servers with nss-mysql in case of many virtual users
> voip / fax (asterisk, hylafax, iaxmodem)
> openvpn
>
> in summary: any network-service for internal usage as well as for
> customer services based on self-written admin- and deployment tools
> on top of VMware vSphere and running all on Fedora since many years
> and any dist-upgrade online with YUM all the time
> -- 
> devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/devel