PCLITEOS™ Professional Edition

PCLITEOS™ Enterprise Edition

Developer: PCLITE™ Software & Hardware Systems OS family: Unix-like Working state: Current Source module: Open source with exceptions Initial release: Fusion July 14, 2015 Latest release: Build 512.8.1 March 27, 2017 Available in: Multilingual Update method: front-end application Package manager: dpkg Platforms: x86-64 Kernel type: Monolithic, Linux (Hardened) Userland: GNU Default user interface: KDE Plasma Desktop License: DFSG-compliant with PCLITE™ commercial license Official website: https://pclite.net

Developer: PCLITE™ Software & Hardware Systems OS family: Unix-like Working state: Current Source module: Open source with exceptions Initial release: Galactic July 14, 2015 Latest release: Build 512.8.1 March 27, 2017 Available in: Multilingual Update method: front-end application Package manager: pkgng Platforms: x86-64 Kernel type: Monolithic, FreeBSD (Hardened) Userland: BSD Default user interface: KDE Plasma Desktop License: Simplified BSD with PCLITE™ commercial license Official website: https://pclite.net

 

Release Changes 01-2020

Rolling Release Screenshot

Upgraded to rolling release version Configured to install latest kernel stable version Added new kernel security parameters Added new security menu to change passwords Designed new smart rescue and recovery system Added new preinstalled hardware drivers Upgraded to use latest kde plasma Added new browser security addons Installed new cutting edge office suite Added new preinstalled desktop applications Configured with new settings and preferences Designed new desktop environment alignments Setup attractive transparent interfaces Added new look application and widget dock Added New fonts, icons, themes and codecs

 

Hardware Requirements

 

Minimum Hardware Requirements	Recommended Hardware Requirements
Platform: BIOS Boot System with GPT Support Processor: Intel Haswell Core i3-4370 or AMD Kaveri A8-7650 Memory: 4GB SDRAM DDR2 1066MHz Graphics: VESA 1024x768 32-bit 60Hz Sound: Digital Stereo Channel Network: Intel, Realtek & D-Link Series Port: USB 2.0 Standard and SATA2 Update: Downloading Patches Manually	Platform: UEFI Boot System with GPT Support Processor: Intel Haswell Core i5-4690 or AMD Kaveri A10-7870 Memory: 8GB SDRAM DDR3 1600MHz Graphics: VESA 1366x768 32-bit 85Hz Sound: Digital Surround Channel Network: Intel, Realtek & D-Link Series Port: USB 3.0 Standard and SATA3 Update: High Speed Internet Connection

  

- HP machines such fax, scan and printers are recommended.

- Above explained details are limited to PCLITE™ portable devices.

 

Linux Hardware Drivers

Huge range of hardware devices are covered by the following drivers and they can be detected via installing these packages from the applications repository:

bluez-firmware: this firmware is required for operation of Bluetooth dongles based on the Broadcom BCM203x chipset.

firmware-amd-graphics: this package contains the binary firmware for AMD/ATI graphics chips supported by the radeon, amdgpu and r128 drivers.

firmware-atheros: this package contains the binary firmware for USB wireless network and Bluetooth cards supported by the ar5523, ath3k, ath6kl_sdio, ath6kl_usb, ath9k_htc, ath10k, or wilc6210 drivers.

firmware-linux: this package depends on both free and non-free firmware which may be used with drivers in the Linux kernel.

firmware-linux-free: this package contains firmware which was previously included in the Linux kernel and which is compliant with the Debian Free Software Guidelines.

firmware-linux-nonfree: this package depends on non-free firmware which may be used with drivers in the Linux kernel.

firmware-realtek: this package contains the binary firmware for Realtek Ethernet, wifi and Bluetooth adapters supported by various drivers.

 

Linux Supported Filesystems

Many range of file systems are covered by the following modules and they can be detected via installing these packages from the applications repository:

btrfs-progs: btrfs is a new copy on write filesystem for Linux aimed at implementing advanced features while focusing on fault tolerance, repair and easy administration.

exfat-utils: utilities to manage extended file allocation table filesystem. This package provides tools to create, check and label the filesystem.

hfsprogs: the HFS+ file system used by Apple Computer for their Mac OS is supported by the Linux kernel. Apple provides mkfs and fsck for HFS+ with the Unix core of their operating system, Darwin.

