Usenet 是一个巨大的全球性讨论组集合。每个讨论组都有一个名称，例如comp.os.linux.announce，以及消息的集合。这些消息通常被称为 文章，由像你我这样可以访问 Usenet 服务器的读者发布，然后存储在 Usenet 服务器上。
这种读取和写入 Usenet 新闻组的能力使 Usenet 与今天人们所称的“互联网”的大部分内容截然不同。“互联网”已成为指代万维网的口语术语，而万维网（在很大程度上）是只读的。虽然有带有 Web 界面的在线讨论组，也有邮件列表，但对于大多数大型讨论社区来说，Usenet 可能比这两者都更方便。这是因为文章会被复制到您的本地 Usenet 服务器，因此您无需访问全球互联网即可阅读和发布文章，这对于那些互联网连接速度较慢的人来说非常有价值。Usenet 文章也节省带宽，因为它们不像基于电子邮件的邮件列表那样进入并驻留在每个成员的邮箱中。通过邮件列表，一个办公室的 20 名成员将在他们的邮箱中复制每条消息的 20 份副本。但是，对于 Usenet 讨论组和本地 Usenet 服务器，每篇文章只有一个副本，并且不会填满任何人的邮箱。
拥有自己的本地 Usenet 服务器的另一个优点是，即使您已阅读文章，文章也会保留在服务器上。您不会像从邮箱中删除消息那样意外删除 Usenet 文章。这样，Usenet 服务器是极佳的方式，可以在本地服务器上存档小组讨论的文章，而无需将存档责任放在任何小组成员身上。这使得本地 Usenet 服务器作为公司内网内部讨论消息的存档非常有价值，前提是 Usenet 服务器软件的文章过期配置已设置为足够长的过期时间。
Usenet 新闻的工作方式是，读者首先启动 Usenet 新闻程序，在当今的 GUI 世界中，很可能类似于 Netscape Messenger 或 Microsoft 的 Outlook Express。有很多经过验证、设计良好的基于字符的 Usenet 新闻阅读器，但用户代理软件的适当评测超出了本 HOWTO 的范围，因此我们仅假设您正在使用您喜欢的任何软件。然后，读者从其本地服务器托管的数百或数千个新闻组中选择一个 Usenet 新闻组，并访问所有未读文章。这些文章将显示给她。然后她可以决定回复其中的一些文章。
当读者撰写文章时，无论是回复现有文章还是作为全新讨论主题的开始，她的软件都会将此文章发布到 Usenet 服务器。该文章包含要发布到的新闻组列表。一旦被服务器接受，其他用户就可以阅读和回复它。服务器会根据其软件中设置的过期策略自动过期或删除文章在其内部存档中的内容；文章的作者通常对其文章的过期几乎无能为力。
Usenet 服务器很少单独工作。它构成服务器集合的一部分，这些服务器彼此自动交换文章。文章从一台服务器到另一台服务器的流动称为新闻馈送。在简单的情况下，可以想象一个全球服务器网络，所有服务器都配置为彼此复制文章，一旦其中一台服务器收到人类读者发布的新文章，就忙于在网络中传递副本。这种复制由强大且容错的进程完成，并赋予 Usenet 网络其力量。您的本地 Usenet 服务器实际上拥有所有相关新闻组中所有当前文章的副本。
任何有抱负的 Usenet 服务器管理员或创建者必须阅读 “关于配置机器以存储 Usenet 新闻所涉及的基本步骤的定期发布”，也称为站点设置 FAQ，可从以下网址获取ftp://rtfm.mit.edu/pub/usenet/news.answers/usenet/site-setup或ftp://ftp.uu.net/usenet/news.answers/news/site-setup.Z。
如果您希望您的 Usenet 服务器成为所有新闻组中所有文章的存储库，您可能不会阅读本 HOWTO，或者即使您阅读了，您也会很快意识到任何需要阅读本 HOWTO 的人都可能还没有准备好设置这样的服务器。这是因为 Usenet 上的文章容量已达到需要非常专业的网络、非常高端的服务器和大型磁盘阵列来处理如此大的 Usenet 容量的地步。这些设置称为“运营商级”Usenet 服务器，将在本 HOWTO 的后面部分进行讨论。管理这样的硬件阵列可能不是新的 Usenet 管理员的工作，而本 HOWTO（以及大多数 Linux HOWTO）正是为他们编写的。
然而，了解我们正在谈论的容量可能很有趣。根据我们从运营商级 Usenet 管理员的评论中听到的，Usenet 新闻文章的容量大约每十四个月翻一番。在 1997 年初，这个容量是每天 1.2 GB 的文章。因此，到我们到达撰写本文时的 2002 年中期，容量应该大致翻了五番，或者增长了 32 倍。这使我们每天的容量达到 38.4 GB。假设这种传输使用未压缩的 NNTP（常态），并为 NNTP、TCP 和 IP 的开销增加 50% 的额外费用。这为您提供了每天 57.6 GB 或大约 460 Gbps 的原始数据传输量。如果您必须在 24 小时（86400 秒）内传输如此大的数据量，您将需要大约 5.3 Mbps 的原始带宽才能接收所有这些文章。您需要更多带宽来向其他相邻的 Usenet 服务器发送馈送，然后您需要带宽来允许您的读者访问您的服务器并以零售量阅读和发布文章。显然，这些容量数字超出了大多数公司组织或教育机构的网络带宽，因此只有那些从事提供 Usenet 新闻业务的人才能负担得起。
在规模的另一端，小型办公室完全可以订阅 Usenet 新闻组的良好修剪子集，并排除大多数大容量新闻组。本 HOWTO 的作者所在的公司 Starcom Software 曾使用过 600 个新闻组的相当大的子集，这仍然只是运营商级服务提供的 15,000 多个新闻组的一小部分。您的办公室或学院甚至可能不需要 600 个组。我们公司也排除了特定的高容量但低效用的新闻组，例如talk, comp.binaries和alt层次结构。通过修剪后的子集，每天的文章总容量可能仅为每天大约一百兆字节左右，并且可以轻松地由大多数小型办公室和教育机构处理。在这种情况下，单台 Intel Linux 服务器可以作为 Usenet 服务器提供出色的性能。
然后是内部 Usenet 服务。我们这里所说的内部是指私有的 Usenet 新闻组集，而不是私有计算机网络。每个运行 Usenet 新闻服务的公司或大学都会创建自己的内部新闻组层次结构，这些新闻组的文章永远不会离开校园或办公室，因此不会消耗互联网带宽。这些新闻组通常是访问最频繁的新闻组，并且将比您组织内可能订阅的所有“公共”新闻组承载更多的内部生成流量。毕竟，除非他正在讨论像“Unix 规则！”这样的全球相关主题，否则一个人多久才能说一些与整个世界相关的事情？如果这些内部新闻组是您的 Usenet 服务器的重点，那么您可能会发现，根据您的组织规模，相当适度的硬件和互联网带宽就足够了。
新的 Usenet 服务器管理员必须进行容量评估，以确保他不会承担超出他或他的网络资源所能承受的范围。我们希望我们已为他提供足够的信息以开始提出正确的问题。