Changeset 86


Ignore:
Timestamp:
Nov 16, 2006, 10:08:17 AM (19 years ago)
Author:
ktk
Message:

Version for WSE06, first work

File:
1 edited

Legend:

Unmodified
Added
Removed
  • presentations/wse06/wse06.tex

    r84 r86  
    55%% this template is still evolving - it might differ in future releases!
    66
    7 % Voyager presentation for Developers Workshop 2006
     7% Voyager presentation for Warpstock Europe 2006
    88% Adrian Gschwend
    99
    10 %\documentclass{beamer}
     10\documentclass{beamer}
    1111% Handout:
    12 \documentclass[handout]{beamer}
     12%\documentclass[handout]{beamer}
    1313
    1414\mode<presentation>
    1515{
    16   \usetheme{Warsaw} 
    17   \setbeamercovered{transparent}
     16\usetheme{Warsaw}
     17\setbeamercovered{transparent}
    1818}
    1919
     
    2525\beamertemplatetransparentcovereddynamic
    2626
    27 \logo{\includegraphics[height=0.5cm]{dws06.png}}
     27%\logo{\includegraphics[height=0.5cm]{dws06.png}}
    2828
    2929\title[netlabs.org - The Voyager Project]
     
    3838\institute[netlabs.org]
    3939{
    40   netlabs.org - Open Source Software for OS/2 and eCS
     40netlabs.org - Open Source Software for OS/2 and eCS
    4141}
    4242
    43 \date[8.4.2006]
    44 {DWS 2006, Biel, Switzerland}
     43\date[17.11.2006]
     44{Warpstock Europe 2006, Cologne, Germany}
    4545
    4646\subject{OS/2 and eCS development}
     
    4949% \AtBeginSubsection[]
    5050% {
    51   % \begin{frame}<beamer>
    52     % \frametitle{Overview}
    53     % \tableofcontents[part-1]
    54   % \end{frame}
     51% \begin{frame}<beamer>
     52% \frametitle{Overview}
     53% \tableofcontents[part-1]
     54% \end{frame}
    5555% }
    5656
     
    5959
    6060\begin{frame}
    61   \titlepage
    62 \end{frame}
    63 
    64 \begin{frame}
    65   \frametitle{Outline - Voyager}
    66   \tableofcontents[part=1,hideallsubsections]
     61\titlepage
     62\end{frame}
     63
     64\begin{frame}
     65\frametitle{Outline - Voyager}
     66\tableofcontents[part=1,hideallsubsections]
    6767\end{frame}
    6868
    6969\part{Voyager}
    7070\section{History}
    71 \subsection{The Idea}
    72 \begin{frame}
     71
     72\begin{frame}
     73\begin{alertblock}{Warning}
     74This is not a very technical presentation!
     75
     76(Please don't walk out now ;-)
     77\end{alertblock}
     78\end{frame}
     79
     80\subsection{Motivation}
     81\begin{frame}
     82\frametitle{One Year Ago}
     83After last years presentation:
     84\begin{itemize}
     85  \item<1-2>Joy
     86  \item<2>Shock
     87  \item<3->\textit{Why Voyager, my eComStation works just fine!?}
     88\end{itemize}
     89\end{frame}
     90
     91\begin{frame}
     92\frametitle{Motivation, Hardware}
     93eCS and OS/2 works just fine \texttrademark
     94\begin{itemize}[<+->]
     95  \item Might be true nowadays
     96  \item Might be hidden for many users
     97  \item We (the developers) know the technical limitations
     98  \item Annoying kernel limitations and bugs
     99  \item Hardware envolves
     100\end{itemize}
     101\end{frame}
     102
     103\begin{frame}
     104\frametitle{Motivation, Other Issues}
     105It's not just about the hardware\ldots
     106\begin{itemize}[<+->]
     107  \item The valuable stuff is done by the same few people
     108  \item Motivation is not what it used to be for various reasons
     109  \item It is annoying and frustrating to
     110  \begin{itemize}[<+->]
     111    \item write device drivers
     112    \item code around bugs
     113    \item port software and toolkits
     114    \item know that the work will be useless in a few years
     115  \end{itemize}
     116  \item Almost no new people are joining the community
     117\end{itemize}
     118\end{frame}
     119
     120\begin{frame}
     121\frametitle{Conclusion}
     122\begin{block}{Conclusion}
     123If we do \textit{business as usual} it will not go on one day.
     124\end{block}
     125\end{frame}
     126
     127\begin{frame}
     128\frametitle{Wouldn't it be nice?}
     129We can now either fall into depression or come up with some idea.
     130
     131Why not
     132\begin{itemize}[<+->]
     133  \item rewrite what we like?
     134  \item profit from existing Open Source Software?
     135  \item \textit{do it right} ourself?
     136  \item start the whole idea on eComStation?
     137\end{itemize}
     138Thus the idea of Voyager was born!
     139\end{frame}
     140
     141\subsection{The Journey}
     142\begin{frame}[allowframebreaks=0.6]
    73143\frametitle{The Idea}
    74 \begin{itemize}
    75       \item long process of thinking about the future for several years
    76       \item first idea with Kernel of MacOS X in Summer 2004
    77       \item first presentation of that idea at Developers Workshop 2005 in Dresden
    78       \item reconsideration of this idea because it doesn't solve the main problem: Desktop
    79       \item new idea with OpenGL based Desktop with well known toolkits, developed at SYSTEMS fair in Munich
    80       \item talks to various people and first presentation of that idea at Warpstock Europe 2005 in Dresden
    81     \end{itemize}   
     144Wind of change
     145\begin{itemize}[<+->]
     146  \item Long process of thinking about the future for several years
     147  \item First idea with Kernel of MacOS X in Summer 2004
     148  \item First presentation of that idea at Developers Workshop 2005 in Dresden
     149  \item Reconsideration of this idea because it doesn't solve the main problem: Desktop
     150  \item New idea with OpenGL based Desktop with well known toolkits, developed at SYSTEMS fair in Munich
     151  \item Talks to various people and first presentation of that idea at
     152  Warpstock Europe 2005 in Dresden
     153  \item Presentation of first concept and design studies at Developers
     154  Workshop 2006 in Biel, Switzerland
     155  \item License decission during Summer 2006
     156  \item First 0.1 release of \textit{The Design of Voyager} released to the
     157  public for Warpstock Canada 2006
     158\end{itemize}
    82159\end{frame}
    83160
     
    85162\begin{frame}
    86163\frametitle{The Goal}
    87         There are many free desktop environments available, like KDE and GNOME. Our focus is different:
    88         \begin{itemize}
    89                 \item SOM like object model, binary compatible (unlike everything else out there on Unix)
    90                 \item provide a WPS like desktop environment (OS/2 "Feeling")
    91                 \item well integrated applications (drag and drop, CUA, etc)
    92                 \item focus on localization right from the beginning (Unicode/UTF-8)
    93                 \item keep unique ideas like IOProcs and reimplement them
    94                 \item use as much existing code/apps as possible (as long as it makes sense), don't reinvent the wheel
    95         \end{itemize}
     164There are many free desktop environments available, like KDE and GNOME. Our focus is different:
     165\begin{itemize}
     166  \item SOM like object model, binary compatible (unlike everything else out there on Unix)
     167  \item provide a WPS like desktop environment (OS/2 "Feeling")
     168  \item well integrated applications (drag and drop, CUA, etc)
     169  \item focus on localization right from the beginning (Unicode/UTF-8)
     170  \item keep unique ideas like IOProcs and reimplement them
     171  \item use as much existing code/apps as possible (as long as it makes sense), don't reinvent the wheel
     172\end{itemize}
    96173\end{frame}
    97174
     
    99176\begin{frame}
    100177\frametitle{The middle-term Goal}
    101         Software takes time to grow, usually more than one thinks. So it is important to have a middle-term strategy as well:
    102         \begin{itemize}
    103       \item the development of this project should be possible on many platforms, including eCS
    104       \item in parallel, we should provide support for the most popular Unix-like systems at the moment
    105       \item eCS developers should be motivated to use SOM for new ideas because code can be reused
    106       \item users can continue to use eCS as we know it today and still get new features
    107       \item in middle-term we can start a smooth migration to the new desktop
    108     \end{itemize}     
     178Software takes time to grow, usually  more than one thinks. So it is important
     179to have a middle-term strategy as well:
     180\begin{itemize}
     181  \item the development of this project should be possible on many platforms, including eCS
     182  \item in parallel, we should provide support for the most popular Unix-like systems at the moment
     183  \item eCS developers should be motivated to use SOM for new ideas because code can be reused
     184  \item users can continue to use eCS as we know it today and still get new features
     185  \item in middle-term we can start a smooth migration to the new desktop
     186\end{itemize}
    109187\end{frame}
    110188
     
    113191\begin{frame}
    114192\frametitle{The long-term Goal}
    115         While eCS is a platform that works fine nowadays we won't have any more support from IBM for new hardware, so in long-term we need something else:
    116         \begin{itemize}
    117       \item a team of interested developers might start working on an OS/2 compatibility layer for Unix like systems
    118       \item in long term we need a new kernel, that discussion is absolutely open right now
    119       \item most of the OS/2 coders don't like the Linux Design so other options are preferred
    120       \item if you can help out on that project, you are very welcome :)
    121       \item final goal: our own distribution based on existing and new software
    122       \item and finally: world domination (aka \it{Stage 3})
    123     \end{itemize}
     193While eCS is a platform that works fine nowadays we won't have any more support from IBM for new hardware, so in long-term we need something else:
     194\begin{itemize}
     195  \item a team of interested developers might start working on an OS/2 compatibility layer for Unix like systems
     196  \item in long term we need a new kernel, that discussion is absolutely open right now
     197  \item most of the OS/2 coders don't like the Linux Design so other options are preferred
     198  \item if you can help out on that project, you are very welcome :)
     199  \item final goal: our own distribution based on existing and new software
     200  \item and finally: world domination (aka \it{Stage 3})
     201\end{itemize}
    124202\end{frame}
    125203
     
    128206\begin{frame}
    129207\frametitle{Voyager Components}
    130         \begin{itemize}
    131                 \item Voyager Object Model
    132                 \item Window Manager (for Cairo and Xlib)
    133                 \item Cairo as GPI replacement (opinions?)
    134                 \item OpenGL based Cairo backend
    135                 \item Xorg OpenGL device drivers (no Xlib necessary in mid-term)
    136                 \item Xlib - see Everblue presentation
    137                 \item open question: Input Handling - who can help?
    138                 \item anything missing?
    139         \end{itemize}
     208\begin{itemize}
     209  \item Voyager Object Model
     210  \item Window Manager (for Cairo and Xlib)
     211  \item Cairo as GPI replacement (opinions?)
     212  \item OpenGL based Cairo backend
     213  \item Xorg OpenGL device drivers (no Xlib necessary in mid-term)
     214  \item Xlib - see Everblue presentation
     215  \item open question: Input Handling - who can help?
     216  \item anything missing?
     217\end{itemize}
    140218\end{frame}
    141219
     
    143221\begin{frame}
    144222\frametitle{Voyager Object Model}
    145         \begin{itemize}
    146                 \item SOM is a binary compatible object model, no need to recompile objects (unlike on GNOME for example)
    147                 \item there are some design documents from IBM itself (published in ACM)
    148                 \item there is quite some documentation available written by former IBM employees
    149                 \item Chris Wohlgemuth started to reimplement SOM from scratch, see Voyager Object Model presentation
    150                 \item drawback: not many people know SOM - but we are used to that fact as OS/2 users ;-)
    151         \end{itemize}
     223\begin{itemize}
     224  \item SOM is a binary compatible object model, no need to recompile objects (unlike on GNOME for example)
     225  \item there are some design documents from IBM itself (published in ACM)
     226  \item there is quite some documentation available written by former IBM employees
     227  \item Chris Wohlgemuth started to reimplement SOM from scratch, see Voyager Object Model presentation
     228  \item drawback: not many people know SOM - but we are used to that fact as OS/2 users ;-)
     229\end{itemize}
    152230\end{frame}
    153231
     
    155233\begin{frame}
    156234\frametitle{Cairo}
    157         \begin{itemize}
    158                 \item modern, open source, cross-platform 2D API
    159                 \item PDF/PS-like 2D API (hint: MacOS X Quartz)
    160                 \item multiple output systems (screen, printer)
    161                 \item OS/2 port exists, not accelerated so far
    162                 \item OpenGL based backend exists, called Glitz (hint: MacOS X Quartz :)
    163         \end{itemize}
     235\begin{itemize}
     236  \item modern, open source, cross-platform 2D API
     237  \item PDF/PS-like 2D API (hint: MacOS X Quartz)
     238  \item multiple output systems (screen, printer)
     239  \item OS/2 port exists, not accelerated so far
     240  \item OpenGL based backend exists, called Glitz (hint: MacOS X Quartz :)
     241\end{itemize}
    164242\end{frame}
    165243
     
    167245\begin{frame}
    168246\frametitle{Voyager Security}
    169         Most desktops nowadays do have security problems, we try to do it better:
    170         \begin{itemize}
    171       \item each developer should think about the consequences of his code in terms of security
    172       \item peer-reviews of sourcecode by other developers
    173       \item there are many papers available regarding security, many are already linked in the Voyager wiki
    174       \item a binary object model doesn't make it easier, Apple had to learn that as well
    175       \item use existing research work know how (like DOpE - http://os.inf.tu-dresden.de/dope/)
    176         \end{itemize}
     247Most desktops nowadays do have security problems, we try to do it better:
     248\begin{itemize}
     249  \item each developer should think about the consequences of his code in terms of security
     250  \item peer-reviews of sourcecode by other developers
     251  \item there are many papers available regarding security, many are already linked in the Voyager wiki
     252  \item a binary object model doesn't make it easier, Apple had to learn that as well
     253  \item use existing research work know how (like DOpE - http://os.inf.tu-dresden.de/dope/)
     254\end{itemize}
    177255\end{frame}
    178256
     
    181259\begin{frame}
    182260\frametitle{Toolkit}
    183         \begin{itemize}
    184                 \item modern toolkits are much simpler to use than PM
    185                 \item GTK+ or qt are the options for existing ones, main toolkit will be GTK+
    186                         \begin{itemize}
    187                                 \item GTK+ is C, wrappers for all kind of languages
    188                                 \begin{itemize}
    189                                         \item SWT for GTK+
    190                                         \item wxWidgets on top of GTK+
    191                                         \item Firefox \& Thunderbird are using GTK+
    192                                 \end{itemize}
    193                                 \item qt is C++ only, one should support it
    194                         \end{itemize}
    195                 \item We don't need yet another toolkit \texttrademark
    196         \end{itemize}
     261\begin{itemize}
     262  \item modern toolkits are much simpler to use than PM
     263  \item GTK+ or qt are the options for existing ones, main toolkit will be GTK+
     264  \begin{itemize}
     265    \item GTK+ is C, wrappers for all kind of languages
     266    \begin{itemize}
     267      \item SWT for GTK+
     268      \item wxWidgets on top of GTK+
     269      \item Firefox \& Thunderbird are using GTK+
     270    \end{itemize}
     271    \item qt is C++ only, one should support it
     272  \end{itemize}
     273  \item We don't need yet another toolkit \texttrademark
     274\end{itemize}
    197275\end{frame}
    198276
     
    200278\begin{frame}
    201279\frametitle{Window Manager}
    202         \begin{itemize}
    203       \item the open client windows
    204       \item the client stacking order
    205       \item the client to virtual desktop assignment
    206       \item the session
    207       \item multiple screens
    208       \item client decorations
    209       \item ...
    210         \end{itemize}
     280\begin{itemize}
     281  \item the open client windows
     282  \item the client stacking order
     283  \item the client to virtual desktop assignment
     284  \item the session
     285  \item multiple screens
     286  \item client decorations
     287  \item ...
     288\end{itemize}
    211289\end{frame}
    212290
     
    214292\begin{frame}
    215293\frametitle{IOProc Replacement}
    216         The OS/2 way to abstract codecs and such stuff is quite unique
    217         \begin{itemize}
    218                 \item see \it{IOProc Replacement} presentation
    219         \end{itemize}
     294The OS/2 way to abstract codecs and such stuff is quite unique
     295\begin{itemize}
     296  \item see \it{IOProc Replacement} presentation
     297\end{itemize}
    220298\end{frame}
    221299
     
    225303\begin{frame}
    226304\frametitle{Motivation}
    227         \begin{itemize}
    228       \item OpenGL is the standard nowadays, only MS is doing their own game mit DirectX
    229       \item OpenGL allows fancy stuff like blending and 3D effects, no fun on 2D Hardware
    230       \item powerful API
    231       \item MacOS X is using it as backend, Xorg Project is moving towards OpenGL as well
    232         \end{itemize}
     305\begin{itemize}
     306  \item OpenGL is the standard nowadays, only MS is doing their own game mit DirectX
     307  \item OpenGL allows fancy stuff like blending and 3D effects, no fun on 2D Hardware
     308  \item powerful API
     309  \item MacOS X is using it as backend, Xorg Project is moving towards OpenGL as well
     310\end{itemize}
    233311\end{frame}
    234312
     
    236314\begin{frame}
    237315\frametitle{Options Today}
    238         \begin{itemize}
    239       \item DirectX based Device Drivers - proprietary, binary only and not OpenGL
    240       \item Xorg device driver backend, open source and used on most Unix platforms, supports OpenGL for new cards (ATI and Nvidia)
    241       \item SNAP does not have OpenGL and we don't see that changing in the near future
    242     \end{itemize}
    243     Our choice should be Xorg Device Driver backend
     316\begin{itemize}
     317  \item DirectX based Device Drivers - proprietary, binary only and not OpenGL
     318  \item Xorg device driver backend, open source and used on most Unix platforms, supports OpenGL for new cards (ATI and Nvidia)
     319  \item SNAP does not have OpenGL and we don't see that changing in the near future
     320\end{itemize}
     321Our choice should be Xorg Device Driver backend
    244322\end{frame}
    245323
     
    247325\begin{frame}
    248326\frametitle{Xorg OpenGL Design}
    249         \begin{columns}
    250                 \column[T]{5cm}
    251                         \includegraphics[width=3cm]{ogl-backend.pdf}
    252                 \column{5cm}
    253                         Simplified design of the Xorg OpenGL backend (taken from official docs), Xlib stripped out
    254         \end{columns}
     327\begin{columns}
     328\column[T]{5cm}
     329%                       \includegraphics[width=3cm]{ogl-backend.pdf}
     330\column{5cm}
     331Simplified design of the Xorg OpenGL backend (taken from official docs), Xlib stripped out
     332\end{columns}
    255333\end{frame}
    256334
     
    259337\begin{frame}
    260338\frametitle{Some Ideas}
    261         People do ask for binary compatibility. We see the following option:
    262         \begin{itemize}
    263       \item use a pure VM based solution - easy and will work well, already possible
    264       \item rewrite the whole OS as proposed by some people - unrealistic, waste of ressources
    265       \item implement a minimal OS/2 personality on top of an existing kernel and get binary compatibility to work
    266         \end{itemize}
     339People do ask for binary compatibility. We see the following option:
     340\begin{itemize}
     341  \item use a pure VM based solution - easy and will work well, already possible
     342  \item rewrite the whole OS as proposed by some people - unrealistic, waste of ressources
     343  \item implement a minimal OS/2 personality on top of an existing kernel and get binary compatibility to work
     344\end{itemize}
    267345\end{frame}
    268346
     
    270348\begin{frame}
    271349\frametitle{OS/2 OS Personality}
    272         To get a minimal OS/2 personality to work we would have to implement:
    273         \begin{itemize}
    274       \item DOS*, MOU*, KBD* and VIO* API's
    275       \item LX loader
    276       \item GRADD driver for OpenGL backend
    277       \item what is missing?
    278     \end{itemize}
    279         Some things exist, like JdeBP - unfortunately not open source
     350To get a minimal OS/2 personality to work we would have to implement:
     351\begin{itemize}
     352  \item DOS*, MOU*, KBD* and VIO* API's
     353  \item LX loader
     354  \item GRADD driver for OpenGL backend
     355  \item what is missing?
     356\end{itemize}
     357Some things exist, like JdeBP - unfortunately not open source
    280358\end{frame}
    281359
     
    283361\begin{frame}
    284362\frametitle{GRADD on OpenGL}
    285         \begin{columns}
    286                 \column{3cm}
    287                         \includegraphics[scale=0.3]{ogl-gradd.pdf}
    288                 \column{6cm}
    289                         \begin{itemize}
    290               \item OpenGL GRADD driver could be  used on OS/2 already, Xorg should work (with some effort)
    291               \item As soon as a OS/2 personality would work, one could migrate to the new kernel
    292             \end{itemize}
    293         \end{columns}
     363\begin{columns}
     364\column{3cm}
     365%                       \includegraphics[scale=0.3]{ogl-gradd.pdf}
     366\column{6cm}
     367\begin{itemize}
     368  \item OpenGL GRADD driver could be  used on OS/2 already, Xorg should work (with some effort)
     369  \item As soon as a OS/2 personality would work, one could migrate to the new kernel
     370\end{itemize}
     371\end{columns}
    294372\end{frame}
    295373
     
    300378\begin{frame}
    301379\frametitle{Documentation}
    302         Many developers complain about the quality of documentation of some open source projects
    303         \begin{itemize}
    304                 \item Apple provides very good API docs \& tutorials for Darwin
    305                 \item we must provide that as well, right from the beginning
    306                 \item it should be very easy for new people to get an overview of the projects
    307                 \item see How to organize netlabs.org Software Projects presentation
    308         \end{itemize}
     380Many developers complain about the quality of documentation of some open source projects
     381\begin{itemize}
     382  \item Apple provides very good API docs \& tutorials for Darwin
     383  \item we must provide that as well, right from the beginning
     384  \item it should be very easy for new people to get an overview of the projects
     385  \item see How to organize netlabs.org Software Projects presentation
     386\end{itemize}
    309387\end{frame}
    310388
     
    312390\begin{frame}
    313391\frametitle{Coding Guidelines}
    314         \begin{itemize}
    315                 \item CUA, see http://en.wikipedia.org/wiki/Common\_User\_Access
    316                 \item consistent class \& method names (see Darwin Kernel Programming Guide)
    317                 \item Subversion for sourcecode management
    318                 \item TRAC for milestones, bugs, ToDos, source browsing
    319                 \item see http://svn.netlabs.org/libc as an example
    320                 \item goal: make it easy for new developers to join the projects
    321         \end{itemize}
     392\begin{itemize}
     393  \item CUA, see http://en.wikipedia.org/wiki/Common\_User\_Access
     394  \item consistent class \& method names (see Darwin Kernel Programming Guide)
     395  \item Subversion for sourcecode management
     396  \item TRAC for milestones, bugs, ToDos, source browsing
     397  \item see http://svn.netlabs.org/libc as an example
     398  \item goal: make it easy for new developers to join the projects
     399\end{itemize}
    322400\end{frame}
    323401
     
    325403\begin{frame}
    326404\frametitle{License}
    327         \begin{itemize}
    328                 \item we do not want to use (L)GPL for our own code, APL or MPL are candidates
    329                 \item the object model allows binary code, GPL would make that difficult
    330                 \item we might use (L)GPLed code for parts when it makes sense to do that
    331                 \item goal: make the project attractive for commercial vendors right from the beginning
    332         \end{itemize}
     405\begin{itemize}
     406  \item we do not want to use (L)GPL for our own code, APL or MPL are candidates
     407  \item the object model allows binary code, GPL would make that difficult
     408  \item we might use (L)GPLed code for parts when it makes sense to do that
     409  \item goal: make the project attractive for commercial vendors right from the beginning
     410\end{itemize}
    333411\end{frame}
    334412
     
    337415\begin{frame}
    338416\frametitle{Next Steps}
    339         We try to attract developers at this stage already:
    340         \begin{itemize}
    341                 \item build environment on OS/2
    342                 \item GTK+ for OS/2 (via Everblue)
    343                 \item build environment on Linux
    344                 \item more? FreeBSD, MacOS X, Solaris etc volunteers needed :)
    345                 \item mailinglist for discussions
    346                 \item The Design of Voyager - online design document
    347         \end{itemize}
    348         http://wiki.netlabs.org/index.php/Voyager has more information!
     417We try to attract developers at this stage already:
     418\begin{itemize}
     419  \item build environment on OS/2
     420  \item GTK+ for OS/2 (via Everblue)
     421  \item build environment on Linux
     422  \item more? FreeBSD, MacOS X, Solaris etc volunteers needed :)
     423  \item mailinglist for discussions
     424  \item The Design of Voyager - online design document
     425\end{itemize}
     426http://wiki.netlabs.org/index.php/Voyager has more information!
    349427\end{frame}
    350428
     
    364442\frametitle{Join the Project}
    365443\begin{itemize}
    366   \item check the Voyager Wiki & FAQ, monitor netlabs.org pages
    367   \item join the Voyager Mailinglist at 
    368   \item join the #netlabs IRC channel (see http://www.ecomstation.com/chat.phtml)
     444  \item check the Voyager Wiki and FAQ, monitor netlabs.org pages
     445  \item join the Voyager Mailinglist at
     446  \item join the \#netlabs IRC channel (see http://www.ecomstation.com/chat.phtml)
    369447\end{itemize}
    370448\end{frame}
Note: See TracChangeset for help on using the changeset viewer.