on the road to 100% openness

Thursday, Apr 26. 2007  –  Category: OpenSolaris

glad to see john is making some progress in the emancipation project.

i don’t think people realise how important this project is to the long-term future of OpenSolaris. as long as we have closed binaries, even the minimal (1 on x86, 2 on sparc) set, we won’t be a completely open source project. john’s work to remove the libc_i18n.a closed binary build requirement will make OpenSolaris completely 100% open source for x86. (the second requirement on sparc is the sparc disassembler).

so bookmark john’s blog and track his progress and give him a cheer every now and then.

No Trackbacks to “on the road to 100% openness”

3 Comments to “on the road to 100% openness”

  1. richlowe Says:
    April 27th, 2007 at 06:07

    There’s also someone (jbk, I think?) working at least somewhat on the sparc libdisasm.

    If both finish, we can kick usr/closed off into an entirely separate gate like the IHV crud. And be free of its evil entirely.

  2. Gavin Maltby Says:
    April 27th, 2007 at 14:50

    The hardware error injectors are closed-source, for both x86 and sparc. They consume source files from the open tree (header files from the cpu and memory controller drivers). They’re in the ON gate to be sure they continue working, ie stay in sync with changes to the open stuff.

    We do not deliver the error injectors in any distribution (*), but this sort of in-sync requirement is not unreasonable. Kicking it to a separate wad will lead to brokeness of an important test asset. So I’m in favour of keep undelivered stuff in a closed tree, if that is at all possible.

    Gavin

    (*) We don’t want to – they make your very-expensive hardware look broken in ways that are difficult to impossible to distiniguish from real broken hardware.

  3. Garrett D'Amore Says:
    May 2nd, 2007 at 08:46

    But this problem is what interface contracts are for. Instead of forcing stuff into the consolidation in order to keep it in sync, it would, IMO, be much better to examine the interfaces required for the error injectors, and get contracts for those interfaces. (Since they aren’t delivered, it doesn’t mean you can’t change the interfaces, but it hopefully reduces the likelihood of the interfaces changing and breaking the injectors in unexpected ways.)

    The other alternative is to open the sources for the error injectors, and deliver the sources, even if the binaries are not delivered. This second option is even better, if there are not legal hurdles preventing it, IMO.

Leave a Reply

Recent posts

Categories

Grommit

Mozilla

OpenSolaris

Songbird

Archives

Meta