[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbeos
Subject:    [haiku] Re: Tips on making presentations about Haiku
From:       Urias McCullough <umccullough () gmail ! com>
Date:       2009-08-27 15:03:35
Message-ID: 1e80d8750908270803y22729a10mc8ae17ff9b2b4b84 () mail ! gmail ! com
[Download RAW message or body]

I'm going to build on Jorge's points, since he has nailed most of the
primary ones here (and he knows his stuff, his conference demos are
top-notch!)

On Wed, Aug 26, 2009 at 10:34 AM, Jorge G. Mare<koki@haikuzone.net> wrote:
> Hi Ryan,
>
> Ryan Leavengood wrote:
>>
>> I am going to have two opportunities in the next month to make some
>> presentations about Haiku.
>
> <snip>
>
> Here are a few key aspects that I usually focus on; this is mostly based on
> what I have noticed in the many times that I have presented/demoed Haiku
> over the years and in the context of a general -- mostly non-technical --
> introduction, so not all of it may apply to you; but hopefully it can still
> useful at least as reference. :)
>
> #Responsiveness of the system
>
> Talk about how efficient Haiku is thanks to is multi-threadedness; show the
> servers/apps and their threads (and various priorities) in
> ProcessController; stress the system by running multiple videos and show how
> the system remains responsive even if you turn off one CPU/core: use Pulse
> to do this and to visually show the (high) CPU load. Putting this in the
> context of modern multi processor/core modern desktops as well as netbooks
> and other smaller form factor devices makes a lot of people nod.

This is especially fun with my AA1, because people already expect it
to be a poor performer with the Intel Atom N270.

I usually load up a 480p mp4 of big buck bunny running in media player
(note: uses AC3 audio) along with a copy of ScummVM running Flight of
the Amazon Queen to give some color in the background, then load up
the new Haiku3d demo and scale it down a bit (since it's moving 3d
objects, people love those), and pop open pulse... with both bars
nearly 100% (really just one core with HT enabled), i will disable a
"cpu" and demonstrate that everything is responsive, using alt-f2,
alt-f3 to switch workspaces (sometimes I'll have a few tracker windows
open in the other workspaces so they see the switch), and viewing the
deskbar apps, etc.

I point out that the system has been designed so that the media player
decoding has lower priority over user responsiveness, and thus frames
are skipping as the poor little atom is begging for mercy ;), I then
give back the other HT cpu, and watch as the media player starts
smoothing out again. Sometimes I'll demo how easily one can use
ProcessController to analyze which threads are using the most CPU and
kill them easily.

Usually at this point, people who have netbooks, or understand the
atom's performance limitations are keenly interested ;)

> #Data translators
>
> Show how easy it is to convert a graphic image (or part of it) from one
> format to another. This is what I usually do: take a screenshot of the User
> Guide welcome page, open it in ShowImage, select the logo and D&D it on the
> desktop; repeat the same, but use the right mouse button so that you can
> select the file format when you D&D the clip on the desktop. I always
> install the GOCR data translator (http://www.bebits.com/app/4098) to show
> how easy it is to take a block of text from a bitmap image and convert it
> into text using D&D (from ShowImage). Emphasize the modular aspect that
> allows adding data translators to expand the capabilities of the system and
> applications.

I always forget to install GOCR, but this does demo very nicely. When
showing this particular feature, it's sometimes convenient to
emphasize at this point that because the core OS includes the
"Translation Kit", any native application can make use of these
features including the Media kit, the filesystem queries/attributes,
etc. without having to port some library, or include some 3rd party
dependency. Thus the application development experience is richer and
more streamlined.

> #Code base
>
> A lot of people don't understand the Haiku code base. I always try to
> educate them in terms of what the Haiku code base is comprised of: a lot of
> home brew code, but also (the fork of) the NewOS kernel, OpenTracker (open
> sourced by Be Inc.), FreeType, AGG, FFMPEG and other open source software.
> Note the fact that Haiku includes the GNU tool chain, GCC, bash, etc.; many
> people don't know this.

One of the most common questions that newcomers ask is: "So, is this a
Linux distribution?", and when you say no, they often hesitantly ask:
"BSD?", to which another "no" usually frustrates them visibly :)

I noticed that as a result, we tend explain up front: "What you're
looking at is neither Linux, nor BSD." and then go into a synopsis of
the codebase and its roots as Jorge mentioned above. It's worth
mentioning that some pieces have been borrowed from FreeBSD such as
the net driver compatibility layer, and the in-progress port of the
wifi stack, BSD advocates love to hear this. Mentioning the assortment
of GNU tools we include seems to placate a lot of GNU/Linux advocates,
and they'll sometimes ask to see a terminal window running bash (as
proof that we're not lying?).

> #Why not Linux?
>
> I simply tell people that Linux is great, and that in fact I even use it;
> but that at the same we think there is a better, easier, more end-user
> focused approach to personal computing, and that is what Haiku aims to
> become. When you put that in the context of the what makes Haiku unique and
> (at least potentially) better, most people understand.

I sometimes choose the more flametastic approach and ask an individual
if they've used Linux and ask them what about it annoys them the most.
Admittedly, this tends backfire on me ;) On the other hand, sometimes
they'll give you some good material to work with.

Often times, you'll encounter someone who claims that if we know a
better way to do it, we should help fix Linux instead. At this point,
it's usually good to point out that the fragmentation in Linux makes
this extremely difficult, and that sometimes the best way to fix a
problem like that is to get a fresh start. This one is always
uncomfortable for me, as these types of people seem to be a bit
disconnected from the real world :)

People are going to point out that Linux already has huge momentum,
and a huge base of applications. They're going to ask where our
OpenOffice port is, where GIMP is, etc.

This argument gets harder every year I think, as Linux gains even more
momentum, and incrementally improves its usability on the desktop.

Be sure to mention that many (still-relevant) BeOS apps run on Haiku
unmodified (and be sure to have a couple things lying around that you
can pull up and show).

Also remind people that Linux aims to be a "jack of all trades, master
of none" type of OS. It has a lot of "me too" type features that
aren't terribly innovative in themselves, but often are (sometimes
poorly) copied concepts from other mainstream OSes (Windows, OS X,
etc.). Haiku doesn't aim to include every bell and whistle out there,
but rather the ones that make sense and keep the system simple and
easy to use and intuitive.

> #History & people
>
> When giving a presentation, I usually start by putting Haiku in the context
> of the history of BeOS (I have a timeline slide for that). That and putting
> a face to the project by giving the audience an idea of who we are, how many
> and where serves as a good intro to get the audience warmed up. Be brief
> though.
>
> In general, I have come to the conclusion that people seem to relate better
> to the solution that Haiku aims to provide when presented with a
> well-prepared live demo rather than a verbal presentation with slides. Of
> course it all depends on the topic and your audience; but if I were to be
> asked to give a general Haiku introduction presentation today, I would
> probably dedicate the first 10 - 15 minutes (at most) with a few slides
> (say, no more than 10) and then show the system doing a live demo, to end
> with a Q&A session towards the end.
>
> Finally, prepare in advance and don't assume everything will work as
> expected; For example, make sure that the audio/video files you plan to use
> for your demo play well in the MediaPlayer; in the case of live queries,
> make sure what the queries you plan to demo actually work; it can (does)
> happen that they don't. ;)

Yes :(

I'm always eager to get some last minute changes from SVN, and
sometimes I find things broken the night before a show... Gotta test
everything you plan to demo :)

- Urias

[prev in list] [next in list] [prev in thread] [next in thread]