NetBSD Wiki/users/asau/ desktop

Notes on Desktop Project

Some links on Desktop Project

Wiki page with project ideas vanished. Someone has to dig it out.

Opinions

I've discussed the state of Desktop NetBSD Project (DNP) with various developers on IRC and in mail, and I've received different opinions on how developers view it.

I shall not discuss problems arising from lack of hardware drivers, most notably network interfaces, wireless and "wireful," and graphical adapters. I'm concentrating on more general questions here.

Binary packages

One of perceived problems (mbalmer) is that we don't have any toolkit for graphical user interfaces in base, and thus we don't have any chance to write anything with GUI. It is opined that the lack of applications readily available (that use this toolkit) is less important; since there's no toolkit, no applications are available.

Another perceived problem is lack of binary package updates in pkgsrc. I still don't understand what exactly is the problem here, and nobody cared to provide elaborate explanation what it is. We have several different ways to manage software installations using binary packages. Besides using pkgsrc in a way to reuse binary packages ("bin-install" in DEPENDS_TARGET), there exist pkg_chk with support for binary updates, and there exists pkg_rolling-replace, which, I think, can be set up to reuse binary packages as well.

My perception of this "binary packages problem" is that it is imaginary. I've heard some loud praises of pkgin, but I haven't heard more than several voices. Thus I'd rather attribute this problem either to the lack of experience, or to the lack of documentation, or very scarce publicity rather than lack of support. I don't deny though, that there exist real problems which may prevent users from using pkgsrc effectively.

X11

Tobias Nygren (tnn) suggested idea that removing X.org from base can free human resources and help development of more coherent system.

Indeed, moving base X11 version into pkgsrc has brings at least one major benefit: it is much easier to update a package than part of base system. Also, pkgsrc has much shorter release cycle, a quarter rather than two or three years. This means that developers can spend their time more effectively, they can save time otherwise spent in adaptation of new packages to older X.org libraries, drivers, or applications as found in older NetBSD releases.

It was argued (joerg) that there're very few sensible reasons to continue development of base X.org, one of them is cross-compilation, another one is ease of development. pkgsrc provides some cross-compilation support for quite a long time; there exist documents describing how to utilise it, and one of them addresses cross-compilation of (modular) X.org specifically. Thus the only reason remains: ease of development.

I've heard two different opinions related to the ease of development. David Holland pointed out that we need topic-oriented patches in pkgsrc; this needs pkgsrc tools with functionality similar like quilt. Tobias Nygren expressed more radical view, that convenience of two or three developers shouldn't hold the whole project.

It should be possible to help the transition by using support for CVS-based packages from pkgsrc-WIP. In my opinion, this could be used to help X.org hackers working with CVS X.org version (xsrc module) during development cycle. NetBSD could distribute its own X.org version for some time, which could co-exist with pkgsrc's version for some time. This idea met rather strong opposition, but I don't really insist on performing transition exactly this way.

Applications

Priorities

It would be nice to have a list of important packages.

While sometimes it may be hard to come to consensus, there exist packages which are unique (Firefox, OpenOffice) or where there're few important alternatives. A (prioritized) list of them would be nice to have.

An approximation of it could be a list of packages most used by users.

Each quarter we ask users to provide information on installed packages:

"We'd also really appreciate it if people would install the pkgsrc/pkgtools/pkgsurvey package, and then run the pkgsurvey script for us. This will forward us a list of the packages installed on that machine, and the operating system and release level of the operating system. The results will be kept confidential, but the output will help us analyse the packages that are most used."

It is not clear

Perhaps we should publish it or start publishing it in future.

Release cycle

We need someone running pkgsrc bulk builds from current tree before freeze.

We don't even see build problems before first bulk build results, which appear closer to planned end of freeze. Sure, knowing of problem existance doesn't automatically entail quick fix. But we don't even know that the problem is there at the first place. (E.g. in 2010Q4 freeze the problem with renderproto package was discovered 3 days before the freeze ended.)

We need pkgsrc bulk builds with modular X.org.

In many cases base X.org is too old to provide necessary hardware support, significant number of users are forced to use pkgsrc X.org.

Organisation

It is obvious from above, that many problems need organised effort to be solved. Some of them are rather large to be worked on singlehandedly, others require cooperation of some other developers or even users.

It isn't clear if we can get X.org out of base in realistic future, since it requires cooperation of unnamed X.org hackers and, perhaps and most possibly, some other developers.

It isn't clear if we can get realistic picture of pkgsrc usage at all, since it requires cooperation of users, at the very least.

It isn't yet clear if we can get realistic description of use cases of binary packages let alone improve anything in this area. This requires rather long period of maintaining different systems in different ways and by different people.

What is clear, in my opinion, is that we have organisational problems and very passive community. There's very strong faction of developers and users who want Unix as it was decades ago.

Unsorted/unprocessed

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  73 (X_GetImage)
Add a comment
Last edited late Saturday evening, February 12th, 2011
Preferences | Logout