LWN.net Weekly Edition for August 9, 2012

TXLF: TexOS teaching open source

The third annual Texas Linux Fest (TXLF) hosted sessions on a range of technical subjects in San Antonio August 3-4 — plus some lesser-known projects that also centered around open source software. An example of the latter was the report from TexOS, a volunteer project that not only provides school kids with computers, but teaches them about open source as well. The project is gearing up for its third instructional cycle, and is looking to expand what it offers.

What it does

The TexOS session was led by Brian Beck, a faculty development staffer at Angelo State University (ASU), and Dr. George Pacheco, Jr, an ASU communications professor. Beck has previously worked with the HeliOS Project, an Austin-based initiative that restores and donates Linux computers to economically disadvantaged children. TexOS is based in San Angelo, but it differs from HeliOS in another way, too. While HeliOS's mission is refurbishing and supporting the donated computers (and doing so in large numbers), TexOS works with smaller groups of students, providing a multi-week training class that introduces them to Linux and open source.

TexOS gets hardware donations from businesses and colleges in the area and it receives referrals from teachers and local nonprofits about potential students. The students must apply to the program, however, and sign a contract. The terms boil down to "be respectful and show up", Beck said, and is primarily a means for the students to take ownership of their participation.

The first round of classes was held in September and October of 2011, and involved students in grades six through eight. The second round was held in February and March of 2012, and involved slightly older students, in grades eight through ten. That age range is a better fit for several reasons; Beck noted that the older students have greater need for a computer since their homework involves more research and writing. Pacheco also joked that the older students were "a little more receptive toward sitting still".

In both rounds, the curriculum is broken up into six sessions spread out over three consecutive Saturdays. An outline of the first round's curriculum is listed on the TexOS project site; it covers topics from installing Linux to using common desktop applications for homework, while exploring basic system administration and shell commands along the way. But there are also non-technical subjects on the agenda, such as collaborative learning, ethical use of root privileges, and fair use of copyrighted material.

About the curriculum, Beck said that it is a common misconception that schoolchildren of today are "digital natives" (meaning that they have been using technology practically since birth, and have no problems adopting it). While that might have been true ten years ago, he said he has found the kids of today function more like "digital zombies" instead: taking technology for granted, taking no interest in how it works, and not knowing what to do when flipping the "on" switch fails. Thus it is important to teach kids about the technology under the hood, hopefully encouraging them to start hacking on their own.

Extending the concept

Beck said that the project is currently setting up for its third round of classes, to be held in October. This time, the team hopes to bring back students from the 2011 sessions to act as mentors to the new class. It is also looking at expanding to four Saturdays, to cover more scientific applications in the lessons. He also asked for input from the audience about how else to expand the curriculum.

One area he would like to explore is introducing the students to programming, but, as he is not a software developer himself, he would prefer to find a quality curriculum developed elsewhere. A few members of the audience had suggestions for such material, but there are surprisingly few projects out there, particularly those designed for a classroom environment. The project would also like to find a viable solution for helping its students with Internet access, Beck said, given that most of the pupils are from lower-income households. As yet, TexOS has not found an affordable option.

Pacheco addressed the project's other new goal: developing a more formal way to assess the students' progress. He requires his own college students to participate in volunteer activities as part of the "service learning" model, and is interested in getting more of them to work with TexOS. Although the TexOS curriculum sets learning objectives for the complete course and for each session, Pacheco would like to see it develop a more structured method for measuring each student's success — both in learning his or her way around the operating system, and in the regular classroom.

Both metrics present challenges. It is difficult to measure a student's aptitude with technology, and privacy concerns mean that the project cannot simply look at a student's grades to assess academic success. But it is a critical step to take for the project, Pacheco said. The project needs to know where the students are and are not benefiting from the course. He did not yet have a plan for incorporating assessment into the curriculum, and was instead interested in hearing from audience members.

The question-and-answer portion of the session took up about a quarter of the allotted time. There were evidently more than a few educators in the audience, and many of them had suggestions for Beck and Pacheco. One of them suggested that teaching programming might be difficult to fit into a short-run weekend class, and that perhaps a continuing-education model might make more sense, with programming as a more advanced topic.

Price versus freedom

