LDP/LDP/retired/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 expressing their interests in 
			developing PLD, however, number of actively working 
			developers is approximately 50.
		</para>
		<para>
			PLD stands for PLD Linux Distribution.
		</para>
		<para>
			How is PLD different from other Linux distributions?
		</para>
		<orderedlist>
			<listitem>
				<para>
					Large software packages are split into 
					functional subbpackages providing the opportunity
					to install only those pieces of software that are really necessary.
				</para>
			</listitem>
			<listitem>
				<para>
					Packages very often come in reasonable
					default configuration, with bunch
					of useful patches applied.
				</para>
			</listitem>
			<listitem>
				<para>
					PLD has the best IPv6 support among
					all Linux distributions.
				</para>
			</listitem>
			<listitem>
				<para>
					Several choices of crucial servers are available.
				</para>
			</listitem>
			<listitem>
				<para>
					System comes with highly modularized kernel suitable for most machines.
				</para>
			</listitem>
			<listitem>
				<para>
					PLD contains rc-inetd - interface for managing inetd services.
					Packages providing inetd servers (e.g. telnetd, cvs-pserver) 
					use this feature to automatically add particular server to inetd configuration.
				</para>
			</listitem>
			<listitem>
				<para>
					Similar feature to rc-inetd is rc-boot - a system that allows
					for easy managing of bootloaders (changing bootloader, updating
					after kernel upgrade etc).
				</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 implementations of SML and 
				  Prolog, OCaml with several utility programs and 
				  libraries and even experimental compilers, like 
				  Cyclone or Ksi.
				</para>
			</listitem>
			<listitem>
				<para>
					Apart for plain rpm, PLD provides two specialized
					and powerfull RPM managers: clone of Debian apt,
					and our own poldek.
				</para>
			</listitem>
		</orderedlist>
		<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 is avoided (no
				package in PLD requires termcap any more)
			</para>
		</listitem>
		<listitem>
			<para>
				Support for automatic system upgrades, including restarting upgraded services, proper handling of config files, even modified ones
			</para>
		</listitem>
		<listitem>
			<para>
				No packages are mandatory during installation (eg. MTAs and other daemons). We assume that some packages may be preferred over others, user decides which program to use.
			</para>
		</listitem>
		<listitem>
			<para>
				The iproute2 tool as a basic tool for network interfaces manipulation. PLD runtime scripts are simpler and shorter then, offering larger functionality compared	to RedHat. Initscripts can be easily localized.
			</para>
		</listitem>
		<listitem>
			<para>
				Support for easy switching to alternative
				authentication methods (and, if you need it,
				ciphering) 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 of packages and documentation comes in many languages
				but only choosen language versions will be installed.
			</para>
		</listitem>
		<listitem>
			<para>
				Many different frequently repeated tasks can be automatically 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 that are in use during 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 can be 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>