jfsutils: utilities for managing IBM's Journaled File System (JFS) under Linux. IBM's journaled file system technology, currently used in IBM enterprise servers, is designed for high-throughput server environments, key to running intranet and other high-performance e-business file servers.

jmtpfs: FUSE and libmtp-based filesystem for accessing MTP (Media Transfer Protocol) devices. It was specifically designed for exchanging files between Linux (and Mac OS X) systems and newer Android devices that support MTP but not USB Mass Storage.

lvm2: the rewrite of The Linux Logical Volume Manager. LVM supports enterprise level volume management of disk and disk subsystems by grouping arbitrary disks into volume groups. The total capacity of volume groups can be allocated to logical volumes, which are accessed as regular block devices.

ntfs-3g: uses FUSE (Filesystem in Userspace) to provide support for the NTFS filesystem used by Microsoft Windows.

reiserfsprogs: utilities to create, check, resize, and debug ReiserFS filesystems.

xfsprogs: set of commands to use the XFS filesystem, including mkfs.xfs. XFS is a high performance journaling filesystem which originated on the SGI IRIX platform. It is completely multi-threaded, can support large files and large filesystems, extended attributes, variable block sizes, is extent based, and makes extensive use of Btrees (directories, extents, free space) to aid both performance and scalability.

 

FreeBSD Supported Filesystems

Many range of file systems are covered by the following modules and they can be detected via installing these packages from the applications repository:

fusefs-ext2: FUSE module to mount ext2, ext3 and ext4 with read write support.

fusefs-hfsfuse: FUSE driver for HFS+ filesystems.

fusefs-jmtpfs: MTP device filesystem.

fusefs-lkl: full-featured Linux BTRFS, Ext4, XFS as a FUSE module.

fusefs-ntfs: mount NTFS partitions (read/write) and disk images.

 

Booting Instruction

 

 

Device Information

 

 

Comparing Professional & Enterprise

 

	Linux Based	FreeBSD Based
Security	@@@@@	@@@@@
Performance	@@@@	@@@@@
Stability	@@@@@	@@@@@
Portability	@@@@@	@@@@@
Compatibility	@@@@@	@@@@
Multimedia	@@@@@	@@@@@
Interface	@@@@@	@@@@
Community	@@@@@	@@@@@
Gaming	@@@@@	@@@@
License	@@@@	@@@@@

 

Security for Linux kernel is extensible via Grsecurity patches depending on the user and company needs.

 

Comparing BSD and Linux

So what is really the difference between, say, Debian Linux and FreeBSD? For the average user, the difference is surprisingly small: Both are UNIX® like operating systems. Both are developed by non-commercial projects (this does not apply to many other Linux distributions, of course). In the following section, we will look at BSD and compare it to Linux. The description applies most closely to FreeBSD, which accounts for an estimated 80% of the BSD installations, but the differences from NetBSD, OpenBSD and DragonFlyBSD are small.

 

Who owns BSD?

No one person or corporation owns BSD. It is created and distributed by a community of highly technical and committed contributors all over the world. Some of the components of BSD are Open Source projects in their own right and managed by different project maintainers.

 

How is BSD developed and updated?

The BSD kernels are developed and updated following the Open Source development model. Each project maintains a publicly accessible source tree which contains all source files for the project, including documentation and other incidental files. Users can obtain a complete copy of any version. A large number of developers worldwide contribute to improvements to BSD. They are divided into three kinds:

• Contributors write code or documentation. They are not permitted to commit (add code) directly to the source tree. In order for their code to be included in the system, it must be reviewed and checked in by a registered developer, known as a committer.
• Committers are developers with write access to the source tree. In order to become a committer, an individual must show ability in the area in which they are active.
• It is at the individual committer's discretion whether they should obtain authority before committing changes to the source tree. In general, an experienced committer may make changes which are obviously correct without obtaining consensus. For example, a documentation project committer may correct typographical or grammatical errors without review. On the other hand, developers making far-reaching or complicated changes are expected to submit their changes for review before committing them. In extreme cases, a core team member with a function such as Principal Architect may order that changes be removed from the tree, a process known as backing out. All committers receive mail describing each individual commit, so it is not possible to commit secretly.
• The Core team. FreeBSD and NetBSD each have a core team which manages the project. The core teams developed in the course of the projects, and their role is not always well-defined. It is not necessary to be a developer in order to be a core team member, though it is normal. The rules for the core team vary from one project to the other, but in general they have more say in the direction of the project than non-core team members have.

 

