import of old now defunct presentation slides svn repo

3 files changed, 695 insertions, 0 deletions

diff --git a/2009/linux-development-model-kr2009/linux-development-model-kr2009.mgp b/2009/linux-development-model-kr2009/linux-development-model-kr2009.mgp
new file mode 100644
index 0000000..3df8d47
--- /dev/null
+++ b/2009/linux-development-model-kr2009/linux-development-model-kr2009.mgp
@@ -0,0 +1,695 @@
+%include "default.mgp"
+%default 1 bgrad
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+%nodefault
+%back "blue"
+
+%center
+%size 7
+
+Introduction to the
+Linux Development Model
+
+
+%center
+%size 4
+by
+
+Harald Welte <hwelte@hmw-consulting.de>
+hmw-consulting / gpl-violations.org / openmoko.org
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+The Linux Development Model 
+Introduction
+
+Who is speaking to you?
+		an independent Free Software developer, consultant and trainer
+		14 years experience using/deploying and developing for Linux on server and workstation
+		10 years professional experience doing Linux system + kernel level development 
+		strong focus on network security and embedded
+		expert in Free and Open Source Software (FOSS) copyright and licensing
+		digital board-level hardware design, esp. embedded systems
+		active developer and contributor to many FOSS projects
+		thus, a techie, who will therefore not have fancy animated slides ;)
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page 
+The Linux Development Model 
+Introduction
+
+
+What is my affiliation?
+		an independent freelancer, not speaking for any comany
+		working in the Free Software community for many years
+		used to be the maintainer of the Linux firewall netfilter/iptables
+		started many Free Software and Open Hardware projects, e.g.
+			OpenEZX - Open Source for Motorola EZX phones
+			OpenPCD/librfid - 13.56MHz RFID stack
+			OpenBeacon - 2.4GHz active RFID
+			gnufiish - Linux for E-TEN PDA-phones
+			OpenBSC - A GSM backend network BSC+MSC+HLR
+		was employee #1 and Lead System Architect (HW+SW) of Openmoko
+		consulting many companies on FOSS development + licensing	
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+What is Free Software?
+
+	Software that is 
+		available in source code
+		is licensed in a way to allow unlimited distribution
+		allows modifications, and distribution of modifications
+		is not freeware, but copyrighted work
+		subject to license conditions, like any proprietary software
+		READ THE LICENSE
+
+What is Open Source?
+		Practically speaking, not much difference
+		Remainder of this presentation will use the term FOSS (Free and Open Source Software)
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+What is the FOSS Community?
+
+	Diverse
+		any individual can contribute
+		no formal membership required
+		every project has it's own culture, rules, ...
+	International
+		the internet boasted FOSS development
+		very common to have developers from all continents closely working together	
+	Evolutionary
+		developers come and go, as their time permits
+		projects evolve over time, based on individual contributions
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+People / Groups involved
+
+	Really depends on size of projects
+	Small projects often a one-man show
+	Bigger project have groups / subgroups
+	Common Terms / Definitions
+		Maintainer
+			The person who formally maintains a project
+		Core Team / Steering Committee
+			A group of skilled developers who make important decisions
+		Subsystem Maintainer
+			Somebody who is responsible for a particular sub-project
+		Developer Community
+			All developers involved with a project
+		User Community
+			Users of the software who often share their experience with others
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Development Process
+
+	"Rough concensus and running code"
+	Decisions made by technically most skilled people
+	Reputation based hierarchy
+	Direct Communication between developers
+	Not always driven by size of a target market
+	Release early, release often
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Motivations (individual)
+
+	gaining reputation (like in the scientific community)
+	(students) gaining development experience with real-world software
+	solving problems that the author encounters on his computer
+	fighting for Free Software as ideology
+	working on exciting technology without having to work at company XYZ
+	work in creative environment with skilled people and no managers ;)
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Motivations (corporate)
+
+	not having to reinvent the wheel
+	if FOSS provides 80% of your problem solution, you just have to add the missing 20%
+	fully customizable, every aspect of the system can be modified/adopted/changed
+	no per-unit royalties
+		be aware, you have more one-time R&D cost
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Who is "The Community"?
+
+
+	Studies show
+		the majority of the Linux kernel code is developed by professional, paid developers
+		most of them work for large IT companies (Intel, Novell, IBM, RedHat, ...)
+		those companies would not invest the development resources if there was no business case for it!
+	So "the community"
+		is not a random collection of individuals scratching their itch
+		but is a group of very prominent professional developers working for some of the biggest IT companies worldwide
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+FOSS Community likes
+
+	generic solutions
+	portable code
+	vendor-independent architecture
+	clean code (coding style!)
+	open standards
+	good technical documentation
+	raw hardware, no bundle of hardware and software sold as solution
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+FOSS Community dislikes
+
+	monopolistic structures
+		e.g. intel-centrism
+	closed 'industry forums' with rediculous fees
+		e.g. Infiniband, SD Card Association
+	standard documents that cost rediculous fees
+	NDA's, if they prevent development of FOSS
+		note: Samsungs manuals now under NDA :(
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Weak Points of FOSS
+
+When FOSS is entirely volunteer-driven
+	often way behind schedule (if there is any)
+	already too late when projects start
+		started when there already is a real need
+	often a lack of (good) documentation
+		programmers write code, not enduser docs...
+	strong in infrastructure, weak in applications
+		traditionally developers interested in very technical stuff
+
+	Thus, FOSS really improves when commercial entities get involved the right way!
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Windows driver development model
+
+
+		MS defines stable APIs and ABIs for drivers and releases SDK (DDK)
+		All interfaces are specified by a single entity
+		The interface between driver and OS core is designed as binary interface
+		Hardware vendors develop drivers for their hardware component
+		Hardware vendors compile and package drivers for their hardware component
+		Hardware vendors sell bundle of hardware and software driver (object code)
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Linux driver development model
+
+
+		A community-driven process creates in-kernel driver API's
+		Drivers are written against those APIs
+		Drivers are submitted to the kernel developes for inclusion into the OS source tree
+		Because all (good) drivers are inside one singe source tree, OS developers can (and will) refine the APIs whenever apropriate
+		There are no stable in-kernel API's, and especially no stable in-kernel ABI's
+		Linux development community releases kernel source code
+		Hardware vendor sells hardware only.  The Windows driver CD is unused.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Linux driver development model
+
+
+		Without proper support from HW vendor, Most hardware drivers are developed by people inside that community
+			sadly most of them have no relation to the HW manufacturer
+			even more sadly, many of them have to work without or with insufficient documentation (reverse engineering)
+
+		Good HW vendors understand this and support Linux properly!
+
+		Linux is a big market by now
+			Servers
+			Embedded devices (est. > 40% of all wifi/dsl router + NAS appliances)
+			Increasingly popular on the Desktop
+			Recently: Netbooks
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Linux driver development model, bad case timeline
+
+
+		Hardware vendor produces and ships hardware 
+		Users end up getting that hardware without any Linux support
+		Somebody will start a driver and inquire about HW docs
+		Hardware vendor doesn't release docs
+		If hardware is popular enough, somebody will start reverse engineering and driver deevlopment
+		With some luck, the driver is actually useable or even finished before the HW product is EOL
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Linux driver development model, good case timeline #1
+
+
+		Hardware vendor starts Linux driver development for new HW during HW R&D
+		Hardware vendor submits Linux driver for review / inclusion into mainline Linux kernel before HW ships
+		User installs HW and has immediate support by current Linux kernel
+		Hardware vendor publicly releases HW docs when the product ships, or even later
+			This enables the community to support/integrate the driver with new interfaces
+			It also enables the community to support hardware post EOL, at a point where the HW vendor 
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Linux driver development model, good case timeline #2
+
+
+		Hardware vendor releases HW documentation during HW R&D or no later than the product start shipping
+		Somebody in the Linux development community might be interested in writing a driver
+			in his spare time because of technical interest in the HW
+			as a paid contractor by the HW vendor
+		In such cases it helps if the HW vendor provides free samples to trustworthy developers
+		That driver is very likely to get merged mainline
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Why submit your code mainline?
+
+	In the PC world
+		Quantity-wise, most users use some Linux distribution
+		Every version of every distribution ships a different Linux kernel version
+		Most end-users are not capable of compiling their own kernel/drives (but way more than you think!)
+		Thus,
+			teaming up with one (or even two, three) Linux distributions only addresses a small segment of the user base
+			distributing your driver independently (bundled with hardware, ...) in a way that is ready-to-use for end-users is a ton of work and almost impossible to get right
+			the preferred option, with the least overhead for both user and HW vendor is to merge the driver mainline.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Why submit your code mainline?
+
+	In the embedded/ARM world
+		there are more customers of your SoC than just the tier-1 customers
+		the small/medium size customers do not qualify for your support
+			but if documentation and/or source is availale, they can still buy and use your product
+		the more developers know your product, the more will recommend it in their companies
+			existing experience with a sertain SoC is very valuable, reduces lead time, helps solving problems quickly
+		there are even way more custom distributions in the embedded world
+			you can never support even the smallest fraction of them
+			but all of them use the mainline kernel as base version
+			if your driver + support code is in mainline, all of the distributions will easily run on your SoCs
+		keeping all code in mainline reduces fragmentation of the codebase
+		keeping all code in mainline means you get help with porting and integration with new kernel changes
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Samsung LSI is part of the community
+
+
+Samsung LSI is part of the community
+	Linux exists because of massive, industry-wide collaboration
+	Only because everyone contributes, Linux Grows
+	Everyone helps to create a better platform
+	If SLSI Linux drivers/support is good, Linux customers prefer SLSI over other vendors
+	Don't only create drivers, but infrastructure (core OS/kernel)
+	Every company does its small part of the Linux kernel R&D
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+How to submit your code mainline?
+
+
+		The FOSS code quality requirements are _extremely_ high
+		It's not a surprise that Linux is generally considered much more stable than competitors
+		Code needs to be maintainable
+			Linux supports old hardware ages beyond their EOL
+			Thin of MCA, VLB, Decnet, IPX networking, ...
+		So unless you respect the development culture, your code is likely to get rejected!
+		Post your driver at the respective mailing lists
+		Release early, release often
+		Don't hesitate to ask for feedback and suggestions if you are not 100% sure what is the right way to implement a certain feature
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Techncal differences
+
+
+		In the MS world, almost all interfaces are MS defined
+		In the Linux world, Linux is only the OS kernel
+		All other interfaces are specified by their respective projects
+		Often there are many alternatives, e.g. for graphical drivers
+			X.org project (X11 window server, typical desktop)
+			DirectFB project (popular in embedded devices like TV set-top boxes)
+			Qt/Embedded (popular in certain proprietary Linux-based mobile phones)
+		Every project has it's own culture, including but not limited to
+			coding style
+			patch submission guidelines
+			software license
+			communication methods
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Practical Rules
+
+	1. Much more communication
+		It's not a consumer/producer model, but cooperative!
+		Before you start implementation, talk to project maintainers
+			It's likely that someone has tried a similar thing before
+			It's likely that project maintainers have already an idea how to proceed with implementation
+			Avoid later hazzles when you want your code merged upstream
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Practical Rules
+
+	2. Interfaces
+		If there is a standard interface, use it
+		If insufficient: Don't invent new interfaces, try to extend existing ones
+		If there is an existing interface in a later (e.g. development) release upstream, backport that interface
+		Don't be afraid to touch API's if they're inefficient
+			Remember, you have the source and _can_ change them
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Practical Rules
+
+	3. Merge your code upstream
+		Initially you basically have to create a fork
+		Development of upsteram project continues sometimes at high speed
+		If you keep it out of tree for too long time, conflicts arise
+		Submissions might get rejected in the first round
+			Cleanups needed, in coordination with upstream project
+			Code will eventually get merged
+		No further maintainance needed for synchronization between your contribution and the ongoing upstream development
+		Don't be surprised if your code won't be accepted if you didn't discuss it with maintainers upfront and they don't like your implementation
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Practical Rules
+
+	4. Write portable code
+		don't assume you're on 32bit CPU
+		don't assume you're on little endian
+		if you use assembly optimized code, put it in a self-contained module
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Practical Rules
+
+	5. Binary-only software will not be accepted
+		yes, there are corner cases like FCC regulation on softradios
+		but as a general rule of thumb, the community will not consider object code as a solution to any problem
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Practical Rules
+
+	6. Avoid fancy business models
+		If you ship the same hardware with two different drivers (half featured and full-featured), any free software will likely make full features available on that hardware.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Practical Rules
+
+	7. Show your support for the Community
+		By visibly contributing to the project
+			discussions
+			code
+			equipment
+		By funding developer meetings
+		By making rebated hardware offers to developers
+		By contracting / sponsoring / hiring developers from the community
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Distribution Model
+The "Linux" System
+
+
+	What is a so-called Linux system
+		The Linux operating system kernel
+		The X.org X11 windowing system
+		Various non-graphical system-level software
+		A variety of different desktop systems (KDE, Gnome)
+		A variety of GUI programs
+
+	In reality, this is a "Linux Distribution"
+		sometimes referred to as "GNU/Linux System"
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Distribution Model
+Entities in the Linux system
+
+
+	Free Software projects and their developers
+	So-called "Distributors" who create "Distributions"
+	Contributors
+	Users
+	Vendors of proprietary Linux software
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Distribution Model
+FOSS Projects
+
+
+	Free Software projects and their developers
+		Linux Kernel, Xorg, KDE, Gnome, Apache, Samba
+
+	Role
+		Development of the individual program
+		Very focused on their individual project
+		Portability and flexibility usually main concern
+		Interact based on practical neccessity
+
+		Usually they just provide source code, no object code
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Distribution Model
+Distributions
+
+
+	Distributions (both commercial and community based)
+		Debian, Ubuntu, SuSE, Fedora, RedHat, Mandriva, ...
+
+	Role
+		Aggregate thousands of individual FOSS programs
+		Find stable and compatible versions of those programs
+		Do 'software system integration'
+		Offer bianary software packages and installation media
+		Offer (security) updates to their users
+		Offer free/best effort or commercial support for professional users
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Distribution Model
+Contributors
+
+
+	Contributors
+		are people not part of a specific development team
+		usually "very active users" of a particular program
+
+	Role
+		find / document / fix bugs that they find themselves
+		contribute bug reports, documentation or code
+		participate in discussion on features or problems
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Distribution Model
+Users
+
+
+	Users
+		are people just using software
+
+	Role
+		using programs
+		they usually just install+use a particular distribution
+		they typically do not download+install software directly from the particular software project
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Distribution Model
+Vendors of Proprietary Software
+
+
+	Vendors of proprietary Software (e.g. Oracle)
+		remain a small niche in the Linux world
+		usually driven by a very specific industry
+		they can exist because kernel/userspace ABI is stable!
+
+	Role
+		feed-back some of their requirements to the Open Source developers
+		help the operating sytestem development to make sure OS is good for them
+
+	Note: This is not applicable for driver development!
+		drivers are in the Linux kernel, not userspace
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Distribution Model
+Collaborative Software Development
+
+
+	How do projects communicate internally
+		Very rarely in physical meetings (people live too far apart)
+		Very rarely in phone conferences (people live in different timezones)
+		It's almost entirely text-based (e-mails, sometimes chat system)
+
+	Mailing Lists
+		Usually every project has at least one list
+		Often there are separate lists for developers and users
+		Participation in the mailing list (reading and posting) open to anyone
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Distribution Model
+Collaborative Software Development
+
+
+	Project Management / Decision making
+		usually there's a small group (coreteam) or one leader
+		he is often the creator of the program, or it's maintainer
+		he has the final say in what is accepted or not
+		larger projects have 'subsystem maintainers' with delegated authority
+		so quite often, the structure is more hierarchical than people believe
+		rough concensus and running code
+		
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Distribution Model
+Motivation of Software Developers
+
+
+	Why do developers work on a FOSS project
+		because they're interested in a certain area
+		because it's fun to learn and improve skills
+		because it's fun to co-work with world-class hackers
+
+	How do people make money
+		often by offering commercial support for their software
+		by offering poerting or system integration
+		by offering development of extensions/modifications
+		by working for a company that uses/needs that program
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Distribution Model
+Linux and binary compatibility
+
+
+	Linux and binary compatibility
+		Drivers usually run inside the OS kernel
+		Linux doesn't have any stable kernel-internal ABI
+		Linux doesn't even have stable kernel-internal API
+		Only the ABI to userspace is stable/fixed
+
+	Thus, every minor Linux release can break in-kernel ABI+API
+	This is why binary-only drivers simply don't work!
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Distribution Model
+Linux and binary compatibility
+
+
+	I still don't believe! Why not binary-only drivers
+		because every distribution has a different base kernel revision
+		because every distribution can change their kernel version e.g. as part of a security update
+		users will end up in incompatibility nightmare
+		so please, don't do it.  It will never work for the majority of your users
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Distribution Model
+Implications for Hardware Vendors
+
+
+	Implications for Hardware Vendors
+		Users are used to get all software from the distribution
+		They are not used to separate vendor-provided driver CD's
+		Thus, drivers need to be in the distribution
+		Goal: getting drivers into the distrubution
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Distribution Model
+Implications for Hardware Vendors
+
+
+	How to get drivers into distributions?
+		You can talk directly to the distributions
+		But: Their code architecture/style requirements are high
+		But: Many of them do not accept binary-only drivers
+		But: There are many, many distributions.
+		Linux is only a certain portion of the market
+			Every distribution is only a small portion of the portion
+			Thus, new goal: Get your drivers in the mainline project
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Distribution Model
+Implications for Hardware Vendors
+
+
+	Getting drivers in the mainline project
+		ensures that all distributions will pick up the driver
+		ensures out-of-the box support of your hardware on all distributions
+		ensures best user experience
+		ensures least internal R&D resources
+			no need to provide binaries for 3 versions of 5 distributions
+			no need to constantly try to catch up with distribution kernel updates
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%page
+The Linux Development Model 
+Thanks
+
+
+	Please share your questions and doubts now!
+
+	Please contact me at any later point, if you have questions
+
+	I'm here to help Samsung!
+
+	hwelte@hmw-consulting.de
+
+%center
+Thanks for your Attention
diff --git a/2009/linux-development-model-kr2009/linux-development-model-kr2009.pdf b/2009/linux-development-model-kr2009/linux-development-model-kr2009.pdf
new file mode 100644
index 0000000..5550595
--- /dev/null
+++ b/2009/linux-development-model-kr2009/linux-development-model-kr2009.pdf
diff --git a/2009/linux-development-model-kr2009/linux-development-model-kr2009_bw.pdf b/2009/linux-development-model-kr2009/linux-development-model-kr2009_bw.pdf
new file mode 100644
index 0000000..b43711b
--- /dev/null
+++ b/2009/linux-development-model-kr2009/linux-development-model-kr2009_bw.pdf