LDP/LDP/guide/docbook/PLD-Guide/concept.xml

<section id="Concept">
	<title>Concept of PLD</title>
	<section id="Basicinfo">
		<title>Basic information</title>
		<para>
			PLD is a Linux distribution developed since 1998
			mainly in Poland.
			It is a product of bevy of Linux enthusiasts. We have
			around 200 people expresing their interests in 
			developing PLD, however number of activelly working 
			developers is approximatlly 50.
		</para>
		<para>
			PLD stands for PLD Linux Distribution.
		</para>
		<para>
			How is PLD different from other Linux distributions?
		</para>
		<para>
			In PLD one does, what one needs, or wants to do. This
			simple fact, multiplied by number of developers
			involved, gives good picture how does PLD look like.
		</para>
		<orderedlist>
			<listitem>
				<para>
					Packages very often comes in sensible
					default configuration, with bunch
					of useful patches applied -- that's
					because packagers use packages
					themselves very extensively
				</para>
			</listitem>
			<listitem>
				<para>
					PLD has the best IPv6 support among
					all Linux distributions (and yes,
					that's because some of us are using
					it)
				</para>
			</listitem>
			<listitem>
				<para>
					In general PLD is very sysadmin
					friendly, several choices of crucial
					servers is one example, highly
					modularized kernel from distribution
					suitable for most machines is another 
					(sysadmins with 20+ machines tends not to 
					bother compiling kernel over and over again :^)
				</para>
			</listitem>
			<listitem>
				<para>
				  PLD is also very developer friendly.
				  There are compilers and other development tools 
				  for wide variety of languages. This includes such
				  "standard" things like C (three compilers available), 
				  C++, Perl or Python, but also some less
				  standard things like two implementationsof SML and 
				  Prolog, OCaml with several utility programs and 
				  libraries and even experimental compilers, like 
				  Cyclone or Ksi. As with other packages they are often
				  much better packaged then in other distribution, 
				  especially with respect to splitting them into 
				  subpackages
				</para>
			</listitem>
		</orderedlist>
		<para>
			<emphasis>Some other features</emphasis>
		</para>
		<para>
			It is common in PLD to simplify and cleanup things.
			We have very strict packaging standards. However it 
			goes far beyond that. Installing package
			in PLD is often enough to make it work in some default
			configuration. For example installing telnetd or 
			cvs-pserver adds it to configuration of
			current inetd server (this is done through rc-inetd
			common interface to all inetd servers in PLD), 
			installing kernel generates initrd image for
			it (with geninitrd script), adds it to current
			bootloader configuration (through rc-boot interface), 
			and reinstalls bootloader.
		</para>
		<para>
			PLD is fully prepared for automatic system upgrade. We
			supply indexes for RPM's apt-get port, we also have other 
			upgrade tool, named <emphasis>poldek</emphasis>, 
			with similar functionality.
		</para>
		<para>
			<emphasis>Common myths about PLD</emphasis>
		</para>
		<para>
			PLD is not Polish Linux Distribution, nor Polished, or
			even Polish(ed).
			Specifically it means that system won't talk to you in
			Polish, if you won't instruct it to. It can also speak other
			languages, beside English and Polish.
		</para>
	</section>

	<section id="Goals"><title>Goals</title>
	<orderedlist inheritnum="ignore" continuation="restarts">
		<listitem>
			<para>
				FHS 2.x supported as directory structure
				specification
			</para>
		</listitem>
		<listitem>
			<para>
				termcap and libtermcap usage avoided (no
				package in PLD requires termcap any more)
			</para>
		</listitem>
		<listitem>
			<para>
				fantastic rc-inetd package provided, which is very simple, but also much more elastic than others. (unification of inet-services management)
			</para>
		</listitem>
		<listitem>
			<para>
				automatic system updates supported and ready, including restarting updated services, proper hadling of config files, even modified ones
			</para>
		</listitem>
		<listitem>
			<para>
				no packages are forced during installation (eg. MTAs and other daemons). We assume that some packages may be preferred over others, user decides on which program to use.
			</para>
		</listitem>
		<listitem>
			<para>
				iproute2 as a basic tool for network interfaces manipulation. PLD runtime scripts are simplier and shorter then, offering larger functionality compared	to RedHat. This version of initscripts can be easily localized, accordingly to the tastes of the user
			</para>
		</listitem>
		<listitem>
			<para>
				support for easy switching to alternative
				authentication methods (and, if you need it,
				cyphering) for network communication, such as
				PAM, GASPI, TSL/SSL etc. It's quite possible
				that soon SASL will take the lead in
				authentication systems. In practice this easy
				adaptation to eg. kerberisation is also
				achieved by means of rc-inetd, which allows
				quick replacement of service daemons with
				their kerberised versions, using eg. socks5
			</para>
		</listitem>
		<listitem>
			<para>
				descriptions and documentation are in other 
				languages provided and easily configured. 
				It is mostly done "on the fly".  Everybody 
				can configure and install chosen software 
				with support for selected languages  only,
				i.e. English and
				German or English and  Polish (resources
				linked to other languages will not be
				installed then). We provide such feature by 
				marking  national resources with %lang()
				macro of RPM packages.
			</para>
		</listitem>
		<listitem>
			<para>
				many different frequently repeated tasks can be automaticly done (with regards to current work methodology and package contents)
			</para>
		</listitem>
	</orderedlist>
	</section>
	<section id="assumptions"><title>Assumptions</title>
	<para>
		There are a few assumptions which follow from package
		preparation procedures:
	</para>
	<orderedlist inheritnum="ignore" continuation="restarts">
		<listitem>
			<para>
				documentation files are compressed using gzip
			</para>
		</listitem>
		<listitem>
			<para>
				static libraries are separated into additional
				subpackages (used by people who need it)
			</para>
		</listitem>
		<listitem>
			<para>
				dynamically linked libraries are stripped
				(debug information is found in static
				libraries only)
			</para>
		</listitem>
	</orderedlist>
	</section>
	<section id="methodology"><title>Methodology</title>
	<para>
		The rest of assumptions concerns work methodology:
	</para>
	<orderedlist inheritnum="ignore" continuation="restarts">
		<listitem>
			<para>
				CVS is used to maintain and update resources
			</para>
		</listitem>
		<listitem>
			<para>
				SGML and DocBook are the preferred
				documentation formats
			</para>
		</listitem>
	</orderedlist>
	</section>
</section>