“Last Friday Oliver and I met up to discuss the state of things and how we intend to proceed. The run-time support for package management in Haiku (in the package management branch, of course) is in pretty good shape already. With the system itself and all the third-party software living in packages the system boots and is fully functional.”
I think they’ve picked a really nice way to do package management. You can install an application or just run it from anywhere, use a repository or download a package yourself from any site, it has dependency resolution, and different versions of the same package can be installed at once.
I plan on writing more software for Haiku when package management is done.
Edited 2013-03-30 00:00 UTC
I like it. Mixes *nix and Mac approach to it in the right way.
You mean *nix and RISC OS’s approach
IIRC, NextStep (yeah, I probably got the capitalisation wrong :p ) had it at around the same time as RISC OS. And NextStep 1. was probably more influential 2. lives on as MacOS.
If one looks at the respective release dates, they are so close together that the OS more than likely independently developed the same feature. The NextStep version did become more famous, and ultimately pushed the design further, given that it allowed multi architecture binaries in the bundles that supported IA32, 68K, SPARC and HP RISC in one.
If only that IA32 version of NextStep was available since the beginning, the PC world could be very different now…
Oh well, maybe still something will come out of GNUstep.
Well, as with all great OS designs, it’s not till the mass market is tapped that they get traction. Next was just too late to the party. But OpenStep actually runs quite well on modest PC hardware and under emulation.
There’s also a version of the OPENSTEP API that actually runs on top of Windows NT. Well, two versions… one circa OpenStep, one circa Rhapsody. It kind of runs a bit screwy on a multi monitor set-up, but it has a version of Project Builder and Interface Builder that run under NT, a full compiler that targets Objective-C and C/C++, as well as a bunch of examples. I believe it even supports the Java bridge. It’s pretty cool.
I’m not familiar with RISC, so I couldn’t possibly comment.
Not sure about RISC OS, but if you mean the ability to run everything from the same directory, that used to be the way back then with any OS.
MS-DOS, Atari ST, Mac OS, Amiga
Only with Windows did the installers got into the habit of putting files everywhere.
Yes, also here’s hoping these contracts finally bring package management to such a finished state that it no longer acts as a R1 showstopper.
Of course being able to upgrade my Haiku system with a simple shell command or a gui button click will mean a great deal for useability.
I’d love to see R1 released this year, and with that a gradual migration away from Beos r5 backwards compability and all the system cruft baggage that came along with it.
I think Zima is correct that even if RISCOS had something first, NeXTStep was more influential in making it popular, both by itself, and because it is the basis for Mac OS X.
Ironic that things that keep Haiku from Release 1 are ‘cruft’ left over from its BeOS legacy. As I recall, BeOS’ speed and performance came largely from dropping support for applications from legacy OSes (Mac and Windows) and legacy CPUs (you had to have a PowerPC Mac or Pentium or 486? nothing older would do). Thus backward compatibility with BeOS (to whatever degree it exists) slows Haiku development in a way that the original BeOS programmers would likely frown upon.
That’s not correct, the remaining missing pieces have pretty much nothing to do with R5. The biggest thing keeping us from R1 is plain and simply time and manpower, there aren’t all that many of us working on it, and many of those who remain have started families in the intervening years, which drastically cuts down on available free time.
This incessantly repeated meme that R5 compatibility is what slows us down really needs to stop because it’s completely wrong. The amount of effort required to maintain that is, and has been for years, negligible.
That whole binary compatibility makes no sense 13 years later. Seriously, the remaining software with available sources can be recompiled in no time and most of the closed/proprietary old time BeOS apps aren’t working properly in Haiku a4 anyway.
I’d suggest to break the legacy binary compatibility and focus on full-on Qt port with multimedia and all that jazz. Let Haiku R1 be GCC4 only, at least there’s a chance of getting some new software without scaring the developers away with older build tools and things like that.
You seem to have misunderstood what I wrote (if you were basing your comment on mine), I stated that ‘package management’ is a R1 showstopper.
Package management has nothing to do with Beos R5 ‘cruft’, however by reaching R1 (which is prevented by the lack of functional package management), Haiku can start moving towards R2 and with it start leaving Beos R5 and all it’s baggage behind.
And with baggage I mean things like GCC 2.95 binary compability and really bad core stuff like B_MAX_CPU_COUNT/system_info.