Sugegstions: Live CD+HWDB+Lookup+Roadmap...Phew

1

Lo everyone,

Seems progress is happening all over the place and I do know it’s not yet time to release an Alpha. However, I’d like to bring up 2-3 things that will become increasingly important as this Alpha stage get closer.

  1. Live CD
    Not sure what the status is on this functionality but I definitely believe that this would be a brilliant way for people to test whether hardware plays along or not before doing a complete install. This is NOT meant to stress the issue. However, I would consider this a milestone, just as being selfhosting (even though it might not be the same size of milestone). How about adding a milestone in the Dev/Tasks section about this issue to make it easier to track?

  2. HW DB?
    The above also brings me to another point which I know has been discussed at occassions. Where is the official HW matrix so to speak? Is it the one at Haikuware? Is it Bedrivers? Something “official” would be nice. I believe this would also be a neat way of removing HW related issues from the bugtracker as that should consist of more Haikurelated bugs than driver issues, or perhaps I’m mistaken here.

  3. HW Lookup
    Which brings me to issue no 3. I know there been talks about a software that could “check” the users comp about what HW they have and track that info somewhere so that a HW DB would be possible to build up and even track amount of users in need of a certain driver. Possibly this software could also notify the user about the possibility to add a code bounty or add money to an existing code bounty. Maybe this 3rd issue and 1st issue already is what Haikuware is partially about. However, I think there could definitely be some more straight forward info about this officially from Haiku.

  4. Roadmap
    Milestones, roadmaps and bugtrax =). I would propose (Umccollough?) for someone to step forward and highlight a roadmap for the upcoming time ahead. Like what milestones to expect and what is the aim. Previously this has not really been a big issue (at least not for me) as there’s been so much to do all over the place. Today, things seem to actually be working for some (however buggy) and I think it’d be wise to give some sort of indication of where the progress is headed. Not detailed, just roughly.

Like
Autumn 2007: Alpha R1 release which will basically be a selfhosting Haiku platform.
Late autumn 2007: Live CD release with decent network support
Spring 2008: Alpha R2 release which is expected to contain Browser (FFox?) and ability to play music with low latency
Summer 2008: Beta R1…

Gee, note that above was just an example, just to give a pointer to what I figure. I think this would also increase the perception that Haiku is ALPHA, in order to not make people disappointed.

2

This is not only an oft-requested feature, but an oft-misunderstood situation. I have seen this requested hundreds of times in IRC, and many times here on the forums. In most cases people simply don’t understand why it isn’t simple - I guess that is because so many linux distros now provide an ISO LiveCD.

There are few problems I see right now with this feature:

  1. It’s damn hard to make one (harder than it is with a linux distro) - because it currently requires two-track CDs, where the first track is a specially-created boot floppy/cd image and the second track is a BFS image containing the OS. It even makes it worse because several emulators can’t emulate multi-track CDs properly…

I tried using the makebootfloppy script that is in the repo the other day to create the boot image to burn my own LiveCD, and ended up creating a coaster instead. I think the HaikuLiveCDScript from bebits probably does it differently, and perhaps better.

Furthermore, the only software I’ve reliably burned a two-track CD (.cue) from is Nero Burning ROM under Windows…

  1. Driver support is still not that good. People testing LiveCDs are going to be disappointed I think… granted this would be the quickest and easiest way for them to see if their hardware is supported - they’re going to be really annoyed when it isn’t. It takes a reasonable person to look at Haiku’s hardware support and actually appreciate it - but many are going to be angry because their hardware works with Linux, and they don’t understand why it can’t also work with Haiku.

I think someone (me?) needs to put together a FAQ to answer all the LiveCD related questions, and link to it from the Downloads page. This would include answers to “Why can’t a single ISO file be created?”, “Why hasn’t Haiku provided a LiveCD publicly?”, and “What are the plans to support LiveCDs in the future?”

One thing I’ve heard is that it might be best to create a UDF LiveCD image - since UDF supports attributes (required for booting Haiku) and that would possibly prevent the need for a separate BFS image on the CD.

100% agreed here. I think there is one huge roadblock (pun probably intended) preventing this from happening:

Fear of setting and committing to deadlines.

I’ve seen statements like: “It’ll be done when it’s done” and “We can’t set deadlines for volunteers efforts”… I definitely understand these types of comments, but that doesn’t mean you can’t set goals and milestones with dates attached. Statements like that don’t inspire people though. They certainly don’t excite anyone. Sometimes you gotta just put a stake in the ground - you can always move it later if you must.

A roadmap serves multiple purposes - It provides a set of goals and loosely defines them, and it also provides a vague timeframe for those milestones to be completed. Haiku should at least strive for the first part of that, and throw some dates at the second part. If they miss their stated times, then so be it… that’s life - at least you should be closer than you were before, and still have the goals set.

3

