[Desktop_architects] klik+autopackage: klik slides in ASCII (was:
Notes from autopackage author)
Kurt Pfeifle
k1pfeifle at gmx.net
Sat Dec 31 23:42:27 PST 2005
I received a mail from someone who said that the klik slides (as
PDF) are no longer retrievable from the OSDL website. So I'll now
provide an ASCII copy of these (only 4 pages) of slides, for the
sake of this discussion.
--------------------------------------------------------------------
Slide 1:
--------
klik: Focus Areas
--------------------------------------------------------------------
(We are addressing these gaps. We regard current achievements as
"usable alpha quality")
--------------------------------------------------------------------
- Must be '1-click' installation
(really: 'Don't install, just copy' 1 file)
- Must be even more easy than Windows ('Linux for grandmas')
- Must follow a '1 application == 1 file' paradigm
- Simply move 1 file to a different computer to use this app there
- Must run from anywhere (USB pendrive, CD)
- Must allow use of multiple versions of same app on one system
- Must not require root privilege to 'install' new software/versions
- Must not interfere w. system package manager (rpm, apt, yast, ...)
- Must not endanger system if a klik 'install' fails (no DLL hell)
- Make 'bleeding edge' apps/developm. versions easily available
(bridge gap between non-technical and technical contributors to FOSS
development projects)
Slide 2:
--------
klik: Challenges
--------------------------------------------------------------------
(What we need getting solved)
--------------------------------------------------------------------
- Support more distros (currently Knoppix, Kanotix, Debian, SUSE)
- Create awareness what klik can do even now for devs and ISVs
- Make Gnome support better, get more cooperation from developers
- ABI incompatibilities are hell for klik, ISVs and 3rd Party Developers
- No more GCC ABI changes with every other 'minor' release!
- Define a standard 'klik base system' across all major Linux distros
(which libs/versions can we assume to be present? -- LSB helps here
once it gets more widely implemented)
- See how common interest with other projects can lead to cooperation
(Autopackage, ZeroInstall, Rox, Gobo,...)
- Leverage new (2.6.14) Kernel features for klik's benefit
(FUSE 'filesystem in userspace' == no more fstab;
9P 'plan 9 protocol' == better support for '1 file/1 app' approach)
- Introduce a concept of security
(signing of klik recipes?, verification of download sources?)
Slide 3:
--------
klik: Dependencies
--------------------------------------------------------------------
(projects and needs from each)
--------------------------------------------------------------------
- GCC Project:
* Provide a longterm ABI stability guarantee
* find way to make backward compatible interoperation in cases
where ABI changes are unavoidable
- Linux distros, LSB:
* help to define and provide a base system of libs and versions
which klik can rely on
* make repackaged .debs & .tgzs work on *.rpm systems and vice
versa (the 'acid test')
- New developers:
* subject script-generated klik recipes to more (human) quality
assurance; comb through 4.000 auto-generated klik recipes to
find failures; track version updates & user feedback
* needs more manpower/developers (fortunately, no hardcore
programming skills are required for klik, advanced user
knowledge is enough to fix failing klik recipes!)
- Potential sponsors:
* help developers f.e. with travel costs to attend important
meetings
* more reliable hardware, bandwidth, uptime, funding for klik
web service
Slide 4:
--------
klik: Follow on Meetings
--------------------------------------------------------------------
(list of orgs and topics)
--------------------------------------------------------------------
- FOSDEM 2006
- LinuxTag 2006 ?
- LWE 2006 in Boston ?
- IRC in #klik on Freenode.net
- http://klik.atekon.de/
Note: these slides were made entirely on a Knoppix system
running from CD by online-fetching and using an OOo-2.0
release prepared by the 'klik://ooo2' recipe
--------------------------------------------------------------------
Cheers,
Kurt
More information about the Desktop_architects
mailing list