This arrangement differs from Linux in a number of ways:

1. No one person controls the content of the system. In practice, this difference is overrated, since the Principal Architect can require that code be backed out, and even in the Linux project several people are permitted to make changes.
2. On the other hand, there is a central repository, a single place where you can find the entire operating system sources, including all older versions.
3. BSD projects maintain the entire “Operating System”, not only the kernel. This distinction is only marginally useful: neither BSD nor Linux is useful without applications. The applications used under BSD are frequently the same as the applications used under Linux.
4. As a result of the formalized maintenance of a single SVN source tree, BSD development is clear, and it is possible to access any version of the system by release number or by date. SVN also allows incremental updates to the system: for example, the FreeBSD repository is updated about 100 times a day. Most of these changes are small.

 

BSD releases

FreeBSD, NetBSD and OpenBSD provide the system in three different “releases”. As with Linux, releases are assigned a number such as 1.4.1 or 3.5. In addition, the version number has a suffix indicating its purpose:

1. The development version of the system is called CURRENT. FreeBSD assigns a number to CURRENT, for example FreeBSD 5.0-CURRENT. NetBSD uses a slightly different naming scheme and appends a single-letter suffix which indicates changes in the internal interfaces, for example NetBSD 1.4.3G. OpenBSD does not assign a number (“OpenBSD-current”). All new development on the system goes into this branch.
2. At regular intervals, between two and four times a year, the projects bring out a RELEASE version of the system, which is available on CD-ROM and for free download from FTP sites, for example OpenBSD 2.6-RELEASE or NetBSD 1.4-RELEASE. The RELEASE version is intended for end users and is the normal version of the system. NetBSD also provides patch releases with a third digit, for example NetBSD 1.4.2.
3. As bugs are found in a RELEASE version, they are fixed, and the fixes are added to the SVN tree. In FreeBSD, the resultant version is called the STABLE version, while in NetBSD and OpenBSD it continues to be called the RELEASE version. Smaller new features can also be added to this branch after a period of test in the CURRENT branch. Security and other important bug fixes are also applied to all supported RELEASE versions.

 

By contrast, Linux maintains two separate code trees: the stable version and the development version. Stable versions have an even minor version number, such as 2.0, 2.2 or 2.4. Development versions have an odd minor version number, such as 2.1, 2.3 or 2.5. In each case, the number is followed by a further number designating the exact release. In addition, each vendor adds their own userland programs and utilities, so the name of the distribution is also important. Each distribution vendor also assigns version numbers to the distribution, so a complete description might be something like “TurboLinux 6.0 with kernel 2.2.14”

 

What versions of BSD are available?

In contrast to the numerous Linux distributions, there are only four major open source BSDs. Each BSD project maintains its own source tree and its own kernel. In practice, though, there appear to be fewer divergences between the userland code of the projects than there is in Linux. It is difficult to categorize the goals of each project: the differences are very subjective. Basically,

• FreeBSD aims for high performance and ease of use by end users, and is a favourite of web content providers. It runs on a number of platforms and has significantly more users than the other projects.
• NetBSD aims for maximum portability: “of course it runs NetBSD”. It runs on machines from palmtops to large servers, and has even been used on NASA space missions. It is a particularly good choice for running on old non-Intel® hardware.
• OpenBSD aims for security and code purity: it uses a combination of the open source concept and rigorous code reviews to create a system which is demonstrably correct, making it the choice of security-conscious organizations such as banks, stock exchanges and US Government departments. Like NetBSD, it runs on a number of platforms.
• DragonFlyBSD aims for high performance and scalability under everything from a single-node UP system to a massively clustered system. DragonFlyBSD has several long-range technical goals, but focus lies on providing a SMP-capable infrastructure that is easy to understand, maintain and develop for.

 

There are also two additional BSD UNIX® operating systems which are not open source, BSD/OS and Apple's Mac OS® X:

• BSD/OS was the oldest of the 4.4BSD derivatives. It was not open source, though source code licenses were available at relatively low cost. It resembled FreeBSD in many ways. Two years after the acquisition of BSDi by Wind River Systems, BSD/OS failed to survive as an independent product. Support and source code may still be available from Wind River, but all new development is focused on the VxWorks embedded operating system.
• Mac OS® X is the latest version of the operating system for Apple®'s Mac® line. The BSD core of this operating system, Darwin, is available as a fully functional open source operating system for x86 and PPC computers. The Aqua/Quartz graphics system and many other proprietary aspects of Mac OS® X remain closed-source, however. Several Darwin developers are also FreeBSD committers, and vice-versa.

 