I have attended talks on open source in education at a variety of conferences in recent years, and while in some respects TexOS is pursuing a program akin to larger projects (such as HeliOS), it actually has a unique spin on the subject. Most of the projects that utilize refurbished computers fitted with Linux place the emphasis on access to the Internet and affordable software — in essence, making the argument for Linux and open source based on price.

But while it is certainly true that free software lowers the barrier to entry for software by eliminating (or almost eliminating) the price issue, making that the only selling point risks inadvertently teaching the student that open source is "okay for now," but can be dispensed with later when money is not as tight. The TexOS curriculum makes a stronger pitch, teaching the students about the principles behind open source.

Hopefully, in the coming years that curriculum will be expanded, perhaps even teaching programming. As Beck said, educating students about open source software is a "teach them to fish" operation: if they are trained not to hack on their technology, there are limits to what they will learn — whether Linux is under the hood or not.

Comments (6 posted)

Adobe ventures into open fonts

Adobe surprised many in open source circles with its August 2 release of Source Sans Pro, an open font made available under the standard SIL Open Font License (OFL). Adobe has not historically been an open source player (beyond its involvement with standard file formats like PDF or SVG), so Source Sans Pro is not only its first foray into open fonts, but may also herald an interest in adopting open source development methods.

Designer Paul Hunt announced the font in a post on the Adobe typography blog. The font is available in six weights, with regular and italic versions for each. The first release covers an extended Latin character set, but according to the comments other writing systems are reportedly still to come. Downloads are hosted at SourceForge.net.

Hunt said Adobe created the new font to provide a user interface (UI) font for the company's open source software projects, including its Strobe media playback framework and Brackets code editor, both of which are web applications. An open font allows Adobe to control the UI by delivering the font to the user's browser via CSS's @font-face rule.

The design of the font is inspired by early-20th-Century gothics from American Type Founders, such as News Gothic and Franklin Gothic, but it is the original work of Hunt and not a derivative of those originals. This distinction is a subtle one, but comparing Source Sans Pro to News Cycle (which is my own open font designed as a faithful revival of News Gothic), there are clear differences. In addition to miscellaneous differences between specific glyphs, Source Sans Pro is set wider, is a bit rounder, includes a bit more contrast, and incorporates a different approach to accents. Hunt said in the blog post that he intentionally paid attention to distinguishing between l (lower-case L), I (upper-case i), and 1 (the numeral), which was a less common concern a century ago.

Although the font covers "only" Latin characters, the implementation supports a wide array of languages that use the variations of the basic Latin alphabet (such as additional base characters and diacritic marks). Some of the languages supported, such as Vietnamese, Romanized Chinese, Navajo, and various Eastern European languages, are often under-served by even the commercial font industry. The font also includes some typographic features often omitted from open fonts, such as old-style or "text figure" numerals and alternate styles of various letters (such as variations of I (upper-case i) with and without horizontal top- and bottom-caps, which can further distinguish it from l and 1).

There are also Multiple Master (MM) versions of the fonts included in the release, which is unusual. MM fonts are a rarely-employed format developed at Adobe, in which a set of parameters (usually weight and width) can be adjusted at will to change the appearance of the font. For example, an MM font might ship with an Extra Light and an Extra Black version, representing the lightest and darkest ends of the weight spectrum. The user can then use MM to interpolate smoothly between these extremes to find the right look for the project at hand. It is a clever idea, and spares the designer the overhead of producing separate versions for Extra Light, Light, Demi Bold, Bold, Extra Bold, and so on, ad nauseum.

Similarly, the differences between Condensed and Extra Wide versions can be interpolated to produce various widths in between. Software could naively interpolate between two widths of a non-MM font, too, but the naive approach produces undesirable results (such as fattening or squeezing the line widths in addition to the open spaces of the characters). The MM format is designed to produce eye-pleasing output. In practice, though, most people rarely use more than one or two weight or width variations, so MM has not taken the world by storm.

Building

The release itself is in the form of Zip archives, one of which contains the fonts themselves in both TrueType and OpenType CFF format, and one of which contains the fonts plus the source files used to generate them. The contents of the source package will not be easy to take advantage of for Linux users, however. It consists of spline font sources (in Postscript .SFA format), sources for the proprietary Fontlab editor (in .VFB format), and a set of auxiliary text files used by Adobe's build tools. These text files contain information such as hinting, kerning pairs, and tables of characters composed out of other components (primarily accented letters). The auxiliary files are built for use with Adobe Font Development Kit for OpenType (AFDKO), Adobe's "font SDK."

