Reconstructor is an Ubuntu GNU/Linux CD Creator.

It uses the Desktop(Live), Alternate(Install), or Server disc as a base, and then allows for user customization.

For the Ubuntu Desktop base, you can customize the entire environment. For instance, you can add/remove software, change the default look (splash, themes, fonts, wallpaper, etc.), add desktop links, etc.

For the Alternate and Server bases, you can add any additional software to the disc that you would like installed.

Reconstructor is written in python and is licensed under the GNU General Public License (GPL).

It uses the Ubuntu Linux Live CD as a base, and then allows customization of boot screens (usplash), gnome settings, and software (you can also use the chroot environment to make other changes before creating the live cd).

Reconstructor does not create separate distros. It keeps the solid Ubuntu foundation, and just allows for customization. For example, create a custom Live CD with blender, inkscape, etc. included for a friend in graphics, or simply use reconstructor to re-brand your environment (wallpaper, fonts).

Links:

http://reconstructor.aperantis.com/

http://code.google.com/p/reconstructor/

Security is a top concern: How can we provide tools that help our customers address security—not merely from an operating-system perspective, but also from a position of addressing the whole picture?

It’s not just operating systems but all the things we need to do. We need to do a lot more on a lot of different planes to help people make the software more secure. We have shown that we know how to make our own software secure, but we have not yet fully enabled our customers to make their own software fully secure. From my perspective, it’s a multitiered approach; operating systems and virtualization are definitely important, but you need the right runtime environment, the right software-development tools, and the right process—something we have not talked about much to date. You can talk about formal methods, but there is more to it than that, so that you can address how you go about developing your software so it is more secure and still meets the same time-to-market demands that you have.

Most applications cannot afford $1000 per line of code to ensure the same level of reliability as the space shuttle; the reality is that most of the software in the world does not need to be at that level. If you have a computer system running Windows, Linux, and application code, it might have 100 to 200 million lines of code running on it. How much of that code is high assurance? Only about 20,000 to 30,000 lines of code of that—say, the kernel and a couple of other special components—need to be fully secure.

The things we’ve learned about making our own software secure are streaming out in bits and pieces into our product base, but there is room for a lot more, such as in the automated-testing area, coding-standards enforcement, and tools that help you more reliably develop software. There are also the process things, and this area is one we have not historically been pushing much at all, but we are starting to touch more on it now.

“Virtualization” is a term that the industry is using across multiple contexts, such as design-time and runtime virtualization. Should the industry be using a single term to describe an abstraction concept to apply to multiple contexts?

The term “virtualization,” when you use it as an abstraction of anything, is too general. I have been pushing to use different terms to distinguish between the contexts because using a single term for all of them is confusing. Design-time virtualizations often refer to hardware-, software-, and co-prototyping tools that act as development platforms before the hardware is ready to support parallel development and shorter design cycles. I have proposed using the term “virtual prototype” to refer to these types of abstractions, and it may even be appropriate to have different terms for each of these types of prototypes. For runtime-virtualization tools, I like to use the term “virtual machine,” or “virtual-machine monitor,” or even “hypervisor” to apply to runtime virtualization, especially because no one has previously used these terms, especially “hypervisor,” to refer to virtual-prototype contexts.

Links: http://www.edn.com/article/CA6518694.html

The Linux operating system (OS) has earned strong interest and adoption from those in the embedded software development community who are looking for cost-effective OS support for their latest embedded devices. In parallel, proprietary real-time OSs (RTOSs) offering robust arrays of services that are comparable to those in Linux have gained attention for safety-critical systems and large-scale telecommunications networks. In such applications, these complex RTOSs provide the capabilities that are needed, often including virtual memory, multiple independent levels of security (MILS), and volumes of middleware for security, communications protocols, and support for an array of development systems.

While Linux and complex RTOS products offer such attractive capabilities, they’re also correspondingly difficult to learn and use due to these robust arrays of services. Linux includes hundreds of system services, virtual memory, and tens of millions of lines of open-source code. High-end commercial RTOSs also include many features and lots of code, making them (and Linux) a challenge to master.

