Return to desktop.mdwn CVS log

Up to [NetBSD Developer Wiki] / wikisrc / users / asau

Link to remote desktop software page.

    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
    8: * [[pkgsrc/remote]] - remote desktop software
    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
  112: 
  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>