Michael’s idea with the whole thing (and I agree) is to not set deadlines because they are always wrong. It’s not fear of setting deadlines, it’s more like good sense not to. The last couple of years I’ve heard some of the guys say “this’ll be the year” and invariably, it hasn’t. It actually looks worse to say “it’ll be done by X” and then have to change it over and over again. Remember how people looked at Vista’s deadlines slipping repeatedly. There really isn’t much left to be done right now except to test and squish bugs. IIRC, the Media Kit needs recording support and we don’t have a DriveSetup app and that’s about it. You also can’t plan for attrition or attraction of new developers. It’s easier to bet a black 5 in roulette and win than it is to set a deadline in the parking lot, let alone the ballpark.

In my experience, driver support has been pretty good aside from SATA. Not perfect by any stretch of the imagination, but pretty good. Video is pretty much covered. All the major sound chipsets are supported. Quite a few network chipsets. USB is probably the weakest, but it also hasn’t received much aside from mass storage and input devices. Not bad for a pre-alpha operating system, if you asked me. :slight_smile:

4

Which is why you set smaller goals and milestones…

When something is so big that it can’t be reasonably quantified, you break it up into pieces, with dependencies, and start setting deadlines.

When you miss a deadline, you readjust the deadlines of all dependencies… standard project management stuff.

Either way, there still is no official declaration of what makes alpha, beta, or final R1 of Haiku… the only thing I think has been mentioned is that Haiku will be alpha when it self-hosts. Deadlines are only part of the process, you still must define milestones.

If you say DriveSetup and MediaKit recording support are the only things preventing us from being feature-complete at least that would be something. I think that’s definitely wrong however, as there are obviously parts of the kernel still missing… and I’m not talking about bugs, I’m talking about TODO’s in the code that are unimplemented. There’s a distinct difference.

I’m also not talking about how much Haiku can do now in pre-alpha state, I’m referring to the lack of definition of what “done” means… or even alpha for that matter. Document it, publish it, and then work towards it. That’s how things get done.

5

Okey, so skip the actual deadline, focus on the definition

R1 = Feature complete and up and running

Alpha R1 = Selfhosting

How about just defining what Beta R1 is?

Skipping dates but keeping the definitions would definitely remove a lot of questions and instead unite people towards a common goal.

Here’s a wild try what Beta R1 might be

  • All features of Alpha R1
  • Working USB 1.0, 1.1., 2.0 support
  • Firewire support
  • 4 gig Mem limit
  • Experimental scheduler implemented that utilizes SMP
  • Printer support
  • Functional media kit
  • Functional self updating utility

skip deadlines and focus on definition for a moment. Phipps perhaps can step in and define some goalS?

6

Setting deadlines is not good if they can’t be met.

For instance, if they say SATA drivers will be done in 1 month. Then it isn’t met. They push it back another month. Still not done. Push it back another month, etc.

What happens is that you disappoint people because you’re unable to meet the deadlines.

Another example, When the new Haiku site came up ( early last year ). On the progress page, it estimated Haiku R1 release date of Oct 2007 ( deadline ). Which was removed from Haiku site after pointing it out to Phipps on OSNEWS post. :slight_smile:

The point is, Haiku R1 won’t come out Oct 2007. Probably 2008 or 2009, but trying to know when something will be done, whether it is a driver, application or the OS is impossible ( because of volunteers working in their spare time; not full time basis )

7

Instead, what would be nice to have is a summary of what major or minor improvements have been done to Haiku ( either on a biweekly or monthly basis ). Sort of a progress report. But this requires someone to be actively watching what is going on & then doing a write up of what has been accomplished ( in the month ). I & others would like to know the improvements that are made to the OS without having to dig through the site for them & trying to figure out the status of this or that. But this requires someone to commit their time & energy to get the info, write it up & then post it.

Haiku Alpha 1 = Self Hosting

Haiku will release Alpha 1 once it is capable of self hosting to attract developers & users & hopefully give the project a boost ( through recognition ).

It is difficult, at this point, to predict for sure what Haiku Beta will have. Other than it’ll be fairly complete. All they can really talk about is Haiku Alpha 1 for now. Once Alpha 1 is released then they can decide & let people know about Haiku Alpha 2 & what it’ll hopefully have. Can’t look too far ahead because things can change. Only can set very short term definitions.

8

I agreed to do this on the mailing list months ago. For the last two weeks I have been keeping a little text file up to date with changes from the SVN list, general list, development list, bug tracker and Glass Elevator. I was intending to release them every week - I have the ability to write blog posts here. The reason the first week’s is not up yet is that I started by noting down nearly all changes, which left me with a lot of editing to do at the end of the week which I still haven’t quite finished yet. After that week I have been more selective in the changes I note, which should lead to quicker editting. I’ll try and get the first couple posted tonight.

Simon

9

Good to hear Simon. I don’t read the mailing list and apparently that is where the action is because I miss out on lots just by sticking to the forums.

If there are enough updates for weekly Reports then great otherwise biweekly is alright also.

Simon, I hope you like my suggestion in the other post because I read through your first update & though it had good information, it felt like I was reading through an essay. And I prefer the structure to be more point form like, so that I can go through it quicker & search it easier.