Linux’s complexity has created an industry dedicated to configuring and supporting it for use in embedded applications. These companies, most notably Wind River Systems and MontaVista, charge for their services, and their fees are well justified. Likewise, complex commercial RTOSs with hundreds of services, are generally expensive to license, often burdened with run-time royalties, and are relatively difficult to learn and use. For many high-end applications in defense and telecommunications, these complex OSs are necessary, and serve those needs well.

But what about the majority of applications where low-cost development and fast time-to-market are the primary goals and the system’s technical requirements are relatively modest? Many companies developing electronic devices staff such projects with a few engineers in the hopes of containing cost. In these cases, there may be no room in the budget for commercial Linux support or in-house Linux gurus, nor for expensive proprietary solutions. Achieving fast time-to-market and low-cost development demand a simpler approach. There’s little time to sort out configuration complexities, or to learn which of the many services are actually needed.

Links:  http://embedded.com/columns/guest/204801349

Get an overview of the memory management techniques that are available to Linux™ programmers, focusing on the C language but applicable to other languages as well. This article gives you the details of how memory management works, and then goes on to show how to manage memory manually, how to manage memory semi-manually using referencing counting or pooling, and how to manage memory automatically using garbage collection.

Memory management is one of the most fundamental areas of computer programming. In many scripting languages, you don’t have to worry about how memory is managed, but that doesn’t make memory management any less important. Knowing the abilities and limitations of your memory manager is critical for effective programming. In most systems languages like C and C++, you have to do memory management. This article covers the basics of manual, semi-automatic, and automatic memory management practices.

Back in the days of assembly language programming on the Apple II, memory management was not a huge concern. You basically had run of the whole system. Whatever memory the system had, so did you. You didn’t even have to worry about figuring out how much memory it had, since every computer had the same amount. So, if your memory requirements were pretty static, you just chose a memory range to use and used it.

Links: http://www.ibm.com/developerworks/linux/library/l-memory/

Makers of both processor chips and operating systems are well aware of the huge growth opportunities in embedded systems development—for example, in automobiles, where the number of cars in the United States with some kind of “telematics” capability is projected to grow at a compound annual rate of 63 percent over the next five years. Intel opened this month with availability announcements for Pentium-, Celeron-, and XScale-family chips aimed at somewhat more familiar embedded applications such as telecommunications, point-of-sale, media players, and other roles in which one can’t expect to ask for system management assistance from the user.

Also at the beginning of this month, AMD introduced a new reference design for thin-client devices with compact size and low power consumption.

To sell chips into these environments, Intel and AMD need reliable suppliers of companion operating systems that range from Windows CE or XP variants, with their extensive tool sets and other support, to Linux with its vigorous community of open-source developers and value-adding infrastructure architects—and also to well-established real-time operating systems vendors such as Wind River Systems Inc., whose views will be part of a panel discussion on device software trends this Tuesday evening in Mountain View, Calif.

Links: http://www.eweek.com/article2/0,1759,1607953,00.asp

. . . That is a question that crops up with regularity on Linux forums when new users are unable to find the defrag tool on their shiny new desktop. Here’s my attempt at giving a simple, non-technical answer as to why some filesystems suffer more from fragmenting than others.

Rather than simply stumble through lots of dry technical explanations, I’m opting to consider that an ASCII picture is worth a thousand words. Here, therefore, is the picture I shall be using to explain the whole thing:

This is a representation of a (very small) hard drive, as yet completely empty – Hence all the zeros. The a-z’s at the top and the left side of the grid are used to locate each individual byte of data: The top left is aa, top right is za, and bottom left is az. You get the idea, I’m sure. . .

We shall begin with a simple filesystem of a sort that most users are familiar with: One that will need defragmenting occasionally. Such filesystems, which include FAT, remain important to both Windows and Linux users: if only for USB flash drives, FAT is still widely used – unfortunately, it suffers badly from fragmentation.