How does the BSD license differ from the GNU Public license?

Linux is available under the GNU General Public License (GPL), which is designed to eliminate closed source software. In particular, any derivative work of a product released under the GPL must also be supplied with source code if requested. By contrast, the BSD license is less restrictive: binary-only distributions are allowed. This is particularly attractive for embedded applications.

 

What else should I know?

Since fewer applications are available for BSD than Linux, the BSD developers created a Linux compatibility package, which allows Linux programs to run under BSD. The package includes both kernel modifications, in order to correctly perform Linux system calls, and Linux compatibility files such as the C library. There is no noticeable difference in execution speed between a Linux application running on a Linux machine and a Linux application running on a BSD machine of the same speed.

 

The “all from one supplier” nature of BSD means that upgrades are much easier to handle than is frequently the case with Linux. BSD handles library version upgrades by providing compatibility modules for earlier library versions, so it is possible to run binaries which are several years old with no problems.

 

Which should I use, BSD or Linux?

What does this all mean in practice? Who should use BSD, who should use Linux? This is a very difficult question to answer. Here are some guidelines:

• “If it ain't broke, don't fix it”: If you already use an open source operating system, and you are happy with it, there is probably no good reason to change.
• BSD systems, in particular FreeBSD, can have notably higher performance than Linux. But this is not across the board. In many cases, there is little or no difference in performance. In some cases, Linux may perform better than FreeBSD.
• In general, BSD systems have a better reputation for reliability, mainly as a result of the more mature code base.
• BSD projects have a better reputation for the quality and completeness of their documentation. The various documentation projects aim to provide actively updated documentation, in many languages, and covering all aspects of the system.
• The BSD license may be more attractive than the GPL.
• BSD can execute most Linux binaries, while Linux can not execute BSD binaries. Many BSD implementations can also execute binaries from other UNIX® like systems. As a result, BSD may present an easier migration route from other systems than Linux would.

 

Who provides support, service, and training for BSD?

BSDi / FreeBSD Mall, Inc. have been providing support contracts for FreeBSD for nearly a decade. In addition, each of the projects has a list of consultants for hire: FreeBSD, NetBSD, and OpenBSD.

 

Directory Structure in Linux

Debian GNU/Linux adheres to the Filesystem Hierarchy Standard for directory and file naming. This standard allows users and software programs to predict the location of files and directories. The root level directory is represented simply by the slash /. At the root level, all Debian systems include these directories:

 

Directory	Content
bin	Essential command binaries
boot	Static files of the boot loader
dev	Device files
etc	Host-specific system configuration
home	User home directories
lib	Essential shared libraries and kernel modules
media	Contains mount points for replaceable media
mnt	Mount point for mounting a file system temporarily
proc	Virtual directory for system information (2.4 and 2.6 kernels)
root	Home directory for the root user
sbin	Essential system binaries
sys	Virtual directory for system information (2.6 kernels)
tmp	Temporary files
usr	Secondary hierarchy
var	Variable data
srv	Data for services provided by the system
opt	Add-on application software packages

 

The following is a list of important considerations regarding directories and partitions. Note that disk usage varies widely given system configuration and specific usage patterns. The recommendations here are general guidelines and provide a starting point for partitioning.

 