AFDKO implements the font-building portion of Adobe's font development workflow. The glyph outlines are developed in a separate application (such as Fontlab) in PostScript Type 1 format. AFDKO includes proofing and validation tools, plus scripts that add OpenType features (such as substitution rules or stylistic alternates) based on text configuration files like those included with the Source Sans Pro package. It also includes scripts to build installable font files. Although the documentation says several of the individual scripts in AFDKO are open source, the download as a whole is not; the license agreement forbids reverse-engineering. The auxiliary files themselves are not in a standard, documented format that other tools can utilize.

However, that does not mean the auxiliary files are of no value. Some of their information could be extracted with minimal fuss and the judicious application of scripting. Many of the same features can also be extracted from the font files themselves in an open source editor like FontForge. Vernon Adams, developer of KDE's Oxygen font, commented on the blog post that he was interested in extracting the horizontal spacing information from Source Sans Pro and adapting it to Oxygen.

In the purely-open-source font development workflow, adding OpenType features to a font is typically done in FontForge — although it is far from pleasant. FontForge hides the necessary options and tools remarkably well, and effectively dictates that building the final font files be done manually. Better command-line tools like those in AFDKO could help automate the procedure. Intriguingly enough, several commenters in the blog post discussion raised questions about AFDKO, and Hunt replied with interest asking what would be necessary to make the release buildable on Linux.

In reply, Hunt got advice not just on the build process, but on how to set up Source Sans Pro as a "real" project and not just a Zip-dump — including issue tracking, revision control, and a development mailing list. He gave a hopeful-sounding response:

Bug reports and fixes are already beginning to queue up, too. Several on the Open Font Library list noticed problems with the weight values of the fonts (numeric metadata used to sort the various "light" to "heavy" versions of the font). As John Haltiwanger put it, "And (finally) we are legally allowed to fix a broken element in an Adobe font!"

Fonts and project management

Adobe is not alone among open font projects that come up short on bug tracking, revision control, and other development tools. Only a few large font projects tackle these challenges, and they do so in decidedly different ways. DejaVu, Liberation, SIL, and Ubuntu all employ different methods for tracking issues and feature requests, managing source code, merging patches, and making releases. Individuals working on a handful of personal font projects are even less likely to deploy such support utilities.

The lack of formal source code repositories and issue trackers generally means that distributions undertake the work of packaging and testing open fonts. Because Source Sans Pro relies on the non-free Fontlab and AFDKO, one might think it has scant chances of working its way into distribution packages, but Fedora's Ian Weller observed that Fedora's guidelines do not require that a font be buildable with open source software alone — they merely recommend it. A Fedora review request was opened on August 4. There is also a package request for the font in Debian, although Debian's guidelines dictate that a font with a non-free build path will be packaged for contrib.

There are a few inconsistencies in the Zip files, such as which feature files are present in which directories, and which include .SFA versus .VFB source files. Those are problems that source code management would help quash. Hunt also teased the future release of a monospace version of the font, which would be of particular interest to developers. Seeing such ongoing work in the open would also be a nice touch, and would allow the community to contribute to the process. However, one should not lose sight of Source Sans Pro's importance even in Zip format: Adobe has released its first open font, its team seems well aware of the issues involved (licensing and tool support included), and is expressing interest in fitting the project into the expected conventions and procedures of open source.

Comments (27 posted)

GENIVI: moving an industry to open source

Given this editor's recent history (3 years working there), an article on the GENIVI Alliance was perhaps inevitable, and perhaps it's better done sooner while the experience is still fresh. However, GENIVI is more than just a matter of personal interest and experience: the development of GENIVI has some interesting lessons on the adoption of free and open source software, and the results of the consortium's work are soon likely to be directly visible to many readers of this article on a daily basis.

Goals and history

The first question of course is: what is GENIVI? The brief answer is that it is a consortium of companies whose goal is to define a standardized common software platform for developing in-vehicle infotainment (IVI) systems and to nurture a development ecosystem around that platform. IVI systems, known in the trade as head units, are the computer systems commonly found in high-end cars and commercial vehicles—and increasingly in mid-range cars and other vehicles—that provide a range of entertainment and other functions.

