Weblog

Friday June 29, 2007

Split personalities

Working inside a company that is backing an open source project poses a interesting challege for those who really believe in open source: sometimes you need to take two different perspectives on a situation.

As an employee of Sun, there's no question about what I want to see as the outcome from the OpenSolaris project, but sometimes this is at at odds with what I want from OpenSolaris as an open source community member, where my goals and expectations are much more idealistic. That isn't to say there is anything necessarily wrong with one or the other, just that the goals aren't (and can't) always be aligned.

At what point does having a leg in both camps represent a conflict of interest between the two legs and how do I not end up being torn in two? Do I remove a leg from one camp? Or try and bring both into alignment? Or just give in and wind up crazy?

One element that is becoming increasingly clear is that interacting with the OpenSolaris community using an @sun.com email address, carries a burden that in some instances is too heavy to wear and can quite possibly impede the interaction I'd like to have with the community.

How do other people manage this type of situation?

• Just give up on trying to be in both places, adopt one and withdraw from the other?
• Construct boundaries around the amount/style of interaction with one?
• Or do you never find yourself in such a position because you never see conflicts of interest?
• Does anyone know how people that work on Linux for IBM (or others) fare in this situation?

Thoughts welcome.

Sunday June 24, 2007

Sliding value of the USD...

For many people coming to the USA means coming to a land of endless riches and wealth, and maybe 5 years ago I would have said the same, but right now, as an Australian, moving to the USA increasingly looks like a bad decision as the value of the US dollar continues to slide vs the Australian Dollar. How bad is this slide? Look at this graph from yahoo Year to date, USD/AUD.

At the start of the year, the US dollar bought 1.26 Australian dollars, but since then there's been a drop of around 6.4% to around 1.18. To an Australian working in the USA that has outstanding debts (such as a mortgage) in Australia, this effectively amounts to a real degradation in the value of my salary by the same amount - not exactly what you would call uplifting but at the same time, outside of the control of everyone in my immediate sphere. To put it more succintly, at the start of the year USD$1000 = AUD$1260 but today, USD$1000 = AUD$1180. At this end of the scale, it is only $80, but multiple that number by 10 or 20 or more and it becomes significant.

What is responsible for this change? Lots of things. For one it is intrinsicly tied to the strength of the Australian economy - exporting of coal to places like Japan and iron ore and other basic materials to China is resulting in a windfall to various Australian operations as the hunger of that country to meet its demands from growth. Consequently inflation is running close to the high watermark in Australia, prompting the Reserve Bank of Australia to keep nudging the interest rate up - Australia's interest rates are around 0.75% above the global average meaning that short term cash deposits in Australia are generating a higher return than elsewhere - the current cash rate there is 6.25%. Looking on the US Federal Reserve web site, it would appear that the official interest rate in the USA is about 1% lower - a difference of 16%. Yes, if I was an American looking to invest and make money, I'm sure I'd have a greedy eye or two on what is happening down under.

Update 2/7/2007: at 1USD=1.17AUD, the drop from 1.29 is now 7.14%. Depressing. They say what goes up must come down, but what was up and what was down? 18 hours later, USD$1 = AUD$1.16. Sigh

( Jun 24 2007, 08:35:28 PM PDT ) Permalink Comments [0]

Friday June 15, 2007

The next step for packet interception in [Open]Solaris

The packet filtering hooks project (PSARC/2005/334) delivered a first take on a framework to deliver the ability to intercept packets inline with the processing flow without requiring any additional STREAMS modules to be inserted between IP and the network device driver. Whilst this has been successful in improving performance for IPFilter, the other primary goal of exposing an interface for external use has not yet been achieved. The rest of this blog entry will summarise what the state of play is here and what we need to be doing for the future. The design document for PSARC/2005/334 can be found at: Packet Filtering Hooks Design, 3 Sep 2006

Interface Changes

The goal of software engineering fot the Solaris kernel is have all of the Committed public APIs become stable, so that code can osentsibly be recompiled, or even reused as binary blobs, on any later release. This means that it is necessary to understand in great depth how the interface is going to be used.

For the packet filtering hooks, the design presented for PSARC/2005/334 was for a world without IP Instances (PSARC/2006/366.) IP Instances introduced something very important that was previously absent: a pointer that was the context in which all of the networking code needed to run. For packet filtering, this impacts the interface at which packets are delivered to IPFilter. It also impacts the initialisation/teardown as IPFilter was changed to provide a seperate set of rules for each IP Instance. This one change, introducing context for IP, would have meant an incompatible change was required to the kernel interfaces published - not a position we would ever want to be in by design.

Life being what it is, the existing documentation for PSARC/2005/334 was written without taking into account the changes from PSARC/2006/336, so at this point in time, the documentation of the interfaces is not 100% correct in describing the function calls and parameter lists. Looking forward, we need to revisit this area and update internal drafts of documentation to better reflect these changes so that they can be included in the distribution and published at the appropriate point in time.

Functionality Changes

