Annotation of wikisrc/users/asau/desktop.mdwn, revision 1.3

1.1       asau        1: # Notes on Desktop Project
                      2: 
                      3: ## Some links on Desktop Project
                      4: 
                      5: * <http://mail-index.netbsd.org/netbsd-desktop>
                      6: * <http://www.wired.com/news/technology/0,70037-0.html> - something to muse on
                      7: * <http://wiki.netbsd.org/projects/code-in/> - parts of general plan
1.3     ! asau        8: * [[pkgsrc/remote]] - remote desktop software
1.1       asau        9: 
                     10: Wiki page with project ideas vanished. Someone has to dig it out.
                     11: 
                     12: 
                     13: ## Opinions
                     14: 
                     15: I've discussed the state of Desktop NetBSD Project (DNP)
                     16: with various developers on IRC and in mail,
                     17: and I've received different opinions on how developers view it.
                     18: 
                     19: I shall not discuss problems arising from lack of hardware drivers,
                     20: most notably network interfaces, wireless and "wireful," and
                     21: graphical adapters.
                     22: I'm concentrating on more general questions here.
                     23: 
                     24: ### Binary packages
                     25: 
                     26: One of perceived problems (mbalmer) is that we don't have
                     27: any toolkit for graphical user interfaces in base, and thus
                     28: we don't have any chance to write anything with GUI.
                     29: It is opined that the lack of applications readily available
                     30: (that use this toolkit) is less important; since there's no
                     31: toolkit, no applications are available.
                     32: 
                     33: Another perceived problem is lack of binary package updates in pkgsrc.
                     34: I still don't understand what exactly is the problem here,
                     35: and nobody cared to provide elaborate explanation what it is.
                     36: We have several different ways to manage software installations
                     37: using binary packages.
                     38: Besides using pkgsrc in a way to reuse binary packages
                     39: ("bin-install" in DEPENDS_TARGET),
                     40: there exist pkg_chk with support for binary updates,
                     41: and there exists pkg_rolling-replace, which, I think,
                     42: can be set up to reuse binary packages as well.
                     43: 
                     44: My perception of this "binary packages problem" is that it is imaginary.
                     45: I've heard some loud praises of pkgin, but I haven't heard more than
                     46: several voices. Thus I'd rather attribute this problem either
                     47: to the lack of experience, or to the lack of documentation,
                     48: or very scarce publicity rather than lack of support.
                     49: I don't deny though, that there exist real problems
                     50: which may prevent users from using pkgsrc effectively.
                     51: 
                     52: ### X11
                     53: 
                     54: Tobias Nygren (tnn) suggested idea that removing X.org from base
                     55: can free human resources and help development of more coherent system.
                     56: 
                     57: Indeed, moving base X11 version into pkgsrc has brings at least one major benefit:
                     58: it is much easier to update a package than part of base system.
                     59: Also, pkgsrc has much shorter release cycle, a quarter rather than
                     60: two or three years. This means that developers can spend their time
                     61: more effectively, they can save time otherwise spent in adaptation
                     62: of new packages to older X.org libraries, drivers, or applications
                     63: as found in older NetBSD releases.
                     64: 
                     65: It was argued (joerg) that there're very few sensible reasons
                     66: to continue development of base X.org, one of them is
                     67: cross-compilation, another one is ease of development.
                     68: pkgsrc provides some cross-compilation support for quite a long time;
                     69: there exist documents describing how to utilise it, and one of them
                     70: addresses cross-compilation of (modular) X.org specifically.
                     71: Thus the only reason remains: ease of development.
                     72: 
                     73: I've heard two different opinions related to the ease of development.
                     74: David Holland pointed out that we need topic-oriented patches in pkgsrc;
                     75: this needs pkgsrc tools with functionality similar like quilt.
                     76: Tobias Nygren expressed more radical view, that
                     77: convenience of two or three developers shouldn't hold the whole project.
                     78: 
                     79: It should be possible to help the transition by using
                     80: support for CVS-based packages from pkgsrc-WIP.
                     81: In my opinion, this could be used to help X.org hackers
                     82: working with CVS X.org version (xsrc module) during development cycle.
                     83: NetBSD could distribute its own X.org version for some time,
                     84: which could co-exist with pkgsrc's version for some time.
                     85: This idea met rather strong opposition,
                     86: but I don't really insist on performing transition exactly this way.
                     87: 
                     88: ### Applications
                     89: 
                     90: #### Priorities
                     91: 
                     92: It would be nice to have a list of important packages.
                     93: 
                     94: While sometimes it may be hard to come to consensus,
                     95: there exist packages which are unique (Firefox, OpenOffice)
                     96: or where there're few important alternatives.
                     97: A (prioritized) list of them would be nice to have.
                     98: 
                     99: 
                    100: An approximation of it could be a list of packages most used by users.
                    101: 
                    102: Each quarter we ask users to provide information on installed packages:
                    103: 
                    104: "We'd also really appreciate it if people would install the
                    105: pkgsrc/pkgtools/pkgsurvey package, and then run the pkgsurvey script for us.
                    106: This will forward us a list of the packages installed on that machine,
                    107: and the operating system and release level of the operating system.
                    108: The results will be kept confidential, but the output will help us analyse
                    109: the packages that are most used."
                    110: 
                    111: It is not clear
