|
|
Application bundles: system integration 02Aug08 In my comments on the recent LWN seed “Will LSB 4 Standardize Linux?”, I made the argument in favour of application bundles: Or even integrate with the OS’ version control system, especially now that Linux has You’d need a package management system that automatically scans built packages for what To provide the context: the discussion was on how application vendors can easily target LSB 4 with a single binary image. My post was in direct response to an argument by another reader, that complicated schemes do not add much real value over tarballs, to which I begged to differ, arguing that the metadata available in bundles make the integration of binary applications much easier. The issue of binary distribution triggers an allergic reaction from some people in the FLOSS community, a reaction that is, in my opinion, rather unwarranted. Even Debian provides, in their non-free repositories, stub packages that will download binary packages and create a standard .DEB package out of them. There are clear advantages to making binary-only applications more well-behaved, in fact the same argument for having package management systems with graph-based dependency tracking in the first place: dependency, dependency, dependency. When installing/upgrading a package, you’d want all its dependencies to be pulled in automatically. When upgrading a library, you want to make sure that all its dependents will still work. When there is a security vulnerability, you want a non-techie end-user to be notified, preferably within a fixed period of the vulnerability being made public (through periodic updates), or the next time the user launches the application concerned. There have been attempts to create a one-size-fits-all universal package format, that’s distribution-independent and vendor-friendly. This is a red herring, IMHO, for the same reason that the Unix market splintered in the ’70s and ’80s, and that we have a proliferation of Linux distributions — and multiple independent BSD operating systems, each of them with their own ports tree (DragonFly being an exception in that they share NetBSD’s pkgsrc system). It’s nice to control your own packaging format, or if it’s a shared format (like RPM is), to control the naming conventions, etc. What application bundles can do is provide the best of both worlds: vendors can ship binary-only bundles that declare dependencies in a least-common denominator format that the LSB can standardize, for example: The first time the bundle is launched, the launcher can add it to its index of available bundles. If any of the dependencies are missing, the system-native package management (or a meta management infrastructure such as PackageKit) is triggered to install the missing dependencies. The bundles themselves can be placed anywhere (though library bundles — in NextStep/OpenStep/OS X parlance, “frameworks” should probably be placed in pre-determined paths, e.g. /Library/Frameworks, /System/Library/Frameworks and ~/Library/Frameworks). The only problem is that the system-provided libraries might not be ABI-compliant with the specified LSB standard, for example, libraries written in C++ after a compiler ABI change. There would probably be a need for the native packages to declare their compliance, or non-compliance, with LSB standards. And one last nice thing about bundles: fat binaries. It’s easy to provide multi-arch bundles, and stripping away unwanted architectures is a simple rm operation. Filed under: FLOSS | 1 Comment
Unlike Apple, Microsoft does not control the hardware that its software runs on. This means that Apple can more easily move all its users to an x64 operating system: all Macs currently have 64-bit CPUs, and Snow Leopard is rumored to be a 64-bit-only release. Windows 7, on the other hand, will still be released in x86 and x64. Microsoft would prefer not to make Windows 7 available on computers with 32-bit CPUs (indeed, Windows 7 Server will be x64-only), but the decision is driven by software compatibility demands.
Filed under: Linux, Microsoft | 0 Comments Planète Béranger has raised the ABI issue surrounding Fedora and RHEL’s recent upgrade to Firefox 3. In short, RHEL 5.2 ships with Firefox updated to the new xulrunner-based Firefox 3, but its Eclipse and libswt3-gtk2 is still at 3.2, which depends on the old gtkmozembed interface. This seems like a good argument in favour of adopting Debian-style package naming, when it comes to libraries: append the ABI version to the (sub)package name containing libraries that are linked to from other packages. So the old Firefox 1.5 would have a libgtkmozembed18 subpackage, that can be shipped with RHEL 5.2 without shipping the rest of Firefox 1.5 (technically speaking, the ABI version is 1.8.x.y, as prior to XULRunner 1.9 the ABI is ever-changing, but packages already handle this by depending on the specific version and release number anyway) This is already done from time to time in the RHEL/Fedora world, in the form of compatibility packages, but making it the default would avoid this kind of breakage, where a package /has/ to be updated (due to upstream EOL) but parts of it are needed downstream. Filed under: Fedora | 2 Comments This will be rather interesting to watch. The idea of writing an OS kernel in a strongly-typed language makes sense — witness House and Singularity. The effort is not expected to be ready for years — this is not Windows 7, and I’d guess there will still be a traditional Windows 8, even if Midori is ready by then. Incidentally, the OSS community already has a strongly-typed virtual machine designed for efficient native code generation: LLVM. If one takes a Unix kernel (or, more practically, microkernel) and get it to compile using LLVM’s C front-end, one then has the opportunity to gradually rewrite it one module at a time in any language with LLVM front-ends. In the time it will take for Midori to get ready, would there perhaps be an ML-like front-end to LLVM? clipped from arstechnica.com Every once in a while, an article gets posted somewhere in the blogosphere about how Microsoft needs to release a complete Windows rewrite, something along the lines of what Apple did with Mac OS X. Most people realize that Microsoft is in no position to pull a stunt like that at the moment; it’s hard to see Microsoft phasing out support for a billion-Windows-PC-strong user base, but that day may one day come, perhaps thanks to robust virtualization technology.
But in the meantime, Microsoft has settled on rewriting bits and parts of the Windows operating system as it sees fit, with Vista being one of the biggest rewrites (a fact which partially explains the many hardware and software compatibility issues XP’s successor experienced at launch). Speculation around a non-Windows operating system in the works at Microsoft has been present for years, but recent trustworthy tidbits of information have found their way into the hands of Microsoft ZDNet bloggers Mary Jo Foley and Ed Bott. |