Typical IVI functions include control of the media system (e.g., music player, radio, rear-seat video), navigation assistance and location-based services, and display from the rear-view camera on vehicles that provide one. Input to a modern IVI system is via physical wheel devices and buttons or a touch-screen interface, and, commonly, voice recognition. Many modern IVI systems provide integration with consumer-electronics devices via technologies such as Bluetooth and USB. The most interesting such devices are of course smart phones, where integration with the IVI system allows functionality such as playback of media hosted on the phone and hands-free, voice-activated calls conducted via the head-unit audio system. This type of integration also allows conveniences such as automatically turning the volume of the radio down when an incoming caller rings the phone.

The formation of the consortium was announced at the start of 2009, although there is some prehistory to its foundation that we'll briefly return to in a moment. The founding membership consisted of 8 companies that typify several categories of what is by now a much larger membership: automotive manufacturers (BMW Group, PSA Peugeot Citroën, General Motors), tier 1 automotive suppliers (Delphi, Magneti-Marelli, Visteon), Silicon vendors (Intel), and operating system vendors (Wind River Systems, then an independent company, now a subsidiary of Intel). During the subsequent three years, membership in each of the aforementioned categories has swelled (notably, a number of ARM Silicon vendors now balance out the heavyweight Intel among the Silicon vendors). In addition, ISVs (independent software vendors), middleware vendors, and software services companies with an interest in the automotive sector have also joined the consortium, with the result that the GENIVI membership has now grown to over 150 companies spread across Europe, America, and South and East Asia.

Above, I said GENIVI's goal is to define a standardized common software platform. That platform is not a complete IVI system. Rather, it is a packaging of operating system and middleware components that implement a range of non-differentiating functionalities that all IVI systems require. (Bluetooth connectivity is an example of what automotive manufacturers might consider non-differentiating functionality: manufacturers want a working implementation, but don't market their IVI systems to customers based on the Bluetooth implementation.) In effect, one of GENIVI's goals is to decrease the cost of developing the base system, so that developer resources can be devoted to innovating at higher levels in the software stack, such as the human-machine interface.

Linux and open source software were chosen as for the GENIVI software platform during an evaluation project that predated the foundation of the consortium. That project (conducted by BMW, Magneti Marelli, Intel, and Wind River) was motivated by the desire to balance two opposing requirements. On one side stand ever-increasing demands on the development and scope of IVI systems: to drivers, an IVI system starts to look more and more like other consumer electronics devices, and drivers expect to see similar levels of functionality and rapid development cycles. Furthermore, there is a market pressure to see IVI systems in all vehicle categories, rather than just the high end. On the other side, the costs of IVI system development have grown astronomical—a figure of $100 million to bring a solution from the drawing board to dashboard is not unheard of, and such costs are becoming intolerable for all but the largest automotive manufacturers.

In the evaluation phase, a number of platform alternatives were considered, including proprietary systems such as Windows CE and QNX. However, it quickly became clear that a platform based on Linux and free software had the most to offer, based on factors such as the economies available from reuse of software components and, importantly, the realization that free software would allow the greatest degree of control of the content and development of the platform. On that basis, the evaluation project embarked (successfully) on a proof-of-concept implementation of a prototype head-unit system based on Linux and free software components.

GENIVI outputs

In addition to code projects worked on by members, the consortium produces two primary outputs: a compliance specification and a baseline software release.

