Older blog entries for sej (starting at number 177)

obi, you have no idea of the depth of my interest in Fresco :-).

As for hardware acceleration of alpha-compositing, yes that's true, though this still relies on access of a framestore (i.e. memory) by a processor. The processor and framestore are probably optimized for the task at hand, but the same option of acceleration is available to the X server I would think.

finkify

ivtools is now available as a fink package on Mac OS X 10.2 (Jaguar), thanks to Ben Hines. Fink is an interesting cross-breeding between Debian's apt-get and the more fluid community of OS X developers/packagers. It proved to be an incredibly slack way of acquiring ghostview and gimp for OS X.

the lost city of Fresco

Once upon a time there was a resolution-independent cross-platform X11 toolkit called Fresco that lost a standards battle with the entrenched Motif forces. Then there was a built-from-scratch replacement for X11 called Berlin that got nowhere until a fresh group of developers reused the Fresco sources to make their CORBA driven high-level windowing system.

Then after a few more years in the wilderness they decided to change the project name to Fresco, to honor the original sources (which are still available, and still work). It is, above all, an interesting experiment in windowing systems. Elevating the protocol to the level of the original Fresco class hierarchy drastically alters throughput and footprint requirements, while resetting the social foundation of the application space.

And building in anti-aliasing and alpha-transparency from the start might have certain advantages over the X11 extension process. Though not to the extent claimed in a recent slashdot post, where the Keith Packard's approach of grabbing the background to do alpha-transparency on top is ridiculed. I'm quite sure that Fresco (and its renderers) have to rely on an intermediate pixmaps for that as well. And as long as the pixmaps are local to one process (or in shared memory), "grabbing" them is as simple as reading local memory.

(p.s. not to brag too much, but I did scoop the Fresco name change here)

6 Nov 2002 (updated 7 Nov 2002 at 00:24 UTC) »
Debian

Looks like progess in the offing working with Jordi. I really appreciate it.

MacOS X and gcc

The GNU programming suite on MacOS X is the most stable packaging of gcc and gdb I've seen in years, especially for C++ programming. At least this is true for 10.1. I imagine they did the same amount of internal testing and modification to gcc-3.1 on the 10.2 release. Other than missing self-descriptive virtual pointers (but nobody gets these anymore from gcc), I find the interplay between compiler, debugger, and binary format to be extremely reliable and predictable.

Without that foundation I might as well be programming in Java. In a way they are beating RedCyg at its own game, with its own tools. I'm glad somebody raised the bar.

Unidraw

And with that foundation I found (and removed) an ancient bug in Unidraw. It was an out-of-order destruction of global objects upon program termination that had never been caught before. The problem would only show up with an aggressive malloc that intentionally overwrites freed blocks to highlight this kind of error. I love finding old bugs. However, given the possible life of the software, they are really quite young.

Design Patterns aren't the territory

There is a slashdot review of the Design Patterns book today. Good to see publicity for some of the fundamentals of object-oriented programming. But I have to admit, I've only read the introduction.

When I met John Vlissides he said that I must have been the perfect audience for their book, a long-form textual explanation of the underlying design of the software I work with. I said no, for the most part I learned the patterns from the code. Ok, there was a paper or two published early on, but real understanding came from watching the patterns come to life via gdb.

Debian

I sent an e-mail to Anthony Towns, asking if he could explain why ivtools was removed from woody. It would be helpful information for any party considering adoption of the package, as we move forward to Sarge.

ok, I have to retract a portion of yesterday's entry. The RC bug for ivtools reported on debian-devel-announce (#94609) was fixed in March 2002, prior to the final freeze. So it still seems to me ivtools was removed from woody for an undocumented reason, in an undocumented manner.

thom, I've invested time to fix problems that only show up for Debian. Don't you think some sort of reciprocity is in order? Sure, with open-source one can package a distribution without any viable relationship with the developers, but what happens when you need them?

jbucata, is there an all option when searching newsgroups at lists.debian.org? Without that it is quite a task to find those needles in that haystack of newsgroup postings.

