Free thin layer software for linux

Thinux is a thin client system that resides on a Red Hat Linux server. When a thin client requests to boot on LAN, the server will upload the thin client linux system to the thin client. Ideal for lightweight devices such as Point-of-Sales terminals, embedded devices, etc.

WidgetServer (WiSer) is a Java/XML server-side GUI-framework which enables an application to run as either
- a monolithic application with a Swing GUI,
- a client/server application with a thin Swing client,
- or as an application with a rich Web client based on HTML and JavaScript
without any change!
The framework supports a mixed deployment mode, which enables one server to serve Swing clients and Web clients at the same time. A XML markup language helps to define an applications GUI.
Furthermore a common widget-based, object-oriented programming interface for Web and Swing GUIs is offered to the developer to control and assemble the GUI. This prevents from struggling with HTML, JavaScript and HTTP requests or from caring about the internals of Swing (e.g. Drag&Drop implementation).
For Swing client/server applications the framework cares for the client/server split as well as for the client/server communication including compression and security layers. The functionality of the Swing widget set is covered widely (and sometimes enhanced) in both (Swing and Web/HTML) client channels.
The project comes with a WYSIWYG GUI-builder which is completely build on the Wi.Ser-framework technology.
Main features:
- Support for internationalisation
- Standard widgets like inputfield, combobox, radiobuttons, ...
- Enhanced widgets like treeviews, table, tabbedpanes, splitpanes, ...
- XML configuration to separate GUI definition from application code
- Unified object oriented API for all targeted clients
- Support for drag&drop operations
- GridBagLayout and absolute positioning
- Support for MDI and SDI applications
- Multiple render/templatekits to support individual CIs and multiple browsers
- Preconfigured support for IE and Mozilla
- Snapshot render widget to use individual swing renderers within the framework
- DrawPane widget to create images on the fly
- GUI events like actionevent, clickevent, keyevent, ...can be received and handled on the serverside
- Plugin mechanism to exentd the framework
- Applications are deployed either into a standard servlet container
- or alternatively into the WidgetServer runtime
- Rich functionality for input validation
- GUI builder, examples and tutorial

The purpose of the SurakWare Base Library (SWL/libswl) is to serve as a platform independent development framework for C++ and QPascal.
The SWL includes both thin layers over functionality exposed by the Linux and Windows operating systems as well as higher level classes for many purposes. Save for a few exceptions, the SWL is completely indpedenent from the STL and the C/C++ runtime library.
Platform independence has been achieved by encapsulating OS-specific implementation details in a number of SWL classes. There should never be a need to use "#ifdef"s to distinguish between platforms.
Enhancements:
- Some memory and file descriptor leaks were fixed.
- Some buffer indexing problems were fixed. I/O dispatcher problems on high load notifies were fixed.
- TFile::directory() was fixed.
- TEventManagers add/remove operation logic was improved.
- TNullEnumerator::moveNext() was fixed so that it returns false rather than throwing an exception.
- Some 64-bit vs. 32-bit compilation fixes were made.
- TStream::readTimeout and writeTimeout were backported from trunk to 0.4 (and thus introduced EIOTimeout exception).
- General improvements were made to TArgumentEvaluator and TAnsiColor.
- General code cleanup was done.

libmsntp is a full-featured, compact, portable SNTP library. SNTP (RFC 2030) is a simplified version of NTP (RFC 1305), which allows precise synchronization of system clocks over a best-effort network.

libmsntp provides SNTP client and server functionality in a shared library with a simple API.

libmsntp is implemented as a thin layer on top of msntp, N.M. Maclarens command-line SNTP utility. msntp is compact, straightforward, and elegant, and Im indebted to Nick, and to the Cambridge High Performance Computing Facility, for providing the msntp source to the public.

Installation:

To install, type "make install". You may need to be the superuser. libmsntp installs into /usr/local by default; to install to a different location, edit the Makefile and change the PREFIX variable.

Pluto is the Reference Implementation of the Java Portlet Specfication. The current version of this specification is JSR 168.
Portlets are designed to run in the context of a portal. They are written to the Portlet API which are similar to the Servlet API.
In contrast to servlets, portlets may not do things like sending redirects or errors to browsers directly, forwarding requests or writing arbitrary markup to the output stream to assure that they don?t distract the portal web application which uses them.
Another difference compared to servlets is that portlets rely on portal specific infrastructure functions such as access to user profile information, standard interface for storing/retrieving persistent settings, getting client information, etc. Generally,
portlets are administrated more dynamically than servlets typically are.
A portlet container provides a runtime environment for portlets implemented according to the Portlet API. In this environment portlets can be instantiated, used and finally destroyed. The portlet container is not a stand-alone container like the servlet container; instead it is implemented as a thin layer on top of the servlet container and reuses the functionality provided by the servlet container.
Pluto serves as portlet container that implements the Portlet API and offers developers a working example platform from which they can test their portlets. However, its cumbersome to execute and test the portlet container without a driver, in this case, the portal.
Plutos simple portal component is built only on the portlet containers and the JSR 168s requirements. (In contrast, the more sophisticated, Jetspeed project concentrates on the portal itself rather than the portlet container, and considers requirements from other groups.)
Enhancements:
- Added Pluto 1.1 index page and basic documentation
- PLUTO 164: response contentType can change after getWriter()
- PLUTO 155: URL encoding in pluto 1.0.1-RC4 issue when using apache with jk2
- PLUTO 157: portlet.tld taglib is using jsp version 1.1. JSR168 spec requires JSP version 1.2
- PLUTO 152: Support maven deployment to a remote repository
- PLUTO 130: portlet:namespace fails inside JSTL c:set
- PLUTO-107: Admin portlet fails to add page. Hot deployment now supported.
- PLUTO-92: Deployer strips elements from web.xml (Deploy War Portlet)