The biggest problem with PSARC/2005/334 as it existed going into PSARC review was how to manage multiple hooks for the same event, especially when hooks are given license to change the contents of a packet. The first proposal was to use a numbering system that implemented a priority mechanism, similar to what Linux uses today, but this was rejected. The current thoughts on how to proceed with this are to allow two different mechanisms:

• When registering a callback for a particular hook event, allow one of following attributes to be specified:
  • first - put the callback at position #1 in the list
  • last - put the callback at end of position the list
  • before - require that this callback be before another callback
  • after - require that this callback be after another callback
• Allow a command line utility to specify a more absolute ordering, such as "a,ipf,*,y" that overrides the above

Without a final design that is accepted to answer this capability, it is not possible to promote the current API to being suitable for public use. This is one of the major issues that is outstanding today - only one callback can be registered for hooks such as inbound IP packets.

Kernel Socket Interface

At the time the first design was put togehter, there was no work being done on an interface to present an API for kernel socket programming, so some functionality that exists in user space via ioctls was implemented internally with direct function calls instead. An easy example of this is obtaining an IP address from a network interface. Fast forward to today where we do have a project underway to deliver Kernel Sockets, we need to reconsider whether or not it is necessary to retain that direct function call interface or discard it because it duplicates functionality.

Summary of the state of play today

So where are we at today?

Today we have a programming interface that exists in [Open]Solaris where the primary user is IPFilter. The API used is considered to be private (or internal), so strictly speaking it is not available to programmers outside of Solaris development. However, because it will result in various header files being shipped and that the source code can be easily observed, it seems like it is there, ready, waiting to be used.

At this point, the best we can say is that people should look at the PDF above, look at the header files and start to experiment with it, get a feel for how the interface works, how to integate it into your greater source code tree, etc, with the knowledge that whilst it may compile and work cleanly for you now, the programming interface will change, it will fail if another hooks beats you to registering and most importantly, it is unsupported, meaning if someone else outside of Sun has a problem (i.e panic) using it, Sun is not in any way obliged to either fix the problem or provide a patch.

Invitation to ISVs

If you're reading this blog entry and you work for an ISV that is intending to target Solaris for your product or you're working to build a product on top of Solaris and wish to make use of this interface at some point in the future, the best advice is to contact your local Sun sales office and get in contact with someone from our MDE team.

Discussion on changes

If you would like to either comment on the above design doucment for PSARC/2005/334, have some requirements that are currently not being met by this or planned future work, or anything else you'd like to discuss relating to this topic, please join us in the OpenSolaris networking community in the networking-discuss forum. ( Jun 15 2007, 09:09:42 PM PDT ) Permalink Comments [2]

Monday June 11, 2007

Taking Holidays in the USA

I'll preface this by saying prior to 2006 I have been an employee in Australia where 4 weeks holiday leave per year is standard, with some places allowing it to acrue to be "some number of months worth." Sick leave is also generally available on top of that.

As a starting employee at Sun here in the USA, I'm entitled to a meagre 10 days of holiday each year for the first n years, after which it increases to 3 weeks and after more time again, it raises to 4 and thereafter it remains. As a company, Sun is struggling to find a way in which to post a profit and reducing the number of holidays for which they are liable for is one of the goals in which they can play accounting tricks to get there.

But with so few days of holiday available, there is absolutely no incentive to take them because they just don't amount to enough to take a holiday with and so when we're all told to "take a day or two off" to bring back the liability, there is absolutely no motivation for me to do so. Until relatively recently, Sun also liked to tell people in the USA when they would take two weeks of holiday: July 4 week and between Christmas and New Year. This is no longer the case and for that we owe Jonathan a big thank you!

How could things improve? Well clearly Sun wants to limit its liability, so having a cap on the amount of time off a person can take is quite desirable. Giving people n days of holiday to use up, at the start of some "year", rather than have them accrue, would change the nature of the accounting game as the liability would start high at the beginning of each year and reduce over time. However it would enable people to plan for a holiday over the boundary of that "year" that was actually longer than their total holiday allotment for an entire calendar year (good for employees!) Raising the number of days you get as holiday when you start at Sun from 2 weeks to 3 weeks would also be very welcome but if the company sees a high turnover of staff not staying around long then it supposedly doesn't lose as much - if I could make a casual observation about this, it is that it is the people who have been around Sun for longer that seem more inclined to leave, not those who have been around for a short period of time. But the general meme here is that while you have few, you're less inclined to use any until you have too many.

What should Sun do? Personally, I'd like to see everyone entitled to at least 4 weeks holiday per year, whether they're allowed to acrue or not, I don't mind so much. Is it in the best interest of Sun? Well, I'm not sure that any change could make things any worse (except to regress to the previous situation where they told us when we could take holidays.)

End note: It's not clear to me if this (so few days of holiday per year) is normal behaviour for companies in the USA - if it is, I'm shocked that American employees put up with it and don't demand more holiday time off from their employers.

p.s. For all the good that is said about Google, I'm curious about what their policy is, from an academic viewpoint, and if it is skewed to make the employee happy as are many of their other perks.