1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
|
Niches for the Hurd
===================
In the bug-hud mailinglist we did a search for niches where the Hurd is *the biggest
fish in the pond*.
This search was segmented into four distinct phases, three of them major:
- Brainstorm
- Reality check: can already do vs. could be used for
- Turn ideas into applications
- Find a compromise -> About which niches should we talk in the wiki?
Brainstorm
----------
"Which niches could there be for the Hurd?"
### Basic Results
The result is a mix of target groups,
nice features and options of the Hurd, reasons for running a Hurd and areas where
the Hurd offers advantages:
#### Nice features and options the Hurd offers
- Give back power to users: arbitrary mounts, subhurds
- Nice features: dpkg -iO ftp://foo/bar/*.deb
- Easier access to low-level functions
- Advanced lightweight virtualization
- operating system study purposes as its done with minix
- The possibility to create more efficient and powerful desktop environments
- Having a _complete_ GNU System
- All-in-one out-of-the-box distro running a webserver for crash-proof operation.
#### Target groups and strong environments
- Tinkerers who like its design.
- multicore-systems
### The keyphrases in more detail or with additional ideas
#### Give back power to users: arbitrary mounts, subhurds
Simpler virtual computing environments - no need to setup XEN, everyone can
just open up his/her computer for someone else by creating a new user account,
and the other one can login and easily adapt the system for his/her own needs.
If most systems just differ by the translators setup on them, people could
even transfer their whole environment from one computer to another one without
needing root access or more root interaction than creating a new user account.
"I want my tools" -> "no problem, just setup your translators".
Also it would be possible to just open an account for stuff like joining the
"World Community Grid" allowing for easier sharing of CPU time.
#### Easier access to low-level functions
One important use is for very technical people, who don't always go with
standard solutions, but rather use new approaches to best solve their
problems, and will often find traditional kernels too limiting.
Another interesting aspect is application development: With the easily
customized/extended system functionality, and the ability to contain
such customizations in subenvironments, I believe that Hurd offers a
good platform for much more efficient development of complex
applications. Application developers can just introduce the desired
mechanisms on a very low level, instead of building around existing
abstractions. The extensible filesystem in particular seems extremely
helpful as a powerful, intuitive and transparent communication
mechanism, which allows creating truly modular applications.
#### Advanced lightweight virtualization
There is also the whole area I called "advanced lightweight
virtualization" (see
http://tri-ceps.blogspot.com/2007/10/advanced-lightweight-virtualization.html
), i.e. the ability to create various kinds of interesting
subenvironments. Many use cases are covered by much bigger fish; but the
flexibility we offer here could still be interesting: I think the middle
grounds we cover between directly running applications, and full
isolation through containers or VMs, are quite unique. This could
simplify management of demanding applications for example, by partially
isolating them from other applications and the main system, and thus
reducing incompatibilities. Creating lightweight software appliances
sounds like an interesting option.
#### The possibility to create more efficient and powerful desktop environments
While I believe this can be applied to any kind of applications, I'm
personally most interested in more efficient and powerful desktop
environments -- these considerations are in fact what got me seriously
interested in the Hurd.
Even more specifically, I've done most considerations (though by far not
all) on modular web browsing environments. Those interested can read up
some of my thoughts on this:
http://sourceforge.net/mailarchive/message.php?msg_name=20080909073154.GB821%40alien.local
(Just skip the text mode browsing stuff -- the relevant part is the long
monologue at the end... I really should put these ideas into my blog.)
#### Nice features
Another example of features which would be easily possible with the Hurd:
* media-player translator:
- settrans play /hurd/mediaplayer_play
- cp song1.ogg song2.ogg play
- # -> files get buffered and played.
or even:
* cp ftp://foo/bar/ogg play
that's KDEs fabled network transparency on the shell level.
Reality check
-------------
Check which of the ideas can already be done easily with the Hurd in its current
state, which ones are a bit more complex but already possible, which ones need a bit
of coding (could be accomplished in a few months judging from the current speed of
development), which ones need a lot of work (or fundamental changes) and which ones
aren't possible.
### Already possible and easy
### Already possible but complex or underdocumented
### Need a few month of coding
### Need a lot of coding or fundamental changes
### Unfeasible ideas
Applications
------------
A minor phase, which will surely be interleaved with the others: Making the ideas
tangible to turn them into ways how people can use the Hurd.
"Hey, look, this is the Hurd. You can use it like this to do that which you can't do
as well/easily/elegantly in any other way."
### Applications for private use
### Applications for companies
Compromise
----------
For each niche:
- How many additional programmers can the Hurd get in this niche?
- How does choosing this niche limit the flexibility of further development?
- Can we easily move on to conquering the next niche once we got this one?
- What should the Hurd accomplish on the long term? Which possible niches help that?
Each participant:
- Give your personal priorities to the niches:
* Must -> all of these of all developers must be included;
remember that at most 3 to 4 ideas can be conveyed in any text.
* Should -> The number of shoulds can be used for ranking and similar.
("must", because in a community people can do what they perceive as important, and
telling someone to stop what he's doing is no option (in my opinion))
|