1.2       asau      112: 
1.1       asau      113: * why the information is kept secret;
                    114: * if there's enough statistics being gathered;
                    115: * if this information is used at all.
                    116: 
                    117: Perhaps we should publish it or start publishing it in future.
                    118: 
                    119: #### Release cycle
                    120: 
                    121: We need someone running pkgsrc bulk builds from current tree before freeze.
                    122: 
                    123: We don't even see build problems before first bulk build results,
                    124: which appear closer to planned end of freeze.
                    125: Sure, knowing of problem existance doesn't automatically entail quick fix.
                    126: But we don't even know that the problem is there at the first place.
                    127: (E.g. in 2010Q4 freeze the problem with renderproto package
                    128: was discovered 3 days before the freeze ended.)
                    129: 
                    130: 
                    131: We need pkgsrc bulk builds with modular X.org.
                    132: 
                    133: In many cases base X.org is too old to provide necessary hardware support,
                    134: significant number of users are forced to use pkgsrc X.org.
                    135: 
                    136: 
                    137: ### Organisation
                    138: 
                    139: It is obvious from above, that many problems need organised effort to be solved.
                    140: Some of them are rather large to be worked on singlehandedly,
                    141: others require cooperation of some other developers or even users.
                    142: 
                    143: It isn't clear if we can get X.org out of base in realistic future,
                    144: since it requires cooperation of unnamed X.org hackers and, perhaps
                    145: and most possibly, some other developers.
                    146: 
                    147: It isn't clear if we can get realistic picture of pkgsrc usage at all,
                    148: since it requires cooperation of users, at the very least.
                    149: 
                    150: It isn't yet clear if we can get realistic description of use cases
                    151: of binary packages let alone improve anything in this area.
                    152: This requires rather long period of maintaining different systems
                    153: in different ways and by different people.
                    154: 
                    155: What is clear, in my opinion, is that we have organisational problems
                    156: and very passive community. There's very strong faction of developers
                    157: and users who want Unix as it was decades ago.
                    158: 
                    159: 
                    160: ### Unsorted/unprocessed
                    161: 
                    162: * lack of interactivity support in pkgsrc tools
                    163: * NetBSD-specific problems in X.org (possibly connected to 64-bit time_t):
                    164: touchscreen looses ButtonRelease events,
                    165: problems with X_GetImage (in Xnest and other applications, e.g. FriCAS)
                    166: * touchscreen calibration support
                    167: * X server which doesn't need configuration file
                    168: * "Distribuition" based on NetBSD?
                    169: *
                    170: <pre>
                    171: X Error of failed request:  BadMatch (invalid parameter attributes)
                    172:   Major opcode of failed request:  73 (X_GetImage)
                    173: </pre>

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb