United States (change)
Shortcuts: Downloads Fedora Red Hat Network
Account Links: Cart Your Account
Red Hat People is an aggregation of blogs kept by individual Red Hat employees. The opinions expressed are their own, and are not necessarily shared by Red Hat, Inc.
May 03, 2008 11:13 PM
May 03, 2008 01:22 PM
May 02, 2008 06:05 PM
May 02, 2008 03:11 AM
The last couple weeks uncovered a few problems in the incremental compiler.
First, suppose you compile a program with the incremental compiler, then recompile it. You would expect to get the same warnings as well. But — whoops — I never thought about this until a week or two ago.
I hate that awful moment of realization. It reminds me of getting in trouble as a kid. “Oh shit”, I think. “What am I going to do? Does this sink the project?”
In this case, there are some options. If the set of warning flags does not change between compilations, I think I can modify GCC to store the warnings with their corresponding declarations. This is a bit of a pain, but nothing too awful — and I think I can avoid imposing a cost on the non-warning case by representing the warnings as tree objects and storing them in the hunk with the other declarations.
If the user does change the warning flags, then what? Record it and recompile, I guess. A similar idea applies to options that change the ABI — because ABI decisions get baked into the tree objects we create, if the ABI changes, we cannot reuse the trees.
My other uh-oh moment has to do with inlining. I got bored by the tedious sub-projects I was working on — integrating pragmas (by the way. If you design a language, don’t design pragmas. Thanks) into the dependency computation, fixing the remaining test suite failures — so I decided today to start looking at incremental code generation. Something fun!
I tried out a quick implementation. If a function is parsed, we arrange to compile it; if it is not parsed, we don’t bother. This won’t work on real programs, of course, since those “missing” functions have to come from somewhere, but this should give a good idea of the possible speedup.
After testing on my typical small test program (zenity), I noticed something odd, namely that recompilations were not as blazingly fast as I thought they should be. (I first estimated the absolute lower bound as the time it takes to preprocess the source files.)
Hmm. A mystery. But first, a brief aside about tools. The compile server forks and runs code generation in the subprocess. I wanted to debug this fork. So, Plan A: use gdb and set follow-fork to child. But… that fails because, although my program does not use threads, it still links in the thread library (relic of my failed threading experiment), and gdb does not seem to handle this well. So, Plan B: maybe ftrace from frysk can help me — all I want to do is see a stack trace at a particular function call, perfect for ftrace. But, the ftrace I have aborts at startup. So I update and rebuild — but there is a build error. I suppose I could have gone with Plan C: stick in a sleep() call and attach, just like I did 15 years ago. Instead I picked Plan D: printf. Not quite as good, since I still need some of that information. Somehow I didn’t feel like Plan E: rip out the threading code and start over at Plan A.
Right now I’m doing a lot of debugging and pretty much every week has a vignette like that. I didn’t do that python stuff in gdb purely for fun.
Anyway. What is going on in the compile server?
What I found is that the code generation process still does some processing on every function, even functions that we intend to drop. In particular it is lowering each function to GIMPLE. I think what is going on here is that GCC is lowering functions and running local optimizations on them so that they can be considered as candidates for inlining. At least, that’s my working theory until I get back to Plan C and dig around a bit.
I’m not totally sure yet what to do about this. I think I will have to go back and rip out the decl re-smashing pass I wrote a while back, and instead find a way to perform gimplification in the server. That way, the compile server can keep the gimplified form for use by the back end. Other than the work involved, and some tricky details in lowering without smashing, I think this will work.
This isn’t going to be pretty, but at least it isn’t a total disaster. I’d like to think this isn’t totally an accident. GCC has undergone a lot of changes in the last five years to make it more flexible internally, and I’ve pushed a little bit more in that direction on the branch. This makes it a bit simpler to change the point at which we put a fork in the pipeline.
It feels a bit strange to write about the mistakes I make. On the plus side, I know how to fix these problems; writing about really unknown problems would, of course, be beyond the pale.
May 02, 2008 12:54 AM
Abstract
This Internet-Draft outlines high-level requirements for the
integration of flexible Mandatory Access Control (MAC) functionality
into NFSv4.1 . It describes the level of protections that should be
provided over protocol components and the basic structure of the
proposed system. It also gives a brief explanation of what kinds of
protections MAC systems offer and why existing NFSv4 protection
mechanisms are not sufficient.
May 01, 2008 06:37 PM
May 01, 2008 05:11 PM
May 01, 2008 04:15 PM
May 01, 2008 12:12 PM
From May 6-9, Red Hat will be in San Francisco, CA at the JavaOne conference in booth #734. Here, you can meet JBoss core developers and attend over 15 different presentations and live demos that will show you how to use JBoss technology to solve real-world problems.
Make plans to join us at our Enterprise Acceleration events around North America too. These events provide the opportunity to hear from Red Hat executives about how IT can enable you to transform your business. You’ll also learn how to move beyond legacy, client server and first-generation Java technology and how to do more with less. JBoss customers will also tell you about the success they’ve had in developing JBoss Enterprise Middleware.
Red Hat executives will also be delivering keynotes at several stops on the CIO Forum and Executive IT Summit this spring. During keynotes, our executives will discuss driving innovation and value across the enterprise with open source, and will draw on the needs of today’s CIOs to map the adoption of open source in the enterprise. Hear how Red Hat is helping customers realize better performance from development to deployment.
We’ll be at the following cities:
Other North American events:
See more Red Hat North American events here.
See more on Red Hat EMEA events here.
For information on Red Hat’s APAC events here.
For information on Red Hat’s events in Latin America, visit here.
May 01, 2008 12:09 PM
Open source now has an established presence in the Australian market and shows significant opportunity for further growth. As recognized in the recently published Australian Open Source Industry and Community Report, when it comes to open source, the continent is also a key center of innovation and world leadership.
The report was compiled by Waugh Partners based on research carried out in late 2007 and it recognizes the many ways that Australia has made its mark on the numerous facets of open source – industry, community, education and skills, careers and employment, innovation, the market and business development.
Some key points in the study:
With new opportunities for development and innovation, the future for open source in Australia looks bright. The Australian Open Source Industry and Community Report confirms a strong market today and forecasts encouraging growth tomorrow.
Working with over 800 customers and over 100 partners in Australia, Red Hat is committed to working with the industry to foster this growth in Australia.
The full Australian Open Source Industry and Community Report is available here.
May 01, 2008 10:34 AM
So I finished off Jan’s initial gio OpenOffice.org integration work (i.e. issue 88090 as workspace ucpgio1)
The gio api is a far better fit to the OOo worldview than gnome-vfs is and was pretty straightforward to implement modulo my own bafflement as to why I had an error claiming that mounting share named “X” failed as not existing which incredibly had the root cause that the share named “X” was really called “Y”.
April 30, 2008 06:02 PM
Last week, iHealthBeat posted an 8 minute audio interview discussing the recently announced Open Health Tools consortium. Open source and healthcare has the potential to change the current healthcare IT landscape, enabling healthcare IT vendors to focus on what truly differentiates systems instead of forcing them to invest in developing basic infrastructure. Collaboratively, OHT will focus on developing free, open source healthcare IT infrastructure for use by anyone.
April 30, 2008 12:09 PM
April 30, 2008 08:29 AM
Dear Lazyweb,
I have a short list of questions that I would like to see answered by Microsoft. If anyone from Microsoft wants to answer them, please do. If you are also interested in answers, please forward these questions to your Microsoft contact of choice and add the answers you receive as comment.
1. When will which versions of Microsoft Office and Microsoft Works will be updated to deliver a native implementation of the ISO standardized version of the OOXML document format?
2. As Microsoft claims to be a big supporter of Open Standards, when will which versions of Microsoft Office and Microsoft Works be updated to deliver a native implementation of the ISO standardized version of the ODF document format?
3. In the Microsoft Open Specification Promise only the old version of OOXML which is not an ISO standard is mentioned. When will the ISO standardized version of OOXML be added to the list?
I am honestly interested in answers to these questions.
Jan Wildeboer
April 29, 2008 07:40 PM
Red Hat Information Technology has created a new middleware architecture for our internally-developed applications. Although many of our internal applications take advantage of open source solutions, we have historically used tools such as Tomcat and Perl on a standalone basis and not taken full advantage of our JBoss application stack.
We’ve defined our new middleware architecture based on JBoss technology. This includes an Enterprise Service Bus implementing a Services Oriented Architecture (SOA); Seam, the JBoss integration framework; the JBoss Business Process Modeling suite (JBPM); and Drools, the JBoss rules processing environment.
The entire stack runs on Red Hat Enterprise Linux, taking advantage of the operating system tools for virtualization, provisioning, configuration, and other functionality. The full technical architecture incorporates Cobbler/Koan, JBoss SOA, Xen, LVM, Git, and more.
Architecture Framework
The new middleware architecture is defined as an element within the Zachman framework, in which we consider data, function, network, people, time and motivation mapped against scope, business model, system model, technology model, and detailed presentation. We are excited about the potential of the architecture because it gives us great flexibility while at the same time allowing us to implement projects in alignment with our desired future state. Ultimately, the architecture enables us to reduce complexity while enabling our business users.
Architecture Definition
The internal name for the new architecture is Everest. Among the key underlying elements are the use of the Logical Volume Manager (LVM) to support virtualized guest operating systems and Xen virtualization to assist in the management and deployment of multiple environments.
We use the JBoss Enterprise SOA Platform to provide loose coupling, a messaging infrastructure, process orchestration, protocol translation, adapters, change management, quality of service, quality of protection (encryption and security), and management services. JBoss Seam provides our application framework, unifying and integrating multiple web technologies while reducing complexity for our developers.
Git provide source code management under the new architecture. Git is a flexible, distributed, offline source management tool. It addresses some of the shortcomings of our previous solutions and provides support for parallel development, collaboration and the ability to maintain a consistent deployable branch of the source tree. Git use will result in a smaller, cleaner set of changes to our source code.
Although not strictly part of the run time architecture, Puppet is an important architectural component. Puppet is a configuration management tool that can be used to provide container and system configurations that can be deployed into production without modification. Puppet will also free our Release Engineering team from many manual steps and enable them to move to a review and release mode.
Of course, the entire environment runs on Red Hat Enterprise Linux. We anticipate that some of our developers will use Fedora as an alternative operating system for their development workstations.
Architecture Provisioning
One of the first challenges addressed by the architecture team was the need to provision systems which comply with the new architecture. The deployment implementation supports 20 machine types, ranging from a web-proxy to an ldap service.
The most common types include a host machine, a repo machine, and a JBoss development machine. The host machine type is used to host virtual guests in the Everest environment. It provides a suitable graphical user desktop, automated NFS home directories, a Kerberos login, Xen virtualization, and access to all of the Everest tools.
A repo machine is at the core of Everest. Repo machines are self-contained provisioning, configuration and artifact stores. Repo machines are capable of creating all other machine types, including other repo machines. Features of repo machines include Cobbler for RPM and provisioning, a Puppetmaster for configuration, an Artifactory Maven proxy, Git repos for content under /pub/git, and gitweb running on a known address.
A JBoss development machine is an aggregation of several machine types. (One of the features of the architecture is the ability to consolidate machine types for development and later disaggregate them for the production environment.) Features of the JBoss development machine include the ability to use it on base metal or in a virtual environment; nomachine for remote desktop access; the SUN JDK; an Apache proxy; JBoss Enterprise Application Platform (EAP); JBoss Enterprise Service Bus (ESB); MySQL for JBoss data stores; build tools including Eclipse, Git and Maven; gitweb on a known address; and a Git daemon to serve repos.
Provisioning with Cobbler and Koan
Cobbler is a provisioning and update server that supports deployments via network booting, virtualization, and reinstalls of existing systems. A significant advantage of Cobbler is that it integrates multiple technologies and reduces the need for the user to understand the details of each. The update features of Cobbler integrate yum mirroring and kickstart.
Koan, which is an acronym for “Kickstart over a Network”, is an emerging technology that configures machines from remote Cobbler servers. Koan also enables the use of virtualization and re-installs from a Cobbler server. When launched, it requests install information from the server and creates a virtual guest or replaces the machine it is running on.
We’ve used both these tools as the foundation for deployment of systems complying with the new architecture. In our tests, we can quickly build and deploy a complete development server with no intervention. The provisioning solution significantly reduces both our time to deliver a development solution and to deploy systems in the production environment.
If you’d like to know more about Cobbler and Koan, see the Red Hat Magazine article on Cobbler by Michael DeHaan and the relevant man pages.
Application
We are working with Red Hat engineering, select partners, and the community to share our provisioning vision broadly. Although some elements of the provisioning solution remain as advanced technology and are not guaranteed to become supported elements of Red Hat Enterprise Linux and the JBoss suite, we are confident that the benefits of the solution outweigh that slight risk. We also anticipate that our efforts in IT will facilitate moving the solutions into the mainstream.
More broadly, we are excited regarding the possibilities presented by the new architecture and the capability it gives us to execute our technical strategy. The ability to integrate best of breed applications solutions using a common stack, to project the resulting applications into web environments using common tools, and to take advantage of the scalability and recovery solutions inherent in JBoss will yield substantial benefits.
April 29, 2008 05:29 PM
April 29, 2008 04:23 PM
April 29, 2008 04:01 PM
April 29, 2008 03:27 PM
É. Parece que alguém está enriquecendo com meu nome.
O FolhaInvest, pelo que entendi, é um concurso de investidores. Parece que meu homônimo está indo bem.
Ps.: A dica veio do Edson Tirelli. Valeu!
April 29, 2008 05:09 AM
And in some other news