4 Nov 2002 (updated 4 Nov 2002 at 06:59 UTC) »
daniels, ok, I could be investigating the wrong mailing list. It's not the first time. But this is where I got that idea. Am I missing something?

So let me check the debian-devel-announce mailing list. There it is, the audit trail of a release critical bug I never knew about it until today, 3 months after the fact (and those were three months of fairly active investigation). I take back what I said about the lack of openness in the Debian process. But I think I have a good case for complaining about the opaqueness of the process, and the fact that a single e-mail to the upstream developer and a single NMU could have rescued the ivtools package from being scrapped from woody. A large part of the problem lies in the fact that I've found no way to search the entire archive of Debian newsgroups all at once - they don't all seem available on deja.com.

2 Nov 2002 (updated 3 Nov 2002 at 15:19 UTC) »
garym, you're not alone in your assessment of the state of affairs in software development. Connection to money/management has the upper hand over connection to the technology, and when inevitable schedule disappointments arise (exacerbated by the richest law-breaking monopolist around), management reverts to its conventional hierarchy to make decisions, and skilled contrarian technologists are jettisoned one way or another.

The keystone issue has been (will be) how to make software more reliable, and software development more cost effective and predictable. Two theories have emerged -- study of the source which promises to make it easy for you after much hard practice versus control by a single all powerful entity that promises to make it easy for you in a little bit.

Of course the money is going to follow the money. However, this leaves intact the disruptive nature of any source intensive approach. There will be innovative businesses that get a competitive advantage by retaining control over their software. After all our efforts in the world of free software, we have a long way to go to reach the level of professionalism and cooperation that are the hallmarks of the medical or legal profession. We've only just begun.

more Debi-aint

daniels I just searched the devel-changes archive for the first 9 months of 2002. There was no discussion of removing ivtools from woody. Yes, there was a single RC bug submitted in April for not building on alpha, and yes the maintainer failed to address it in time (I was unaware of the dilemma, else I might have prodded him to accept my patch in a more timely fashion).

People are under the impression the Debian process is completely open and democratic, but I can tell you from experience that the unwieldiness of the release process, combined with the inevitable time pressure, causes the release manager to make undocumented removal decisions. The salt in the wound is the policy that once released, packages cannot be re-introduced into a distribution, without a security reason or a successful appeal via an undocumented process.

1 Nov 2002 (updated 1 Nov 2002 at 17:30 UTC) »
Jordi, I'm sorry, but that is exactly what happened to ivtools when it got yanked from woody. We still don't know to this date what the actual reason was for yanking. We can assume it was related to a last-minute build problem on the alpha platform, something that was addressed by me but never propogated to the Debian package. But there was no e-mail notification, and it was only listed as a removed package (without cause) after bug reports were filed on the release notes.

One e-mail to me, and one NMU would have fixed the problem. Since this happened I have received no adequate explanation from any involved party, despite several polite inquiries via e-mail and newsgroup. Yes, the previous maintainer has been swamped with other work, and the package is now up for adoption, but that happened after the woody release. I do not believe I am misrepresenting anything, just highlighting something you might not be aware of.

SFO to JFK to SFO

Just back from the big city. I was struck with how dwarvish New York is. Everyone is a cave dweller, albeit with nice silicon-covered portholes to peer out of. And they have many tunnels with many ore cars to shuttle people around. By contrast, San Francisco is obviously quite elvish.

Debi-aint

My admiration of the Debian distribution has faded, as I've been continually exposed to the crankiness of their release machinery. Projects that are perfectly positioned at the start of the two year release process need continual vigilance to keep them in the game, as the constantly evolving standards and practices seem to invent new ways to reject working stuff. If the downstream maintainer gets distracted all their work (and the work of the upstream developer) can be removed from the release without so much as e-mail notification to either party.

I think there is a niche for a public ports-based distribution in the Linux world, similar to FreeBSD. GenToo is the closest I know of, but it seems the dominion of a .com, not a .org.

Off to a consulting job at a company that needs my skills because they laid off the employee who could do the job :-).

168 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!