Links:

http://linux.wordpress.com/2007/04/15/why-doesnt-linux-need-defragmenting/ 

IBM has just published an online article about BusyBox, the single executable file that implements an extensive set of standard Linux commandline utilities in a highly resource-efficient manner. The article explores the purpose of BusyBox, how it works, how to use it, and how to extend it, among other topics.

BusyBox is one of the most widely used open-source applications. It’s used by almost every embedded Linux developer, and can be found on nearly every Linux-based embedded device, not to mention within “normal” Linux servers and desktops (type “busybox –help” on your Linux desktop’s commandline).

Author M. Tim Jones writes, “BusyBox contains simple utilities, such as cat and echo, as well as larger, more complex tools, such as grep, find, mount, and telnet (albeit, with fewer options than the traditional version); some refer to BusyBox as the Swiss Army knife of utilities.”

Jones notes that BusyBox was initially written in 1996 by Bruce Perens, for use on the Debian GNU/Linux setup disk. “The goal was to create a bootable GNU/Linux system on a single floppy disk that could be used as an install and rescue disk,” Jones writes.

The article covers:

• The birth of BusyBox
• How it works
• Configuring and building BusyBox
• Shrinking BusyBox
• Standard commandline options
• Adding new commands

Recently, the BusyBox and uClibc projects joined a conservancy launched by the Software Free Law Center (SFLC) to provide free software projects with “fiscal and administrative services.”

Links:  http://www.linuxdevices.com/news/NS8858676291.html

A typical real-time application involves a task performing some operation within a deadline. For example: storing some data, or updating a display. The task often is designed to repeat such activities ad infinitum, beginning each iteration at the occurrence of a hardware interrupt. This interrupt may be caused by a human clicking a button, a temperature reading, data from a visual sensor, or innumerable other possibilities.

In this article, we’ll discuss Linux, with respect to aiding such systems. For starters, let’s assume that our real-time system involves the following:

• One or more user level tasks
• An interrupt handler
• A single CPU

If there is only a single task to worry about, lots of issues, such as kernel preemptibility, are no longer pertinent. If you are not dealing with hardware interrupts, then, do you really have a real-time system (we include timers here)? If your target system has multiple CPUs then you may have a means of distributing your tasks and interrupts in such a way that the issues discussed, again, are not important.
Links:  http://www.linuxdevices.com/articles/AT5709748392.html

You’ve probably realized by now that there are many ways to add real-time capabilities to Linux based systems. Certainly, one method is to throw hardware at the problem, by running faster processors or employing specialized hardware. For example, specialized peripheral controllers and digital signal processors (DSPs) can offload critical real-time tasks from the main system CPU. However, assuming you want to use the main system processor to manage real-time system events, there are a great many options from which to choose.

Given the somewhat bewildering variety of alternatives, we’ve assembled the LinuxDevices.com “Real-time Linux Quick Reference Guide” which we hope will assist you in locating Linux-based solutions that match your system requirements. Included within this guide is information about . . .

• Real-time Linux Commercial Distributions
• Open-source real-time Linux implementations
• Open source real-time performance enhancements & tools
• Articles and whitepapers about real-time Linux and related topics

Links: http://www.linuxdevices.com/articles/AT8073314981.html

1. What does “real-time” mean?
2. Who (or what) needs real-time, anyhow?
3. How much real-time is really needed?
4. What are the alternative ways to add real-time to Linux?

In this article, we’ll try to clear away the smoke, and provide some perspective on the subject of real-time Linux.

Here’s the plan. First, we’ll define terms like real-time, hard real-time, soft real-time, and learn how real-time performance is characterized. Next, we’ll learn what sorts of systems need real-time, and how much they need. Then, we’ll compare some of the basic approaches used to add real-time to Linux. Stick around, ’cause at the end of the article, we intend to introduce you to a new, evolving “quick reference guide” to real-time Linux products and resources!

Links: http://www.linuxdevices.com/articles/AT9837719278.html