PXES project is a micro Linux thin client distribution. PXES will boot a real thin client or will help to convert in minutes any compliant hardware (see list bellow) into a versatile thin client.
They will be capable of accessing any XDM server presenting the graphical login screen or any Microsoft Terminal Server through RDP protocol. The actual configuration of clients is made with an easy to use graphical configuration tool, allowing the specification of clients parameters or the server to access to.
You can recover hardware that is useless running current desktop OS or office package and give it a second chance. This thin client boots from the network with PXE (Intel Pre-Execution Environment specifications) so neither boot diskette nor boot eprom is needed.
The linux kernel and an initial root filesystem is transmitted over the network (the compressed size as of version 0.4 is about 4M).
Main features:
Supported servers and protocols
- Unix/Linux supporting XDM
- Microsoft Terminal Server using RDP
- Citrix using ICA
- VNC using TightVNC
- LOCAL local graphical session with simple desktop
- LTSP or K12LTSP
- IBM Host using 3270 or 5250 emulation (soon)
- Telnet emulating ANSI terminal
- SSH
- Tarantella using proprietary protocol
- NoMachine using NX
- Thinlinc
Boot methods
- PXE network card included in most modern PC hardware
- Etherboot to boot from diskette or EPROM
- CD-ROM
- Hard disk
- DOC DiskOnChip and DOM DiskOnModule
- USB Storage
- For Hard Disk, DOC, DOM or other flash memory installation you may also use PXES HD/DOM Installer (http://pxes.sourceforge.net/enterprise/install-dom.shtml) which is part of Enterprise Edition (http://pxes.sourceforge.net/enterprise/index.php).
- You can also see the detailed information about Boot Methods.
Hardware requirements
- Processor: x86 architecture (i486, i586, i686, VIA C3, Geode, Vortex86, Transmeta Crusoe, etc.)
- BUS: PCI recommended (although ISA works)
- RAM: 32 Mb recommended (16 Mb minimum)
- NIC: see supported network card list
- Video: see supported video card list
Local devices
- Diskette
- Hard disk
- CD-ROM
- Printers parallel, serial and USB
- Serial devices (bar code reader, etc.)
- Audio
- Flash memory / USB storage
Supported operating system
- Linux
- Solaris
- AIX
- SCO
- BSD
- HP-UX
- Microsoft Windows NT4
- Microsoft Windows 2000
- Microsoft Windows 2003
- Microsoft Windows XP
Enhancements:
- Support for different boot loaders was added.
- Support for GRUB on ISO images was added.
- A correction was made in the kernel and image path in isolinux.
- A message telling the user to run "pxesconfig --updatefstab" was added.
- updatefstab was added in post.
- Support for 2.4.32 and 2.6.15 kernels was added.
- Automated owner and permission changing on specific files was added, so now the whole pxes-base tree can be checked out as a normal user.

JMagick is an open source Java interface of ImageMagick. It is implemented in the form of Java Native Interface (JNI) into the ImageMagick API.

JMagick does not attempt to make the ImageMagick API object-oriented. JMagick project is merely a thin interface layer into the ImageMagick API.

JMagick currently only implements a subset of ImageMagick APIs. Should you require unimplemented features in JMagick, please join the mailing list and make a request.

IrNET is a protocol allowing to carry TCP/IP traffic between two IrDA peers in an efficient fashion. It is a thin layer, passing PPP packets to IrTTP and vice versa. It uses PPP in synchronous mode, because IrTTP offer a reliable sequenced packet service (as opposed to a byte stream). In fact, you could see IrNET as carrying TCP/IP in a IrDA socket, using PPP to provide the glue.

The main difference with traditional PPP over IrCOMM is that we avoid the framing and serial emulation which are a performance bottleneck. It also allows multipoint communications in a sensible fashion.We can automatically handle incomming connections through irnetd.


The main difference with IrLAN is that we use PPP for the link management, which is more standard, interoperable and flexible than the IrLAN protocol. For example, PPP adds authentication, encryption, compression, header compression and automated routing setup. And, as IrNET let PPP do the hard work, the implementation is much simpler than IrLAN.

IrNET was first introduced by Microsoft in the IrDA stack of Windows 2000, and they decided to remove both IrCOMM and IrLAN in favor of IrNET in their new IrDA stack. IrNET is a great idea (removing IrLAN and IrCOMM, on the other hand...), however IrNET is not an IrDA specification (at least, not yet, but there are rumors of something called IrDial...).

IrNET has been included in Linux kernel 2.4.0-test11, so all subsequent version of the kernel should support it out of the box (provided everything is set up properly). The latest version is in Linux kernel 2.4.15.