The goal of the compliance specification is to ensure that compliant GENIVI products ease integration of third-party software components, rather than guaranteeing full API or ABI compatibility across implementations. (In other words, GENIVI doesn't set out to be a standardization body.) Compliance is currently based on self-certification, but in time the plan is move to a more test-driven form of certification. The compliance specification is currently a members-only document.

The GENIVI baseline software release is essentially an internal proof-of-concept for the compliance specification. It is a packaging of the components required by a specific release of the compliance specification on top of a Linux distribution. The baseline isn't directly available outside the GENIVI membership, but is indirectly available via a number of GENIVI respins created by incorporating the baseline component set into an upstream distribution. These respins are created by GENIVI members and available to anyone for download. GENIVI respins are currently created for Ubuntu, Tizen, and Yocto.

What is the problem that GENIVI is trying to solve?

Technically speaking, implementing partial or complete IVI systems on Linux isn't fundamentally different or more difficult than using the platforms traditionally employed in the automotive industry. The pre-GENIVI proof-of-concept work, the recent Cadillac CUE system, and a range of demonstrator systems that appear at the twice-yearly GENIVI member meetings provide ample evidence of that fact. This raises the questions: why don't we already have (more) Linux-based IVI systems on the road and why is an alliance like GENIVI even necessary?

To answer those questions requires understanding that GENIVI's objective is not to solve a software technical problem, but rather to solve a software business problem. Escalating software costs mean that automotive manufacturers need to escape their traditional cycle of constantly reimplementing individually developed, tailor-made solutions for their IVI systems. The name of the game is to share development costs by collaborating on the development of a common, reusable software platform. The challenge then becomes: how does a diverse group of companies transform their traditional business and software development practices, stepping toward a new model to collaboratively define a common platform and bring it to reality? In practice that has proved to be quite a challenge.

The rocky road from prototype to product

To see why the path forward for GENIVI has been difficult requires some understanding of the traditional software development model in the automotive industry.

The traditional approach to IVI software development is rather waterfall in style: the automotive manufacturer develops a set of requirements and then, armed with a large checkbook, enters into a contract with a tier 1 supplier who does all of the software development to fulfill those requirements (in fact, the tier 1 supplier is often tasked with delivering the whole package of IVI hardware and software). Once development is completed, the manufacturer black-box tests the resulting software, and then ships it in vehicle head units. (In this traditional approach, it's worth noting that the manufacturer typically has few software engineers, and does little software development.)

Given their historical role as holders of the checkbooks, it's perhaps unsurprising that automotive manufacturers at first tried to remake GENIVI in the mold that was familiar to them. Thus, in its initial incarnation, although GENIVI's stated goal was to create a (largely) open source platform, the proposed development process was rather waterfall style, driven from the top down by the automotive manufacturers. The proposed process consisted of traditional phases: gathering of requirements, discovering an architecture, mapping the architecture to software components, and then selecting (existing) open source software components, and implementing new components to fill the gaps. Waterfall-style development is prone to be complex and time consuming; what made it even worse in GENIVI's case was trying to the scale the development process to handle multiple participating companies.

For many readers, it is probably no surprise that the results of trying to employ such a model to select and create open source software were not as successful as hoped: internal teams got bogged down in trying to define the process, and the alliance found it too unwieldy to implement in practice. Further complicating the problem was the fact that information was not open equally to all members of the alliance (there were restrictions on access to information such as draft specifications and other in-progress work according to the paid-for level of membership). The consequence of that differential access to information was to further impede participation in the work of the consortium.

What happened in response to the early low participation levels is something of a textbook lesson for any company, or, more particularly, any industry group trying to move to open source. Recognizing the problem, the consortium's Board of Directors implemented some simple but radical steps: membership-based restrictions to information inside the consortium were abolished and the top-down waterfall model described above was replaced by requirements gathering and implementation driven from the bottom, via domain-specific "Expert Groups" that any interested member company was free to participate in. The results of these changes became apparent quite rapidly: the level of mailing-list traffic, wiki activity, scheduled face-to-face meetings, and code contribution all increased dramatically.

Engaging with the open source community

Having read this far, the question you may be left wondering is: is GENIVI open?

From a process perspective, the answer is no. Access to various internal resources such as the wiki, issue tracker, and mailing lists is limited to the (paying) membership. Similarly, attendance at face-to-face meetings is limited to the membership. However, the boundary between members and nonmembers is already somewhat permeable. For example, a number of open source developers with relevant expertise have been invited to GENIVI meetings and provided valuable input—among them Kay Sievers and Lennart Poettering (systemd), Marcel Holtmann (BlueZ, ConnMan, oFono), Samuel Ortiz (ConnMan), and Kristian Hoegsberg (Wayland). In time, it can be expected that the boundary between members and nonmembers may become even more permeable; it's an ongoing process.

From a code perspective, GENIVI is not fully open source, but it's getting steadily closer. As noted above, the GENIVI baseline respins are publicly available, but the repositories of GENIVI-developed code are not (even though the code in those repositories is all under OSI-approved licenses). However, that situation is likely to change quite soon, as moves are afoot to open GENIVI work more widely to the outside world (so that individual GENIVI code projects have open code repositories, bug trackers, and mailing lists). At that point, it's likely that activity on GENIVI will notch up yet further, as outside developers start to take a closer interest in pieces of the code. (It should be noted GENIVI's goal is, as far as possible, to reuse open source software components; new components are developed by GENIVI members only in cases where no suitable free software component can be found. Thus, there are to date relatively few GENIVI code projects, for example, an automotive specific audio manager and a graphics layer management system; the vast majority of the components in the GENIVI respins are direct from the open source ecosystem.)

Looking in the other direction, GENIVI is increasingly participating in upstream projects, with members getting involved via code or conversations in a number of open source projects, such as systemd and ConnMan. In recent times, GENIVI has even been getting involved with kernel development, sponsoring development of kernel patches to improve D-Bus performance. (As noted in an earlier LWN article, the attempt to upstream this work has not so far proved successful. However, D-Bus is viewed as a key component of GENIVI, and it's likely that further work will be done to come up with a kernel solution to improving D-Bus performance that may be acceptable to the maintainer of the Linux networking stack.)

Challenges

There are a number of ongoing challenges for GENIVI, and one or two that remain unresolved. Some of the challenges can be easily guessed at, or can be deduced with a little reflection. For example, as with most open source projects, more contributors would always speed up development.

The process of adapting from closed software development in competition with peers to a model of collaboratively working and sharing ideas (so far, mainly within the membership) is ongoing. For companies that have not previously done so (which includes much of the GENIVI membership), contributing code under open source licenses involves educating both developers and company lawyers. But considering the heavily proprietary origins of automotive software, the progress has already been considerable.

A notable challenge for automotive manufacturers is that, by virtue of being distributors of open source software in their head units, they now need to ensure their engineers and lawyers are well educated about free software licenses. Furthermore, their code management processes need to be adapted to satisfy the obligations of those licenses, in particular, of course, the source code redistribution requirements of the GPL. By and large, the manufacturers seem to understand the challenge and are rising to it.

The GNU GPLv3 remains a so-far unresolved challenge for GENIVI. Already, a small but significant percentage of free software projects use this license, and over time more can be expected to do so. However, automotive manufacturers feel that they can't use software under this license in IVI systems. The problem hinges on the so-called anti-Tivoization clause of the GPLv3. In essence, this clause says that if GPLv3-licensed object code is placed on a computer system, then, either the system must prevent updates to that code by all users (i.e., no one, including the manufacturer, can perform updates) or, if the system does allow updates to the GPLv3-licensed software (e.g., so that the manufacturer can make updates), then the software recipient (i.e., the car driver) must likewise be permitted to update the software. The automotive manufacturers' position is that they need to be able to update the software in an IVI system, but they can't let the driver do so.

The issues for the manufacturers are driver safety, and manufacturer liability and reputation. Even if head-unit systems where fully isolated from the in-vehicle networks that control safety-critical functions such as the braking system (and in most automotive architectures they are not fully isolated), there are features of IVI systems that can be considered safety-impacting. It's easy to see that accidents could result if the navigation system directs the driver in the wrong direction up a one-way street or the picture from the rear-vision camera is delayed by 2 seconds. Consequently, the manufacturers' stance is that the only software that they can permit on the head unit is software that they've tested. Since the GPLv3 would in effect require manufacturers to allow drivers to perform software updates on the head unit, GPLv3-licensed software is currently considered a no-go area. (An oft-proposed resolution to the manufacturers' conundrum is the "solution" that the manufacturer should simply void the warranty if the driver wants to make software updates to the head unit. However, that's not a palatable option: such disclaimers may or may not hold up in court, and they don't protect reputations in the face of newspaper headlines along the lines of "4 killed following navigation failure in well-known manufacturer's car".)

The future

With respect to IVI systems, the future for GENIVI in particular, and Linux in general, looks bright. A number of manufacturers plan to have GENIVI-based head units in production within the next two years. In addition, at least one other Linux-based product (the Cadillac CUE) is already in production, and other Linux-based systems are rumored to be under development. Overall, a substantial body of automotive interest seems to be coalescing around Linux, so it's perhaps no surprise that the Linux Foundation is organizing the second Automotive Linux Summit next month in England. It seems likely that in a few years, we'll be living in a world where Linux in automotive IVI systems is as common as it is in today's consumer electronic devices.

Comments (79 posted)