• The root partition / must always physically contain /etc, /bin, /sbin, /lib and /dev, otherwise you won't be able to boot. Typically 150–250MB is needed for the root partition.
• /usr: contains all user programs (/usr/bin), libraries (/usr/lib), documentation (/usr/share/doc), etc. This is the part of the file system that generally takes up most space. You should provide at least 500MB of disk space. This amount should be increased depending on the number and type of packages you plan to install. A generous workstation or server installation should allow 4–6GB.
• /var: variable data like news articles, e-mails, web sites, databases, the packaging system cache, etc. will be placed under this directory. The size of this directory depends greatly on the usage of your system, but for most people will be dictated by the package management tool's overhead. If you are going to do a full installation of just about everything Debian has to offer, all in one session, setting aside 2 or 3 GB of space for /var should be sufficient. If you are going to install in pieces (that is to say, install services and utilities, followed by text stuff, then X, ...), you can get away with 300–500 MB. If hard drive space is at a premium and you don't plan on doing major system updates, you can get by with as little as 30 or 40 MB.
• /tmp: temporary data created by programs will most likely go in this directory. 40–100MB should usually be enough. Some applications — including archive manipulators, CD/DVD authoring tools, and multimedia software — may use /tmp to temporarily store image files. If you plan to use such applications, you should adjust the space available in /tmp accordingly.
• /home: every user will put his personal data into a subdirectory of this directory. Its size depends on how many users will be using the system and what files are to be stored in their directories. Depending on your planned usage you should reserve about 100MB for each user, but adapt this value to your needs. Reserve a lot more space if you plan to save a lot of multimedia files (pictures, MP3, movies) in your home directory.

 

Directory Structure in FreeBSD

The FreeBSD directory hierarchy is fundamental to obtaining an overall understanding of the system. The most important directory is root or, “/”. This directory is the first one mounted at boot time and it contains the base system necessary to prepare the operating system for multi-user operation. The root directory also contains mount points for other file systems that are mounted during the transition to multi-user operation.

 

A mount point is a directory where additional file systems can be grafted onto a parent file system (usually the root file system). This is further described in “Disk Organization”. Standard mount points include /usr/, /var/, /tmp/, /mnt/, and /cdrom/. These directories are usually referenced to entries in /etc/fstab. This file is a table of various file systems and mount points and is read by the system. Most of the file systems in /etc/fstab are mounted automatically at boot time from the script rc unless their entry includes noauto. Details can be found in “The fstab File”.

 

A complete description of the file system hierarchy is available in hier. The following table provides a brief overview of the most common directories.

 

Directory	Description
/	Root directory of the file system.
/bin/	User utilities fundamental to both single-user and multi-user environments.
/boot/	Programs and configuration files used during operating system bootstrap.
/boot/defaults/	Default boot configuration files. Refer to loader.conf for details.
/dev/	Device nodes. Refer to intro for details.
/etc/	System configuration files and scripts.
/etc/defaults/	Default system configuration files. Refer to rc for details.
/etc/mail/	Configuration files for mail transport agents such as sendmail.
/etc/periodic/	Scripts that run daily, weekly, and monthly, via cron. Refer to periodic for details.
/etc/ppp/	ppp configuration files.
/mnt/	Empty directory commonly used by system administrators as a temporary mount point.
/proc/	Process file system. Refer to procfs, mount_procfs for details.
/rescue/	Statically linked programs for emergency recovery as described in rescue.
/root/	Home directory for the root account.
/sbin/	System programs and administration utilities fundamental to both single-user and multi-user environments.
/tmp/	Temporary files which are usually not preserved across a system reboot. A memory-based file system is often mounted at /tmp. This can be automated using the tmpmfs-related variables of rc.conf or with an entry in /etc/fstab; refer to mdmfs for details.
/usr/	The majority of user utilities and applications.
/usr/bin/	Common utilities, programming tools, and applications.
/usr/include/	Standard C include files.
/usr/lib/	Archive libraries.
/usr/libdata/	Miscellaneous utility data files.
/usr/libexec/	System daemons and system utilities executed by other programs.
/usr/local/	Local executables and libraries. Also used as the default destination for the FreeBSD ports framework. Within /usr/local, the general layout sketched out by hier for /usr should be used. Exceptions are the man directory, which is directly under /usr/local rather than under /usr/local/share, and the ports documentation is in share/doc/port.
/usr/obj/	Architecture-specific target tree produced by building the /usr/src tree.
/usr/ports/	The FreeBSD Ports Collection (optional).
/usr/sbin/	System daemons and system utilities executed by users.
/usr/share/	Architecture-independent files.
/usr/src/	BSD and/or local source files.
/var/	Multi-purpose log, temporary, transient, and spool files. A memory-based file system is sometimes mounted at /var. This can be automated using the varmfs-related variables in rc.conf or with an entry in /etc/fstab; refer to mdmfs for details.
/var/log/	Miscellaneous system log files.
/var/mail/	User mailbox files.
/var/spool/	Miscellaneous printer and mail system spooling directories.
/var/tmp/	Temporary files which are usually preserved across a system reboot, unless /var is a memory-based file system.
/var/yp/	NIS maps.